4 ms·
> Gaps that are too small and scattered throughout the heap can lead to new "fresh" blocks of memory being allocated to accommodate a new value that won’t fit o
by adrianmonk 4y ago
> Gaps that are too small and scattered throughout the heap can lead to new "fresh" blocks of memory being allocated to accommodate a new value that won’t fit otherwise. Though unfortunately because of how memory management works a "defrag" is not possible.
This is how memory management works now, but some older systems like classic Mac OS and Palm OS used a design that did make it possible to compact the heap.
See https://en.wikipedia.org/wiki/Classic_Mac_OS_memory_management https://en.wikipedia.org/wiki/Classic_Mac_OS_memory_manageme...
When you allocated memory, instead of getting a pointer back, you'd get a handle. While the handle was unlocked, the operating system was free to move the memory around. If you wanted to access the memory, you'd lock the handle, giving a pointer with the actual address, then unlock the handle when done.
To the extent that you kept handles unlocked, the system could fight fragmentation.
It was tedious, and your code had lots of lock/unlock clutter in it. It also led to bugs where you'd accidentally use a pointer value after unlocking its handle, which makes the pointer value invalid because your data might have been moved somewhere else. Worse, usually your data was not moved, so these bugs were hard to detect, much like use-after-free bugs.
But, when memory is very limited and you also don't have an MMU, life isn't easy.
- Narishma 4y agoEarly Windows version worked like that too.
- Asooka 4y agoRust's borrow checker should make it impossible to reference an unlocked pointer in safe code. I suspect it should be possible to have a compacting heap as a library.
- vlovich123 4y agoYeah. I wonder if something like this might be interesting for a pure Rust program / what computing would look like if Rust were available back then (we now have a path dependency on modern memory allocation patterns that are unlikely to change where we rely on the allocator to do really heavy lifting). I wonder how expensive the extra handle indirection would be (I imagine modern CPUs should be an able to speculate through it without much difficulty).