1.3.2 The Gigabyte Heap

The NT native heap is flexible, able to grow and shrink in line with the demands of the application. The heap is able to expand into disjoint address ranges if memory is fragmented.

In contrast the LeapHeap snatches a full gigabyte of address range, half the total available to the application, when it initialises. LeapHeap partitions most of this memory into compartments, each one dedicated to allocations falling within a particular size range. LeapHeap only commits memory within a compartment to the extent that the application allocates it. There is also a catchall area for allocating memory blocks bigger than any compartment can handle.

When the application requests memory from the heap, LeapHeap jumps over large expanses of uncommitted address range to get to the appropriate compartment, hence the name.

The gigabyte of address range that LeapHeap does not use is enough for (say) 250 standard size thread stacks plus 750 MB (one megabyte is two to the power 20 bytes) of code and static data. If this proves insufficient, the size of the LeapHeap is adjustable through per application settings, as explained in section 6.3 Tuning. One gigabyte is just a default.

Outside the compartment area, LeapHeap reserves about 1 MB of memory for bitmaps that hold bookkeeping information for the compartments. This memory is always committed.

For a typical application, the LeapHeap will run fairly empty, as indicated in the diagram above. For a demanding application, the compartment sizes should be tuned to the allocation pattern of that application, and the LeapHeap will be more nearly full. As noted previously, the latter circumstance is a consequence of our position late in the processor cycle, with RAM capacity overtaking virtual memory capacity. The 64-bit implementation of LeapHeap will take 100 GB of address range and run almost empty; or perhaps it will take one terabyte of address range, as unused portions of the bookkeeping bitmaps consume cheap pagefile memory rather than RAM.