harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject [DRLVM][GC] high-level design proposal for GCV5
Date Tue, 22 Aug 2006 07:46:27 GMT

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

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.



Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message