The SLUB allocator

Posted Apr 12, 2007 21:43 UTC (Thu) by flewellyn (subscriber, #5047) [Link]

SSHHHHH! You can't say that word around C programmers! They get all twitchy and start to yell incoherently.

Posted Apr 12, 2007 23:58 UTC (Thu) by bronson (subscriber, #4806) [Link]

What kind? The kernel already has reference counting. If you're advocating mark & sweep... Well, go ahead and give it a shot! It might be a good master's thesis, but I'm not sure it would ever be better than the slightly buggy manual mess that we have now. :)

Posted Apr 19, 2007 10:20 UTC (Thu) by jfj (guest, #37917) [Link]

One problem with GC is that resources are not freed As Soon As Possible. For memory that may be a win, but there are other things: File descriptors, inodes, locks, etc. These things Must be freed as soon as possible, and no you can't do that periodically every time GC is triggered. So since the code is there, it is also better to free the memory as well.

I mean, why do: close the file descriptor, but leave the memory for the GC.

GC collection would then have to traverse the entire object space and kill all the caches for good! Just free the damn thing when you're there.

Posted Apr 22, 2007 22:50 UTC (Sun) by RareCactus (guest, #41198) [Link]

> I'm yet again left thinking what would happen
> if the kernel devs actually thought about proper
> garbage collection.
> Rich.

Things that are good practice for sysadmins writing perl scripts or programmers writing Java or COBOL "business logic" are not good practice for kernel hackers.

Garbage collection is about managing memory lazily. It will always hold on to memory longer than equivalent non-GC code would. It will trash the data cache by rummaging through things unecessarily.

Traditional garbage collection algorithms like mark and sweep and generational GC tend to require the system to come to a "stop" while the garbage collector thread scans through everything. It should be obvious to anyone that this is unacceptable for a kernel, especially on a multi-core system. There are some newer algorithms that mitigate this behavior somewhat, at the cost of even worse performance.

The kernel is about efficiency. Yes, even in 2007. It's about writing code that everyone will use. It's about spending 2x the time to get a 10% speedup. It's about scaling up to 4, 8, 16 CPUs, and down to a 50 MHz antique.

The kernel manages many other resources besides memory: things like network connections, file descriptors, IRQs, hardware stuff. malloc() might make your head spin, but it's not as hard to write as the TCP stack.

Userspace can and should move more and more to high-level languages with garbage collection, first-class functions, the whole nine yards. I like Ruby, myself. And there are certain resources in the kernel that might benefit from a GC-like approach. But memory is not one of them.

R/C