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 Wed, 26 Sep 2007 11:50:57 GMT
Rana,

so, you do not have any benchmark that "feels" the change? Maybe you
could publish a relevant microbenchmark? Otherwize I cannot say this
complex change is a "stability fix". It potentially creates more
instability, and performance impact is not measured, right?

On the 0x35C day of Apache Harmony Rana Dasgupta wrote:
> Egor,
> 
> 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
> >
> >
> 

-- 
Egor Pasko


Mime
View raw message