#8703 closed feature request (wontfix)

Use guard pages rather than heap checks

Reported by: schyler Owned by: simonmar
Priority: normal Milestone:
Component: Runtime System Version:
Keywords: Cc: simonmar
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

By mmap'ing memory using MAP_ANONYMOUS (or /dev/zero) as PROT_NONE (Windows has an equivalent functionality with VirtualAlloc), it's possible to create a page that will fault when read or written to. It may be possible to remove the heap checks in the runtime, speeding up allocations, and instead expand the heap when a fault is raised.

This is likely cheaper for large pages full of many small allocations than the cost of the heap checking branch.

Change History (1)

comment:1 Changed 17 months ago by simonmar

  • Resolution set to wontfix
  • Status changed from new to closed

This is a lot harder to do than you might imagine - the problem is not the memory protection itself, but how to handle the fault when the invalid page is accessed. This requires all kinds of platform-specific hackery.

GHC's heap is constructed of linked lists of pages, so at the end of each page we have to swing the heap pointer to the next page in the list, which is often not contiguous with the previous page. Using the page fault trick is even harder when the memory must grow through non-contiguous pages, because the fault handler has to also update the current heap pointer.

I'm not saying it can't be done, but it is (a) very tricky, (b) non-portable, and (c) after you've surmounted all the obstacles, it probably doesn't save that much time, if any. And because it's non-portable, you still have to keep the old way of doing things.

I'm closing the ticket. But if you want to implement this and demonstrate that it is indeed a win, be my guest!

Note: See TracTickets for help on using tickets.