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
