Rana, I think turning class unloading on is a right step towards the stability. Currently we are in a feature freeze state. Let's turn CU on after the final M3 snapshot is ready.
Thanks, Pavel On 9/24/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > > Hi, > Harmony DRLVM has recently added a class unloading feature. It's now > ready for trial and regular use. It's not on by default, and to turn > on the feature, a couple of options are needed: > -XX:gc.ignore_vtable_tracing=false -XX:gc.force_major_collect=true > > For the hotspot jvm, it's on by default, and one can choose to switch > it off with -Xnoclassgc( benchmarking runs do this ). However, the CU > design in DRLVM is different from the RI. GC tries to unload classes > only when there is heap pressure which has initiated a full > collection. The second option above forces this to happen for every > collection, and is only useful for testing the class unloading code > deterministically. It's not directly related to CU. > For the gc to do vtable tracing to identify unloadable classes in > every gc cycle is too expensive. But keeping class unloading turned > off means that our regular testing does not test these code paths. > With SPecJBB ( 32 bit ) eg., turning on the feature shows me no > variation in performance ( ~1% which is noise ). So, we could make a > decision to turn on the first option by default. In this case, if we > encountered scenarios that really need CU to happen, it would unload > classes. What do you think? > BTW, I have been unable to find a scenario that stresses the gc > heap, and needs to unload unused classes, and it would be good find > such test cases. > > Thanks, > Rana >
