harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [drlvm]Leave classunloading on by default?
Date Tue, 25 Sep 2007 06:54:59 GMT
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


Mime
View raw message