How is jProfiler handling JIT?

Question

I use jProfiler extensively and it is a great tool but I am wondering how is jProfiler handling the effects of the JIT compilation.

Am I able to observe for example method inlining? If a method is inlined, it will not be visible in the snapshot at all or is jProfiler still able to compute its execution time?

Similarly, a method that has no side effects and can be fully optimized away will also not be shown in the jProfiler. Is this correct?

I usually profile my applications after quite a long warmup time so I expect the code to be JIT-ed/optimized where possible. Therefore, methods that I suspect that should be optimized away and are yet visible in the profile are always a big mystery for me.

Answer 1

I use jProfiler extensively and it is a great tool but I am wondering how is jProfiler handling the effects of the JIT compilation.

Just-in-time compilation is actually a rather old technology that was replace with the HotSpot adaptive optimizer. A JIT blindly compiles every method from Java bytecode into native code, and may (or may not) be able to optimize it well.

However, an adaptive optimizer looks at how the code runs right now and optimizes only the code that is being executed most often. Because the optimizer is aware of how the code is being used, the optimizer can and does better method inlining, branch prediction, lock coarsening, loop unwinding and more.

Am I able to observe for example method inlining? If a method is inlined, it will not be visible in the snapshot at all or is jProfiler still able to compute its execution time?

JProfiler will not report which methods have been inlined; however, it will happily report their invocations, even if the compiler as placed them inline in another method.

How? Well, during the compilation, the compiler demarcs the method boundaries in the native code. This is essential for the JVM to be able to reconstruct a stack trace when an exception or error occurs. When the JVM is sampled, the JVM responds with stack traces of the executing threads, and so the current method is accurately reported, even if it was inlined.

Similarly, a method that has no side effects and can be fully optimized away will also not be shown in the jProfiler. Is this correct?

You are almost correct. A method with no side effects or computed return value or call to another method with a possible side effect is almost entirely optimized out, but there is a fossil remnant in the JVM that records that the method would have been called. The marginal overhead is extremely small, but has the following interesting characteristics:

1. When sampling, it is highly unlikely that this method will ever be on the stack at the moment of sampling, so most likely will not be detected by jProfiler (or other sampling profilers).
2. When instrumenting, the profiler traces all method calls and will detect the method call. The total cost will be, as mentioned above, trivially small.

The difference in sampling vs. instrumenting is explained in this article.