May 2013 - ghc-tickets

[GHC] #7763: Resource limits for Haskell
by GHC 17 Jun '13

17 Jun '13

#7763: Resource limits for Haskell -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Component: Profiling Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- {{{ commit 1f5eb79cc278fd64ee3f1f4249ea3b7404f62ba1 Author: Edward Z. Yang <ezyang(a)mit.edu> Date: Thu Mar 7 13:53:31 2013 -0800 Primops and runtime support for space resource limits. This patch adds support for resource limits in Haskell, especially for monitoring and triggering events when portions of Haskell code exceed memory usage and/or allocation. The system is described in more detail at. http://hackage.haskell.org/trac/ghc/wiki/Commentary/ResourceLimits This patch adds the following types: CostCentre# - non-GCd pointer to CostCentre struct CostCentreStack# - non-GCd pointer to CostCentreStack struct Listener# - GC'd object for listening to pointer events and the following primops: ccToAddr addrToCC ccsToAddr addrToCCS newCC# setCCSOf# withCCS# pushCC# queryCCS# listenCCS# unlistenCCS# These previously existing primops have had their types changed, mainly for better type safety (replacing Addr# with CostCentreStack#) getCCSOf# getCurrentCCS# We add the following new RTS options: -hl equivalent to -hc but also keeps census information in- memory for access and does not write out a *.hp file -xf modified cost-centre stack semantics, where function entries never modify the stack (so only CAFs and explicit set CCCS affect cost-centres). To utilize these new features, compile with -prof and run with +RTS -hl -xf }}} See also http://hackage.haskell.org/trac/ghc/wiki/Commentary/ResourceLimits -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7763> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 10

[GHC] #7779: building GHC overwrites the installed package database if GHC_PACKAGE_PATH is set
by GHC 16 Jun '13

16 Jun '13

#7779: building GHC overwrites the installed package database if GHC_PACKAGE_PATH is set -----------------------------+---------------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 7.4.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- When building GHC, if `GHC_PACKAGE_PATH` is set to a single path, then the build process will register packages in that path instead of in the build tree. Since `GHC_PACKAGE_PATH` points to the host compiler's package database, the build system overwrites the host compiler's package database, rendering the host compiler unusable. To reproduce: 1. Get a binary distribution of GHC 7.4.1 and a source distribution of GHC 7.4.2 2. Configure the binary distribution to install in a temporary directory: `./configure --prefix=$HOME/workspace1` 3. Install the binary distribution 4. Set up the environment to use only the installed compiler: `export PATH=$HOME/workspace1/bin:$PATH; export GHC_PACKAGE_PATH=$HOME/workspace1/lib/ghc-7.4.1/package.conf.d` 5. Configure the source distribution to install in a different directory: `./configure --prefix=$HOME/workspace2` 6. Build the source distribution: `make` Building will eventually run commands that modify the package database in `GHC_PACKAGE_PATH`. One of these commands is `"inplace/bin/ghc-pkg" update --force rts/package.conf.inplace`. I confirmed that the database is being modified by making `ghc-pkg` print the name of the file it's about to update. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7779> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 3

[GHC] #7811: intermittent 'unexpected' results of test ghcpkg01
by GHC 16 Jun '13

16 Jun '13

#7811: intermittent 'unexpected' results of test ghcpkg01 -----------------------------+---------------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Component: ghc-pkg Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I get this unexpected error from ghcpkg01 {{{ Actual stderr output differs from expected: ... +WARNING: cache is out of date: localXXX/package.cache + use 'ghc-pkg recache' to fix. }}} when running the full suite, but cannot reproduce it when running just that test; it passes when run individually. (This was also reported in #5503.) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7811> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 2

[GHC] #7836: Runtime failure profiling with +RTS -hc -hbdrag,void
by GHC 16 Jun '13

16 Jun '13

#7836: Runtime failure profiling with +RTS -hc -hbdrag,void -------------------------+-------------------------------------------------- Reporter: hyperthunk | Owner: Type: bug | Status: new Priority: normal | Component: Profiling Version: 7.4.2 | Keywords: profiling osx Os: MacOS X | Architecture: x86 Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- Running the attached program, compiled with "-threaded -Wall -auto-all -caf-all -fforce-recomp -fprof-auto-top -fprof-auto-calls" - with the following flags: +RTS -hc -hbdrag,void -RTS The output is as follows: leaks: internal error: Invalid object in processHeapClosureForDead(): 60 (GHC version 7.4.2 for i386_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7836> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 7

[GHC] #7744: Can't install conduit via cabal-install
by GHC 16 Jun '13

16 Jun '13

#7744: Can't install conduit via cabal-install -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- When I did {{{cabal install hoogle}}} it failed on one of the dependencies, called conduit. Here is the output: {{{ Downloading conduit-1.0.2... Configuring conduit-1.0.2... Building conduit-1.0.2... Preprocessing library conduit-1.0.2... [1 of 7] Compiling Data.Conduit.Internal ( Data/Conduit/Internal.hs, dist/build/Data/Conduit/Internal.o ) [2 of 7] Compiling Data.Conduit.Util ( Data/Conduit/Util.hs, dist/build/Data/Conduit/Util.o ) [3 of 7] Compiling Data.Conduit ( Data/Conduit.hs, dist/build/Data/Conduit.o ) [4 of 7] Compiling Data.Conduit.List ( Data/Conduit/List.hs, dist/build/Data/Conduit/List.o ) [5 of 7] Compiling Data.Conduit.Binary ( Data/Conduit/Binary.hs, dist/build/Data/Conduit/Binary.o ) ghc: internal error: evacuate: strange closure type 8 (GHC version 7.6.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Failed to install conduit-1.0.2 }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7744> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 2

[GHC] #7941: Running 'make maintainer-clean' doesn't remove all build artefacts
by GHC 16 Jun '13

16 Jun '13

#7941: Running 'make maintainer-clean' doesn't remove all build artefacts -----------------------------+---------------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Component: Build System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Running `make maintainer-clean` in the build tree doesn't remove all build artefacts. I'd like to update Makefiles so that these files are removed. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7941> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 7

[GHC] #7847: Maintain per-generation lists of weak pointers
by GHC 15 Jun '13

15 Jun '13

#7847: Maintain per-generation lists of weak pointers -----------------------------------------+---------------------------------- Reporter: akio | Owner: Type: feature request | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time performance bug | Blockedby: Blocking: | Related: -----------------------------------------+---------------------------------- Currently the runtime system keeps a list of all live weak pointers, and traverses it once every (major or minor) GC. This is very slow if the program keeps many weak pointers alive. Some comments in the rts source suggest that it should be using one weak pointer list per generation, so these patches implement that. The attached test program tries to imitate the memory behavior of code that uses a particular FRP library. The patches make the program 3x faster on my machine. One problem I can see with the patches is that it creates a race condition between finalizeForeignPtr and addForeignPtrFinalizer. I'm not even sure what the correct behavior is when addForeignPtrFinalizer is called after finalizerForeinPtr. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7847> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 13

[GHC] #7933: JavaScript Cmm backend
by GHC 15 Jun '13

15 Jun '13

#7933: JavaScript Cmm backend -----------------------------+---------------------------------------------- Reporter: bosu | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I'd like to RFC on the attached patch implementing JavaScript Cmm backend for GHC. It adds -fjavascript compilation option. Calling ghc -fjavascript produces JS in the output file. Otherwise the ghc binary should be fully functional as a native compiler. Thus -fjavascript is similar to -fllvm in spirit. The patch adds HscJavaScript constructor to HscTarget. It is used to dispatch code output to the new JsCodeGen module. Generated JavaScript code relies on the built-in JS garbage collection. JsTransforms module disables GHC Hp and Sp overflow checks. As JavaScript has no pointers, we emulate them using JS closures containing arrays and indices. To distinguish between pointers and scalars we run Hoopl heuristics in PointerMarker module. As in native world, the generated JS object files are to be linked. In order to do this, there is another project, tentatively called Josh[1]. Josh is regular cabalized Haskell binary which links JS object files using function maps provided by GHC. The JavaScript RTS has rts/*.cmm compiled to JavaScript almost as is. In addition there is a handful of handwritten JS code residing in Josh distribution[2]. ghc-prim[3], integer-gmp[4] and base[5] are compiled with small changes. Those changes seem to be orthogonal to the GHC patch. For bootstrap process please see Josh README at github. Josh also includes several tests which work on 32-bit Debian Wheezy. Generated code is in order of 2 MB uncompressed and un-minified. Most of it is in RTS. It compresses very well though (to 150Kb approx). Plenty of low-hanging fruit optimizations are possible. There are plenty caveats to the current patch. It works on 32 bits only. Math is fishy and Integer support is nonexistant. Lots of tests should be imported from GHC, GHCJS, Fay. No Handle based IO works at the moment. No performance tests were done. Despite its shortcomings, the patch is fairly non-invasive, IMHO. It should be noted, that the same approach could work for other GC based platforms (e.g. Java, C#). I'd like to continue working towards merging the patch into GHC, if possible. Could GHC committers provide any guidance of what should be done in order to merge it? [1] https://github.com/bosu/josh [2] https://github.com/bosu/josh/blob/master/etc/ptr.js [3] https://github.com/bosu/ghc-prim [4] https://github.com/bosu/integer-gmp [5] https://github.com/bosu/base -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7933> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 9

[GHC] #7923: Optimization for takeMVar/putMVar when MVar left empty
by GHC 15 Jun '13

15 Jun '13

#7923: Optimization for takeMVar/putMVar when MVar left empty ------------------------------------+--------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- Right now, we always add an MVar to the mutable list when we takeMVar/putMVar. However, this is unnecessary when the MVar is left empty. This patch arranges that we don't add the MVar to the mutable list in those cases. I've validated the patch but haven't checked performance changes yet. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7923> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 5

[GHC] #7843: GHC should be able to list all possible command line options
by GHC 13 Jun '13

13 Jun '13

#7843: GHC should be able to list all possible command line options -----------------------------+---------------------------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Component: Driver Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I would be happy to have automatic completion of command-line options in GHC. For that we need GHC to be able to list all its possible command line options, similarly to cabal's `--list-options` option. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7843> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 17