harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Date Mon, 23 Apr 2007 00:07:53 GMT
Ok, let's start another thread to discuss the fat lock resource
reclamation design.


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


View raw message