harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [DRLVM][GC] proposal of Tick: a low pause-time GC for Harmony
Date Wed, 27 Jun 2007 19:32:10 GMT
> 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?


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

Mime
View raw message