Weldon, I am writing it. Will submit an initial trace-forward copying collector for the nursery soon, and a mark-compaction collector for the mature later.
Thanks, xiaofeng On 9/11/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
Anyone building the below GC? Can you give us an update? - Weldon On 8/22/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > Hi, > > Going on what's in the email called, "[DRLVM][GC] Goals for > 2006/2007", I put together a top-level design of GC. The intention is > to use this design to guide the implementation of Harmony GCV5. > Briefly the goals are to build a Generational Mark-Compaction (GenMC) > garbage collector, initially it will be two generations: Nursery and > Mature. Your comments are welcome. > > 1. Design principles > > - The source code should have parallel allocation from the start. > Also, the collector should be able to take advantage of multiprocessor > HW from the start. In other words when a single threaded Java app runs > out of memory on a 4-way box, all 4 CPUs should be involved in GC. > > - Collection policy should be separated from the issue of object age. > One space has one collection policy, while multiple spaces can be of > same age. > > - There should be a clear distinction between collection policy and > allocation policy. > > - Where it is not too time consuming, we should develop our own core > data structures such as queues and locks. The intention is to reduce > memory/performance/functional dependencies on platform-specific > libraries. > > 2. Generations > > - The nursery should support linear scan and flexible copying order. > The size should be variable at runtime with min and max boundaries. > For expedient initial implementation, the nursery can use depth-first > trace-forwarding algorithm for the collection. > > - The mature can be arranged in blocks and collected with parallel > mark-compaction algorithm. (c.f. Compressor). The blocks are in the > range of 64KB in size. > > - Large Object Space can start with a simple treadmill collector. > > - Collection triggering should be abstracted from collection itself. > The intention is to allow experimentation with different collection > trigger heuristics without actually modifying the collector. > > - More than two generations should be considered in the design. > > 3. Write barrier > > - The initial implementation should be a "slot remembering" barrier. > Object remembering and card marking can be implemented later for > experiments or performance evaluation. Substituting write barrier may > be implemented if initial performance data suggests it is worthwhile. > (Substituting write barrier is a kind of barrier design that does both > the write and the barrier operations. It is an optimization for > performance and flexibility.) > > - putfield/aastore/putstatic will need a write barrier, so do some > native functions. It would be a good idea to evaluate if it is better > to enumerate statics as root references or use a write barrier. The VM > itself will need manual write barriers at places appropriate. > > - The initial write barrier implementation should be an SSB. Its OK > to use explicit buffer overflow checks at the beginning. > > 4. Parallelism > > - Parallel allocation: Each mutator thread should grab a Nursery chunk > for thread local allocation. Also, each collector thread should grab a > Mature chunk for promoting live objects into Mature space. LOS > allocation does not have to be parallel. > > - Parallel collection: The new GC should be designed with parallel > trace-forwarding for the nursery and parallel mark-compaction for > mature space. > > - Data structures and algorithms should be thread-safe in design from > the beginning. The parallelism should be controllable, e.g., the > number of parallel collection threads should be controllable at the > command line. > > - For debug purposes, it should be possible to force the GC into > single threaded collection. > > Comments? > > Thanks, > xiaofeng > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Weldon Washburn Intel Middleware Products Division
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
