#8199: Get rid of HEAP_ALLOCED ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: 5435 Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by ezyang): Today, I took a closer look, and actually it looks like profiling does have a hack to ensure that the constructor is loaded: {{{ -- Note [pipeline-split-init] -- If we have a stub file, it may contain constructor -- functions for initialisation of this module. We can't -- simply leave the stub as a separate object file, because it -- will never be linked in: nothing refers to it. We need to -- ensure that if we ever refer to the data in this module -- that needs initialisation, then we also pull in the -- initialisation routine. -- -- To that end, we make a DANGEROUS ASSUMPTION here: the data -- that needs to be initialised is all in the FIRST split -- object. See Note [codegen-split-init]. }}} (We probably annotate the link-step in the verbose output to this effect, as a reminder what the link step is doing). So the way to fix this problem here is to arrange for the first split object to contain the "data that needs to be initialized." In particular, all static closures have to be collected in the first split section. But this might actually be quite bad for split objects: with profiling, it is not a big deal if profiling data for a module is always loaded, since it doesn't contain any pointers to further data. But static closures contain pointers to their relevant code segments, and thus unconditionally loading the static closures could greatly increase the size of split-obj'd executables. I should probably implement this version and see how bad the bloat is, before we try to do something more complicated. Collecting this data through the compiler will be annoying, though, since it involves threading another list of SCCs through the various phases. If the static indirections table is placed in a single object file, which is a good idea, since otherwise the ordering of the various split object files which are linked together is not well-defined, then it may be very difficult to overcome this problem: the indirections table must point to the closures, and so if the indirections table is linked in, so are the rest of the objects. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8199#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler