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
"ok with parallel threads" GC (aka ocaml for multicore)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2009-04-10 (17:03)
From: Philippe Wang <Philippe.Wang@l...>
Subject: "ok with parallel threads" GC (aka ocaml for multicore)
Hello list,

Mathias and Adrien have just started their internship (for their  
Master's degree requirements).
Thus they have some time to spend on this project. Moreover, Mathias'  
internship is strongly related to this project.
=> man power dramatically increased

We are currently searching for the last remaining bugs.

Our thread library is restricted, it contains:
Thread : create, join, yield, id, self, delay
Mutex : full module
Condition : full module

Our alternative garbage collector
  - uses a Stop(the world)&Copy algorithm
  - has memory pages for threads (each thread takes a page at its  
  - has a shared heap for shared values and for old generation from  
pages (i.e. memory pages are flushed to this heap)
  - should be not to hard to replace.
Blocking sections such as I/O operations or mutex locks do not prevent  
garbage collection.

We currently do *not* support POSIX signals (let's say their behaviour  
is not specified).

We should make a release soon, but before:
  - some code has to be cleaned
  - some benchmarks have to be done
  - some documentation has to be completed
  - an installation script still has to be written.
Thus not a lot is left to do before the release :-)

We are writing test programs to search for the last remaining bugs but  
also to measure performances.

So far, as long as there are not too many concurrent memory accesses,  
it is not too hard to go n times faster with a n-core CPU;
though intense memory accesses generate page faults and divide memory  
bandwidth by the number of concurrent accesses,
and intense memory consuming programs show our GC is not as performant  
as INRIA's, of course.


Philippe Wang
   Philippe.Wang \at/ lip6.fr

PS: Sorry for taking so much time, debugging parallel threads in  
shared memory style is hell (you can give it a try).