Is there a way to tell from within the JVM whether a particular method has been JIT compiled?

Question

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.

Answer 1

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.

Answer 2

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.