On 6/27/07, Weldon Washburn <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
