Not logged in
Log in now
Create an account
Subscribe to LWN
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
So we've come incrementally closer to having a garbage collector in the kernel, I see.
Why they don't just bite the bullet and DO it, I have no idea.
The managed resource API
Posted Feb 24, 2007 10:11 UTC (Sat) by k8to (subscriber, #15413)
Posted Mar 1, 2007 8:40 UTC (Thu) by rwmj (subscriber, #5474)
 And they are rare. Java and Emacs have really bad GCs, but because everyone is familiar with them, they assume that GC itself is bad.
Posted Mar 1, 2007 18:40 UTC (Thu) by quintesse (subscriber, #14569)
Posted Mar 1, 2007 19:57 UTC (Thu) by rwmj (subscriber, #5474)
Compare to the OCaml GC. OCaml is maintained by a small team of developers and regularly performs close to and often faster than equivalent C programs. They made a lot of very smart choices with runtime representations of values, and it helps that they have a couple of world-leading GC academics writing the code.
Posted Mar 1, 2007 21:29 UTC (Thu) by massimiliano (subscriber, #3048)
Any link to a "readable" paper with a comparison of their approaches,
or anyway some more detailed information?
Posted Mar 1, 2007 21:55 UTC (Thu) by rwmj (subscriber, #5474)
I'm afraid that I don't know of any readable introduction to the OCaml internals. However if you are
really interested then I'd recommend you read this chapter from the manual:
It took me about a year of on-again off-again reading to understand exactly how clever the runtime
representation of types is which the above chapter describes.
For a general introduction to OCaml, http://www.ocaml-tutorial.org/
Posted Mar 1, 2007 22:10 UTC (Thu) by joib (guest, #8541)
I mean, GC would certainly be nice but while I don't have any GC implementation experience I'd think the effort to write a concurrent GC scalable up to 2048-way NUMA machines (or whatever is the biggest single image system Linux runs on at the moment) is far from trivial.
Posted Mar 2, 2007 9:07 UTC (Fri) by rwmj (subscriber, #5474)
My problem is not that the kernel devs have decided on and rejected garbage collection, but that they're implementing a really bad form of garbage collection without any rational investigation into the field.
Posted Feb 25, 2007 12:13 UTC (Sun) by liljencrantz (guest, #28458)
Posted Mar 1, 2007 8:44 UTC (Thu) by rwmj (subscriber, #5474)
A garbage collector is a 'Fire and forget' memory allocation strategy. What is described here is a memory allocator that groups together allocations so that you can tell the system "when this piece of memory here is recycled, then these pieces over here are no longer needed either".
That shows a poor understanding of garbage collectors. In fact
a GC has precisely this information - that groups of
memory are related and that when one piece of memory is no longer
reachable, that causes other memory allocations to be unreachable too.
This is encoded implicitly in the relationship of pointers between
memory areas. All that is happening here is that the kernel devs
have made this relationship explicit, inefficiently.
Posted Feb 26, 2007 16:53 UTC (Mon) by nix (subscriber, #2304)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds