Minecraft Out of Memory Error

The full message is java.lang.OutOfMemoryError, usually followed by 'Java heap space' or 'GC overhead limit exceeded'. Both mean the same thing from your side: the memory you allowed Minecraft to use was not enough.

The second variant is worth recognising because it is subtler. GC overhead limit exceeded means Java is spending nearly all its time garbage-collecting and reclaiming almost nothing. The heap is not quite full, but it is full enough that the game has effectively stopped. The symptom is severe stuttering before the crash rather than a clean stop.

Both have the same first-line fix, and both have the same second-line cause if that fix does not work.

Startup is comparatively cheap. Minecraft loads mod code, builds registries, and shows you a menu — a few hundred megabytes of work even on a large pack.

Loading a world is where the cost is. Chunk data, entities, block entities, and every texture the world needs all arrive at once. That is why the classic pattern is a game that launches perfectly and dies the moment you click a save.

Flying quickly across unexplored terrain produces the same effect for the same reason. Each new chunk allocates, and generating them faster than the collector can keep up is exactly the GC overhead scenario.

Allocation should scale with mod count, not with how much RAM you happen to own. The figures below are the ones that hold up in practice.

The default is 2GB, which is genuinely fine for vanilla and adequate for a light mod list. It is not adequate for anything described as a modpack.

Never give Minecraft more than about two-thirds of your physical memory, and never give it everything.

Your operating system needs headroom. On Windows, taking 14GB of 16GB means the OS starts paging to disk, and disk paging produces stutter far worse than anything the extra memory fixed.

There is a second, less obvious reason. Java's garbage collector has to walk the heap, and a very large heap takes longer to walk. Past roughly 8GB the pauses become noticeable, and past 12GB they can be worse than the problem you were solving. Allocating 16GB to Minecraft is actively counterproductive.

On a 16GB machine, 6GB to 8GB is the sensible working range for even a large pack.

Open the launcher, go to Installations, hover the profile you use and click the three dots, then Edit. Expand More Options and you will find a JVM Arguments field.

It contains a string beginning -Xmx2G. Change the number, leave everything else alone, and save. -Xmx6G gives it six gigabytes.

The neighbouring -Xms argument sets the starting heap. Setting it equal to -Xmx is a common recommendation and does help slightly by avoiding repeated heap growth, but it is a minor effect and not worth worrying about.

Do not add flags you found in a forum post without knowing what they do. Most JVM tuning advice for Minecraft is copied from a decade ago and applies to garbage collectors that are no longer the default.

Prism Launcher, MultiMC and the Modrinth app all expose memory as a slider or a pair of number fields in the instance settings, which is considerably friendlier than editing an argument string.

The catch is that these launchers have both global settings and per-instance overrides. Setting the global value does nothing if the instance has its own override enabled, and this is the single most common reason someone raises their allocation and sees no change.

Open the specific instance's settings, find the memory section, and check whether the override box is ticked. If it is, that is the value being used.

The CurseForge app has the same arrangement under its own settings menu, with a global default and per-profile overrides.

If you are at 8GB with a hundred mods and still running out, the allocation is not the problem. Something is leaking.

A memory leak in this context means a mod holding references to objects that should have been discarded, so usage climbs steadily during play and never comes back down. The signature is a session that starts fine and degrades over twenty or thirty minutes, ending in a crash regardless of how much you allocated.

Watch the memory graph — press F3 in game and the top-right shows current heap usage. Healthy behaviour is a sawtooth: usage climbs, the collector runs, usage drops sharply. A leak looks like a sawtooth whose bottoms keep rising.

Once you have confirmed that pattern, it is a bisect problem rather than a memory problem.

Two settings cut memory use substantially and cost less than you would expect visually.

Render distance is the big one and it scales roughly with the square of the value. Dropping from 16 chunks to 10 removes well over half the loaded chunk data. On a heavy pack, 8 to 10 is comfortable and most people stop noticing within a few minutes.

Simulation distance controls how far away entities and blocks keep ticking. Lowering it does not change what you can see, only what stays active out of sight. Six is generally plenty for single-player.

Turning off fancy graphics options helps less than people assume — those cost GPU time rather than heap. Render distance is where the memory is.

Shader packs are memory-hungry in a way that catches people out, because the cost lands on both the graphics card and the Java heap.

Add one to two gigabytes to whatever figure you were using without them. A pack that ran comfortably at 4GB will frequently need 6GB once shaders are enabled.

If you are close to your machine's limit, shaders and a large modpack together may simply not be viable. Lowering the shader preset from Ultra to Medium usually recovers more headroom than any allocation change.

A modded server needs its own allocation, and it is a different figure from the client because it is doing different work — no rendering, but every loaded chunk in the world for every player.

Three to four gigabytes suits a light mod list. A hundred-mod pack wants four to six. Large kitchen-sink packs want eight. Add roughly 500MB per concurrent player beyond the first four.

Server-side out-of-memory failures often show up as the server appearing to freeze rather than crashing outright, because the collector is thrashing. Watch the console for warnings that a tick took too long, which usually precedes the actual failure by several minutes.

Work down this list in order and stop when it works. Most people stop at step two.

Confirm the error really is OutOfMemoryError rather than something else producing a crash. Raise the allocation one step using the table above. Verify the change actually applied by checking F3 in game. Lower render distance to 10 and simulation distance to 6. If shaders are on, add headroom or lower the preset. If none of that works, watch the F3 memory graph for a leak pattern and bisect.

Do not skip step three. Believing you raised the allocation when you edited the wrong setting accounts for a surprising share of unresolved cases.