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 <[EMAIL PROTECTED]> wrote:
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
-- With best regards, Alexei, ESSD, Intel
