[JAVA] The story that ARM's processing performance of Open JDK was low

The story that ARM's processing performance of Open JDK was low

When I used the ARM version of Open JDK, the processing speed was slower than the intel version, so Describe the contents of the survey at that time and the sites referred to.

What is JDK (Java Development Environment)?

Development package for Java. In addition to JRE (Java Runtime Environment: environment for executing programs for Java) Contains development software such as compilation for Java.

To JRE JVM (Java Virtual Machine: a virtual environment that runs Java programs) and Contains API (Application interface) for Java.

http://qiita.com/chkkchy/items/3a4594645b3aef7a98b7

Oracle JDK JDK developed by Oracle. There is a charge for commercial use.

A. COMMERCIAL FEATURES. Is described in the column ↓ http://www.oracle.com/technetwork/java/javase/terms/license/index.html

Open JDK An open source version of the JDK where companies other than Oracle are also participating in the development.

After JDK7, OpenJDK and Oracle JDK are basically the same. There is no particular difference if it is about programming normally.

Does Open JDK have low processing performance when the CPU is ARM?

According to the site below, Open JDK is not optimized for ARM, so There is a description that the processing performance is lower than that of Oracle JDK.

https://blogs.oracle.com/jtc/entry/comparing_arm_linux_jvms_revisited

Operation comparison

When the Java program was actually executed with Open JDK and Oracle JDK in the ARM environment on the actual machine, the following results were obtained.

Possibility of slowdown due to deletion of code cache

Since the size of Java code cache (area for temporarily storing compiled code) is small by default, Java functions delete the code cache when the upper limit is exceeded. Since it compiles each time, there seems to be an event that the processing becomes slow.

http://blog.cybozu.io/entry/2016/04/13/080000

Isn't the compilation itself running?

When I checked the compilation status with the jstat command, With Open JDK, it wasn't compiled at all.

*View cumulative JIT compiled tasks
jstat -compiler ${JAVA_PID}Display interval(millisecond)

*View JIT compiled methods
jstat --printcompilation ${JAVA_PID}Display interval(millisecond)

https://docs.oracle.com/javase/jp/6/technotes/tools/share/jstat.html

On the site below, it is stated that the processing delay was improved by disabling the function to delete the code cache in the Java startup option for the following.

In my environment, even if the above measures were taken, the state of not being compiled continued.

http://blog.cybozu.io/entry/2016/04/13/080000

*Display the initial value of Java options, and if code cache is enabled, specify the option to disable code cache deletion
java -XX:+PrintFlagsFinal -version

*Disable code cache deletion
-XX:-UseCodeCacheFlushing

I don't know why, but some Java options are specific to a particular CPU, Is it possible that the option has affected the ARM version so that it is not compiled in the first place?

reference

Recommended Posts

The story that ARM's processing performance of Open JDK was low
This and that of the JDK
[Spring Boot] The story that the bean of the class with ConfigurationProperties annotation was not found
The story of Collectors.groupingBy that I want to keep for posterity
The story that standard output also fatally changes the behavior of the program
A story that struggled with the introduction of Web Apple Pay
A story that confirmed the profile of Yasuko Sawaguchi 36 years ago
A story that I was addicted to twice with the automatic startup setting of Tomcat 8 on CentOS 8
[Java version] The story of serialization
The story of @ViewScoped consuming memory
Was that so, the user_signed_in? method
Order of processing in the program
A memo that was soberly addicted to the request of multipart / form-data
[Java] The story that the expected array was not obtained by the String.split method.
A story that was embarrassing to give anison file to the production environment