Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of xiaofeng.li@gmail.com
 designates 66.249.82.227 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=rBuiZjqAM3wOtl6AK8G0NffjTKTL0xBrWLyCDaD98qiyAr58hKi/pkoEqgs9ZFH22b1+spHPMXm1xgHXuMfQfcBmI07QcC+zjPRaT7M/y99O9aB3H+N0YN9mdPwb5YQsdM0JJZgJHr/x9x+98xul5DZuFZQNxWihL07HvRDP8og=
Message-ID: <9623c9a50704221707p42a8a688i78c4f2fdc118d2ec@mail.gmail.com>
Date: Mon, 23 Apr 2007 08:07:53 +0800
From: "Xiao-Feng Li" <xiaofeng.li@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
In-Reply-To: <4dd1f3f00704221615s79755baem301e2983d9ffd78@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: <9623c9a50704220429t40bc53a7if34d0e2363e069d5@mail.gmail.com>
	 <4dd1f3f00704221615s79755baem301e2983d9ffd78@mail.gmail.com>

Ok, let's start another thread to discuss the fat lock resource
reclamation design.

Thanks,
xiaofeng

On 4/23/07, Weldon Washburn <weldonwjw@gmail.com> wrote:
> Xiao Feng,
>
> I think the below is a good idea.  I would very much like to use GCV5 to
> solve a fat lock design problem.  However, we need to wait until GCV5 is the
> default collector.
>
> For those who have not looked at the code, DRLVM "malloc()s" little C
> structs to hold inflated java object locks.  Currently these C structs are
> never reclaimed.  It seems to be a classic GC kind of problem.  The concept
> is to use a variant of finalizer to discover when a java object is no longer
> reachable and thus invoke C code that calls "free(fat_lock);".
>
> We probably should have a design discussion regarding GC support for
> reclaiming native resources on the dev list.  In addition to reclaiming fat
> locks, there are probably other native resources that can benefit from the
> GC's knowledge of java object lifecycle.  (Class unloading?
> DirectByteBuffer??)  It would be nice to create a general interface for
> releasing internal DRLVM native resources that are tied to java objects.
>
>
>
>
> On 4/22/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> >
> > Hi, folks, I've made the switch of default DRLVM GC component from
> > GCv4.1 (gc_cc) to GCv5 (gc_gen) yesterday. This switch is only trial
> > for one week experiment. If things go well, it might be the default GC
> > from then on; otherwise, it will be switched back waiting for next
> > chance after JavaOne. (We do not know the switch result yet, since the
> > testing infrastructure looks to be resting in weekends.)
> >
> > To make the switch is to bring Apache Harmony an advanced GC module
> > which has state-of-the-art design and implementation as a
> > stop-the-world GC. Basically, GCv5 is fully parallel in all phases of
> > garbage collection, with a couple of dynamic runtime adaptation
> > innovations to improve the throughput. GCv5 supports both generational
> > and non-generational mode. Experiments showed good performance
> > improvement over GCv4.1 for most workloads on parallel machines.
> >
> > I have put a quick overview of Harmony GCv5 at
> > http://people.apache.org/~xli/docs/harmony_gcv5_overview.pdf . A basic
> > design principle of GCv5 is to be modular (or open). This is a big
> > difference from GCv4.1. Hope it could lay a good foundation for the
> > community to develop more sophisticated GC technologies. As I know,
> > there are two university projects already using GCv5 for their
> > Harmony-based research.
> >
> > We would expect some regressions during the transition phase. Let's
> > promptly fix the bugs exposed, and try to make the switch smooth.
> >
> > Thanks,
> > xiaofeng
> >
>
>
>
> --
> Weldon Washburn
>


-- 
http://xiao-feng.blogspot.com