6

When writing microbenchmarks, one can observe a large difference in runtime depending on whether a method has been compiled or not. Is there a way to tell from within a program whether a particular method has been compiled? Alternatively, is there a way to request it, or to know how to warm it up adequately without any extra information about e.g. flags passed to the JVM? Obviously this will not necessarily be perfect (e.g. there may be some condition present that causes the JVM to fall back to interpreted code), but it would certainly be an improvement.

Rex Kerr
  • 166,841
  • 26
  • 322
  • 407
  • You could empirically measure the execution time of the method and check the distribution of results. You will typically have a jump when it gets compiled. There was a question on SO about this methodology but I can't find it right now. Obviously, this is somewhat obtrusive. – assylias Nov 17 '12 at 22:37
  • I'm almost positive the answer is "no, definitely not." – Louis Wasserman Nov 17 '12 at 23:07
  • @assylias - That only works if you are certain that the method hasn't already been compiled. Otherwise there's no jump to find. Also, robust change-detection algorithms are a pain to code. – Rex Kerr Nov 17 '12 at 23:14

2 Answers2

3

For Sun/Oracle JVM you can use the -XX:CompileThreshold=1000 setting.

This - as the official documentation states - defines:

Number of method invocations/branches before compiling

Then, just use the number to "warm up" the JVM.

You can also use the -XX:-PrintCompilation together with -XX:CompileThreshold in order to be notified (in the console) when a method is compiled.

npe
  • 15,395
  • 1
  • 56
  • 55
  • What is a "branch", as counted by the JVM? – Rex Kerr Nov 17 '12 at 23:16
  • @RexKerr -- The JVM attempts to estimate how much time is being spent in the method (and hence how much advantage there would be to compiling it), mainly by counting entries and backward branches (which would indicate loops). But there may be other factors that are included. – Hot Licks Nov 18 '12 at 00:43
  • Well, this looks like the best answer available, unsatisfying though it may be. Thanks! – Rex Kerr Dec 06 '12 at 13:07
1

I'm pretty sure you can turn on logging that will show when methods are JITCed. But I don't know of any way from within Java to tell.

And keep in mind that JIT compilation is not an event but a process -- a method may be recompiled several times, as more information about its characteristics becomes available.

Finally, note that "warming up" is iffy in the general case. While you can usually "warm up" a single method reliably, it's much harder with even a modestly large application, due to a number of factors.

(Though I don't know of any reason why the ability to read some sort of JITC status for a method could not be added to embedded debug tools.)

Added: One thing to beware of, when benchmarking code "snippets", is that the outer-most method that does all the looping is often not JITC-able (depending on how the JITC is implemented) due to the fact that it never returns and hence the JITCed version can never be called. So one should always place the "meat" of the code to be benchmarked in a separate method that is called repeatedly, vs putting the loop and the to-be-benchmarked code in the same method.

Hot Licks
  • 47,103
  • 17
  • 93
  • 151
  • I did specify "microbenchmark". Larger applications are harder to pin down. – Rex Kerr Nov 17 '12 at 23:18
  • Indeed. One also should be aware of garbage collection, whether your test case has the expected level of multiple dispatch for real code, whether results are being discarded and thus code could be elided, etc. etc...even microbenchmarks are not simple to get right! – Rex Kerr Nov 18 '12 at 14:35