JVM Threading-Optimierungen überarbeitet

Von Jeroen Borgers Letzte Woche habe ich einen internen Performance-Tuning-Kurs geleitet und die Teilnehmer über die Threading-Optimierungen in der Java 6 VM aufgeklärt. Wir haben die Übungen des Kurses mit Java 6 Update 11 durchgeführt und als ich ihnen sagte, dass Escape Analysis noch nicht richtig funktionierte, wurde mir klar, dass ich das für dieses Update von Suns Java nicht wirklich wusste. Es ist also an der Zeit, den Benchmark erneut auszuführen und einige unerwartete Ergebnisse zu finden. Ich verwende wieder den gleichen LockTest-Benchmark wie in meinem InfoQ-Artikel, den ich bei jdk update 4 durchgeführt habe. Meine Quelle bei Sun sagte mir damals, dass ich in Update 10 und den folgenden Versionen Verbesserungen bei der Lock-Elimination durch Escape-Analyse erwarten kann. Gute Gründe also, den Test erneut durchzuführen. Escape-Analyse nicht verbessert; andere Locking-Optimierungen verschlechtert Als ich mit den Messungen begann, fand ich schnell heraus, dass sich die Lock Elision durch die Escape-Analyse leider nicht von Update 4 auf das neueste, Update 12, verbessert hat. Ich habe jedoch einige andere unerwartete Leistungsänderungen zwischen Update 4 und Update 12 festgestellt. Die nächste Abbildung veranschaulicht dies.

Abbildung 1. Durchschnittlich gemessene Zeiten [ms] von LockTest für Sun jdk 6 Update 12 im Vergleich zu Update 4 mit Standardeinstellungen. Der durch die Pfeile gekennzeichnete Bereich deckt 67% der Verteilung der gemessenen Zeiten ab. Ich habe jeden Test sieben Mal auf demselben Laptop-Typ wie im InfoQ-Artikel mit der Server-VM und den Standardeinstellungen durchgeführt. Ich habe den Durchschnitt und die Standardabweichung unter der Annahme einer Normalverteilung berechnet. Die roten Pfeile sind von avg - stddev bis avg + stddev gezeichnet, um die Verteilung der Messungen zu zeigen. Aus diesen Messungen lassen sich einige interessante Schlussfolgerungen ziehen. Die gute Nachricht ist, dass es Sun gelungen ist, die Leistung von StringBuilder in diesem Benchmark um etwa 10% zu verbessern. Die schlechte Nachricht ist jedoch, dass sich die StringBuffer-Leistung um etwa 10% verschlechtert hat! Der Threading-Overhead erhöht sich dadurch von 36% auf satte 66%, wodurch die Verwendung von Locking teurer wird, zumindest auf einem Dual-Core Intel Rechner. Außerdem haben sich die Schwankungen bei den Zeiten von StringBuffer deutlich erhöht, wie die roten Pfeile zeigen. Die Ursache für diese Schwankungen muss weiter untersucht werden.Die nächste Abbildung zeigt die Ergebnisse weiterer Messungen mit dem Ein- und Ausschalten der JVM-Optionen -XX:+UseBiasedLocking und -XX:+EliminateLocks. In der Standardeinstellung sind beide Optionen aktiviert.

Abbildung 2. Durchschnittlich gemessene Zeiten [ms] von LockTest für Sun jdk 6 update 12, StringBuffer Zeiten mit verschiedenen JVM-Einstellungen im Vergleich. Der durch die Pfeile gekennzeichnete Bereich deckt 67% der Verteilung der gemessenen Zeiten ab. Ich habe diese Tests auf meinem neuen Laptop mit einer neueren Intel Centrino CPU durchgeführt, daher sind die absoluten Zeiten kürzer als bei früheren Tests. Die relativen Zeiten sind ungefähr gleich. Die Abbildung zeigt, dass mit der Funktion EliminateLocks etwas Merkwürdiges vor sich geht. Mit Update 4 haben wir gesehen, dass BiasedLocking manchmal nicht vollständig zu funktionieren schien. Das ist jetzt nicht mehr der Fall; es gibt jetzt eine gesunde, geringe Schwankung bei den Zeiten, wie Sie an dem Balken ganz rechts in der Abbildung sehen können. Wenn jedoch beide Optionen ausgeschaltet sind und nur EliminateLocks aktiviert ist, ergibt sich eine überraschend hohe Abweichung, die bei Update 4 mit demselben Benchmark noch nicht so hoch war. Und das zeigt sich in geringerem Maße bei den Standardeinstellungen. Und noch auffälliger ist, dass, während bei Update 4 die Standardeinstellung zur besten Leistung führte, sich die EliminateLocks-Optimierung jetzt in diesem Single-Thread-Benchmark sogar als kontraproduktiv erweist. Wir erhalten die besten Ergebnisse, wenn wir die EliminateLocks-Funktion deaktivieren und nur einseitiges Sperren verwenden, anstatt die Standardeinstellungen zu verwenden. Ich kann nur vermuten, was in der VM vor sich geht und wie sie mit der CPU und den Caches arbeitet. Die Funktion Eliminieren von Sperren ist in scheinbar ähnlichen Situationen unterschiedlich effektiv und scheint dem Biased Locking im Weg zu stehen oder sogar mit ihm in Konflikt zu geraten. Das bedeutet jedoch nicht, dass Sie diese Funktion für Ihre Anwendung abschalten sollten. Denken Sie daran, sich vor den Benchmarks in Acht zu nehmen, sie geben eine Antwort auf eine bestimmte Frage. In diesem Fall: Wie hoch ist der sichere Thread-Overhead von StringBuffer, beeinflusst durch die VM-Threading-Optimierungen? Außerdem könnten wir in diesem Mikro-Benchmark Effekte hervorheben, die in realen Anwendungen nicht auftauchen. Es wäre interessant, die Ergebnisse anderer Threading-Benchmarks zu sehen, die diese Aktualisierungen vergleichen. Auf der Grundlage dieses Benchmarks würde ich sagen, dass es für die Hotspot JVM-Entwickler noch Raum für Verbesserungen gibt. Ergebnisse auf der IBM JVM Nur als Randbemerkung: Die virtuelle Maschine von IBM ist laut Berichten von Escape Analysis voll funktionsfähig. Sie kann für Windows als Teil des IBM Development Package for Eclipse heruntergeladen werden. Lassen Sie den Benchmark auf dieser Maschine laufen. ibm_sdk60binjava.exe -showversion -Xmn1g -Xgcpolicy:gencon LockTest java version "1.6.0" Java(TM) SE Runtime Environment (build pwi3260sr1-20080416_01(SR1)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows Vista x86-32 jvmwi3260-20080415_18762 (JIT enabled, AOT enabled) J9VM - 20080415_018762_lHdSMr JIT - r9_20080415_1520 GC - 20080415_AA) JCL - 20080412_01 Starting test StringBuffer: 976 ms. StringBuilder: 1006 ms. Thread safety overhead of StringBuffer: -3% Wow! Die Escape-Analyse zeigt jetzt ihr wahres Gesicht. Ich glaube nicht, dass ich die Balken zeichnen muss, um zu verdeutlichen, dass diese JVM bei der Ausführung dieses Benchmarks viel besser abschneidet. Hut ab vor den J9-Jungs.