harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [DRLVM][GC] proposal of Tick: a low pause-time GC for Harmony
Date Wed, 27 Jun 2007 07:41:31 GMT
On 6/27/07, Weldon Washburn <weldonwjw@gmail.com> wrote:
> Xiao Feng,
> Good ideas below.  I have some questions:
> 1)
> Which paper best describes what you plan to implement? Is the implementation
> similar to what Ezra proposed in [3] below?

Yes, it is for the first step.

> 2)
> 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?

In most cases, pause time is like execution time, i.e., the shorter,
the better.

> 3)
> 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.

>From what I learned, almost all the on-line server applications wish
to have fast response time.

> 4)
> 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]
> below?
>

The current design hopes to eliminate stop-the-world at all. I am not
sure about your question on the address space mapping part. In my
understanding, the algorithm is independent of the address mapping.

Thanks,
xiaofeng

>
> 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
>


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

Mime
View raw message