How to update pointers when memory is reallocated/compacted?

Question

So I am working on a custom programming language and have a long ways to go. One of the things I am currently thinking about is memory management. I am currently considering something like "slab allocation", which has slabs that take one type of struct per slab type (also called a "cache" I think for slab allocator terminology). So a slab might be 4096 bytes, and a struct might be 256 bytes, so you can fit a certain number in the slab. You have different types of structs mapped to different types of slabs that take objects of that struct size. That is all that really matters for purposes of this question.

Now in trying to imagine how this would work, I am imagining the case where you have let's say 10,000 slabs, each 16kb in size, each full to the brim with objects. Now you remove every nth object, leaving all 10k slabs with only one object each, in some random position in each slab. That would be the worst case where memory is highly fragmented . We are only talking about one slab type, with 10k instances of the slab type. This would mean like 99.9x% of the space is wasted. If you could instead put all the 10k objects into one slab, that would be a reallocation and would make the memory layout compact .

Searching for reallocation strategies led me to A Compacting Real-Time Memory Management System , which I don't yet fully understand. But the gist seems to be that every time you deallocate a slot in one of the slabs, you move an object from the end of the slab to the newly emptied slot. They say something like you should only ever have one page that is partially full at any time. I don't quite get that yet, but it sounds intriguing.

But even so, there seems to be a glaring problem. It relates to this idea How to update other pointers when realloc moves the memory block? Say you allocate these objects in these slabs. Then you create references to these addresses in the slabs through pointers (like creating a network of connected records in an in-memory database). If you reallocate the memory layout under the hood to optimize for compaction, all these pointers will now be invalid and will point to random spots most likely unrelated to their original data. So it seems you need to update every pointer so it reflects the new compactified memory layout.

Is that correct? Or is there some magic that will allow you to somehow now remap all your pointers automagically during such a reallocation? If there is some technique, what is the general technique at a high level (could demonstrate in C perhaps, but again I am in the prototype phase of a programming language, so asking at a high level so it can apply to more than one situation).

If it does require you to remap the pointers, I guess that means now that every "memory address" needs to keep track of the pointers which reference it, so I'm going to have to think about that. If that is the correct direction of thinking, please let me know.

In my language, I am currently only at the point of thinking in terms of absolute memory addresses. I don't have the concept of pointers or complex pointers like a language such as Rust has yet.

Hmm, maybe it has something to do with this mark-compact algorithm , not sure yet.

Answer 1

In databases, this problem is solved with a layer of indirection called a "slot directory/slot array"

Instead of storing the structs end-to-end in the memory block, and addressing them that way, what you can do is store a bit of metadata in the header of the page (slab) that contains a lookup table.

This table basically looks like this:

let slots = [
  { offset: 4032, size: 37 },
  { offset: 3562, size: 122 },
]

Now you can move slots around, insert/delete them, etc, and what you do is update the offset and size of the slot in the table

slots[i].offset = newOffset

To mark a slot as deleted (and available for re-use), typically you do something like this:

const DELETED_SLOT_SIZE = 0 // Put any marker value you like

slots[i].size = DELETED_SLOT_SIZE

This lets you make modifications to the tuple data stored in the page without breaking everything.

---