The managed resource API [LWN.net]

The managed resource API

Posted Mar 1, 2007 19:57 UTC (Thu) by rwmj (subscriber, #5474)
In reply to: The managed resource API by quintesse
Parent article: The managed resource API

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.

(Log in to post comments)

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 (guest, #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.