#14461: Reuse free variable lists through nested closures -------------------------------------+------------------------------------- Reporter: tdammers | Owner: alexbiehl Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 7258 | Differential Rev(s): Wiki Page: NestedClosures | -------------------------------------+------------------------------------- Comment (by alexbiehl): I hacked up a POC of this transformation (it excludes updatable thunks from consideration). I had a quick (non-scientific) glance over the amount of CMM code generated for W2.hs (example from #7258): {{{ vanilla ghc ~380000 LOC hacked ghc ~270000 LOC }}} I noticed a lots of small, nested closures which only needed a fraction of the free variables of their outer closures and hence didn't benefit from the transformation.
Some data along these lines would be extremely helpful in guiding what we do. I will instrument my GHC to collect some data to guide us from here.
Another variant: currently we insist that `[gv1,..gvm]` is a '''subset''' of `[fv1,..fvn]`, to avoid space leaks. But with some RTS support we could do better: the closure for `x` could point to the closure for `y`, but ''also'' have a bitmap (in `x`'s info table) to say which of `y`'s free vars are actually used by `x`. That would open up the possibility for much more flexible sharing, at the cost of more bitmaps etc. E.g. {{{ x = [fv1,...fv100] \ [a] -> let y = [fv1,...fv99, a] \ [] -> ... in ... }}}
Sound reasonable. Let's see what the data shows.. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14461#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler