[JAVA] Die Geschichte, dass die Verarbeitungsleistung von ARM von Open JDK niedrig war

Die Geschichte, dass die Verarbeitungsleistung von ARM von Open JDK niedrig war

Als ich die ARM-Version von Open JDK verwendete, war die Verarbeitungsgeschwindigkeit langsamer als die Intel-Version Beschreiben Sie den Inhalt der Umfrage zu diesem Zeitpunkt und die Websites, auf die verwiesen wird.

Was ist JDK (Java Development Environment)?

Entwicklungspaket für Java. Zusätzlich zu JRE (Java Runtime Environment: Umgebung zum Ausführen von Programmen für Java) Enthält Entwicklungssoftware wie die Kompilierung für Java.

Zu JRE JVM (Java Virtual Machine: eine virtuelle Umgebung, in der Java-Programme ausgeführt werden) und Enthält API (Application Interface) für Java.

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

Oracle JDK JDK von Oracle entwickelt. Für die kommerzielle Nutzung wird eine Gebühr erhoben.

A. KOMMERZIELLE EIGENSCHAFTEN Wird in der Spalte ↓ beschrieben http://www.oracle.com/technetwork/java/javase/terms/license/index.html

Open JDK Eine Open-Source-Version des JDK, an der auch andere Unternehmen als Oracle beteiligt sind.

Nach JDK7 sind sowohl Open JDK als auch Oracle JDK grundsätzlich gleich. Es gibt keinen besonderen Unterschied, solange es normal programmiert ist.

Hat Open JDK eine geringe Verarbeitungsleistung, wenn die CPU ARM ist?

Laut der folgenden Site ist das Open JDK nicht für ARM optimiert. Es gibt eine Beschreibung, dass die Verarbeitungsleistung niedriger ist als die des Oracle JDK.

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

Betriebsvergleich

Wenn das Java-Programm tatsächlich mit Open JDK und Oracle JDK in der ARM-Umgebung auf dem tatsächlichen Computer ausgeführt wurde, wurden die folgenden Ergebnisse erzielt.

Möglichkeit der Verlangsamung durch Löschen des Code-Cache

Da die Größe des Java-Code-Cache (Bereich zum temporären Speichern von kompiliertem Code) standardmäßig klein ist, löschen Java-Funktionen den Code-Cache, wenn die Obergrenze überschritten wird. Da es jedes Mal kompiliert wird, scheint es ein Phänomen zu geben, dass die Verarbeitung langsam wird.

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

Läuft die Kompilierung nicht selbst?

Als ich den Kompilierungsstatus mit dem Befehl jstat überprüfte, Mit Open JDK wurde es überhaupt nicht kompiliert.

*Zeigen Sie kumulative JIT-kompilierte Aufgaben an
jstat -compiler ${JAVA_PID}Anzeigeintervall(Millisekunde)

*JIT-kompilierte Methoden anzeigen
jstat --printcompilation ${JAVA_PID}Anzeigeintervall(Millisekunde)

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

Auf der folgenden Site wird angegeben, dass die Verarbeitungsverzögerung durch Deaktivieren der Funktion zum Löschen des Code-Caches in der Java-Startoption für Folgendes verbessert wurde.

In meiner Umgebung wurde der Zustand der Nichterstellung fortgesetzt, selbst wenn die oben genannten Maßnahmen ergriffen wurden.

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

*Zeigt den Anfangswert der Java-Optionen an. Wenn das Code-Caching aktiviert ist, geben Sie die Option zum Deaktivieren des Löschens des Code-Cache an
java -XX:+PrintFlagsFinal -version

*Deaktivieren Sie das Löschen des Code-Cache
-XX:-UseCodeCacheFlushing

Ich weiß nicht warum, aber einige Java-Optionen sind spezifisch für eine bestimmte CPU. Ist es möglich, dass die Option die ARM-Version beeinflusst hat, sodass sie überhaupt nicht kompiliert wird?

Referenz

Recommended Posts

Die Geschichte, dass die Verarbeitungsleistung von ARM von Open JDK niedrig war
Dies und das von JDK
[Spring Boot] Die Geschichte, dass die Bean der Klasse mit der Annotation ConfigurationProperties nicht gefunden wurde
Die Geschichte von Collectors.groupingBy, die ich für die Nachwelt behalten möchte
Die Geschichte, dass die Standardausgabe auch das Verhalten des Programms tödlich verändert
Eine Geschichte, die mit der Einführung von Web Apple Pay zu kämpfen hatte
Eine Geschichte, der ich mit der automatischen Starteinstellung von Tomcat 8 unter CentOS 8 zweimal verfallen war
[Java Edition] Geschichte der Serialisierung
Die Geschichte von @ViewScoped, die Speicher verschlingt
Reihenfolge der Verarbeitung im Programm
Ein Memo, das nüchtern von der Anfrage nach mehrteiligen / Formulardaten abhängig war
[Java] Die Geschichte, dass das erwartete Array nicht von der String.split-Methode erhalten wurde.