Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of xiaofeng.li@gmail.com designates
 66.249.92.173 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=TS1mrOKt8jdPuu6x0pjTJEVjMXr4IMMKGbRI+DxsgU8KOiPcWsBecX9BeCgVehct2ew5onz6ezaqFWDlPDEpM38gLX/jOeG2PKaLVUPj5y+Ibo+1uRjLw/DPctKkCq+4Xxoh5miVwKrgjzxLcT8B9OTI+jwJFuZsfNZ+h6VmsRY=
Message-ID: <9623c9a50609102235j33c5ae37q5c546f1fb84c1980@mail.gmail.com>
Date: Mon, 11 Sep 2006 13:35:42 +0800
From: "Xiao-Feng Li" <xiaofeng.li@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [DRLVM][GC] high-level design proposal for GCV5
In-Reply-To: <4dd1f3f00609101340r49ba17ehf102447387190d1@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <9623c9a50608220046l34444a50v5197e8c96825c73a@mail.gmail.com>
	 <4dd1f3f00609101340r49ba17ehf102447387190d1@mail.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 <weldonwjw@gmail.com> wrote:
> 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
>
>

---------------------------------------------------------------------
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