Pavel Ozhdikhin wrote: > 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.
+1 Tim > 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 >> >
