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 Thu, 28 Jun 2007 02:48:04 GMT
On 6/28/07, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> > The current design hopes to eliminate stop-the-world at all.
> This is very exciting. Could you please give a hint how does this
> design compact global objects referenced from all mutator threads?

Alexei, The idea for concurrent GC is basically depending on write
barrier. With very careful delicate design of the write barrier, the
GC can catch any mutation in object connectivity graph so as to
maintain the coloring invariant.

There are some technical discussions in my blog for your reference. :-)
http://xiao-feng.blogspot.com/2007/03/on-fly-mark-sweep-garbabe-collector.html
http://xiao-feng.blogspot.com/2007/03/comparison-between-snapshot-based-gc.html
http://xiao-feng.blogspot.com/2007/04/incremental-update-tracing-vs-snapshot.html

Thanks,
xiaofeng
> On 6/27/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > 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
> >
>
>
> --
> With best regards,
> Alexei,
> ESSD, Intel
>


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

Mime
View raw message