luke warm methods?

[Tom Rodriguez]

From http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/tip/src/share/vm/runtime/globals.hpp

  product(bool, UseCounterDecay, true,                                      \
           "adjust recompilation counters")                                 \
                                                                            \
  develop(intx, CounterHalfLifeTime,    30,                                 \
          "half-life time of invocation counters (in secs)")                \
                                                                            \
  develop(intx, CounterDecayMinIntervalLength,   500,                       \
          "Min. ms. between invocation of CounterDecay")                    \

The core logic of the decay itself is in http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/tip/src/share/vm/runtime/safepoint.hpp around 439.  The decay itself is a divide by 2.

tom

On Apr 21, 2010, at 7:00 PM, kirk wrote:

> Tom Rodriguez wrote:
>> We decay counters periodically since over time counters should only go up so maybe that's the problem.
> that would line up....
>>  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.  I'd be curious to know if turning off decay improves your app.
>>  
> So will I. This is will be my first run in the morning. Out of curiosity, what are the other flags?
> 
> Thanks,
> Kirk
>> tom
>> 
>> On Apr 21, 2010, at 2:35 PM, Kirk Pepperdine wrote:
>> 
>>  
>>> Hi,
>>> I've a situation where an application I'm looking at runs slow under low load. After a number of tests the problem seems to be related to hotspot optimizations. I ran a low level load test against the application for 8+ hours without any apparent meaningful optimization performed by hotspot. Once the load was increased hotspot immediately kicks in and life it good. Here's were it gets fun. I can put a short burst traffic on the server at any time (including immediately after startup) and I will see an improvement in response times. However, without that burst of traffic, response times remain suboptimal. This happens even though the workload performed during the 8+ hour run is greater than that performed during the burst.
>>> More info, I watched the output from LogCompilation during a run. It showed hotspot working for a while but then as expected, it stopped compiling stuff. When I bursted traffic hotspot started compiling methods that had not been compiled prior. Pretty much what I expected to see. I just don't know why. It suggests that there is more than just the compile threshold involved. I'd be happy if someone could share a plausable explination for the observation?
>>> TIA,
>>> Kirk
>>>    
>> 
>> 
>>  
>