JAX 2007: Garbage Collection – Memories are made of this (Rainer Jung, kippdata)
Zu Rainer Jung: Tomcat-Commiter, Cluster, mod_jk, Geschäftsführer kippdata GmbH
Warm-Up-Fragen, etc. wer benutzt noch 1.3 etc,
Statistik XX-Optionen: 412 + 32 Diagnose
367 in DevBuild
53 Optionen mit verschiedenen Defaults
Beschränkung auf Sun JVM 1.4.2, 1.5, 1.6
Drei Fragestellungen:
- GC run blockiert Anwendung
- GC blockiert CPU Zeiten
- Großes Memory ist teuer
=> Drei widersprüchliche Ziele.
Objekterreichbarkeit – lebt, wenn es Kette v. ObjRefs von "root" zum Obj gibt.
roots: static fields in Klassen, Args, MEmber der Methoden in allen aktuellen Threads.
Realisierungsziele
- schnelleObjAllokation: Eden-Stack; Ende d Stacks wird hochgesetzt -Inkrementierung d Pointers. Was, wenn Eden "voll ist"? Eden leerräumen: In Survivor Space () [=>Minor GC] wird Eden umkopiert. SS kleiner als Eden.
Was, wenn SS voll ist? Zwei SSes Survivor A + Survivor B. Eden=>A=>B. Dabei werden die From und To-Rollen immer abwechselnd vertauscht. Deshalb heißen die SSes auch "Semi-Spaces". - New: Var 1: Eden+ 1 Semi-Space
- Var2: Eden + beide SSes.
- Was, wenn SemiSpace voll ist? Objekte nicht mehr "jung" – Tenured – enthält ältere Objekte. Nach MGC => Eden leer, From leer, alle Objekte in To und Tenured.
- Objekte im SS erhalten Alter "age", wird bei Umkopieren um eins erhöht; Objekte oberhalb eines Age-limits (default 31 (1.4.2), 15 (1.6) und 31/15 (1.5), änderbar) kommen nach Tenured.
- Suche letztes Age A, welches unter N% liegt.
- meisten Obj sterben jung
- wenig Overhead + Störung d. App
Schalter -server / -client Verändert Memory Defaults. 64 bit immer Server.
Server Class Detection: Linux: Anhand d Memory-Werts.
-X-Argumente sind nicht standardisiert. -XX:+/-[Schalter] -XX:[key=value]
Argumente an CL oder .hotspotrc oder _JAVA_PREFIC envvar
Heap: Eden+2*Semi+Tenure
Dynamisches Resizing. Defaults 40/70%
Für Produktion Xmx=Xms
New Size= Eden + 2*Semi
(Kein Schalter f. Tenured). New Size als Anteil New:Tenured = 1:NewRatio
New generation (in Doku): Ein Semi-Space + Eden
Survivor Ratio 1 Semi Space also New /(SurvivorRatio+2)
4 = Eden 4/6, SS 1/6
Tenuring-Verhalten beeinflussen
TargetSurvivorRatio (Zielfüllstand SemiSpaces %)
MaxTenurinbgThreshold
OutOfMemoryErrors
OnError – Kommandoübergabe.
Schalter ShowMessageBoxOnError: Hält Prozess an, damit man Debugger anklemmen kann.
Seit 1.4.2. parallele Minor GC (Throughput Collector). Concurrent: Abarbeitung während App nicht gestoppt wird.
Schalter UseParallelGC bei CMS UseParNewGC, Default ab 1.5 bei server
Anzahl benutzter Threads nach Formel
(ncpus <= ?) ncpus : 8 + (ncpus -8)* 5/ 8
ParallelGCThreads=x einstellen besser!
GC-Ergonomie, in Verbiindung m. Server-Class detection. Andere defaults der Mem-Größen.
UseAdaptiveSizingPolicy – soll Eden und SemiSpaces automatisch skalieren. Wohl weniger performant, zu prüfen.
Major GC / Full GC
Entfernung toter Objekte aus Tenured. Steht nicht in jedem Log. Tenured "voll"? Ganz unterschiedliche Ansätze Tenured-Size Eden – Size 1 Semi ODER 68% Tenured
System.gc() (aber kein Vertrag).
Webapp-Trick: <% System.gc(); %> – für Tests – ULR aufrufen.
GB-Tenured GC kann im Mehrsekundenbereich liegen; vor 1.6 single-threaded.
Zwei Algorithmen
Mark Sweep Compact (Exact GC), default:
Geht nicht nur durch, um tote Obj zu entfernen, sondern "defragmentiert" auch
ab 1.5.06/1.6
optionale parallele Abarbeitung – mehrere Threads Parallel!=Concurrent-Vorsicht!
Gleicher Thread Count
Concurrent Mark Sweep [CMS] GC (seit 1.4.2)
Anwendung nur kurz stoppen, GC in mehreren Phasen. UseConMarkSweepGC mit Minor GC nur mit UseParNewGC
Pausenzeiten deutlich kürzer. Anfangs sehr buggy, jetzt aber empfehlenswert.
Gefahr: Fragmentierung von Tenured. erhöhter Memory Bedarf in Tenured (~30%?)
Neu in 1.6: CMS auch für System.gc(), Schalter ExplicitGCInvokesConcurrent
Parallele Mark-Phase (stop)
1.4.2. ignoriert SurvivorRatio.
Class Garbage Collection;
Demo: Eden und JMeter sendet Requests byteArray allozieren Speicher.
jconsole zeigt Ansteigen der Belegung d Eden Space an.
Demo: Aging Distribution