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 ivan.volosyuk@gmail.com
 designates 64.233.166.180 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=kAoTva68CvfAdbqnq8zg6amoF3Gu+BjuVF3wsjCQPvv4Z0kx6ElVJAE4f2h/LcG1GojHLax1qcAU+GDEsgjuJkTMdxA50iK8iNyjSg7a7Z+lWBPHxPglqlvWNaP6BY5i7CY3+64GsS0J72QOV6BM7MydGsQiaaPKGPDnYxXWmhE=
Message-ID: <12385bbd0608250853r3a4d9e3et52676862b8fa922d@mail.gmail.com>
Date: Fri, 25 Aug 2006 19:53:52 +0400
From: "Ivan Volosyuk" <ivan.volosyuk@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [DRLVM][GC] Goals for 2006/2007
In-Reply-To: <44E18177.4030107@anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4dd1f3f00608141023g1e7d3fadn2564cb3b864e09b2@mail.gmail.com>
	 <44E18177.4030107@anu.edu.au>

On 8/15/06, Robin Garner <robin.garner@anu.edu.au> wrote:
> Weldon Washburn wrote:
> > All,
> >
> > There is rough consensus that the immediate goal for Harmony JVM is to
> > reliably run simple commercial workloads with acceptable performance.
> > In regards to a garbage collector for a Harmony JVM in 2006 there are
> > some data points worth noting.  1) A quick survey shows most basic
> > commercial JVMs implement a generational collector. 2) While the
> > existing drlvm garbage collector, gcv4, implements some interesting
> > advanced concepts, it is not currently a generational collector.  3)
> > The MMTk port to drlvm is not yet finished.  Even assuming MMTk's
> > generational configuration is appropriate, it is still too early to
> > put this garbage collector on the roadmap for a 2006 Harmony JVM.  It
> > might be worth revisiting in 2007.  But it's too far away to debate at
> > this time.
> >
> > Given the above data points, the following is a first stab at
> > requirements for Harmony "GCV5".  The intention is to set down some
> > basic parameters.
> >
> > 1)
> > Generational Collector with mark/compacting mature object space
> Why mark/compact specifically ?  The easiest approach would be to add a
> copying nursery 'in front' of the exiting GCV4 mature space, and then
> look at replacing/updating the implementation of the mature space.  This
> could be achieved with virtually no change to the mature space collector.
>
> As an aside, best performance with a generational collector also comes
> from an Appel-style nursery, ie the nursery size is essentially
> (heap-mature)/2.
>
> The rest of the worklist seems uncontroversial to me, but I wonder how
> much work it is to implement these vs getting MMTk working.

Good point, it seems that this is a way to go. One thing which bothers
me much is that the code of GCV4 is quite bloated. Some cleaning for
the code might be required before.

--
Regards,
Ivan

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