This paper on a malloc() replacement that DOES COMPACTION even on C/C++ is making the rounds:

Scarily beautiful.

@federicomena Interesting! Well worth a read!

Strikes me that GNOME partitions their heap quite similarly with their "Slice" allocator, so I wonder how quickly they would adopt this?


@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 remembers?

· · Web · 3 · 0 · 1

@federicomena @hergertme From what I'm seeing it certainly doesn't look absolete.

I still see it used heavily in plenty of GNOME code, and in the code generated by Vala.

@alcinnz @federicomena @hergertme obsolete in the sense that it doesn't provide any advantage, not in the sense that no code uses it

@federicomena @alcinnz @hergertme

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.

Regístrate para participar en la conversación

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!