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

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

Follow

@federicomena @alcinnz @hergertme@mastodon.social

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.

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!