harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [DRLVM][GC] proposal of Tick: a low pause-time GC for Harmony
Date Tue, 26 Jun 2007 11:53:26 GMT
Xiao-Feng Li 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.

Good to see plans for ongoing development and innovation in Harmony GC
-- so go for it!

Regards,
Tim

Mime
View raw message