On the 0x35B day of Apache Harmony Rana Dasgupta 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?
Rana, what do you mean ny saying 1) too expensive 2) shows me no variation in performance? So, is it expensive or not? how about DaCapo? would this change be within a noise level for DaCapo? Let's ask performance people, most likely, they know :) Taking only SpecJBB into accout is not enough to consider the change that potentially affects performance to a big extent. > 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. BTW, why dont't we start measuring memory footprint of the JVM? The strategy of our performance testing is AFAIR: 1) add infinite number of memory 2) measure ticks but none of us would notice if the stuff grows to a memory eating pig, so real user experience would be constant swapping. BTW2: does anybody update [1] regularly? if so, dear updater, do you think, it is reasonable to add the column "memory footprint"? [1] http://harmony.apache.org/performance.html -- Egor Pasko
