previousupnext

4.3 Overflow

In the compartment area, LeapHeap reserves a certain amount of memory (address range) for each possible size of allocation. Should one of these compartments fill up, so that there are no free cells left within it, an allocating thread will detect the condition when it tests the top tier of the cell bitmap. The allocator then moves to the next larger compartment and tries to allocate there.

A moderate amount of such overflow in the LeapHeap is nothing to worry about, and indeed is inescapable for memory-hungry applications that run LeapHeap heavily loaded. Overflow wastes a small amount of memory and delays an allocator by about a dozen machine instructions for every compartment skipped.

If compartments are full all the way up to the 4 KB threshold, then allocators use the big-block area. Having lots of small allocations in the big-block area is detrimental to performance and this type of overflow is to be avoided. It may also threaten the numeric ceiling for big-block allocations.

Allocating threads that lose out in contention at the top tier of the cell bitmap do not try a larger compartment but go straight to the big-block area to allocate. LeapHeap performance is not significantly affected because there should be no more than a handful of such events.

An allocator that enters the big-block area (for whatever reason) and cannot allocate there gives up and returns the failure code. Unlike the NT native heap, the LeapHeap cannot expand beyond its original boundaries.