Fixing OutOfMemoryError & Java Heap Space in Minecraft

java.lang.OutOfMemoryError: Java heap space sounds like your PC ran out of memory. It almost never did. It means Minecraft hit the RAM ceiling you set for it in the launcher, and the most common cause is simply a heap that's too small for what you're running. The fix is one slider, and it takes ten minutes to get right.

Three errors that sound the same but aren't

People lump every memory error together, but the exact line in your log matters:

• java.lang.OutOfMemoryError: Java heap space: the game ran out of heap while running or loading.
• Could not reserve enough space for object heap: Java never started. The system couldn't hand over the memory you asked for at launch.
• Invalid maximum heap size: Java never started either. The value was malformed, or you asked a 32-bit Java for more than it can address.

Where to read them, on Windows:

• %APPDATA%\.minecraft\crash-reports\
• %APPDATA%\.minecraft\logs\latest.log
• %APPDATA%\SuperLauncher\logs\superlauncher.log

The launcher log is overwritten on every launch, so if you want to inspect a past failure, copy it somewhere else before launching again. When the game fails to start, SuperLauncher shows a red notice pointing at this file, so you don't have to hunt for it.

How the heap actually works

When Java starts, it reserves a block of RAM called the heap and refuses to go past it. The ceiling is the -Xmx flag: -Xmx4G means the heap can grow to 4 GB. In SuperLauncher you never type that. The launcher sets the heap from your choice in Settings > 'Game launch' > 'Memory (RAM)', or from that version's own settings if you want it different for one install. The presets are 2, 4, 6, 8 and 12 GB, up to your PC's limit.

Everything Minecraft creates, from chunk data to mobs to block states, lives in the heap until the garbage collector (GC) sweeps out the dead objects. Which brings me to the part most people get backwards.

Why more RAM can make the game worse

Giving Java a huge heap doesn't make it faster. When the heap is far bigger than the game needs, the GC stops doing small, frequent cleanups and lets garbage pile up. Then it eventually runs one huge collection, and the game freezes for a second or two while it works. That's the classic stutter people blame on "bad optimization": the heap is so big that cleanup turned into an event.

A heap that's about the right size saw-tooths instead: usage climbs, GC clears it, repeat, no drama. So the goal is not "as much as my PC has". It's "a bit more than the game actually needs".

How much RAM to give Minecraft

These are rules of thumb, not lab measurements, but they've held up well across versions:

• Vanilla, 1.16 through 1.21+: 2 to 4 GB. Use 4 GB if you push render distance past 16 chunks.
• Light to medium packs, roughly 50 to 150 mods: 4 to 6 GB.
• Heavy packs, roughly 200 to 300 mods: 6 to 8 GB.
• Huge packs with 128x or 256x resource packs: 8 to 10 GB.

Beyond 10 GB I'd only go for extreme setups, and if you're asking whether it helps, it usually doesn't.

The five real causes, from most to least common

1. The heap is too small for what you're running

The most common case by far. Modpacks load thousands of items, models and textures at startup, and if the ceiling is too low, Java runs out while registries are building or terrain is generating. If you just installed a bigger pack and left the slider at 2 GB, this is you.

1. Open SuperLauncher and go to Settings > 'Game launch' > 'Memory (RAM)', or open the settings of the specific version if you want to change just that one.
2. Pick a preset (2, 4, 6, 8 or 12 GB) that fits the table above. For a medium pack, start at 6 GB.
3. Launch the game.

How to confirm it worked: load into a world and press F3. In the top-right corner, find the line starting with Mem:. It shows a percentage plus used and allocated megabytes, like Mem: 45% 2730/6144MB. If usage sits somewhere in the 40-75% band and drops cleanly after GC runs, the heap is the right size. If it pins at 98-100%, you're still too small.

2. The heap is bigger than your PC's free memory

The opposite mistake, and it's sneakier. If your PC has 8 GB total and you allocate 6 GB while a browser and Discord are open, Windows runs out of physical RAM and starts pushing memory out to the pagefile on your drive. The drive is much slower than RAM, so the game either crawls or Java can't get its allocation at all and dies with Could not reserve enough space for object heap before the window even opens.

1. Press Ctrl + Shift + Esc to open Task Manager and check the Performance tab, Memory.
2. Note the total and what's available right before you launch.
3. Lower the slider so Windows and your background apps keep at least 2 to 4 GB of physical RAM. On an 8 GB machine, that means no more than 4 GB for Minecraft.

How to confirm it worked: launch the game and keep Task Manager open on a second monitor or in the background. System memory usage should stay under about 90%, and the game should start without a heap reservation error in superlauncher.log.

3. High-resolution resource packs and big render distance

512x texture packs and 32-chunk render distances eat memory like nothing else. Textures get unpacked into memory at full resolution, and every loaded chunk adds block, light and entity data to the heap.

1. In game, go to Options > Video Settings and drop render distance to 12 or 16 chunks as a test.
2. Go to Options > Resource Packs and turn off anything 128x or higher.
3. If the crashes stop, add them back one at a time and watch the F3 memory line.

How to confirm it worked: watch the Mem: line while you play. With the pack disabled, memory should fill noticeably slower between GC sweeps, and the game should stop dying at the same spot.

4. 32-bit Java, or the wrong Java for the version

A 32-bit Java can only address a small heap, roughly 1.5 GB, no matter how much RAM your PC has. Ask it for 4 GB and it refuses with Invalid maximum heap size before the game starts. Separately, Minecraft versions need specific Java runtimes:

• 1.16.5 and older: Java 8
• 1.17: Java 16
• 1.18 through 1.20.4: Java 17
• 1.20.5 through 1.21.x: Java 21
• The new 26.x versions: Java 25

Those are the game's own requirements. You don't manage any of it in SuperLauncher: it picks the right runtime from Java 8, 17, 21 or 25 automatically and downloads a 64-bit runtime itself if one is missing. What you can still check is the Windows side:

1. Open Windows Settings > System > About.
2. Read 'System type'. If it says '32-bit operating system', no launcher can give Java a big heap; fixing that means a 64-bit Windows install.

How to confirm it worked: open %APPDATA%\SuperLauncher\logs\superlauncher.log and look at the startup lines for the Java path and version string it used. You should see a 64-bit runtime for your version, and no Invalid maximum heap size anywhere.

5. A mod leaking memory

The rare one, but real. A leaking mod allocates and never releases, so heap usage climbs toward 100% and ignores garbage collection until the game dies with OutOfMemoryError. The tell is that raising RAM only postpones the crash: 4 GB lasts an hour, 8 GB lasts two, the graph still never comes down.

1. Press F3 in game and watch the Mem: line over five or ten minutes of normal play.
2. Healthy memory saw-tooths: it climbs, GC drops it, repeat. A leak climbs in a straight line and never drops much after a sweep.
3. If it's climbing, remove recently added or updated mods from the profile's mods folder (the 'Open version folder' button takes you there) and test again, halving what's left until the climb stops. For how that method works, see our guide to finding a bad mod among a hundred.
4. When you've found it, report it on the mod's issue tracker with your log; you're saving everyone else the same afternoon.

How to confirm it worked: with the mod gone, the Mem: graph should saw-tooth again and level off instead of ratcheting to 100%.

What doesn't help

• Sliding RAM to the maximum "just in case". On a vanilla client this buys you nothing and costs you GC stutter plus whatever Windows was going to do with that memory.
• Adding JVM arguments by hand. SuperLauncher controls the startup flags, and you can't override them from the launcher anyway.
• Updating GPU drivers for a heap error. Drivers fix rendering crashes, not heap ceilings. The only crossover is the reservation failure, and that one is fixed with the slider, not the driver.

Before your next session

• Check your total RAM in Task Manager so you know your real ceiling.
• Match the slider to your content: 2-4 GB vanilla, 4-6 GB light modded, 6-8 GB heavy.
• Leave 2 to 4 GB of physical RAM for Windows and everything else you keep open.
• After launch, press F3 and confirm memory sits under about 85% and saw-tooths.
• If it crashes anyway, copy superlauncher.log and check .minecraft\crash-reports\ before you relaunch, so the evidence survives.