March 2018 - ghc-tickets

[GHC] #13630: ByteString pinned memory can be leaky
by GHC 04 Jan '19

04 Jan '19

#13630: ByteString pinned memory can be leaky -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- My question on IRC: {{{ How does memory allocation for pinned blocks work? Let's say pinned blocks are 4KB in size, and I allocate first a 3 KB ByteString A and then an 8-byte ByteString B. Now I GC A, no longer need it. Then according to https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC/Pinned "a single pinned object keeps alive the whole block in which it resides", my small ByteString B keeps the entire block alive. But what happens with the 3KB in the front of that block? Will it be re-used by the next ByteString allocation (say 1KB)? In other words, how smart is allocatePinned as an allocator? }}} The answer: {{{ slyfox: nh2: allocatePinned it quite dump. it only allocated from free tail space }}} {{{ nh2: slyfox: that sounds like a huge potential for memory leak then slyfox: yes, fragmentation is quite bad for bytestrings }}} So it seems that I can get into the unfortunate situation where a super short `ByteString` of a few bytes can waste an entire 4 KB block of memory; some migth call this a leak. One idea to solve it seems to be to change standard `ByteStrings` to not pinned, and to allocate pinned ones explicitly when needed. This seems to be an often-discussed topic and not trivial because many `ByteString` functions are implemented using libc FFI functions. However, it seems there will always be _some_ need for pinned memory, so we should better have an efficient way to manage it in any case. Efficient here means, for example, to re-use freed memory inside a block instead of only using free tail space. It seems that `jemalloc` has a feature to use given blocks of memory and provide a `malloc()` functionality inside them: https://stackoverflow.com/questions/30836359/jemalloc-mmap-and-shared- memory Perhaps this could be used to provide GHC with a simple method to use pinned memory more efficiently? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13630> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14797: High-residency modules during GHC build
by GHC 04 Jan '19

04 Jan '19

#14797: High-residency modules during GHC build -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While trying to figure out memory allocation failures on the CI server, I tracked allocations and residency on a per-module basis, and noticed that some modules require a lot more memory to compile than others. I've compiled a digest of the most memory-hungry compilation steps: {{{ "/usr/local/bin/ghc" ... compiler/stage1/build/OptCoercion.o: Max. residency: 991356584 / In use: 2094M "inplace/bin/ghc-stage1" ... compiler/stage2/build/OptCoercion.dyn_o: Max. residency: 714940528 / In use: 1471M "/usr/local/bin/ghc" ... compiler/stage1/build/X86/CodeGen.o: Max. residency: 679947656 / In use: 1497M "inplace/bin/ghc-stage1" ... libraries/Cabal/Cabal/dist- install/build/Distribution/SPDX/LicenseId.dyn_o: Max. residency: 653177496 / In use: 1355M "inplace/bin/ghc-stage1" ... compiler/stage2/build/X86/CodeGen.dyn_o: Max. residency: 641515344 / In use: 1425M "/usr/local/bin/ghc" ... -ilibraries/parsec: Max. residency: 593335568 / In use: 1355M "/usr/local/bin/ghc" ... libraries/Cabal/Cabal/dist- boot/build/Distribution/SPDX/LicenseId.o: Max. residency: 575034968 / In use: 1137M "inplace/bin/ghc-stage1" ... compiler/stage2/build/DynFlags.dyn_o: Max. residency: 402734408 / In use: 1059M "/usr/local/bin/ghc" ... compiler/stage1/build/DynFlags.o: Max. residency: 343154784 / In use: 892M "inplace/bin/ghc-stage1" ... libraries/template-haskell/dist- install/build/Language/Haskell/TH/Syntax.dyn_o: Max. residency: 266744312 / In use: 720M "/usr/local/bin/ghc" ... compiler/stage1/build/Parser.o: Max. residency: 258613584 / In use: 679M "inplace/bin/ghc-stage1" ... compiler/stage2/build/CmmOpt.dyn_o: Max. residency: 254639624 / In use: 568M "inplace/bin/ghc-stage1" ... compiler/stage2/build/Parser.dyn_o: Max. residency: 236774592 / In use: 635M "inplace/bin/ghc-stage1" ... ghc/stage2/build/GHCi/UI.dyn_o: Max. residency: 234055792 / In use: 609M "/usr/local/bin/ghc" ... compiler/stage1/build/HsExpr.o: Max. residency: 233724400 / In use: 657M "/usr/local/bin/ghc" ... compiler/stage1/build/CmmOpt.o: Max. residency: 208378888 / In use: 436M "/usr/local/bin/ghc" ... compiler/stage1/build/HscMain.o: Max. residency: 197177248 / In use: 500M "inplace/bin/ghc-stage1" ... compiler/stage2/build/HsExpr.dyn_o: Max. residency: 192780496 / In use: 521M "inplace/bin/ghc-stage1" ... libraries/Cabal/Cabal/dist- install/build/Distribution/Simple/Setup.dyn_o: Max. residency: 191649952 / In use: 521M "/usr/local/bin/ghc" ... compiler/stage1/build/HsDecls.o: Max. residency: 183441120 / In use: 508M "inplace/bin/ghc-stage1" ... compiler/stage2/build/TcSplice.dyn_o: Max. residency: 176802000 / In use: 445M "inplace/bin/ghc-stage1" ... compiler/stage2/build/TcRnDriver.dyn_o: Max. residency: 172892128 / In use: 458M "inplace/bin/ghc-stage1" ... compiler/stage2/build/HscMain.dyn_o: Max. residency: 172802688 / In use: 470M "inplace/bin/ghc-stage1" ... libraries/ghci/dist- install/build/GHCi/TH/Binary.dyn_o: Max. residency: 169775368 / In use: 455M "inplace/bin/ghc-stage1" ... compiler/stage2/build/GhcMake.dyn_o: Max. residency: 167305408 / In use: 431M "inplace/bin/ghc-stage1" ... compiler/stage2/build/PrimOp.dyn_o: Max. residency: 162532408 / In use: 455M "/usr/local/bin/ghc" ... compiler/stage1/build/HscTypes.o: Max. residency: 160814736 / In use: 421M "inplace/bin/ghc-stage1" ... compiler/stage2/build/HsDecls.dyn_o: Max. residency: 160445552 / In use: 426M "inplace/bin/ghc-stage1" ... libraries/Cabal/Cabal/dist- install/build/Language/Haskell/Extension.dyn_o: Max. residency: 159817712 / In use: 363M "/usr/local/bin/ghc" ... compiler/stage1/build/TcSplice.o: Max. residency: 156738656 / In use: 375M "/usr/local/bin/ghc" ... compiler/stage1/build/TcRnDriver.o: Max. residency: 153910768 / In use: 421M "inplace/bin/ghc-stage1" ... libraries/containers/dist- install/build/Data/Sequence/Internal.dyn_o: Max. residency: 151318224 / In use: 405M "inplace/bin/ghc-stage1" ... compiler/stage2/build/MatchLit.dyn_o: Max. residency: 150681176 / In use: 382M "/usr/local/bin/ghc" ... compiler/stage1/build/ByteCodeGen.o: Max. residency: 144579176 / In use: 389M "/usr/local/bin/ghc" ... compiler/stage1/build/GhcMake.o: Max. residency: 144411312 / In use: 379M "/usr/local/bin/ghc" ... compiler/stage1/build/MatchLit.o: Max. residency: 142596736 / In use: 382M "inplace/bin/ghc-stage1" ... compiler/stage2/build/StgCmmPrim.dyn_o: Max. residency: 141484616 / In use: 340M "inplace/bin/ghc-stage1" ... libraries/ghci/dist- install/build/GHCi/Message.dyn_o: Max. residency: 139224136 / In use: 363M "/usr/local/bin/ghc" ... compiler/stage1/build/StgCmmPrim.o: Max. residency: 137390744 / In use: 346M "inplace/bin/ghc-stage1" ... compiler/stage2/build/TcExpr.dyn_o: Max. residency: 136387128 / In use: 370M "inplace/bin/ghc-stage1" ... compiler/stage2/build/Lexer.dyn_o: Max. residency: 135228120 / In use: 337M "inplace/bin/ghc-stage1" ... compiler/stage2/build/TcTyClsDecls.dyn_o: Max. residency: 134817024 / In use: 369M "/usr/local/bin/ghc" ... compiler/stage1/build/MkIface.o: Max. residency: 134039144 / In use: 339M "inplace/bin/ghc-stage1" ... compiler/stage2/build/RnExpr.dyn_o: Max. residency: 133947600 / In use: 345M "inplace/bin/ghc-stage1" ... compiler/stage2/build/HscTypes.dyn_o: Max. residency: 133938840 / In use: 366M "inplace/bin/ghc-stage1" ... compiler/stage2/build/TcGenDeriv.dyn_o: Max. residency: 133744056 / In use: 320M "/usr/local/bin/ghc" ... compiler/stage1/build/TcExpr.o: Max. residency: 131766896 / In use: 336M "inplace/bin/ghc-stage1" ... compiler/stage2/build/GHC.dyn_o: Max. residency: 130998912 / In use: 277M "inplace/bin/ghc-stage1" ... compiler/stage2/build/ByteCodeGen.dyn_o: Max. residency: 129499464 / In use: 348M "inplace/bin/ghc-stage1" ... compiler/stage2/build/InteractiveEval.dyn_o: Max. residency: 128902944 / In use: 286M }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14797> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11962: Support induction recursion
by GHC 04 Jan '19

04 Jan '19

#11962: Support induction recursion -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Now that we have `-XTypeInType`, let's take it a step further and allow induction recursion. This feature exists in Agda and Idris. Here is a short example of what can be done in Agda: {{{ mutual -- Codes for types. data U : Set where nat : U pi : (a : U) → (El a → U) → U -- A function that interprets codes as actual types. El : U → Set El nat = ℕ El (pi a b) = (x : El a) → El (b x) }}} Note that the `U` datatype and the `El` function depend on each other. But if you look more closely, the header for `U` does not depend on `El`; only the constructors of `U` depend on `El`. So if we typecheck `U : Set` first, then `El : U → Set`, then the constructors of `U`, then the equations of `El`, we're OK. Translation into Haskell: {{{ import Data.Kind data family Sing (a :: k) -- we still require singletons data U :: Type where Nat :: U Pi :: Sing (a :: U) -> (El a -> U) -> U type family El (u :: U) :: Type where El 'Nat = Int El (Pi a b) = forall (x :: El a). Sing x -> El (b x) }}} This currently errors with {{{ • Type constructor ‘U’ cannot be used here (it is defined and used in the same recursive group) • In the kind ‘U’ }}} It needn't error. (I'm cheating a bit here, because for unrelated reasons, we can't return a `forall` on the right-hand side of a type family. But that's not the issue at hand.) I have some very sketchy notes on how we might do this [wiki:DependentHaskell/Internal#Separatingtypesignaturesfromdefinitions here]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11962> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8611: nofib’s cacheprof’s allocations nondeterminisitic
by GHC 01 Jan '19

01 Jan '19

#8611: nofib’s cacheprof’s allocations nondeterminisitic -----------------------------------------+--------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark suite | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -----------------------------------------+--------------------------------- This seems to be neither expected nor desired, and hence worth investigating: {{{ ./cacheprof +RTS -t <<ghc: 127588752 bytes, 243 GCs, 2261288/6551032 avg/max bytes residency (6 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (0.12 elapsed), 0.05 GC (0.05 elapsed) :ghc>> ./cacheprof +RTS -t <<ghc: 127392144 bytes, 242 GCs, 2261304/6551576 avg/max bytes residency (6 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.11 MUT (0.11 elapsed), 0.04 GC (0.05 elapsed) :ghc>> }}} The allocations numbers change, when they shoudn’t. Reproduced with 7.6.3 and current HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8611> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #14974: 2-fold memory usage regression GHC 8.2.2 -> GHC 8.4.1 compiling `mmark` package
by GHC 30 Dec '18

30 Dec '18

#14974: 2-fold memory usage regression GHC 8.2.2 -> GHC 8.4.1 compiling `mmark` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I haven't had time yet to diagnose where the memory is going to, but here's how to reproduce: {{{ cabal get mmark-0.0.5.6 && cd mmark-0.0.5.6/ cat > cabal.project <<EOF packages: . package mmark ghc-options: -Rghc-timing EOF }}} Then, `cabal new-build -w ghc-8.4.1` and ``cabal new-build -w ghc-8.2.2` will respectively output {{{ Resolving dependencies... Build profile: -w ghc-8.4.1 -O1 In order, the following will be built (use -v for more details): - mmark-0.0.5.6 (lib) (first run) Configuring library for mmark-0.0.5.6.. <<ghc: 13510872 bytes, 13 GCs, 806197/1299656 avg/max bytes residency (3 samples), 4M in use, 0.001 INIT (0.000 elapsed), 0.007 MUT (0.025 elapsed), 0.018 GC (0.018 elapsed) :ghc>> Preprocessing library for mmark-0.0.5.6.. Building library for mmark-0.0.5.6.. [1 of 9] Compiling Text.MMark.Parser.Internal.Type ( Text/MMark/Parser/Internal/Type.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Parser/Internal/Type.o ) [2 of 9] Compiling Text.MMark.Parser.Internal ( Text/MMark/Parser/Internal.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Parser/Internal.o ) [3 of 9] Compiling Text.MMark.Type ( Text/MMark/Type.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Type.o ) Text/MMark/Type.hs:38:1: warning: [-Wunused-imports] The import of ‘Data.Semigroup’ is redundant except perhaps to import instances from ‘Data.Semigroup’ To import instances alone, use: import Data.Semigroup() | 38 | import Data.Semigroup | ^^^^^^^^^^^^^^^^^^^^^ [4 of 9] Compiling Text.MMark.Trans ( Text/MMark/Trans.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Trans.o ) [5 of 9] Compiling Text.MMark.Util ( Text/MMark/Util.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Util.o ) [6 of 9] Compiling Text.MMark.Render ( Text/MMark/Render.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Render.o ) Text/MMark/Render.hs:25:1: warning: [-Wunused-imports] The import of ‘Data.Semigroup’ is redundant except perhaps to import instances from ‘Data.Semigroup’ To import instances alone, use: import Data.Semigroup() | 25 | import Data.Semigroup | ^^^^^^^^^^^^^^^^^^^^^ [7 of 9] Compiling Text.MMark.Parser ( Text/MMark/Parser.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Parser.o ) [8 of 9] Compiling Text.MMark ( Text/MMark.hs, /tmp/mmark-0.0.5.6 /dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark.o ) [9 of 9] Compiling Text.MMark.Extension ( Text/MMark/Extension.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Extension.o ) <<ghc: 89663269464 bytes, 1856 GCs, 338140365/1430147624 avg/max bytes residency (23 samples), 4130M in use, 0.000 INIT (0.000 elapsed), 58.546 MUT (62.124 elapsed), 31.536 GC (31.505 elapsed) :ghc>> <<ghc: 65387008 bytes, 50 GCs, 2189716/5047200 avg/max bytes residency (5 samples), 11M in use, 0.000 INIT (0.000 elapsed), 0.021 MUT (0.207 elapsed), 0.042 GC (0.042 elapsed) :ghc>> }}} and {{{ Resolving dependencies... Build profile: -w ghc-8.4.1 -O1 In order, the following will be built (use -v for more details): - mmark-0.0.5.6 (lib) (first run) Configuring library for mmark-0.0.5.6.. <<ghc: 13510872 bytes, 13 GCs, 806197/1299656 avg/max bytes residency (3 samples), 4M in use, 0.001 INIT (0.000 elapsed), 0.007 MUT (0.025 elapsed), 0.018 GC (0.018 elapsed) :ghc>> Preprocessing library for mmark-0.0.5.6.. Building library for mmark-0.0.5.6.. [1 of 9] Compiling Text.MMark.Parser.Internal.Type ( Text/MMark/Parser/Internal/Type.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Parser/Internal/Type.o ) [2 of 9] Compiling Text.MMark.Parser.Internal ( Text/MMark/Parser/Internal.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Parser/Internal.o ) [3 of 9] Compiling Text.MMark.Type ( Text/MMark/Type.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Type.o ) [4 of 9] Compiling Text.MMark.Trans ( Text/MMark/Trans.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Trans.o ) [5 of 9] Compiling Text.MMark.Util ( Text/MMark/Util.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Util.o ) [6 of 9] Compiling Text.MMark.Render ( Text/MMark/Render.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Render.o ) [7 of 9] Compiling Text.MMark.Parser ( Text/MMark/Parser.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Parser.o ) [8 of 9] Compiling Text.MMark ( Text/MMark.hs, /tmp/mmark-0.0.5.6 /dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark.o ) [9 of 9] Compiling Text.MMark.Extension ( Text/MMark/Extension.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.4.1/mmark-0.0.5.6/build/Text/MMark/Extension.o ) <<ghc: 89663269464 bytes, 1856 GCs, 338140365/1430147624 avg/max bytes residency (23 samples), 4130M in use, 0.000 INIT (0.000 elapsed), 58.546 MUT (62.124 elapsed), 31.536 GC (31.505 elapsed) :ghc>> <<ghc: 65387008 bytes, 50 GCs, 2189716/5047200 avg/max bytes residency (5 samples), 11M in use, 0.000 INIT (0.000 elapsed), 0.021 MUT (0.207 elapsed), 0.042 GC (0.042 elapsed) :ghc>> hvr@duo:/tmp/mmark-0.0.5.6$ cabal new-build -w ghc-8.2.2 Resolving dependencies... Build profile: -w ghc-8.2.2 -O1 In order, the following will be built (use -v for more details): - mmark-0.0.5.6 (lib) (first run) Configuring library for mmark-0.0.5.6.. <<ghc: 11200976 bytes, 11 GCs, 853349/1518976 avg/max bytes residency (3 samples), 5M in use, 0.001 INIT (0.000 elapsed), 0.017 MUT (0.037 elapsed), 0.021 GC (0.021 elapsed) :ghc>> Preprocessing library for mmark-0.0.5.6.. Building library for mmark-0.0.5.6.. [1 of 9] Compiling Text.MMark.Parser.Internal.Type ( Text/MMark/Parser/Internal/Type.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.2.2/mmark-0.0.5.6/build/Text/MMark/Parser/Internal/Type.o ) [2 of 9] Compiling Text.MMark.Parser.Internal ( Text/MMark/Parser/Internal.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.2.2/mmark-0.0.5.6/build/Text/MMark/Parser/Internal.o ) [3 of 9] Compiling Text.MMark.Type ( Text/MMark/Type.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.2.2/mmark-0.0.5.6/build/Text/MMark/Type.o ) [4 of 9] Compiling Text.MMark.Trans ( Text/MMark/Trans.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.2.2/mmark-0.0.5.6/build/Text/MMark/Trans.o ) [5 of 9] Compiling Text.MMark.Util ( Text/MMark/Util.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.2.2/mmark-0.0.5.6/build/Text/MMark/Util.o ) [6 of 9] Compiling Text.MMark.Render ( Text/MMark/Render.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.2.2/mmark-0.0.5.6/build/Text/MMark/Render.o ) [7 of 9] Compiling Text.MMark.Parser ( Text/MMark/Parser.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.2.2/mmark-0.0.5.6/build/Text/MMark/Parser.o ) [8 of 9] Compiling Text.MMark ( Text/MMark.hs, /tmp/mmark-0.0.5.6 /dist- newstyle/build/x86_64-linux/ghc-8.2.2/mmark-0.0.5.6/build/Text/MMark.o ) [9 of 9] Compiling Text.MMark.Extension ( Text/MMark/Extension.hs, /tmp/mmark-0.0.5.6/dist- newstyle/build/x86_64-linux/ghc-8.2.2/mmark-0.0.5.6/build/Text/MMark/Extension.o ) <<ghc: 89565902800 bytes, 2004 GCs, 225836231/772393000 avg/max bytes residency (27 samples), 2179M in use, 0.001 INIT (0.000 elapsed), 58.237 MUT (61.472 elapsed), 25.823 GC (25.795 elapsed) :ghc>> <<ghc: 79930048 bytes, 56 GCs, 3522920/10072040 avg/max bytes residency (6 samples), 20M in use, 0.001 INIT (0.000 elapsed), 0.028 MUT (0.213 elapsed), 0.059 GC (0.059 elapsed) :ghc>> }}} Consequently, - GHC 8.2.2: **2179M in use**, 0.001 INIT (0.000 elapsed), 58.237 MUT (61.472 elapsed), 25.823 GC (25.795 elapsed) - GHC 8.4.1: **4130M in use**, 0.000 INIT (0.000 elapsed), 58.546 MUT (62.124 elapsed), 31.536 GC (31.505 elapsed) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14974> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14672: Make likelyhood of branches/conditions available throughout the compiler.
by GHC 28 Dec '18

28 Dec '18

#14672: Make likelyhood of branches/conditions available throughout the compiler. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For simple code such as `if a > 10 then foo else bar` it can make a big difference if we jump on `a > 10` or `a <= 10`. We already tracked the likelyhood of such conditionals for stack/heap checks in Cmm. I recently updated the native codegen on X86 to take this information into account where available and in one edge case this improved execution time from 1.7s to 1.5s! Having this info available for other cases like bound checking (assume valid) or partial pattern matches (assume no match failure) should be a small win for most programs and hopefully a big one for a few of them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14672> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #8316: GHCi debugger segfaults when trying force a certain variable
by GHC 28 Dec '18

28 Dec '18

#8316: GHCi debugger segfaults when trying force a certain variable ------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The file Test.hs has following definitions: {{{ whnf :: a -> IO () whnf a = a `seq` (return ()) foo :: [Int] foo = [1..] }}} Calling ghci as: {{{ ghci Test.hs -ignore-dot-ghci }}} and bebugging foo like this: {{{ *Main> :b foo Breakpoint 0 activated at Test.hs:5:7-11 *Main> foo Stopped at Test.hs:5:7-11 _result :: [Int] = _ [Test.hs:5:7-11] *Main> :p foo foo = (_t1::[Int]) [Test.hs:5:7-11] *Main> whnf _t1 }}} results in this segault: {{{ <interactive>: internal error: TSO object entered! (GHC version 7.6.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [1] 5445 abort (core dumped) ghci Test.hs -ignore-dot-ghci }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8316> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #14375: Implement with# primop
by GHC 27 Dec '18

27 Dec '18

#14375: Implement with# primop -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4110 | Wiki Page: -------------------------------------+------------------------------------- In Trac #14346 we proposed the new `with#` primop {{{ with# :: a -> (State# s -> (# State# s, b #)) -> State# s -> (# State# s, b #) }}} This ticket is to track progress. See Phab:D4110. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14375> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #12034: Template Haskell + hs-boot = Not in scope during type checking, but it passed the renamer
by GHC 26 Dec '18

26 Dec '18

#12034: Template Haskell + hs-boot = Not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1-rc2 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I don't think this is a very harmful bug but it definitely is a bug. Consider: {{{ -- A.hs-boot module A where data T -- B.hs module B (module A) where import {-# SOURCE #-} A -- A.hs {-# LANGUAGE TemplateHaskell #-} module A where import qualified B import Language.Haskell.TH f :: B.T -> B.T f x = x $( return [] ) data T = T B.T }}} The point of the splice is to convince GHC to typecheck `f :: B.T -> B.T` before it typechecks the type declaration. But this is not going to work, because `tcLookupGlobal` is going to bail if (1) T is not in the `tcg_type_env` and (2) T comes from this module. It would be a simple matter to improve the error message but from a user's perspective, there is no good reason for this to not typecheck. On the implementation side, I am sympathetic to not letting this typecheck: if it does typecheck, then some `TyCon`s will incorrectly refer to the definition from the hs-boot file, rather than our local definition. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12034> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11627: Segmentation fault for space_leak_001 with profiling (-hc)
by GHC 24 Dec '18

24 Dec '18

#11627: Segmentation fault for space_leak_001 with profiling (-hc) -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Profiling | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: perf/space_leaks/space_leak_001 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `WAY=profasm` is omitted by default for this test, but the code looks like this: Test.hs: {{{ import Data.List main = print $ length $ show (foldl' (*) 1 [1..100000] :: Integer) }}} {{{ $ ghc Test.hs -prof -O $ ./Test +RTS -hc Segmentation fault (core dumped) }}} Reproducible with at least 7.10.3 and HEAD, also without `-O`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11627> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11