harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [DRLVM][GC] high-level design proposal for GCV5
Date Wed, 23 Aug 2006 20:44:09 GMT
I like it.  Some comments.  It would be really nice to avoid dealing
with write barriers during initial bringup.  It would be good if the
GCV5 collector is designed so that it is easy to configure to always
do a full heap collection.  The idea is to eliminate the dependency on
the write barrier during initial development.

It might also make sense to design in a write barrier verifier.  The
concept is to verify that all the old-to-young pointers are properly
handled.  One way of doing this is to force a full heap mark.  Then
compare the full heap mark's old-to-young pointers to what the write
barrier mechanism derived.

On 8/22/06, Xiao-Feng Li <xiaofeng.li@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Weldon Washburn
Intel Middleware Products Division

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