CompileThreshold & BackEdgeThreshold question(s)
Charlie Hunt
chunt at salesforce.com
Fri Aug 3 12:01:06 PDT 2012
Igor, et.al.
Exactly what I was looking for!
You just saved me a *lot* of time looking at (and figuring out) compiler code. :-)
Much appreciated!
charlie ...
On Aug 3, 2012, at 1:56 PM, Igor Veresov wrote:
On Aug 3, 2012, at 11:38 AM, Kirk Pepperdine wrote:
On 2012-08-03, at 8:34 PM, Igor Veresov <iggy.veresov at gmail.com<mailto:iggy.veresov at gmail.com>> wrote:
Each method has two counters in a methodOop. One that counts invocations (method entries), the other one counts the number of backward branches taken within this method (loop iterations).
what happens if the method contains two (or more) loops? They both use the same counter? I guess for an OSR it doesn't matter which loop is holding things up.
Yup. So, it's actually a bit of a gamble, you can end up with multiple OSR compiles (each of which will only support entry if a method is currently at a specific bci). This is true for the tiered policy too. But there's no lock-free way of doing that differently.
For non-tiered policy a method is compiled if the inv_count > CompileThreshold, an OSR will happen if inv_count + bb_count > BackEdgeThreshold on a backward branch. Profiling will start at 33% of these values (InterpreterProfilePercentage).
Oops, just looked at source, I lied here. Non-tiered will do a normal compiler when inv_count + bb_count > CompileThreshould, so there's also a sum of these counters there.
Also keep in mind that for non-tiered policy all these counters are decayed at each safepoint. So there's an invocation frequency limit below which a method will never get compiled.
For tiered it's a bit more complicated. ;)
oh then don't stop there.... :-)
That's a lot to type… :) Basically the thresholds are dynamic. And the predicates are more involved.
Can I just point to you to a big fat comment at the top of this file, since I've already done the typing once: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/file/b72784e722ff/src/share/vm/runtime/advancedThresholdPolicy.hpp
Also, I'm not sure if it's mentioned in the comments, but tiered doesn't have the counter decay. Instead, there's another subsystem in hotspot now, that is called the "code cache flushing" that would GC methods that haven't been used for a while.
igor
Kirk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120803/ef6e0352/attachment.html
More information about the hotspot-compiler-dev
mailing list