The managed resource API
The managed resource API
Posted Mar 1, 2007 18:40 UTC (Thu) by quintesse (guest, #14569)In reply to: The managed resource API by rwmj
Parent article: The managed resource API
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!
Posted Mar 1, 2007 19:57 UTC (Thu)
by rwmj (subscriber, #5474)
[Link] (4 responses)
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.
Posted Mar 1, 2007 21:29 UTC (Thu)
by massimiliano (subscriber, #3048)
[Link] (1 responses)
I'm interested!
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)
[Link]
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
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
For a general introduction to OCaml, http://www.ocaml-tutorial.org/
Rich.
Posted Mar 1, 2007 22:10 UTC (Thu)
by joib (subscriber, #8541)
[Link] (1 responses)
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)
[Link]
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.
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).The managed resource API
The managed resource API
There is a lot of details about the guts here, written by one of the aforementioned experts:The managed resource API
really interested then I'd recommend you read this chapter from the manual:
representation of types is which the above chapter describes.
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...The managed resource API
There was a concurrent Caml Light, as shown in the link you posted.The managed resource API