Java 7 JVM slower than JRockit 6?

Question

I was very interested in upgrading to Java 7 (for my own selfish coding reasons). However, we have users who are very latency sensitive (everything needs to be sub-millisecond). I did a simple performance comparison test between 3 different JVMs and found Java 7 to be so much slower. The test pushed some simple messages through our application. This test is a low load, load volume test, which pushes a single message through, every few seconds. The results were (in microseconds):

 - Hotspot 6 (build 24): msgs= 23 avg= 902 
 - JRockit 6 (R28 b 29): msgs= 23 avg= 481 
 - Hotspot 7 (build 04): msgs= 34 avg=1130

Oracle's strategy is to merge JRockit and Hotspot starting with Java 7 (so JRockit 6 is the last available). Does anyone have any ideas why the performance is so much worse? (One point to note, is that the code was compiled under Java 1.6. Not sure if that would explain it...)

UPDATE: I voted to close my own question because I can see from the comments that I am not really able to communicate enough info to make this a constructive question. Thanks to all who commented.

UPDATE: After more feed back, I thought I would provide more info. Test is always after a fresh start. All factors are equal for each test. The only thing which changes is JVM. Repeating test multiple times gives consistent result. No GCs occurred in any test iteration.

Below is graphed values of one of the test runs. For both JRockit and Hotspot 7, the very first latency value was thrown out. JRockit has huge first value, but then very quickly optimizes and settles toward mean. Hotspot 7 takes longer to optimize, and never drops to a mean as low as JRockit. Each data point represents microseconds to read a message from TCP/IP socket, run through business logic, and write message on another socket. Every message is identical, and no new code paths are entered for any message.

Answer 1

JRockit is its own (pure C) code base different from the OpenJDK. It contains different garbage collectors, and a totally different JIT compiler. One big monetizer when it was owned by BEA was low latency GC, which is quite advanced, even in the non commercial variants. A significant amount of time has been spent on JRockit as a clean room vm implementation. As has been said in the comments, it's not as much a matter of merging as reimplementing stuff in the HotSpot code base. This is far from a fast process and some of the things will not get there at all, at least not in their in their JRockit form. Puzzle pieces do not readily fit without some filing at the edges, so to speak. JDK7 Hotspot, will be good at other things, or different versions of the similar systems, however that might make up for some of your lost performance. Other applications may well run faster than with JRockit 6.

If you are interested in learning more about the JRockit (or any JVM) internals, the book "Oracle JRockit the definitive guide" is a highly recommended read. Full disclosure, I probably get ~$2 before taxes in royalty for each copy and will use it to buy espresso. :)

Answer 2

The main thrust of this question was, all other things being equal (including the JVM args) why does the same JAR of Java code run so much more slowly with Hotspot 7 JVM than with JRockit 6 and Hotspot 6.

This gave rise to a few responses concerned about whether the timing was done correctly (apparently due to people's skepticism that there could really have such a different result between the JVMs). Based on numerous tests, there is no question in my mind that the measurements are correct.

Potential answers I thought possible were:

• Java 7 JVM does not run code compiled under Java 6 as fast as the same code compiled under Java 7
• new JVM args are required for Java 7 to run in most optimized mode possible
• Other people have benchmarked Java 7 against JRockit 6 and seen same result as I did

So the fact is, the new Java 7 JVM behavior is very different with our app, all other things being equal. The only resolution is to profile the code against the Java 7 VM, to discover where the slow points are in the code. (And perhaps at that point, it will be clear what the actual difference between Java 6 JVM and Java 7 JVM was/is).

I appreciate everyone's comments, and apologize that I couldn't provide enough detail for a clear analysis/resolution.