Was macht die java virtuelle Maschine den ganzen Tag?

Dieser Artikel wurde ursprünglich von Ampere Computing

veröffentlicht

Ich habe kürzlich einen Blog -Beitrag über Gprofng gesehen, ein neues Tool für GNU -Leistungsanalyse. In diesem Blog wird ein Matrixvektor -Multiplikationsprogramm verwendet, das als Beispiel in C -Sprache geschrieben wurde. Ich bin ein Java ™ -Programmierer, und die Verwendung von Tools, die für die statisch kompilierte C -Programmierung entwickelt wurden, ist häufig schwierig, Java -Anwendungen zu analysieren, da Java -Programme zur Laufzeit zusammengestellt werden. In diesem Blog -Beitrag werde ich zeigen, dass GPROFNG einfach zu bedienen ist und sehr nützlich ist, um sich mit dem dynamischen Verhalten von Java -Anwendungen zu befassen.

Der erste Schritt besteht darin, ein Matrix -Multiplikationsprogramm zu schreiben. Ich habe ein komplettes Matrix -Multiplikationsmatrixprogramm geschrieben, da es nicht schwieriger ist als die Matrix -Multiplikationsvektoren. Es gibt drei Hauptmethoden: Eine Methode berechnet die innerste Multiplikation und den Additionsbetrieb, eine Methode kombiniert die Multiplikation und den Additionsbetrieb in ein einzelnes Element des Ergebnisses, und eine Methode iteriert über jedes Element des Ergebniss.

Ich wickle die Berechnungen in ein einfaches Testprogramm ein, um das Matrixprodukt wiederholt zu berechnen, um sicherzustellen, dass die Zeit wiederholbar ist. (Siehe Anmerkung 1.) Das Programm druckt die Zeit aus, in der jede Matrixmultiplikation beginnt (relativ zu der Zeit, in der die virtuelle Java -Maschine gestartet wird) und die Zeit, die für jede Matrix -Multiplikation benötigt wird. Hier habe ich das Testprogramm durchgeführt, um zwei 8000 × 8000 -Matrizen zu multiplizieren. Das Testerprogramm wiederholte die Berechnung 11 Mal und um das nachfolgende Verhalten besser hervorzuheben, schlafe zwischen 920 Millisekunden zwischen Wiederholungen:

$ numactl --cpunodebind=0 --membind=0 -- \
java -XX:+UseParallelGC -Xms31g -Xmx31g -Xlog:gc -XX:-UsePerfData \
  MxV -m 8000 -n 8000 -r 11 -s 920

Abbildung 1: Ausführen des Matrix -Multiplikationsprogramms

Bitte beachten Sie, dass die zweite Wiederholung 92% der Zeit der ersten Wiederholung dauert, während die letzte Wiederholung nur 89% der Zeit der ersten Wiederholung dauert. Diese Änderungen der Ausführungszeit bestätigen, dass Java -Programme einige Zeit benötigen, um sich aufzuwärmen.

Die Frage lautet: Kann ich GPROFNG verwenden, um zu sehen, was zwischen den ersten und letzten Wiederholungen passiert, was zu Leistungsverbesserungen führt?

Eine Möglichkeit, diese Frage zu beantworten, besteht darin, das Programm auszuführen und GPROFNG Renneninformationen zu sammeln. Glücklicherweise ist dies einfach: Ich muss nur die Befehlszeile vorabfixieren, um das zu erfassen, was Gprofng "experimentelle" Informationen nennt:

$ numactl --cpunodebind=0 --membind=0 -- \
gprofng collect app \
    java -XX:+UseParallelGC -Xms31g -Xmx31g -Xlog:gc --XX:-UsePerfData \
        MxV -m 8000 -n 8000 -r 11 -s 920

Abbildung 2: Ausführen des Matrix -Multiplikationsprogramms unter Gprofng

Das erste, was zu beachten ist, ist, dass das Sammeln von Leistungsanalyseinformationen wie bei jedem Leistungsanalyse -Tool die Anwendung kosten kann. Im Vergleich zu früheren nicht analysierten Läufen scheint GPROFNG keinen signifikanten Aufwand zu verursachen.

Ich kann dann fragen, wie die Zeit in Gprofng die gesamte Anwendung verbracht wird. (Siehe Anmerkung 2.) Für den gesamten Lauf sind die 24 beliebtesten Methoden von GPROFNG:

$ gprofng display text test.1.er -viewmode expert -limit 24 -functions

Abbildung 3: 24 Möglichkeiten, die heißesten Gprofng

zu zeigen

Die oben gezeigte Funktionsansicht ergibt die exklusive und Einschluss -CPU -Zeit für jede Methode, die im Prozentsatz von Sekunden und der gesamten CPU -Zeit ausgedrückt wird. Die benannte Funktion ist eine von GPROFNG erzeugte Pseudofunktion mit dem Gesamtwert verschiedener Indikatoren. In diesem Fall sehe ich, dass die gesamte CPU -Zeit der gesamten Anwendung 1,201 Sekunden beträgt.

Anwendungsmethoden (die aus der MXV -Klasse) sind alle darin und belegen den größten Teil der CPU Das Matrix -Multiplikationsprogramm. Diese Anzeige der gesamten Programmausführung erfasst die Zuordnung (MXV.alcode) und die Initialisierung (mxv.initialize), die mich nicht sehr interessiert, da sie Teil des Testprogramms sind, nur während des Starts verwendet und vervielfacht werden Mit Matrix ist es kaum wichtig.

Ich kann GPROFNG verwenden, um den Teilen der Anwendung zu folgen, an denen ich interessiert bin. Ein großartiges Merkmal von GPROFNG ist, dass ich nach dem Sammeln von Experimenten den Filter auf die gesammelten Daten anwenden kann. Schauen Sie sich beispielsweise an, was während eines bestimmten Zeitintervalls passiert oder was passiert, wenn sich eine bestimmte Methode auf dem Anrufstapel befindet. Zu Demonstrationszwecken und um die Filterung zu vereinfachen, fügte ich einen strategischen Aufruf zum Thread hinzu. Aus diesem Grund liegt der Programmausgang in Abbildung 1 zwischen jeder Wiederholung ungefähr eine Sekunde, auch wenn jede Matrixmultiplikation nur etwa 0,1 Sekunden dauert.

gprofng ist skriptierbar, daher habe ich ein Skript geschrieben, um eine einzige Sekunde aus dem Gprofng -Experiment zu extrahieren. In der ersten Sekunde dreht sich alles um das Start von Java Virtual Machine.

Abbildung 4: Die heißeste Methode zum Filtern der ersten Sekunde. In dieser Sekunde wurde die Matrix -Multiplikation manuell verzögert, sodass ich JVM -Startup

zeigen kann

Ich kann sehen, dass der Compiler zur Laufzeit beginnt (z. B. Compilation :: compile_java_method, 16% der CPU -Zeit), auch wenn eine Methode der Anwendung noch nicht ausgeführt wurde. (Der Matrix -Multiplikationsaufruf wurde durch den Schlafanruf verzögert, den ich eingefügt habe.)

Die erste Sekunde ist eine Sekunde, in der die Allokations- und Initialisierungsmethoden mit verschiedenen JVM -Methoden ausgeführt werden, der Matrix -Multiplikationscode jedoch noch nicht gestartet wurde.

Abbildung 5: Die heißeste Methode in der zweiten Sekunde. Matrixzuweisung und Initialisierung konkurrieren mit JVM Startup

Nachdem das JVM -Start und die Zuweisung und Initialisierung des Arrays abgeschlossen wurden, gibt es in der dritten Sekunde die erste Wiederholung des Matrix -Multiplikationscodes, wie in Abbildung 6 gezeigt. Beachten Sie jedoch, dass der Matrix -Multiplikationscode mit dem Java -Laufzeit -Compiler (z. B. CompileBroker :: Invoke_Compiler_on_Method, 8% in Abbildung 6) konkurriert, der die Methoden zusammenstellt, da der Matrix -Multiplikationscode als heiß ist.

Trotzdem erhält der Matrix -Multiplikationscode (z. B. "Zeit" die Zeit in der mxv.main -Methode, 91%) immer noch den größten Teil der CPU -Zeit. Die Einschlusszeit zeigt an, dass die Matrixmultiplikation (z. B. mxv.multiply) 0,100 CPU -Sekunden dauert, was mit der tatsächlichen Zeit übereinstimmt, die in Abbildung 2 von der Anwendung angegeben ist. (Es dauert einige Zeit, um die tatsächliche Zeit zu sammeln und zu melden, die außerhalb der CPU -Zeit liegt.

Abbildung 6: Die heißeste Methode in der dritten Sekunde, die darauf hinweist In diesem speziellen Beispiel konkurriert die Matrix -Multiplikation nicht wirklich um die CPU -Zeit, da die Tests auf einem Multiprozessor -System mit einer großen Anzahl von Leerlaufzyklen durchgeführt werden und der Laufzeit -Compiler als separates Faden ausgeführt wird. In restriktiveren Fällen, wie beispielsweise auf gemeinsamen Maschinen mit schweren Lasten, können 8% der Zeit, die der Compiler der Laufzeit aufgewendet hat, ein Problem sein. Andererseits führt die Zeit, die im Laufzeit Compiler verbracht wird, zu einer effizienteren Methodenimplementierung. Wenn ich also viele Matrix -Multiplikationen berechne, wäre es eine Investition, die ich tätigen möchte.

In der fünften Sekunde verfügt der Matrix -Multiplikationscode über die virtuelle Java -Maschine.

Abbildung 7: Alle Methoden werden in der fünften Sekunde ausgeführt, was darauf hinweist, dass nur die Matrix -Multiplikationsmethode aktiv ist

Bitte beachten Sie die 60%/30%/10% -Allokation zwischen mxv.onecell, mxv.multiplyadd und mxv.multiply in Bezug auf exklusive CPU -Sekunden. Die mxv.multiplyadd -Methode berechnet nur die Multiplikation und die Addition: Es ist jedoch die innerste Methode bei der Matrixmultiplikation. Mxv.onecell hat eine Schleife, um mxv.multiplyadd zu rufen. Ich kann sehen, dass Schleifenaufwand und Anruf (Bewertungsbedingungen und Kontrollübertragung) relativ mehr funktionieren als direkte arithmetische Operationen in mxv.multiplyadd. (Mxv.onecell hat eine exklusive Zeit von 0,060 CPU -Sekunden, während mxv.multiplyadd 0,030 CPU -Sekunden beträgt, was diesen Unterschied widerspiegelt.) Die Ausführungsfrequenz der äußeren Schleife in mxv.multiply ist nicht hoch genug, dass der Laufzeit -Compiler es noch nicht zusammengestellt hat. Aber die Methode verwendet 0,010 CPU -Sekunden. Die matrix -Multiplikation

wird bis in die neunte Sekunde fortgesetzt, wenn der JVM -Laufzeit -Compiler erneut beginnt und feststellt, dass Mxv.multiply sehr heiß geworden ist.

In der letzten Wiederholung nutzt der Matrix -Multiplikationscode die java virtuelle Maschine voll.

Abbildung 9: Die letzte Wiederholung des Matrix -Multiplikationsprogramms, die die endgültige Konfiguration des Codes

zeigt

Schlussfolgerung

Ich habe gezeigt, wie einfach die Laufzeit von Java -Anwendungen gelangt, indem ich GPROFNG für die Leistungsanalyse verwendete. Mit der Filterfunktion von GPROFNG, um Experimente nach Zeitschriften zu überprüfen, konnte ich die interessierenden Programmstadien überprüfen. Beispielsweise ohne die Allokation und Initialisierungsphase der Anwendung und das Zeigen einer Wiederholung des Programms, wenn der Laufzeit -Compiler seine Magie ausführt, kann ich die Leistung hervorheben, die sich im Laufe des Hotcodes verbessert.

Weiteres Lesen

Für Leser, die sich über Gprofng kennen möchten, finden Sie hier einen Blog -Beitrag mit Einführungsvideos über Gprofng, einschließlich Anweisungen zur Installation von Oracle Linux.

Danksagung

Vielen Dank an Ruud van der Pas, Kurt Goebel und Wladimir Mezentsev für ihre Ratschläge und technische Unterstützung sowie an Elena Zannoni, David Banman, Craig Hardy und Dave Neary, weil sie mich ermutigt haben, diesen Blog -Beitrag zu schreiben.

Notizen

1. Die Motivation der Program -Befehlszeilenkomponente lautet:

• numactl - -cpunodeBind = 0 -Membind = 0 -. Begrenzt den Speicher, der von Java Virtual Machines verwendet wird, auf den Kern und den Speicher eines NUMA -Knotens. Durch die Begrenzung des JVM auf einen Knoten kann die Differenz zwischen den laufenden Programmen reduziert werden.
• Java. Ich benutze die OpenJDK-Version von JDK-17.0.4.1 von AArch64.
• -xx: UseParallelGC. Aktivieren Sie den parallelen Müllsammler, da er in verfügbaren Sammlern minimale Hintergrundarbeiten ausführt.
• -xms31g -xmx31g. Bietet genügend Java -Objekthaufen und benötigt nie Müllsammlung.
• -xlog: gc. Nehmen Sie GC -Aktivitäten auf, um zu überprüfen, ob es wirklich nicht sammeln muss. ("Vertrauen, aber verifizieren.")
• -xx: -Useperfdata. Reduzieren Sie den Overhead von Java -virtuellen Maschinen.

2. Die Erklärung der Option Gprofng lautet:

• -Limit 24. Nur die ersten 24 Methoden werden angezeigt (sortiert nach der exklusiven CPU -Zeit hier). Ich kann sehen, dass das Zeigen von 24 Methoden mir eine gute Vorstellung von denen gibt, die die Zeit kaum nutzen. Später werde ich an einigen Stellen die Grenze 16 verwenden, an denen 16 Methoden auf diejenigen reduziert werden können, die eine triviale CPU -Zeit beitragen. In einigen Beispielen begrenzt Gprofng selbst die Anzeige, da nicht so viele Methoden die Zeit ansammeln.
• -ViewMode Expert. Die Methoden, die alle kumulativen CPU -Zeit zeigen, nicht nur Java -Methoden, einschließlich der der JVM selbst. Mit diesem Flag kann ich Laufzeit -Compiler -Methoden usw. sehen.

Das obige ist der detaillierte Inhalt vonWas macht die java virtuelle Maschine den ganzen Tag?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!