Jul 2, 2024

One option I've considered is having the store expose an allocator that can be passed to specific objects, such as for tx construction. A store blob table is a memory manager. Allocation is from a memory map - which can be sized via configuration and resized as necessary. When we hit a space limit we would just reset the allocation pointer to the beginning of the map (unlike store tables this cannot be allowed to grow indefinitely). This implies of course that all uses of the allocated memory are first deleted. We track this already for table remapping. However in this case we wouldn't want to track at the level of granularity of each allocation. We would just want to know (for example) that there are no tx objects. That would require the tx construction to obtain the memory object that we currently use, and hold it until destruct. Then we just block new allocations until all are released. As long as work progresses, this results in a periodic delay (like table remap) but makes allocation almost free - and deallocation becomes a nop. Basically this would allow us to allocate all tx object memory on a mmap and strictly control that level of allocation. Blocks and headers are trivial by comparison, and there's really not much else. Allocation would be cheap due to the large singular reservation and deallocation would be free. Memory full behavior would be similar if not identical to virtual memory, as pages would get swapped to disk as RAM becomes unavailable. However it may very well be better, due to the memory locality.