harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Date Sun, 22 Apr 2007 23:15:51 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message