4 ms·

I've gotten a lot of mileage out of the following two extensions to the linear allocator: 1. A "pop-to" operation. If you're ready to free ALL memory allocate

I've gotten a lot of mileage out of the following two extensions to the linear allocator: 1. A "pop-to" operation. If you're ready to free ALL memory allocated at or after allocation X, you can do this by moving the start-of-free-space pointer back to the start of allocation X. 2. An end-of-free-space pointer, with its own push and pop-to operations. In combination, these are often enough to get maximum value out of a fixed-size memory workspace. A function can allocate all returned data structures on one side of the workspace, and use the other side of the workspace for all temporary allocations. This approach does require tight coupling so there are a lot of settings where it clearly doesn't belong, but I've found it to be very effective for high-performance scientific code.

dbandstra 6y ago
This is a really nice system. Quake used it back in 1996 to fit the game in 8MB. They called it a "hunk"[0] and it worked pretty much exactly as you said. The main drawback I find is that you can't use some generic data structure implementations that expect to be able to free memory out of order, unless you're fine with leaking before the final cleanup (if integrated into a generic allocator interface, the "free" method will probably be a no-op). For example, maybe you need a temporary hashmap to help with parsing a text file. It can be interesting to come up with implementations that work without freeing out of order. Of course, you can always opt to use another, more general purpose allocator, on a block of memory retrieved from the hunk (see Quake's "zones"). [0] https://github.com/id-Software/Quake/blob/master/WinQuake/zone.h https://github.com/id-Software/Quake/blob/master/WinQuake/zo...