Technical Details
BlockPool
The BlockPool is the core of the memory manager. It supports the allocation and de-allocation of 64 kb blocks of memory. The complete implementation is contention free on SMP systems by using thread safe single linked lists. 1MB chunks of address space are reserved as needed (without committing physical memory). On request 64kb blocks are committed for allocation requests. De-allocation put these blocks into a list of already committed blocks without decommitting them for faster reuse.
The BlockPool is periodically swept by a low priority background thread that decommits unused 64kb blocks and frees unused 1MB chunks of address space. Moving this cleanup into a low priority thread increases responsiveness by postponing it until the system is idle.
Replacement Memory Manager
In addition to offering special
nxGetMem/nxFreeMem/nxReallocMem calls NexusDB can replace the main memory
allocator from Borland. Allocations below 16kb are redirected to the correct
memory pool. Allocations over that are directly handled via VirtualAlloc.
Advantages
The Nexus Memory Manager prevents memory fragmentation, which would result in an application using more and more memory and finally running out. In contrast to the Borland Memory Manager which synchronizes all operations with a single critical section the Nexus Memory Manager allows contention free allocation/deallocation on SMP systems. By moving most cleanup and management code into a low priority background thread it minimizes the overhead when the system is busy and optimizes itself for minimal memory and address space usage when the system is idle.
Disadvantages
The Memory Manager is optimised for a high number of allocation/deallocation with less than 16kb. For allocations over that limit VirtualAlloc is directly used. This results in an address space granularity of 64kb and a memory granularity of 4kb which increases the allocation overhead for allocations that are not a multiple of 4kb but reduces fragmentation even for large allocations.