jitwatch | Log analyser / visualiser for Java HotSpot JIT compiler

(note: proper answer must go beyond reproduction).

After millions of invocations, quicksort1 is definitely faster than quicksort2, which have identical code aside from this 1 extra arg.

The code is at the end of the post. Spoiler: I also found the jit code is fatter by 224 bytes even if it should be actually simpler (like the byte code size tells; see very last update below).

Even after trying to factor out this effect with some microbenchmark harness (JMH), the performance difference is still there.

I'm asking: WHY is there a such a difference in native code generated and what is it doing?

By adding an argument to a method, it makes it faster...! I know about gc/jit/warmup/etc effects. You can run code as-is, or with larger/smaller iteration counts. Actually, you should even comment out one then the other perf test and run each in distinct jvm instance just to prove it's not an interference between each other.

The bytecode doesn't show much difference, aside the obvious getstatic for sleft/sright but also a strange 'iload 4' instead of "iload_3" (and istore 4/istore_3)

What the heck is going on? Is the iload_3/istore_3 really slower than iload 4/istore 4? And that much slower that even the added getstatic call is still not making it slower? I can guess that static fields are unused so the jit might just skip it.

Anyway, there is no ambiguity on my side as it is always reproducable, and I'm looking for the explanation as to why the javac/jit did what they did, and why the performance is affected so much. These are identical recursive algo with same data, same memory churn, etc... I couldn't make an more isolated change if I wanted to, to show a significant replicable runtime difference.

Env:

my code is here =>

Let's assume we have the following code:

Here's the example I tried to reproduce from Java Performance: The Definitive Guide, Page 97 on the topic of Escape Analysis. This is probably what should happen:

1. getSum() must get hot enough and with appropriate JVM parameters it must be inlined into the caller main().
2. As both list and sum variables do not escape from main() method they could be marked as NoEscape hence JVM could use stack-allocation for them instead of heap-allocation.

But I ran it through jitwatch and the result showed that getSum() compiles into native-assembly and doesn't get inlined into main(). Not to mention consequently stack-allocation didn't happen either.

What am I doing wrong in here ? (I have put the whole code and hotspot log here.)

Here's the code:

I'm bench-marking Chronicle queue for one of our use cases and noticed that readDocument() API of the ExcerptTailer creates too much garbage! JFR shows that the process spends around 66% of the time in the stack below.

What version of Chronicle Queue am I using ?

net.openhft:chronicle-queue:4.5.9

How am I creating the queue ?

I am trying to use JITWatch to see how assembler code corresponds to original Java source code. However, JITWatch does not seem to see my assembly code and prints the following message:

Assembly not found. Was -XX:+PrintAssembly option used?

I am using Oracle's JRE 1.8.0_121 on Windows 10 Home. I've added dissembly dll's to my JRE. The dll's were downloaded from FCML project. I can confirm that assembly is generated when I run program with java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly test.Test options.

I've configured JITWatch paths so that *.java and *.class files are visible to it. For JITWatch analysis I run my Java program with java -XX:+UnlockDiagnosticVMOptions -XX:+TraceClassLoading -XX:+LogCompilation -XX:+PrintAssembly test.Test and open the generated .log file with JITWatch. It can see the Java code and bytecode, but not the assembly. I suspect the problem is caused by the fact that assembly is printed to standard output (to the console) and not to log file. Is there an option I am missing?