[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