| |||||||||||||
|
| |||||||||||||
The managed resource APIThe managed resource APIPosted Feb 24, 2007 10:11 UTC (Sat) by k8to (subscriber, #15413)In reply to: The managed resource API by flewellyn Parent article: The managed resource API
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.
(Log in to post comments)
The managed resource API Posted Mar 1, 2007 8:40 UTC (Thu) by rwmj (guest, #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 (subscriber, #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 (guest, #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 (guest, #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
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.
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 (guest, #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.
|
|
||||||||||||