harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [drlvm]Leave classunloading on by default?
Date Mon, 24 Sep 2007 08:36:23 GMT
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 <rdasgupt@gmail.com> 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
>>
> 

Mime
View raw message