harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject [DRLVM][GC] low pause garbage collection for Harmony
Date Wed, 14 Feb 2007 02:47:39 GMT

Harmony now has a reasonably advanced and stable parallel/generational
GC built for 32bit platforms (the GCv5). The remaining work for GCv5 I
think is mainly about 64bit port and leverage of large heap size
enabled by 64bit, while performance tuning is always a continuous

Besides the ongoing work of GCv5, I would like to start thinking of a
low-pause garbage collector for Harmony now, since some Harmony users
might expect their applicaitons' execution interrupt for garbage
collection to be as short as possible. For them, the "throughput" of
GC is not all they want. GC's "pause time" or "latency" or "response
time" is critical as well.

Low-pause GC usually means "concurrent GC", in contrast to
"stop-the-world GC". In concurrent GC, the mutators (application
threads) can keep running while collectors (GC threads) are doing
garbage collection. GCv5 so far is a "stop-the-world" GC, where all
the mutators are suspended when a collection is started.

The concept "parallel" is orthogonal to "concurrent". "Parallel" GC
refers to that a collection can be conducted by multiple collector
threads simultaneously. "Generational" is orthogonal as well.

There is a claimed "pauseless GC" by Azul Systems [1], which depends
on Azul's specific hardware support for read/write barriers. Without
HW support, read barriers can be expensive [2]; but I think a
very-short-pause-time GC is acceptable for Harmony, at least good
enough in the near future.

Some researchers seperate "on-the-fly" GC from concurrent GC as a
special case [3]. The difference as stated is "on-the-fly" GC doesn't
require any synchronization point where all mutators are suspended,
i.e., it suspends and resumes mutators one after another, not at the
same time. There is also "real-time" GC proposed that can satisfy
required real-time bounds. Metronome is one example [4].

Considering the support in available platforms and Harmony's
objectives, an on-the-fly GC might be our choice. But before that, we
can have a traditional concurrent GC implemented, and adapt it into

Anybody has good advices? Thanks.


[1] http://www.usenix.org/events/vee05/full_papers/p46-click.pdf
[2] http://cs.anu.edu.au/~Steve.Blackburn/pubs/papers/wb-ismm-2004.pdf
[3] http://www.cs.technion.ac.il/~erez/Papers/ms-sliding-views.ps
[4] http://www.research.ibm.com/people/d/dfb/papers/Bacon03Realtime.pdf

View raw message