[GHC] #9706: New block-structured heap organization for 64-bit

GHC ghc-devs at haskell.org
Mon Oct 20 21:22:11 UTC 2014


#9706: New block-structured heap organization for 64-bit
-------------------------------------+-------------------------------------
              Reporter:  ezyang      |            Owner:  simonmar
                  Type:  task        |           Status:  new
              Priority:  normal      |        Milestone:
             Component:  Runtime     |          Version:  7.8.3
  System                             |         Keywords:
            Resolution:              |     Architecture:  Unknown/Multiple
      Operating System:              |       Difficulty:  Unknown
  Unknown/Multiple                   |       Blocked By:
       Type of failure:              |  Related Tickets:
  None/Unknown                       |
             Test Case:              |
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------

Comment (by rwbarton):

 > Next, probe for some appropriately aligned chunk of available virtual
 address space for this. On POSIX, we can mmap /dev/null using PROT_NONE
 and MAP_NORESERVE.

 Is this different from using MAP_ANONYMOUS?

 BTW, I found that I could mmap 100 TB with PROT_NONE (or even PROT_READ)
 and MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED with no measurable delay, and
 I can start 10000 such processes at once, so there doesn't seem to be any
 significant cost to setting up the page table mappings (at least on my
 system). Not sure why that is, exactly. The VSZ column in ps looks quite
 funny of course :)

 Also, this was on a system with overcommit disabled (vm.overcommit_memory
 = 2). So PROT_NONE or PROT_READ pages don't count against the commit
 limit.

 > To allocate, we keep track of the high-watermark, and mmap in 1MB pages
 as they are requested. We also keep track of how much metadata we need,
 and mmap extra pages to store metadata as necessary.

 By "mmap" here do you mean using mprotect() to make parts of our reserved
 area writable, or something else?

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


More information about the ghc-tickets mailing list