February 2018 - ghc-tickets

Re: [GHC] #5775: Inconsistency in demand analysis
by GHC 01 Feb '18

01 Feb '18

#5775: Inconsistency in demand analysis -------------------------------------+------------------------------------- Reporter: rl | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => Comment: Unmilestoning due to lack of progress. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5775#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11195: New pattern-match check can be non-performant
by GHC 01 Feb '18

01 Feb '18

#11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- In my work in merging Phab:D808 (and originally pointed out by thomie), I ran into a peculiar bug: the new pattern-match check took gobs of memory (~10GB) to check !OptCoercion in the stage-2 compiler. My analysis got only as far as nailing the problem down to `pmTraverse`, which took 80% of the time, and got called roughly a gajillion times. To reproduce, simply compile !OptCoercion (with `-package ghc`) and you'll see your memory usage explode. So that you'll be able to build GHC until this is fixed, I've disable the pattern-match check in that file. There is a good chance that this is caused by an interaction between the pattern-match check and the type=kind code. I'm happy to probe further, but I'd want George's help. NB: This applies only after my patch is merged. Which should be today. For some value of today. Hopefully today's value of today. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11195> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #14013: Bad monads performance
by GHC 01 Feb '18

01 Feb '18

#14013: Bad monads performance -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 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: -------------------------------------+------------------------------------- Hi! We've been struggling with a very strange GHC behavior on IRC today. Let's consider the following code (needs mtl and criterion to be compiled, not all extensions are needed): {{{ {-# LANGUAGE AllowAmbiguousTypes, ApplicativeDo, Arrows, BangPatterns, BinaryLiterals, ConstraintKinds, DataKinds, DefaultSignatures, DeriveDataTypeable, DeriveFoldable, DeriveFunctor, DeriveGeneric, DeriveTraversable, DoAndIfThenElse, DuplicateRecordFields, EmptyDataDecls, FlexibleContexts, FlexibleInstances, FunctionalDependencies, GeneralizedNewtypeDeriving, InstanceSigs, LambdaCase, MonadComprehensions, MultiWayIf, NamedWildCards, NegativeLiterals, NoImplicitPrelude, NumDecimals, OverloadedLabels, PackageImports, QuasiQuotes, RankNTypes, RecursiveDo, ScopedTypeVariables, StandaloneDeriving, TemplateHaskell, TupleSections, TypeApplications, TypeFamilies, TypeFamilyDependencies, TypeOperators, ViewPatterns, LiberalTypeSynonyms, RelaxedPolyRec #-} module Main where import Prelude import Criterion.Main import qualified Control.Monad.State.Strict as Strict import qualified Control.Monad.State.Class as State import Control.DeepSeq (NFData, rnf, force) import GHC.IO (evaluate) import Data.Monoid ----------------------------- -- === Criterion utils === -- ----------------------------- eval :: NFData a => a -> IO a eval = evaluate . force ; {-# INLINE eval #-} liftExp :: (Int -> a) -> (Int -> a) liftExp f = f . (10^) ; {-# INLINE liftExp #-} expCodeGen :: NFData a => (Int -> a) -> (Int -> IO a) expCodeGen f i = do putStrLn $ "generating input code (10e" <> show i <> " chars)" out <- eval $ liftExp f i putStrLn "code generated sucessfully" return out {-# INLINE expCodeGen #-} expCodeGenBench :: (NFData a, NFData b) => (Int -> a) -> (a -> b) -> Int -> Benchmark expCodeGenBench f p i = env (expCodeGen f i) $ bench ("10e" <> show i) . nf p ; {-# INLINE expCodeGenBench #-} ------------------------------- -- === (a*) list parsing === -- ------------------------------- genList_a :: Int -> [Char] genList_a i = replicate i 'a' ; {-# INLINE genList_a #-} pureListParser_a :: [Char] -> Bool pureListParser_a = \case 'a':s -> pureListParser_a s [] -> True _ -> False {-# INLINE pureListParser_a #-} mtlStateListParser_a :: State.MonadState [Char] m => m Bool mtlStateListParser_a = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a [] -> return True _ -> return False {-# INLINE mtlStateListParser_a #-} mtlStateListParser_a_typed :: Strict.State [Char] Bool mtlStateListParser_a_typed = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a_typed [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_typed #-} mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool mtlStateListParser_a_let = go where go = Strict.get >>= \case 'a':s -> Strict.put s >> go [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_let #-} {-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-} {-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-} main = do defaultMain [ bgroup "a*" $ [ bgroup "pure" $ expCodeGenBench genList_a pureListParser_a <$> [6..6] , bgroup "mtl.State.Strict" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a) <$> [6..6] , bgroup "mtl.State.Strict typed" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a_typed) <$> [6..6] , bgroup "mtl.State.Strict let" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a_let) <$> [6..6] ] ] }}} The code was compiled with following options (and many other variations): `-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick- factor=1000 -flate-dmd-anal` Everything in this code has `INLINE` pragma. The important part we should focus on are these two functions: {{{ pureListParser_a :: [Char] -> Bool pureListParser_a = \case 'a':s -> pureListParser_a s [] -> True _ -> False {-# INLINE pureListParser_a #-} mtlStateListParser_a :: State.MonadState [Char] m => m Bool mtlStateListParser_a = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a [] -> return True _ -> return False {-# INLINE mtlStateListParser_a #-} }}} Which are just "parsers" accepting strings containing only 'a' characters. The former is pure one, while the later uses `State` to keep the remaining input. The following list contains performance related observations: 0. For the rest of the points, let's call the performance of `pureListParser_a` a "good" one and everything worse a "bad" one. 1. The performance of `mtlStateListParser_a` is bad, it runs 10 times slower than `pureListParser_a`. Inspecting CORE we can observe that GHC jumps between `(# a,b #)` and `(a,b)` representations all the time. 2. If we add a specialize pragma `{-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-}`, the performance of `mtlStateListParser_a` is good (exactly the same as `pureListParser_a`). 3. If we do NOT use specialize pragma, but we use explicite, non- polymorphic type signature `mtlStateListParser_a_typed :: Strict.State [Char] Bool`, the performance is bad (!), identical to the polymorphic version without specialization. 4. If we use SPECIALIZE pragma together with explicite, non-polymorphic type, so we use BOTH `mtlStateListParser_a_typed :: Strict.State [Char] Bool` AND `{-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-}` we get the good performance. 5. If we transform `pureListParser_a` to {{{ mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool mtlStateListParser_a_let = go where go = Strict.get >>= \case 'a':s -> Strict.put s >> go [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_let #-} }}} we again get the good performance without the need to use `SPECIALIZE` pragmas. The above points raise the following questions: 1. Why GHC does not optimize `mtlStateListParser_a` the same way as `pureListParser_a` and where the jumping between `(# a,b #)` and `(a,b)` comes from? 2. Is there any way to tell GHC to automatically insert `SPECIALIZE` pragmas, especially in performance critical code? 3. Why providing very-explicite type signature `mtlStateListParser_a_typed :: Strict.State [Char] Bool` does not solve the problem unless we use `SPECIALIZE` pragma that tells the same as the signature? 4. Why the trick to alias the body of recursive function to a local variable `go` affects the performance in any way, especially when it does NOT bring any variable to the local let scope? We've been testing this behavior in GHC 8.0.2 and 8.2.1-rc3 and several people reported exactly the same observations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14013> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #12665: Make Read instances faster, and make them fail fast
by GHC 01 Feb '18

01 Feb '18

#12665: Make Read instances faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: high | Milestone: 8.2.1 Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At present, the `Read` instances for standard types are generally written ''as though'' `Read` were a typical parser for a programming language. However, it most assuredly is not. Specifically, we currently follow the pattern of lexing and then parsing. Lexing looks at the string and attempts to identify the next token, whatever it may be. But for `Read`, we don't need that. Thanks to the types, we have a very clear sense of what characters we expect to encounter. I've started to sketch out an improvement, which reads `Int` and `Word` around seven times as fast (9.5 times as fast with parentheses and negation), and will fail immediately on something like `read (fix ('a':)) :: Int` rather than going into an infinite loop. To begin with, modify the definition of `paren` thus: {{{#!hs expectP' :: Char -> ReadPrec () expectP' c = lift (expect c) {-# INLINE expectP' #-} paren :: ReadPrec a -> ReadPrec a -- ^ @(paren p)@ parses \"(P0)\" -- where @p@ parses \"P0\" in precedence context zero paren p = do expectP' '(' x <- reset p expectP' ')' return x }}} This allows fast failure when looking for parentheses, so we don't have to scan to the end of the first token (whatever it may be) before concluding that it is not `'('`. Now we can parse `Word` and `Int` very efficiently. I had to specialize earlier than I wanted to convince GHC that I don't want to convert through `Integer`. I'm not sure why the `fromIntegral` rule doesn't fire reliably around here. The code below (temporarily) uses the current definition for base 16, because that's a bit fussy; I'll rewrite it soon. {{{#!hs charDiff :: Char -> Char -> Word charDiff c1 c2 = fromIntegral (ord c1 - ord c2) {-# INLINE charDiff #-} readHexOct :: ReadP Word readHexOct = do _ <- ReadP.char '0' baseId <- lexBaseChar case baseId of Oct -> readBaseP 8 Hex -> L.readHexP {-# INLINE readHexOct #-} data BaseId = Oct | Hex lexBaseChar :: ReadP BaseId lexBaseChar = do { c <- ReadP.get; case c of 'o' -> pure Oct 'O' -> pure Oct 'x' -> pure Hex 'X' -> pure Hex _ -> ReadP.pfail } readWord :: ReadP Word readWord = readNumber (readHexOct ReadP.<++ readBaseP 10) readInt :: ReadP Int readInt = fromIntegral <$> readWord readBaseP :: Integral a => Word -> ReadP a readBaseP !base = do c <- ReadP.get let diff = charDiff c '0' if diff < base then readBaseP' base (fromIntegral diff) else ReadP.pfail {-# INLINE readBaseP #-} readBaseP' :: Integral a => Word -> a -> ReadP a readBaseP' !base !acc0 = ReadP.look >>= go acc0 where go !acc (c:cs) | diff < base = ReadP.get *> go (fromIntegral base * acc + fromIntegral diff) cs where diff = charDiff c '0' go !acc _ = pure acc {-# INLINE readBaseP' #-} readNumber :: Num a => ReadP.ReadP a -> ReadPrec a readNumber p = parens $ do cs <- lift skipSpaces *> look case cs of ('-': _) -> get *> lift (skipSpaces *> (negate <$> p)) _ -> lift $ skipSpaces *> p {-# INLINE readNumber #-} }}} Other `Word` and `Int`-like types can be built on top of that foundation. I haven't yet attempted to deal with other instances, but I think there are probably a lot of opportunities for similar improvements. WARNING: I know very little about parsing, and less about `ReadPrec`. It's conceivable that I've made some semantic errors here, although I don't think I have. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12665> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #14676: GHCI doesn't recover from bad :add
by GHC 01 Feb '18

01 Feb '18

#14676: GHCI doesn't recover from bad :add -------------------------------------+------------------------------------- Reporter: Juzley | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- In GHCi, when the user attempts to add a module that can not be found, the error message for that module will be repeated for any subsequent :add calls. {{{ ghci> :add Slightly/Misspelled/File.hs <no location info>: error: can't find file: Slightly/Misspelled/File.hs ... ghci> :add Correctly/Spelled/File.hs <no location info>: error: can't find file: Slightly/Misspelled/File.hs }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14676> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14732: -fdefer-type-holes breaks a correct program
by GHC 01 Feb '18

01 Feb '18

#14732: -fdefer-type-holes breaks a correct program -------------------------------------+------------------------------------- Reporter: MitchellSalad | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- Here's a bug I discovered in `vector` that Ryan Scott identified as a regression from 7.10.3: https://github.com/haskell/vector/issues/200 Here is Ryan's minimal example: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} module Bug where import Prelude hiding (zip, zipWith) zipWith :: (a -> b -> c) -> Bundle v a -> Bundle v b -> Bundle v c zipWith = undefined class GVector (v :: * -> *) a instance GVector Vector a data Bundle (v :: * -> *) a data Vector a class Unbox a stream :: GVector v a => v a -> Bundle v a {-# INLINE [1] stream #-} stream = undefined zip :: (Unbox a, Unbox b) => Vector a -> Vector b -> Vector (a, b) {-# INLINE [1] zip #-} zip = undefined {-# RULES "stream/zip [Vector.Unboxed]" forall as bs . stream (zip as bs) = zipWith (,) (stream as) (stream bs) #-}{#!hs }}} Output (8.2.2): {{{ Bug.hs:29:11: error: • Could not deduce (Unbox a) arising from a use of ‘zip’ from the context: GVector Vector (a, b) bound by the RULE "stream/zip [Vector.Unboxed]" at Bug.hs:(28,11)-(30,46) Possible fix: add (Unbox a) to the context of the RULE "stream/zip [Vector.Unboxed]" • In the first argument of ‘stream’, namely ‘(zip as bs)’ In the expression: stream (zip as bs) When checking the transformation rule "stream/zip [Vector.Unboxed]" | 29 | stream (zip as bs) = zipWith (,) (stream as) | ^^^^^^^^^ }}} Similar output in 8.0.1, 8.0.2, 8.2.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14732> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14723: GHC 8.4.1-alpha loops infinitely when typechecking
by GHC 01 Feb '18

01 Feb '18

#14723: GHC 8.4.1-alpha loops infinitely when typechecking -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 (Type checker) | 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: -------------------------------------+------------------------------------- This issue prevents `jvm-streaming` from compiling with GHC 8.4.1-alpha2. Here is my best attempt at minimizing the issue: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} module Bug () where import Data.Kind (Type) import Data.Proxy (Proxy(..)) import Data.String (fromString) import Data.Int (Int64) import GHC.Stack (HasCallStack) import GHC.TypeLits (Nat, Symbol) data JType = Iface Symbol data J (a :: JType) newIterator :: IO (J ('Iface "java.util.Iterator")) newIterator = do let tblPtr :: Int64 tblPtr = undefined iterator <- (loadJavaWrappers >> (((((((qqMarker (Proxy :: Proxy "{ return new java.util.Iterator() {\n @Override\n public native boolean hasNext();\n\n @Override\n public native Object next();\n\n @Override\n public void remove() {\n throw new UnsupportedOperationException();\n }\n\n private native v oid hsFinalize(long tblPtr);\n\n @Override\n public void finalize() {\n hsFinalize($tblPtr);\n }\n } ; }")) (Proxy :: Proxy "inline__method_0")) (Proxy :: Proxy "tblPtr")) (Proxy :: Proxy 106)) (tblPtr, ())) Proxy) (((callStatic (fromString "io.tweag.inlinejava.Inline__jvmstreaming022inplace_Language_Java_Streaming")) (fromString "inline__method_0")) [coerce tblPtr]))) undefined class Coercible (a :: Type) where type Ty a :: JType class Coercibles xs (tys :: k) | xs -> tys instance Coercibles () () instance (ty ~ Ty x, Coercible x, Coercibles xs tys) => Coercibles (x, xs) '(ty, tys) qqMarker :: forall -- k -- the kind variable shows up in Core (args_tys :: k) -- JType's of arguments tyres -- JType of result (input :: Symbol) -- input string of the quasiquoter (mname :: Symbol) -- name of the method to generate (antiqs :: Symbol) -- antiquoted variables as a comma-separated list (line :: Nat) -- line number of the quasiquotation args_tuple -- uncoerced argument types b. -- uncoerced result type (tyres ~ Ty b, Coercibles args_tuple args_tys, Coercible b, HasCallStack) => Proxy input -> Proxy mname -> Proxy antiqs -> Proxy line -> args_tuple -> Proxy args_tys -> IO b -> IO b qqMarker = undefined }}} With GHC 8.2.2, this is properly rejected by the typechecker: {{{ $ /opt/ghc/8.2.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:27:12: error: Variable not in scope: loadJavaWrappers :: IO a0 | 27 | (loadJavaWrappers >> | ^^^^^^^^^^^^^^^^ Bug.hs:36:16: error: Variable not in scope: callStatic :: t0 -> t1 -> [a2] -> IO a1 | 36 | (((callStatic | ^^^^^^^^^^ Bug.hs:40:17: error: Variable not in scope: coerce :: Int64 -> a2 | 40 | [coerce tblPtr]))) | ^^^^^^ }}} But in GHC 8.4.1-alpha2, this simply hangs forever. To make things more interesting, if you pass `-ddump-tc-trace` when compiling, you'll get a panic: {{{ $ /opt/ghc/8.4.1/bin/ghc Bug.hs -ddump-tc-trace ... kcLHsQTyVars: cusk JType [] [] [] [] * [] [] [] [] kcTyClGroup: initial kinds [rB8 :-> ATcTyCon JType :: *, rB9 :-> APromotionErr RecDataConPE] txExtendKindEnv [rB8 :-> ATcTyCon JType :: *, rB9 :-> APromotionErr RecDataConPE] kcTyClDecl { JType env2 [] tcExtendBinderStack [] env2 [] tcExtendBinderStack [] lk1 Symbol tcTyVar2a Symbol * u_tys tclvl 1 * ~ TYPE t_a1qq[tau:1] arising from a type equality * ~ TYPE t_a1qq[tau:1] u_tys tclvl 1 'GHC.Types.LiftedRep ~ t_a1qq[tau:1] arising from a type equality * ~ TYPE t_a1qq[tau:1] u_tys tclvl 1 GHC.Types.RuntimeRep ~ GHC.Types.RuntimeRep arising from a kind equality arising from t_a1qq[tau:1] ~ 'GHC.Types.LiftedRep u_tys yields no coercion writeMetaTyVar t_a1qq[tau:1] :: GHC.Types.RuntimeRep := 'GHC.Types.LiftedRep u_tys yields no coercion u_tys yields no coercion checkExpectedKind * TYPE t_a1qq[tau:1] <*>_N kcLHsQTyVars: not-cuskghc: panic! (the 'impossible' happened) (GHC version 8.4.0.20180118 for x86_64-unknown-linux): kcConDecl }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14723> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14715: GHC 8.4.1-alpha regression with PartialTypeSignatures
by GHC 01 Feb '18

01 Feb '18

#14715: GHC 8.4.1-alpha regression with PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 (Type checker) | Keywords: | Operating System: Unknown/Multiple PartialTypeSignatures | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This bug prevents `lol-apps`' tests and benchmarks from building with GHC 8.4.1-alpha2. This is as much as I'm able to minimize the issue: {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE PartialTypeSignatures #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -Wno-partial-type-signatures #-} module Bug (bench_mulPublic) where data Cyc r data CT zp r'q class Reduce a b type family LiftOf b bench_mulPublic :: forall z zp zq . (z ~ LiftOf zq, _) => Cyc zp -> Cyc z -> IO (zp,zq) bench_mulPublic pt sk = do ct :: CT zp (Cyc zq) <- encrypt sk pt undefined ct encrypt :: forall z zp zq. Reduce z zq => Cyc z -> Cyc zp -> IO (CT zp (Cyc zq)) encrypt = undefined }}} On GHC 8.2.2, this compiles without issue. But on GHC 8.4.1-alpha2, this errors with: {{{ $ /opt/ghc/8.4.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:15:1: error: • Could not deduce (Reduce fsk0 zq) from the context: (z ~ LiftOf zq, Reduce fsk zq) bound by the inferred type for ‘bench_mulPublic’: forall z zp zq fsk. (z ~ LiftOf zq, Reduce fsk zq) => Cyc zp -> Cyc z -> IO (zp, zq) at Bug.hs:(15,1)-(17,14) The type variable ‘fsk0’ is ambiguous • In the ambiguity check for the inferred type for ‘bench_mulPublic’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the inferred type bench_mulPublic :: forall z zp zq fsk. (z ~ LiftOf zq, Reduce fsk zq) => Cyc zp -> Cyc z -> IO (zp, zq) | 15 | bench_mulPublic pt sk = do | ^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14715> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14725: memory leak: forkOS not releasing thread local `Task` struct upon end of thread
by GHC 01 Feb '18

01 Feb '18

#14725: memory leak: forkOS not releasing thread local `Task` struct upon end of thread ------------------------------------------+--------------------------- Reporter: RobertZabel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.2 Keywords: forkOS memory leak | Operating System: POSIX Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------------------+--------------------------- I came to notice a memory leak in the runtime system while letting warp use `forkOS` and conducting a load test.\\ A minimal snippet to reproduce: {{{#!hs module Main where import Control.Concurrent main :: IO () main = replicateM_ 10000000 $ forkOS $ return () }}} This patch will clean up the thread local `Task` struct just before threads created by forkOS terminate. {{{ diff --git a/rts/posix/OSThreads.c b/rts/posix/OSThreads.c index c9adf4e..bd4e75d 100644 --- a/rts/posix/OSThreads.c +++ b/rts/posix/OSThreads.c @@ -223,6 +223,7 @@ forkOS_createThreadWrapper ( void * entry ) cap = rts_lock(); rts_evalStableIO(&cap, (HsStablePtr) entry, NULL); rts_unlock(cap); + rts_done(); return NULL; } }}} I think win32 platforms need an equivalent patch, but unfortunately I cannot verify that. \\ Hence I'm only targeting posix here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14725> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14702: Runtime is keeping hold to too much memory
by GHC 01 Feb '18

01 Feb '18

#14702: Runtime is keeping hold to too much memory -------------------------------------+------------------------------------- Reporter: blaze | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.2.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently runtime only releases memory to OS when it has more than 4x of the amount used. This leads to heavy memory overuse when process is run using many processes and large nurseries. For example, if process is run on 16 CPUs with each having 32MB nursery, it will use total 512MB allocation area. This will push "release boundary" to the 2GB. If process is ever to allocate that much memory for a short term use, it will never be given back to OS and effectively wasted. Nursery and other non-growing data areas should be excluded from this multiplier. Runtime should only keep an extra memory proportional to heap allocation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14702> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5