February 2013 - ghc-tickets

[GHC] #7662: Improve GC of mutable objects
by GHC 23 Apr '13

23 Apr '13

#7662: Improve GC of mutable objects -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Haskell is a purely functional language at its core, but it can be also used for workloads involving mutation; it is for these workloads that our GC can be pretty poorly tuned (historically, we’ve fixed these issues case-by-case when they were causing problems for users, e.g. #650). Fortunately, the question of generational garbage collection in the face of lots of mutability is a well-studied one (c.f. the JVM) so this bug asks whether or not we can systematically appropriate any of the machinery developed here for GHC. Some ideas include: * Utilizing card marking at the page level for write barriers, instead of our current mutable lists, * Separating mutable and immutable (and lazy) data on the heaps, to make the previous scheme more likely to work well, * Organizing our generations in different pages, so that checking the generation of any object is as simple as a pointer comparison, * Figure out if we can do better than permanently keeping all mutable arrays permanently on the mutable list (which is really killer when you have lots of tiny mutable arrays), * More mutable closure types to remove the indirection that would normally result from an IORef (actually, you can UNPACK these, and I’m not 100% what happens in that case; it depends on how MutVar#s are represented) There’s probably more things but this is just a start to get things rolling. Test cases and benchmarks also appreciated! -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7662> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7606: Stride scheduling for Haskell threads with priorities
by GHC 23 Apr '13

23 Apr '13

#7606: Stride scheduling for Haskell threads with priorities -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Currently, GHC uses a round-robin scheduler for Haskell threads, with some heuristics for when threads should be bumped to the front of the queue. This patch set replaces this scheduler with 'stride scheduling', as described by Waldspurger and Weihl '95, which is an efficient, deterministic method for scheduling processes with differing priorities. Priorities are assigned by giving 'tickets' to threads; a thread with twice as many tickets as another will run twice as often. I’d like to replace the round-robin scheduler completely with this scheduler. Here are nofib benchmarks comparing the old scheduler to the new: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- Min -0.0% -52.2% -18.8% -18.6% -83.1% Max +1.0% +4.2% +4.9% +5.1% +7.7% Geometric Mean +0.1% -2.8% -0.9% -0.9% -2.9% }}} Here are some technical details: * Without any changes to ticket values, scheduling behavior should be functionally identical to round-robin. (By default, new threads, including the IO thread, get allocated the max nubmer of tickets possible.) This is not quite identical, since our heap does not have FIFO property (see below.) * The current patch-set uses a very simple (e.g. undergrad level) resizable-array backed heap to implement the priority queue; we can play some tricks to reduce the memory footprint of the priority queue (e.g. using the container_of macro to eliminate the extra keys store); and a more fancy data structure would make it easier for us to surgically remove entries or reweight them, but I wanted to keep overhead low. If anyone has a pet implementation of priority queues in C feel free to swap it in. Right now, this only affects the uses of promoteInRunQueue() in Messages.c; I still need to check if #3838 has regressed. * We get three new primops: `setTickets#`, `getTickets#` and `modifyTickets#`. We don't support creating threads with specific numbers of tickets (mostly because that would have added an annoyingly large set of extra primops); instead, you're expected to spawn a thread which gets max-ticket allocation, and then weight it down. * `_link` is no longer used for linking TSOs in the run queue. I have tried my best to stamp out any code which operated on this assumption, but I may have missed some. * Modifying a TSO's tickets takes out the scheduler lock; the hope is that this operation is quick and rare enough that a global lock here is not too bad. * We are unfortunately stuck with some magic constants w.r.t. ticket values: 1 << 20 is the maximum number of tickets our implementation is hard-coded to support. * Sleeping and blocked tasks do not get any 'bonus' for being blocked. * In an ideal world, when a thread hits a black hole, it should temporarily give its tickets to the thread evaluating the black hole, so it will unblock more quickly. Unfortunately, implementing this is pretty complicated (the blackhole evaluating thread could die; or it could get stuck on a blackhole itself and need to gift its tickets; it shouldn't be able to give away the tickets it was gifted.) So this implementation leaves that out. Similar semantics for MVars are probably possible, but will require userland assistance too. I haven't prepared a patch to base yet with a user-level API, but here is a proposed draft: {{{ type Tickets = Int -- | Maximum number of tickets we support a thread having. (Currently 2 >> 20) -- Note that this doesn't bound the *global* maximum tickets. maxTickets :: Tickets -- | Changes the number of tickets allocated to a thread. The ticket count must -- not be less than or equal to zero, or greater than maxTickets. (Corresponds -- to setTickets# primop) setTickets :: ThreadId -> Tickets -> IO () -- | Returns the number of tickets currently allocated to a thread. (Corresponds to -- getTickets# primop) getTickets :: ThreadId -> IO Tickets -- | Atomically performs a linear transformation on the number of tickets a thread; -- e.g. scaling the number of tickets by a rational number, adding another fixed -- set of tickets, and then returning the number of 'leftover' tickets from the operation; e.g. -- if the net amount of tickets is reduced, then the returned result is positive; -- if the net amount of tickets is increased, the returned result is negative. -- In the absence of concurrent threads, the following property holds forall -- t, m and x: -- -- do r <- getTickets t -- d <- scaleTickets t m x -- r' <- getTickets t -- return (r == r' + d) -- -- If the scaling would reduce the number of tickets below zero or increase the -- number of tickets beyond maxTickets, this function will instead fail with -- an exception. This function will be subject to some rounding error; powers of two -- are, however, likely to be exact. (Corresponds to modifyTickets# primop; note -- that the sentinel value for failure is maxTickets + 1, since it is impossible for -- a thread's ticket value to change by that much.) modifyTickets :: ThreadId -> Ratio Int -> Tickets -> IO Tickets -- | Forks a new thread, transferring some percentage of tickets from the current -- thread to it (so the net number of tickets stays constant.) Fails if the rational -- is greater than 1 or less than or equal to zero, or if there are not enough tickets -- in the current thread. forkIOWith :: IO a -> Ratio Int -> IO ThreadId }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7606> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 40

[GHC] #7626: Add common utility variants of trace to Debug.Trace
by GHC 21 Apr '13

21 Apr '13

#7626: Add common utility variants of trace to Debug.Trace -----------------------------+---------------------------------------------- Reporter: chrisseaton | Owner: Type: feature request | Status: new Priority: normal | Component: libraries/base Version: 7.6.1 | Keywords: trace Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- As discussed on the libraries list. http://www.haskell.org/pipermail/libraries/2013-January/019319.html 'traceId' traces a value, and then returns that same value. This avoids the common case of 'trace a a'. {{{ traceId :: String -> String traceId a = trace a a }}} 'traceM' runs 'trace' and returns unit in an arbitrary monad. This is useful for writing traces in do-notation, as each can sit on their own line. {{{ traceM :: (Monad m) => String -> m () traceM string = trace string $ return () }}} For example: {{{ ... = do x <- ... traceM $ "x: " ++ show x y <- ... ... }}} That application of 'traceM' there can be temporarily commented out with a simple line comment. Finally, equivalents of 'traceShow' for those two functions. {{{ traceShowId :: (Show a) => a -> a traceShowId a = trace (show a) a }}} {{{ traceShowM :: (Show a, Monad m) => a -> m () traceShowM = traceM . show }}} Advantages: I use these functions in my code all the time. When I discussed it on the libraries list there were several enthusiastic +1s of people doing the same. Disadvantages: The documentation in the patch makes it clear that traceM does not actually add a trace action to the monad you're using, which is a potential point of confusion (http://www.haskell.org/pipermail/libraries/2013-January/019322.html) I had originally suggested that 'traceIO == traceM', but it turns out this is not so. Henning Thielemann suggested that 'traceM' was better achieved with directly using 'trace' and 'printf' (http://www.haskell.org/pipermail/libraries/2013-January/019320.html) Of course, any function can be replaced with its RHS, and whether or not the user uses 'show' or 'printf' or whatever is orthogonal. I haven't written any tests, as it's all output generating code, so I'm really not sure how that's tested in GHC - sorry. Status of patch: Applies against base 3b51b741f45d4d85e79b2128d00479ce230f72f2 and compiles with GHC 388e1e825f79f2d16536fc583a48e5ce9c191b06. I've run a full GHC compile cycle with it without problem. Includes documentation. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7626> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7719: System.Timeout.timeout may leak <<timeout>> exceptions
by GHC 21 Apr '13

21 Apr '13

#7719: System.Timeout.timeout may leak <<timeout>> exceptions -------------------------+-------------------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.7 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- The current implementation of {{{timeout}}} can leak {{{Timeout}}} exceptions if an asynchronous exception is delivered at the wrong time. The most worrysome such case is another {{{Timeout}}} exception raised by surrounding call to {{{timeout}}}. The following program reproduces the issue reliably for me: {{{ import System.Timeout import Control.Monad import Control.Concurrent t d = timeout d $ timeout d $ timeout d $ timeout d $ timeout d $ timeout (10^9) $ threadDelay 100 main = forever $ mapM_ t [1..200] -- > ghc -O2 -rtsopts -threaded --make TT.hs -- > ./TT +RTS -N1 -- TT: <<timeout>> }}} Context: A recent thread on {{{ghc-users}}}, starting with http://www.haskell.org/pipermail/glasgow-haskell- users/2013-February/023811.html, got me thinking about corner cases of timeout handling again. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7719> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #7709: ios patch no 7: Omit ghc-pwd from final stage when cross compiling
by GHC 20 Apr '13

20 Apr '13

#7709: ios patch no 7: Omit ghc-pwd from final stage when cross compiling ------------------------------+--------------------------------------------- Reporter: StephenBlackheath | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: ------------------------------+--------------------------------------------- Without this patch, we get this error when cross compiling: {{{ "cp" -p utils/ghc-pwd/dist-install/build/tmp/ghc-pwd inplace/bin/ghc-pwd cp: utils/ghc-pwd/dist-install/build/tmp/ghc-pwd: No such file or directory make[1]: *** [inplace/bin/ghc-pwd] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7709> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #7638: bindist refers to libgmp.so.3 which is missing on Fedora 17
by GHC 20 Apr '13

20 Apr '13

#7638: bindist refers to libgmp.so.3 which is missing on Fedora 17 ----------------------------+----------------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: None/Unknown | Blockedby: Blocking: | Related: ----------------------------+----------------------------------------------- binary distribution ghc-7.6.2-x86_64-unknown-linux.tar.bz2 contains executable(s) that expect libgmp.so.3 but recent systems (Fedora 17) have libgmp.so.10 instead, and I don't see how I could roll back. No big deal, but each fix requires a recompile (of gmp, of ghc). -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7638> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #7586: :kind command cannot show kind of type synonyms
by GHC 16 Apr '13

16 Apr '13

#7586: :kind command cannot show kind of type synonyms -----------------------------+---------------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The following illustrates the problem: {{{ Prelude> type T a = Int Prelude> :k T <interactive>:1:1: Type synonym `T' should have 1 argument, but has been given none In a type in a GHCi command: T }}} Undoubtedly, T has a kind, and there's no reason to insist that the type given to the :kind command should be fully applied. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7586> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7598: ghc-stage1 generates wrong assembler on StgCmmPrim (operand out of range)
by GHC 14 Apr '13

14 Apr '13

#7598: ghc-stage1 generates wrong assembler on StgCmmPrim (operand out of range) --------------------------------+------------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Linux | Architecture: powerpc Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- Hello, an attempt to compile today GHC HEAD on linux powerpc fails with this message {{{ "inplace/bin/ghc-stage1" -static -H32m -O -package-name ghc-7.7.20130115 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/../rts/dist/build -Icompiler/stage2 -Icompiler/. -Icompiler/parser -Icompiler/utils -optP- DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.17.0 -package array-0.4.0.2 -package base-4.7.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.10.3.0 -package containers-0.5.0.0 -package directory-1.2.0.1 -package filepath-1.3.0.2 -package hoopl-3.10.0.0 -package hpc-0.6.0.1 -package process-1.2.0.0 -package template-haskell-2.9.0.0 -package time-1.4.0.2 -package transformers-0.3.0.0 -package unix-2.6.1.0 -Wall -fno-warn-name-shadowing -XHaskell98 -XNondecreasingIndentation -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O2 -no-user-package-db -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -hisuf hi -osuf o -hcsuf hc -c compiler/codeGen/StgCmmPrim.hs -o compiler/stage2/build/StgCmmPrim.o /tmp/ghc20445_0/ghc20445_0.s: Assembler messages: /tmp/ghc20445_0/ghc20445_0.s:98896:0: Error: operand out of range (0x00000000000081ac is not between 0xffffffffffff8000 and 0x0000000000007ffc) make[1]: *** [compiler/stage2/build/StgCmmPrim.o] Error 1 make: *** [all] Error 2 }}} The platform is 32bit PowerPC running debian wheezy which provides GHC 7.4.1 used for bootstrapping GHC HEAD. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7598> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #7725: Operators without colons
by GHC 13 Apr '13

13 Apr '13

#7725: Operators without colons ----------------------------------------+----------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- This code is accepted: {{{ data A x y = (&) x y }}} but it's wrong - as far as I know operators on the value level are constructors iff they start with a colon `(:&)`. (In fact {{{a = (&)}}} reports "Not in scope: (&)".) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7725> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7724: cross-compile to iOS
by GHC 13 Apr '13

13 Apr '13

#7724: cross-compile to iOS ------------------------------+--------------------------------------------- Reporter: StephenBlackheath | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Other | Architecture: arm Failure: None/Unknown | Blockedby: 7700, 7705, 7707, 7709, 7718, 7720, 7721, 7722 Blocking: | Related: ------------------------------+--------------------------------------------- A bug for the whole task of cross-compiling to iOS, so we can block it by the individual tasks. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7724> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4