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 <[EMAIL PROTECTED]> 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
