On my Raspberry I did some Performance Tests like CaffeineMark and SciMark with both JVMs. There is a huge performance difference between them even though I have heard that the differences are very small. I also tried calculating with floating numbers and the Oracle JDK got a better Score even though both should support the hard float abi.
I use Linux raspberrypi 3.18.11-v7+
as OS.
OpenJDK:
java version "1.7.0_79"
OpenJDK Runtime Environment (IcedTea 2.5.5) (7u79-2.5.5-1~deb7u1+rpi1)
OpenJDK Zero VM (build 24.79-b02, mixed mode)
OracleJDK:
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) Client VM (build 24.0-b56, mixed mode)
SciMark results:
OpenJDK OracleJDK
Composite Score 14.280735577363213 || 32.24948180361924
FFT (1024) 9.482866845055302 || 26.447121360843663
SOR (100x100) 27.14938943220646 || 59.68022533004399
Monte Carlo 3.6298604956147384 || 10.561671865446971
Sparse matmult 15.603809523809524 || 26.64931580928407
LU (100x100) 15.53775159013005 || 37.90907465247749
I used a program that counts a float in 0.1 steps to 600000. I tried to test the performance of the JVM on handling floats.
OpenJDK: 257ms
OracleJDK: 151ms
0.1 steps to 1200000:
OpenJDK: 457ms
OracleJDK: 263ms
public class Testing {
/**
* @param args
*/
public static long Test()
{
float counter=0.0f;
long startTime = System.currentTimeMillis();
while (counter <= 1_200_000.0f)
{
counter += 0.1f;
}
return System.currentTimeMillis() - startTime;
}
public static void main(String[] args){
System.out.println(Test());
}
}
I tried the enhancements mentioned from SlipperySeal and put the test in the loop. I also tried to use the c2 compiler but the results were not different.
OpenJDK Zero VM is an interpreter only JVM. On the one hand, it's easier to port because it has no architecture specific assembly code but, on the other hand, it's not performant because it has no architecture specific assembly code.
OracleJDK takes advantage of the platform's floating point ABI (Soft Float on RP1 and Hard Float on RP2). I can imagine it has quite an amount of assembly code, specific to the ARM architecture, and that is why it scores better.
A JIT compiler named Shark, based on LLVM, was introduced in OpenJDK Zero VM early on. I'm not sure if your system's OpenJDK was build with Shark but it probably was. It provides a compromise between not having assembly code and still running efficient native code. If Shark is not enabled then building IcedTea with Shark enabled will improve performance. If Shark is enabled then that is the reason why OpenJDK does not suck as much.