[GHC] #8199: Get rid of HEAP_ALLOCED

[GHC]

#8199: Get rid of HEAP_ALLOCED
-------------------------------------+-------------------------------------
        Reporter:  ezyang            |                   Owner:  ezyang
            Type:  feature request   |                  Status:  new
        Priority:  normal            |               Milestone:  7.12.1
       Component:  Compiler          |                 Version:  7.7
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |               Test Case:
      Blocked By:  5435              |                Blocking:
 Related Tickets:                    |  Differential Revisions:  D207
-------------------------------------+-------------------------------------

Comment (by ezyang):

 Reproducing some comments from the Phabricator diff for posterity.

 #9706 didn't work on Windows because Windows counted page table memory as
 part of committed memory. Go has the same problem:

 {{{
         // Number of bits in page to span calculations (4k pages).
         // On Windows 64-bit we limit the arena to 32GB or 35 bits.
         // Windows counts memory used by page table into committed memory
         // of the process, so we can't reserve too much memory.
         // See https://golang.org/issue/5402 and
 https://golang.org/issue/5236.
         // On other 64-bit platforms, we limit the arena to 512GB, or 39
 bits.
         // On 32-bit, we don't bother limiting anything, so we use the
 full 32-bit address.
         // On Darwin/arm64, we cannot reserve more than ~5GB of virtual
 memory,
         // but as most devices have less than 4GB of physical memory
 anyway, we
         // try to be conservative here, and only ask for a 2GB heap.
 }}}

 The links are good reading: https://golang.org/issue/5402 and
 https://golang.org/issue/5236 (scroll down).

 Note that there is a little bit about Go relying on overcommitting causing
 problems for people on systems that don't overcommit; this is not relevant
 to us since we're not actually committing memory and relying on the OS to
 lazily initialize it if they don't actually use it.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8199#comment:51>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler