English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
The Future Possibility of Concurrent Garbage Collection?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2006-09-15 (14:29)
From: Yaron Minsky <yminsky@c...>
Subject: Re: [Caml-list] The Future Possibility of Concurrent Garbage Collection?
On 9/15/06, Damien Doligez <damien.doligez@inria.fr> wrote:
> On 2006-09-14, at 17:40, Jim Battin wrote:
> > It seems Moore's law is taking us in the direction of more cores per
> > microprocessor with less effort placed on exploring ILP.  With the
> > advent of multi-core processors, and their inevitable ubiquity, are
> > there any plans, considerations, or ideas for a concurrent garbage
> > collector in Ocaml?
> It's very nice to have a concurrent run-time system, and we know how
> to do it (at significant cost), but it's not really worth the trouble
> until we have an answer to this question: what programming language
> features do we put on top of it?
> Shared memory with threads, locks, and conditions just doesn't cut
> it, in terms of writing programs that work.

I understand where you're coming from, but this point of view implies, I
think, an inappropriate division of labor between language designers and
language users.  I agree, ordinary shared-state concurrency with threads is
a disaster.  But the burden of figuring out how to write concurrent programs
in a reasonable way is not just the responsibility of the language designer
--- library writers can come up with good abstractions to take advantage of
threads as well.

That is, they could do so if they had access to threads with real
concurrency.  Right now, ocaml doesn't provide that, and it's a real
weakness of the language.  The lack of a concurrent GC, in my opinion,
stifles innovation in this area, at least within the caml world.

That said, I do understand that a concurrent GC is a big technical
challenge, and I can understand why the ocaml team isn't eager to take it on
right now.

> To my knowledge, Caml Light had a concurrent garbage collector under
> > development by Xavier Leroy but was abandoned due to significant
> > technical challenges.  Prior to that, there appears to have been some
> > academic research regarding concurrent GC (Doligez, Leroy).
> The development was done by myself, it was done before the
> publications, and as part of the academic research (like everything
> we do here).
> The most significant challenges are in making Posix threads work
> under Unix (threads and Unix signals just don't mix well, given the
> currently available APIs).
> In summary, you shouldn't hold your breath.  In my opinion, we
> will need some major breakthrough before we can make good use
> of multicore architectures in normal programs.  In any language.
> -- Damien
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs