From: Philippe Wang <Philippe.Wang@lip6.fr>
To: caml-list@inria.fr
Cc: Philippe Wang <Philippe.Wang@lip6.fr>
Subject: "ok with parallel threads" GC (aka ocaml for multicore)
Date: Fri, 10 Apr 2009 19:04:12 +0200 [thread overview]
Message-ID: <50CD0BA8-B89C-49E2-9082-FFA037F251A6@lip6.fr> (raw)
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
creation)
- 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.
Cheers,
--
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).
next reply other threads:[~2009-04-10 17:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-10 17:04 Philippe Wang [this message]
2009-04-10 20:52 ` [Caml-list] " Jon Harrop
2009-04-10 23:20 ` Jerome Benoit
[not found] ` <BB3C091F-3BE9-4883-A7CF-9D672CDDF829@x9c.fr>
2009-04-14 10:21 ` Philippe Wang
2009-04-14 14:18 ` xclerc
2009-04-16 9:45 ` Philippe Wang
2009-04-17 22:15 ` Philippe Wang
2009-04-17 22:20 ` Joel Reymont
2009-04-17 22:29 ` Philippe Wang
2009-04-17 23:05 ` forum
2009-04-23 16:49 ` Philippe Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50CD0BA8-B89C-49E2-9082-FFA037F251A6@lip6.fr \
--to=philippe.wang@lip6.fr \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox