This paper on a malloc() replacement that DOES COMPACTION even on C/C++ is making the rounds: https://arxiv.org/pdf/1902.04738.pdf
@alcinnz I'm afraid glib's slice allocator is pretty obsolete these days 😅
I think it was nice when system malloc() was slow, but those have improved a lot. Also, unfortunately Glib's slice allocator could never really use the recycle-to-default-values scheme from Solaris's original allocator.
I don't remember if the GTK team had plans to remove GSlice and just use malloc... maybe @email@example.com remembers?
GLibc malloc was always on par with GSlice performance. GSlice was faster than non-glibc malloc() impls and it's more memory efficient, because it doesn't have to store boundary tags (2*size_t fields before each memory block that contain the memory size free() needs to know about).
True to the original slab magazine paper, it only recycles memory back to the kernel after a timeout of several seconds, a fact the Gitlab bug benchmarks don't reflect.
La red social del futuro: ¡Sin anuncios, sin vigilancia corporativa, diseño ético, y descentralización! ¡Sé dueño de tu información con Mastodon!