memory defragmentation

Posted Jun 26, 2003 17:19 UTC (Thu) by elanthis (guest, #6227) [Link]

Kernel supported garbage collection would be most excellent. A few modifications to ELF to support GC hints/etc. in the executable format, and GC could become very commonplace. (Like it should have years ago.)

Imagine natively compiled Java or C# apps that make use of kernel-accelerated GC... or C/C++ extensions that offer the same. Heck, languages like Python/Ruby/etc. could drop their own home-brewed GCs and use the kernel one (when running in Linux) to increase their own performance as well.

Just remember, tho, compiler support is _required_ for a good GC implementation to work as efficiently as possible. Things like the Boehm-Weiss collector, while certainly cool "hacks", don't perform nearly as well as they could, since they do so much work ( a good deal of which is guess work ) to try to figure things out that the compiler could've provided for it.

Posted Jun 26, 2003 19:50 UTC (Thu) by daniel (subscriber, #3181) [Link]

<i>Daniel's plans for memory defragmentation require some fancy footwork to relocate physical pages, like needing to know what kernel data structures are pointing to which pages. Once they've gone that far, how long until someone hacks the Linux kernel to support garbage collection??</i>

The kernel already has garbage collection, for example, dentries and cold cache pages. But that's probably not what you meant. If you mean, we should use algorithms that don't keep track explicitly of what references what, and clean up with a classic garbage collector, I'd argue against it. Explicit reference counting is generally a more efficient, predictable way to handle dynamic objects, and so is more suitable for kernel use. Sure, it may be more work to write and debug code that works that way, but that is just the way life is in kernel land.

Regards,

Daniel