harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [DRLVM][GC] proposal of Tick: a low pause-time GC for Harmony
Date Wed, 27 Jun 2007 03:05:11 GMT
Xiao Feng,
Good ideas below.  I have some questions:
Which paper best describes what you plan to implement? Is the implementation
similar to what Ezra proposed in [3] below?
What is the metric for measuring Tick's success?  How do we know if Tick is
50% successful or 90% successful?  Is there a DaCapo realtime GC benchmark?
Is there a java app that some IT shop is willing to give Apache?  Are you
inventing a special benchmark?
Can you tell us end-user workloads that will benefit from lower latency GC?
A wild guess.  Maybe there are Wall Street bond trading apps written in Java
that would benefit from low latency.
Will Tick have a much shorter stop-the-world? Or no stop-the-world at all?
A related question -- will tick use address space mappings to like [3]

On 6/25/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> 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

Weldon Washburn

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message