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.178 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=D+ZpO2s5lR+7qNxmUQK+ZvtJry67BvXYmvcuvyUHSW9rvHZzws2LuNtqwch3Sx7RAKo5yGqLJXxG4wC5uAxtVlDTdc2w0mf5sFWvsiH4nEL0sYa9nhY+rT1ItwnvSoMMXH+76e6xSeMZ5f7DfDhnKL+eqG7Pd2UsHIoomAuduD8=
Message-ID: <12385bbd0606131230i72cc58e8u57eab5c73d27bf2f@mail.gmail.com>
Date: Tue, 13 Jun 2006 23:30:52 +0400
From: "Ivan Volosyuk" <ivan.volosyuk@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [DRLVM] one more gc
In-Reply-To: <51d555c70606131138r3c86dbbbncdd78f507a016976@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: <12385bbd0606090859k3bcbd58bt9be42738ba8360ba@mail.gmail.com>
	 <4dd1f3f00606121914j5fea8b52o21e2a4f6804b41e2@mail.gmail.com>
	 <12385bbd0606130404w1fdd73cao89e67f67d946c186@mail.gmail.com>
	 <51d555c70606131138r3c86dbbbncdd78f507a016976@mail.gmail.com>

On 6/13/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
> Hi Ivan,
>
> On 6/13/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
> >
> >
> > >Btw, I have found small performance improvement to GCv4 which can be
> > >easily added to it.
>
>
>      Could you please post more details about this possible perf enhancement
> to V4?
> .......

It is just very specific code. The layout of gc data in VTable can be
changed a bit. It gives about 1.5% speed up of garbage collection and
may also have insignificant performance improvement on allocation.

>
> > >Well, I'm going to do this development just for education and to
> > >extend my own horizon. It can be done here or privately. Either
> > >variant is acceptable for me.
>
>
>      Since this is more of an experiment, ( educational as you point out )
> and it is a little unclear immediately what is the value it adds  to the
> DRLVM GC infrastructure, would it make sense for you to make some progress
> offline and bring back your findings to this list before doing incremental
> JIRA code postings? What do you think?

Yes, it makes sense. I want to do a few experiments and the postings
will at one hand will slow-down me, at the other hand it is of no use
for others.

--
Regards,
Ivan

>
> Thanks,
> Rana
>
> --
> > Ivan
> >
> > On 6/13/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> > >  Ivan,
> > >
> > > Please note that two guys who worked for me on ORP
> > > (http://orp.sourceforge.net/ ) spent 2-3 years building and tuning the
> > > train algorithm.  We could never get the performance to acceptable
> > > level.  Ultimately we ditched the train algorithm and built GCV4 in
> > > less than 3 months.  GCV4 was never finished.  I suspect other VM
> > > builders also experimented with the train algorithm and abandoned it.
> > > As far as I know, there are no production or research MRTEs containing
> > > the train algorithm.  Also note there is already a complete
> > > implementation of the train algorithm in Apache compatible licensed
> > > open source.  Look for orp-1.0.10.tgz on
> > > http://sourceforge.net/projects/orp ).  The train algorithm is
> > > contained in the directory gc_v2.  Since the GC/VM interface has not
> > > evolved much in the transition from ORP to DRLVM, it should be an easy
> > > port.  This port would be interesting for two reasons:
> > >
> > > a)
> > > A teaching tool to show why/where the train algorithm fails.  Tony
> > > Printezis and Richard Jones wrote an excellent paper that used GCspy
> > > to graphically demonstrate where the train algorithm falls down.
> > >
> > > Look for, "GCspy: An Adaptable Heap Visualization Framework" by Tony
> > > Printezis and Richard Jones,
> > > ( http://www.cs.kent.ac.uk/pubs/2002/1426/index.html ).  Also look for,
> > > (http://research.sun.com/projects/gcspy/printezis-garthwaite-ismm2002.pdf
> >
> > > ), "Visualizing the Train Garbage Collector".
> > >
> > > It might be interesting to hook up GCV2 and GCspy to harmonydrlvm and
> > > reproduce this paper.  This would calibrate GCspy for future
> > > harmonydrlvm work.
> > >
> > > b)
> > > GC_V2 really stressed the write barrier subsystem. (GCV2 does a
> > > substantial amount of object copying.)  If GC_V2 can be ported
> > > quickly, it might be a good stepping stone to getting MMTk going.
> > >
> > > On 6/9/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
> > > > While some works going on to properly integrate DRLVM in harmony build
> > system...
> > > >
> > > > I would like to start development of new garbage collector. I know
> > > > about Weldon's work related to MMTk. I am not sure that it is the
> > > > right way.
> > > >
> > > > Instead of doing GC based on java, I would concentrate on the one
> > > > written in C. I think that the VM written in C (or C++ ) should have
> > > > GC written the same way.
> > > >
> > > > I have some experience in garbage collectors (stop-the-world ones for
> > > > now) and want to extend my knowledge in this area. That is one of the
> > > > reasons I want to make the GC, but do not port the existing one. I
> > > > hope I will eventually produce something which is better then existing
> > > > implementations or at least a few new ideas.
> > > >
> > > > I would like to start implementing something similar to Train
> > > > algorithm, then possibly modify it in direction to Garbage First
> > > > collector. I want to create something with high performance and low
> > > > pauses.  At the beginning it will not even compile. I do not expect
> > > > this to be interesting to anyone for some time, but as Geir always
> > > > suggests I going to do this in public to avoid surprises.
> > > >
> > > > All required VM functionality (for GC written in C) is already in
> > > > place. DRLVM's interfaces for GC is ok for me and should be quite
> > > > portable. Write barriers implementation is already in place, suitable
> > > > for C-based Gc: (Harmony-504 (me), Harmony-581 (Ming Wu)).
> > > >
> > > > As I don't have commiter account, I going to create one JIRA and start
> > > > to fill it with patches. In the patches I will create directory
> > > > enhanced/drlvm/trunk/vm/gcx and will start to fill it with stubs and
> > > > implementation. I am going to do it mostly at spare time.

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