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] proposal of Tick: a low pause-time GC for Harmony
Date Tue, 26 Jun 2007 04:17:56 GMT
Hi, it is about four months since last time I proposed the concurrent
GC for Harmony. During the this period, GCv5 has been through the
intensive bug fixing phase, and now is the default GC of Harmony. To
make Harmony GC development into a pipeline, now I'd like to make the
low pause-time GC proposal more concrete with Tick subproject and
start it immediately.

1. Tick will be based on GCv5's infrastructure. This can help to
largely reduce the code size, and exercise the modularity/flexibility
design of GCv5. The direct implication of this design choice is, Tick
will share the same source directory with GCv5, well may take some
separate sub-directories. This is not necessarily the final form, but
we want to make it current development principle.

2. Tick will be partitioned into a couple of steps, and a couple of
sub-tasks for each step. The steps will roughly be:
       a) a concurrent mark-sweep GC;
       b) a concurrent generational mark-sweep GC;
       c) a concurrent compact GC;
       d) a soft real-time GC.

The subtasks for the first step are:
       a) high performance parallel (stop-the-work) mark-sweep GC;
       b) concurrent (parallel) marking algorithm;
       c) on-the-fly root set enumeration;
       d) connection of the above into a real on-the-fly mark-sweep GC.

I believe the first step subtasks can be achieve within next quarter.
Please let me know if any people have good suggestions. More design
details will be send later.

(Btw, as to the GCv5 front, there are a couple of things to implement
or to polish in next quarter. One major thing is to enable the class
unloading support. Other GC tasks include, e.g., to implement
gc.verbose info output, to make the generational collections flawless,
to study the potential and possibility of enabling large page mode for
all the runtime, etc. At the same time, performance and heap size
tunings of GCv5 are always the focuses, along with more applications
enabled with Harmony.)

Hope all the work around GC can help Harmony to be a valuable software
for Java workloads and runtime research.

Thanks,
xiaofeng

On 2/14/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> Hi,
>
> 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
> effort.
>
> 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
> on-the-fly.
>
> Anybody has good advices? Thanks.
>
> -xiaofeng
>
> [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
>


-- 
http://xiao-feng.blogspot.com

Mime
View raw message