Interesting article. 16-24 bytes per allocation is pretty big and it sounds like it would a bit too much overhead, an actual demo would be nice.
My approach with Valk is to allocate per type size and in incremental sized blocks. These blocks work alot like tiny bump allocators and can be reset with 1 line of code without losing the objects in it that are still used.
If the overal memory usage increased a certain percent, we trace the stack, clean up the blocks from long existing objects and free blocks that are completely empty.
My benchmark performes 2x faster than rust, and 4x golang. We use 8 bytes per allocation.
Other nice people on this comment thread pointed out that I can bring it down to 8, I had just missed some simple tricks I could do (like overriding the object data with the forwarding pointer since that data is garbage anyway).
So 8 bytes per allocation sounds about right.
How do you deal with variable size types like arrays?
We dont have static arrays for GC types. Creating multiple objects is always 1 by 1 and we would put them in a dynamic array. We do support non-GC structs, which allow you to create static arrays in a single allocation. I havent spent much time on this problem yet. I might figure it out in the future, but it's kinda low-priority for me.
My approach with Valk is to allocate per type size and in incremental sized blocks. These blocks work alot like tiny bump allocators and can be reset with 1 line of code without losing the objects in it that are still used.
If the overal memory usage increased a certain percent, we trace the stack, clean up the blocks from long existing objects and free blocks that are completely empty.
My benchmark performes 2x faster than rust, and 4x golang. We use 8 bytes per allocation.