[GHC] #8199: Get rid of HEAP_ALLOCED

[GHC]

#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