harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm]Leave classunloading on by default?
Date Tue, 25 Sep 2007 17:36:22 GMT

On 25 Sep 2007 10:54:59 +0400, Egor Pasko <egor.pasko@gmail.com> wrote:
> Rana,
> what do you mean ny saying 1) too expensive 2) shows me no variation
> in performance? So, is it expensive or not?

I think that the reason that witching on CU does not show any impact
on performance of SpecJBB( 32) is that it does not cause any
significant number of full collections and has no classes to unload.
As such, it is not a great test case for class unloading. A good test
scenario would be one that did both. There will be some tradeoff of
performance loss against memory footprint reduction of this feature
that only good scenarios will help tune.

> 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.

Yes, I agree with this. Overall, Pavel's comment to turn on CU as a
memory leak oriented stability feature post M3 sounds sensible. I'll
do this, we can commit the change after M3.

> 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

View raw message