#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