KRRegion draws inspiration from the region allocation
strategy and also the
famed allocator described by Brian Kernighan and Dennis Ritchie in section 8.7
of the book "The C
Programming Language", Second Edition, Prentice Hall, 1988.
struct KRRegion(ParentAllocator) ;
Region + Kernighan-Ritchie Allocator
KRRegion starts in "region" mode: allocations are served from
the memory chunk in a region fashion. Thus, as long as there is enough memory
KRRegion has the performance profile of a region allocator.
Deallocation inserts (in Ο(
1) time) the deallocated blocks in an
unstructured freelist, which is not read in region mode.
Once the region cannot serve an
to "free list" mode. It sorts the list of previously deallocated blocks by
address and serves allocation requests off that free list. The allocation and
deallocation follow the pattern described by Kernighan and Ritchie.
The recommended use of
KRRegion is as a region with deallocation. If the
KRRegion is dimensioned appropriately, it could often not enter free list
mode during its lifetime. Thus it is as fast as a simple region, whilst
offering deallocation at a small cost. When the region memory is exhausted,
the previously deallocated memory is still usable, at a performance cost. If
the region is not excessively large and fragmented, the linear allocation and
deallocation cost may still be compensated for by the good locality
If the chunk of memory managed is large, it may be desirable to switch
management to free list from the beginning. That way, memory may be used in a
more compact manner than region mode. To force free list mode, call
switchToFreeList shortly after construction or when deemed appropriate.
The smallest size that can be allocated is two words (16 bytes on 64-bit systems, 8 bytes on 32-bit systems). This is because the free list management needs two words (one for the length, the other for the next pointer in the singly-linked list).
ParentAllocator type parameter is the type of the allocator used to
allocate the memory chunk underlying the
KRRegion object. Choosing the
NullAllocator) means the user is responsible for passing a buffer
at construction (and for deallocating it if necessary). Otherwise,
automatically deallocates the buffer during destruction. For that reason, if
ParentAllocator is not
KRRegion is not
In free list mode,
KRRegion embeds a free blocks list onto the chunk of
memory. The free list is circular, coalesced, and sorted by address at all
times. Allocations and deallocations take time proportional to the number of
previously deallocated blocks. (In practice the cost may be lower, e.g. if
memory is deallocated in reverse order of allocation, all operations take
constant time.) Memory utilization is good (small control structure and no
per-allocation overhead). The disadvantages of freelist mode include proneness
to fragmentation, a minimum allocation size of two words, and linear worst-case
allocation and deallocation times.
KRRegion (in free list mode) with the
- Free blocks have variable size and are linked in a singly-linked list.
- The freelist is maintained in increasing address order, which makes coalescing easy.
- The strategy for finding the next available block is first fit.
- The free list is circular, with the last node pointing back to the first.
- Coalescing is carried during deallocation.
Differences from the Kernighan-Ritchie allocator:
- Once the chunk is exhausted, the Kernighan-Ritchie allocator allocates
another chunk using operating system primitives. For better composability,
KRRegionjust gets full (returns
nullon new allocation requests). The decision to allocate more blocks is deferred to a higher-level entity. For an example, see the example below using
AllocatorListin conjunction with
- Allocated blocks do not hold a size prefix. This is because in D the size information is available in client code at deallocation time.
||Allocates all memory available to this allocator. If the allocator is empty,
returns the entire available block of memory. Otherwise, it still performs
a best-effort allocation: if there is no fragmentation (e.g.
||Deallocates all memory currently allocated, making the allocator ready for
other allocations. This is a Ο(
||Checks whether the allocator is responsible for the allocation of
||Forces free list mode. If already in free list mode, does nothing. Otherwise, sorts the free list accumulated so far and switches strategy for future allocations to KR style.|
KRRegion is preferable to
Region as a front for a general-purpose
deallocate is needed, yet the actual deallocation traffic is
relatively low. The example below shows a
KRRegion using stack storage
fronting the GC allocator.
.experimental .allocator .building_blocks .fallback_allocator : fallbackAllocator; import std .experimental .allocator .gc_allocator : GCAllocator; import std .typecons : Ternary; // KRRegion fronting a general-purpose allocator ubyte[1024 * 128] buf; auto alloc = fallbackAllocator(KRRegion!()(buf), GCAllocator .instance); auto b = alloc .allocate(100); writeln(b .length); // 100 writeln((() pure nothrow @safe @nogc => alloc .primary .owns(b))()); // Ternary.yes
The code below defines a scalable allocator consisting of 1 MB (or larger) blocks fetched from the garbage-collected heap. Each block is organized as a KR-style heap. More blocks are allocated and freed on a need basis.
This is the closest example to the allocator introduced in the K&R book. It should perform slightly better because instead of searching through one large free list, it searches through several shorter lists in LRU order. Also, it actually returns memory to the operating system when possible.