Slightly OT, but may-be interesting for the D/LLVM folks

OCaml comes along now with a parallel garbage collector ... well let's have a look :
OCaml on *eight cores* http://planet.ocamlcore.org/


quote :
/
Fortunately, Jane St. Capital (one of the largest industrial users of OCaml) have chosen to fund a "multicore" summer project that aims to provide a basic concurrent garbage collector implementation for OCaml. The team from the Université Pierre et Marie Curie, led by Emmanuel Chailloux, intend to complete this project during the summer of 2008.

********************

We have already written to team to suggest that they might also make their run-time compatible with the excellent LLVM project because this would make it much easier for open source developers to reuse this exciting technology.
/
http://ocamlnews.blogspot.com/2008/04/ocaml-to-get-concurrent-garbage.html

bjoern
and folks, beside : D at TIOBE is a joke. Search for OCaml jobs or who is using OCaml.

BLS wrote:
> Slightly OT, but may-be interesting for the D/LLVM folks
> 
> OCaml comes along now with a parallel garbage collector ... well let's
> have a look :
> OCaml on *eight cores* http://planet.ocamlcore.org/
> 
> 
> quote :
> /
> Fortunately, Jane St. Capital (one of the largest industrial users of
> OCaml) have chosen to fund a "multicore" summer project that aims to
> provide a basic concurrent garbage collector implementation for OCaml.
> The team from the Université Pierre et Marie Curie, led by Emmanuel
> Chailloux, intend to complete this project during the summer of 2008.
> 
> ********************
> 
> We have already written to team to suggest that they might also make
> their run-time compatible with the excellent LLVM project because this
> would make it much easier for open source developers to reuse this
> exciting technology.
> /
> http://ocamlnews.blogspot.com/2008/04/ocaml-to-get-concurrent-garbage.html
> 
> bjoern
> and folks, beside : D at TIOBE is a joke. Search for OCaml jobs or who
> is using OCaml.

Am I reading that right?  A garbage collector that wouldn't have to suspend the runtime?  Or just one that plays nice with threads?

Chris R. Miller wrote:
> 
> Am I reading that right?  A garbage collector that wouldn't have to
> suspend the runtime?  Or just one that plays nice with threads?
> 

There are GCs that don't have to suspend any threads: incremental GCs. But they need language support to work... and I'm not sure the concept really fits in a systems language.


Sean

On Mon, 08 Sep 2008 18:05:42 -0400, Chris R. Miller <lordSaurontheGreat@gmail.com> wrote:
> Am I reading that right?  A garbage collector that wouldn't have to
> suspend the runtime?  Or just one that plays nice with threads?

No, concurrent GCs still have to suspend the runtime, they just have to do it a lot less. Generally, they only suspend threads twice to read only the stack during each pass. See
http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Stop-the-world_vs._incremental_vs._concurrent
Or any articles on the Java GC.

Robert Jacques a écrit :
> On Mon, 08 Sep 2008 18:05:42 -0400, Chris R. Miller <lordSaurontheGreat@gmail.com> wrote:
>> Am I reading that right?  A garbage collector that wouldn't have to
>> suspend the runtime?  Or just one that plays nice with threads?
> 
> No, concurrent GCs still have to suspend the runtime, they just have to do it a lot less. Generally, they only suspend threads twice to read only the stack during each pass. See
> http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Stop-the-world_vs._incremental_vs._concurrent 
> 
> Or any articles on the Java GC.

Note that even though the concurrent GC scales well with multiples core (contrary to normal GC), AFAIK most of them are not real-time so you wouldn't want to use them for say a game for example.

IBM has made a real time Java GC, but they didn't talk about parallelism so I guess that it doesn't scale well.

The 'ideal GC' must have so many properties: concurrent, incremental, scalable, real-time, VM-aware (so that its performance stays correct even with swapping), precise, compacting (to reduce trashing caused by leaks) AND still being somewhat efficient in memory and CPU usage..

renoX

On Fri, 19 Sep 2008 17:21:32 -0400, renoX <renosky@free.fr> wrote:

> The 'ideal GC' must have so many properties: concurrent, incremental, scalable, real-time, VM-aware (so that its performance stays correct even with swapping), precise, compacting (to reduce trashing caused by leaks) AND still being somewhat efficient in memory and CPU usage..

I'd also add support for ownership types (i.e. shared / local) to that list although it's kinda part of scalable.