Java 10: Garbage-Collector Interface (JEP 304) & Parallel Full GC für G1 (JEP 307)

JEP 304 – Garbage-Collector Interface

Vor Java 10 war GC-Implementierungscode über die Codebase verstreut und schwer austauschbar. JEP 304 führt eine saubere GC-Interface ein:

Alternative GC-Implementierungen können als Plugins eingebunden werden.
Codebase-Isolation: GC-Logik gekapselt, leichter wartbar/testbar.
Basis für zukünftige experimentelle Collector (z. B. ZGC, Shenandoah Entwicklung).

JEP 307 – Parallel Full GC für G1

Hintergrund: G1 (Garbage First, Standard ab Java 9) vermeidet Full GCs durch inkrementelle Sammlung. Wenn jedoch Speicher nicht schnell genug zurückgewonnen wird (z. B. bei hoher Allokationsrate), fällt G1 auf einen Single-Threaded Full GC (Mark-Sweep-Compact) zurück → lange Pausen.

Verbesserung in Java 10

G1 nutzt nun parallele Threads für den Fallback-Full-GC. Mehrere Threads führen Mark-Sweep-Compact gleichzeitig aus → deutlich reduzierte Worst-Case-Latenz.

Thread-Anzahl steuern

java -XX:ParallelGCThreads=4 -jar meineapp.jar

ParallelGCThreads steuert auch die Threads für den parallelen Full GC (Standard: CPU-Count-basiert).

Zusammenfassung

Feature	JEP	Nutzen
GC Interface	304	Pluggable GCs, saubere Code-Isolation, Basis für neue Collector
Parallel Full GC für G1	307	Geringere Max-Pause-Zeiten bei Full-GC-Fallback, bessere Skalierbarkeit

Beide JEPs sind interne VM-Verbesserungen – für Anwendungsentwickler meist transparent, aber wichtig für JVM-Tuning und Verständnis von GC-Verhalten.

Java 10: Application Class-Data Sharing (AppCDS, JEP 310) – Schnellerer App-Start Java 10 Locale-Verbesserungen: Erweiterte Unicode-Erweiterungen (JEP 314)

Java