User: Password:
|
|
Subscribe / Log in / New account

The managed resource API

The managed resource API

Posted Feb 23, 2007 23:28 UTC (Fri) by flewellyn (subscriber, #5047)
Parent article: The managed resource API

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.


(Log in to post comments)

The managed resource API

Posted Feb 24, 2007 10:11 UTC (Sat) by k8to (subscriber, #15413) [Link]

If you consider a reference counter to be a type of garbage collector, it seems they are slowly doing it. I don't realy expect a heavier garbage collector to appear anytime soon, however.

The managed resource API

Posted Mar 1, 2007 8:40 UTC (Thu) by rwmj (subscriber, #5474) [Link]

The problem is that reference counting is the heaviest garbage collector there is. Real, well-implemented GCs[1] are much better than reference counting.

Rich.

[1] 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.

The managed resource API

Posted Mar 1, 2007 18:40 UTC (Thu) by quintesse (guest, #14569) [Link]

Java has a bad GC?? Do you have any kind of basis for that statement because I was under the impression that it was doing a pretty good job. Sun engineers are working constantly to improve Java's GC, often not just by incremental changes but also by including completely new algorithms. So I'm sure they would be delighted if someone could point out to them that there are far superior GCs out there!

The managed resource API

Posted Mar 1, 2007 19:57 UTC (Thu) by rwmj (subscriber, #5474) [Link]

That was a bit of a dig at Java. There are a number of architectural problems with the Java runtime which is why it's taken an enormous effort to get something which is still (IME) pretty sluggish except under very special conditions (long running server-side processes).

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.

Rich.

The managed resource API

Posted Mar 1, 2007 21:29 UTC (Thu) by massimiliano (subscriber, #3048) [Link]

I'm interested!

Any link to a "readable" paper with a comparison of their approaches, or anyway some more detailed information?

The managed resource API

Posted Mar 1, 2007 21:55 UTC (Thu) by rwmj (subscriber, #5474) [Link]

There is a lot of details about the guts here, written by one of the aforementioned experts:

http://cristal.inria.fr/~doligez/caml-guts/

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:

http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html

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/

Rich.

The managed resource API

Posted Mar 1, 2007 22:10 UTC (Thu) by joib (subscriber, #8541) [Link]

Then again, the Ocaml runtime is single-threaded, and the usual response to requests to make it multithreaded is that it would make the GC massively slower. Or to be precise, multiple threads are supported but there is a global lock so that only one thread may be executing ocaml code at a time. See e.g. http://caml.inria.fr/pub/ml-archives/caml-list/2002/11/64...

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.

The managed resource API

Posted Mar 2, 2007 9:07 UTC (Fri) by rwmj (subscriber, #5474) [Link]

There was a concurrent Caml Light, as shown in the link you posted.

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.

Rich.

The managed resource API

Posted Feb 25, 2007 12:13 UTC (Sun) by liljencrantz (guest, #28458) [Link]

I disagree. 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 is sometimes exteremely useful, since it turns out that allocation time is often a time when you have pretty detailed knowledge of when something will die.

The managed resource API

Posted Mar 1, 2007 8:44 UTC (Thu) by rwmj (subscriber, #5474) [Link]

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.

Rich.

The managed resource API

Posted Feb 26, 2007 16:53 UTC (Mon) by nix (subscriber, #2304) [Link]

There already is at least one (in net/unix/Space.c, IIRC). If you don't garbage-collect fds in transit down AF_UNIX sockets, you open a trival DoS hole. (But that's a very special-purpose GC so may not count.)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds