[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-dev
Subject:    luke warm methods?
From:       tom.rodriguez () oracle ! com (Tom Rodriguez)
Date:       2010-04-30 0:07:46
Message-ID: ACFCA89D-2D83-4D2B-9DC5-1E2B395240C4 () oracle ! com
[Download RAW message or body]


On Apr 29, 2010, at 2:30 AM, Vikram A wrote:

> Please wait for Thomas's comments on this, but I would like to know...
> Shouldn't TieredCompilation help perform better in such cases...
> 
> http://blogs.sun.com/fatcatair/entry/tiered_compilation_almost_live

Tiered definitely would help since you'd get to C1 quality code very quickly but you \
still might not transition to C2 quality code, leaving some performance on the floor. \
We'll also probably revisit the decay logic since we've changed how invocation \
counters operate a bit and I think simply decaying them doesn't really make sense.  \
I'm not sure it makes a lot of sense in the first place I guess.

tom

> 
> thanks,
> Vikram.
> 
> On Thu, Apr 29, 2010 at 2:32 PM, Ben Evans <ben.evans at db.com> wrote:
> > 
> > hotspot-dev-bounces at openjdk.java.net wrote on 22/04/2010 00:42:28:
> > 
> > > We decay counters periodically since over time counters should only
> > > go up so maybe that's the problem.  If you run with -XX:-
> > > UseCounterDecay it will turn it off but all the other flags that
> > > control it aren't available in product mode. This is certainly one
> > > of the pathologies of an invocation counter based system with
> > > relatively high thresholds.
> > 
> > Just so I'm clear, this doesn't affect the compiled status of methods,
> > right?
> > 
> > What's being discussed here is that if an initial burst of activity results
> > in a method being called say 4096 times (vs a threshold of 10000), then
> > after 1 minute, then that method has had its invocation counter reduced to
> > 1024.
> > 
> > So the usual scenario whereby HotSpot reaches a steady state in terms of
> > compilation activity can be disrupted by a sudden flurry of activity on
> > rarely-used methods (which will be effectively cold due to the decay
> > process), which pushes the invocation counts of these methods above
> > compilation threshold. If these methods then go quiet again, then HS will
> > *not* deoptimize and drop these methods back to interpreted mode, even if
> > their invocation counters subsequently decay below threshold. Correct?
> > 
> > Thanks,
> > 
> > Ben
> > --
> > Ben Evans
> > GFFX Auto Trading
> > Deutsche Bank, London
> > Office: +44 (0)20 7541 3953
> > 
> > ---
> > 
> > This e-mail may contain confidential and/or privileged information. If you
> > are not the intended recipient (or have received this e-mail in error)
> > please notify the sender immediately and delete this e-mail. Any
> > unauthorized copying, disclosure or distribution of the material in this
> > e-mail is strictly forbidden.
> > 
> > Please refer to http://www.db.com/en/content/eu_disclosures.htm for
> > additional EU corporate and regulatory disclosures.
> > 


[prev in list] [next in list] [prev in thread] [next in thread]