Re: [DRLVM][GC] high-level design proposal for GCV5

[Weldon Washburn <we...@gmail.com>]

Anyone building the below GC?  Can you give us an update?
  - Weldon


On 8/22/06, Xiao-Feng Li <xi...@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

Re: [DRLVM][GC] high-level design proposal for GCV5

[Xiao-Feng Li <xi...@gmail.com>]

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 <we...@gmail.com> wrote:
> Anyone building the below GC?  Can you give us an update?
>   - Weldon
>
>
> On 8/22/06, Xiao-Feng Li <xi...@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