[gclist] GC for multi-threaded and multi-processor systems?
Taura Kenjiro
tau@is.s.u-tokyo.ac.jp
Thu, 9 Jul 1998 14:51:36 +0900 (JST)
Hi,
>
> The documentation for the BDW collector (v4.11) explains how to
> configure it for Solaris threads (we're using Suns, so that's OK), which
> would make it MT-safe, but I'm concerned that this might not be
> sufficient for a truly parallel system: alloc.c/solaris_threads.c
> suggest that it stops the world (all the LWPs in the process) to do its
> collection, thereby forming a potentially serious parallel bottleneck,
> but how severe is this in practice? (Or have I misunderstood how it
> works?) Does the BDW collector have a truly parallel version (and if
> not, does its incremental mode help?), or can anyone recommend another
> garbage collector that does? Finally, are there any nasty gotchas I
> should know about with any of the above?
>
We have been working exactly on this topic.
We have extended BDW collector for shared memory multiprocessors. We
specifically aimed at achieving speedup of GC process itself by doing
a single collection in parallel. With our modified collector, (1) a
thread can allocate a memory without lock acquisition (in most cases),
and (2) mark and sweep is done in parallel. Currently, we stop user
threads during a collection.
Results are described in the following paper (fetchable from our web
page http://web.yl.is.s.u-tokyo.ac.jp/gc/, which is now under
construction) :
@InProceedings{Endo97AScalable,
author = "Toshio Endo and Kenjiro Taura and Akinori Yonezawa",
title = "A Scalable Mark-Sweep Garbage Collector on
Large-Scale Shared-Memory Machines",
booktitle = "Proceedings of High Performance Computing and
Networking (SC'97)",
year = "1997",
}
The best result so far is 30 fold speedup (of GC) on 64 processors
Ultra Enterprise 10000 server. Speedup depends on applications and
machine (currently, it is noticeably worse on Origin 2000), though.
We are now working to release this piece of software and it will be
ready in a month or so. For now, we support Solaris Sparc, Solaris
x86, and Origin 2000 (I believe porting to other machines won't be
difficult). If you are willing to be our test user, we are pleased to
write a minimal document and some sample programs and send them to you
in a week or so.
We also welcome general requests, questions, and comments on this
work.
--
Kenjiro Taura
Yonezawa Laboratory
Department of Information Science
Faculty of Science
University of Tokyo
7-3-1 Hongo, Bunkyo-ku Tokyo 113 Japan
tau@is.s.u-tokyo.ac.jp (http://web.yl.is.s.u-tokyo.ac.jp/)
tel: +81-3-3812-2111 ext. 4108 or +81-3-5800-6913
fax: +81-3-5689-4365