Java 10: Thread-Local Handshakes (JEP 312) – Schnellere VM-Safepoints

JEP 312 – Thread-Local Handshakes

Hintergrund: Globale Safepoints

Die HotSpot VM nutzt globale Safepoints, um alle Application-Threads anzuhalten (z. B. für GC, Deoptimierung, Biased Locking Revocation). Alle Threads müssen an einem sicheren Punkt anhalten – das kostet Zeit und skaliert schlecht bei vielen Cores/Threads.

Lösung: Thread-Local Handshakes

Java 10 führt Thread-Local Handshakes ein: Die VM kann einen einzelnen Thread anhalten und einen Callback ausführen, ohne alle anderen Threads zu stoppen.

• Neue VM-Option: -XX:+ThreadLocalHandshakes (Standard: on auf unterstützten Plattformen).
• Funktioniert auf x64 (Intel/AMD) und SPARC.
• Andere Plattformen fallen auf klassische globale Safepoints zurück.

Wie es funktioniert

1. VM fordert Handshake für Thread T an.
2. Thread T erreicht nächsten Safepoint-Poll (bereits vorhanden für GC).
3. Thread T führt den Handshake-Callback aus (z. B. Stack-Walk, Deopt-Check).
4. Thread T läuft sofort weiter – keine anderen Threads betroffen.

Vorteile

• Reduzierte Stop-the-World-Zeiten für Operationen, die nur einzelne Threads betreffen.
• Bessere Skalierbarkeit auf Many-Core-Systemen (64+ Cores).
• Feinere Kontrolle für VM-Interna (z. B. Biased Locking Revocation, Thread-Dump, JFR Events).

Einschränkungen

• Nur x64 & SPARC (Hardware-Support für effiziente Polling-Sequenzen nötig).
• Nicht alle Safepoint-Operationen sind darauf umgestellt (GC bleibt global).
• Experimentell in Java 10, stabiler in Java 11+.

Verwandte Optionen

-XX:+ThreadLocalHandshakes           # Aktivieren (Default auf x64/SPARC)
-XX:-ThreadLocalHandshakes           # Deaktivieren
-XX:ThreadLocalHandshakePollingInterval=... # Polling-Intervall (Experten)

Fazit

Thread-Local Handshakes sind eine VM-interne Optimierung, die besonders bei hochparallelen Workloads (viele Threads, viele Cores) Latenzspitzen reduziert. Für Anwendungsentwickler transparent – kein Code-Change nötig.