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 Sun, 10 Sep 2006 20:40:31 GMT
Anyone building the below GC?  Can you give us an update?
  - Weldon


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message