harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Ozhdikhin" <pavel.ozhdik...@gmail.com>
Subject Re: [drlvm]Leave classunloading on by default?
Date Mon, 24 Sep 2007 05:54:32 GMT

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.


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message