Java-Speicher und Garbage Collection

Wie Minecraft Speicher nutzt

Minecraft ist ein Java-Programm. Wie jedes Java-Programm läuft es in einer Java Virtual Machine (JVM), die einen festen Anteil System-RAM bekommt. Alles, was Minecraft tut, geladene Chunks, Entities, Mod-State, Texturen, lebt in diesem Anteil.

Wenn du in den Instance Settings von GDLauncher Instance Java Memory einstellst, setzt du -Xmx, die maximale Heap-Größe, die die JVM nutzen darf. Java-Code (Objekt-Allokationen, Mod-Datenstrukturen, Welt-State) lebt in diesem Heap. Texturen und OpenGL-Buffer liegen außerhalb, im Native Memory, und sind von Xmx nicht betroffen.

Der wahre Engpass ist der Garbage Collector

Java gibt Speicher nicht von Hand frei; es hat einen Garbage Collector, der periodisch den Heap scannt, Objekte ohne Referenzen findet und freigibt. Modernes Minecraft nutzt standardmäßig den G1-Collector.

GC läuft in zwei Modi:

• Young GC. Kurz, häufig. Scannt eine kleine “Young Generation” frisch erzeugter Objekte. Meist ein paar Millisekunden.
• Old GC / Mixed GC. Länger, seltener. Scannt den Rest des Heaps. Auf großem Heap zig Millisekunden bis mehr.

Wenn der GC läuft, ist Minecraft pausiert. Je größer der Heap, desto länger die großen Collections. Deshalb macht mehr RAM über das eigentliche Bedürfnis hinaus Pause-Ruckler schlimmer, nicht besser.

Das ist das kontraintuitivste an Java-Memory-Tuning: weniger zuteilen kann smoother sein als mehr.

Die richtige RAM-Menge

Grobe Richtwerte für den passenden Heap ohne Thrashing:

Über 10 GB nur, wenn die Pack-Doku es explizit verlangt. Manche speicherhungrigen Mod-Kombos (Better End plus NetherEx z. B.) brauchen wirklich mehr, dann folgst du der Empfehlung des Packs.

Wie GDLaunchers Slider funktioniert

Instanz öffnen, auf den Settings-Tab klicken, zu Instance Java Memory scrollen. Den Toggle umlegen, um den Per-Instance-Override zu aktivieren, dann den Slider ziehen; er geht von 1 GB bis zum Gesamt-RAM des Systems (mit Warnung jenseits 80 %). Der Launcher übersetzt den Wert in -Xmx<n>M und gibt’s der JVM.

Denselben Slider gibt’s global in Settings → Java → Java Memory, als Default für jede Instanz, die nichts überschreibt. Den globalen niedrig halten, nur schwere Modpacks anheben.

Aikar’s Flags

Lange Liste an JVM-Argumenten, die G1 auf kurze Pausen statt Durchsatz tunen. Original für Minecraft-Server, aber auch auf modded Clients nützlich. Sieht so aus:

-XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 ...

GDLauncher setzt sie nicht standardmäßig. Einfügen kannst du sie in das Instance Java Arguments-Feld im Settings-Tab der Instanz (oder in Settings → Java → Java Arguments für global). Effekte variieren; konstantester Vorteil sind weniger lange Pausen auf Heaps zwischen 6 und 10 GB.

Wichtige Punkte:

• Tuned für ältere Java-Versionen. Auf Java 17+ ist der Default schon gut, Aikar’s Gewinn geringer.
• Geht von Server-Allokationsmustern aus. Auf Desktop mit kleinem Heap kann’s schaden.
• Bringt keinen extra Speicher und ändert nicht, wie viel das Spiel nutzt, nur das Verhalten des Collectors.

Ohne konkreten Grund: das Java-Arguments-Feld so lassen, wie GDLauncher es setzt.

Ruckler diagnostizieren

Wenn Minecraft alle paar Sekunden hunderte Millisekunden steht:

1. F3-Debug-Screen öffnen, “Mem:“-Zeile (rechts oben) checken. Springt sie schnell zwischen niedrig und hoch, ist GC-Churn die Ursache.
2. Xmx um 1-2 GB runter und nochmal testen. Kontraintuitiv, aber kleinerer Heap GC’d schneller.
3. Bestimmter Mod allokiert wild (manche Pregen- oder Rendering-Mods tun das), zeigt sich in Mod-Profilern (Spark, JmxMC). Mod braucht vielleicht ein Update.
4. CPU bei 100% während Pausen heißt, der GC arbeitet wirklich hart. Xmx weiter senken oder speicherhungrige Mods raus.

TL;DR

• Java Memory auf gerade genug stellen, nicht so viel wie du hast.
• Engpass ist GC-Pausenzeit, nicht reine Heap-Größe.
• Aikar’s Flags helfen auf großen Heaps, sind kein Allheilmittel.
• 4-6 GB ist für fast alles Modded richtig.