Confirm that memory caused the crash
Look for Java heap space, GC overhead limit exceeded, or a direct OutOfMemoryError in the full log. Low frame rate and a high memory percentage do not by themselves prove that the crash was caused by heap exhaustion. A mod conflict can terminate the game while plenty of memory remains.
Check whether the failure happened during startup, world generation, resource reload, or after a long play session. Timing helps distinguish a pack that needs a slightly larger starting allocation from a repeatable leak or unusually heavy task.
Allocate memory without starving the computer
Increase the maximum allocation in moderate steps and leave enough RAM for the operating system, launcher and background software. Assigning nearly all physical memory can force the system to swap data to disk and make both Minecraft and the computer less stable.
Use a 64-bit Java runtime. A 32-bit runtime cannot use the amount of heap expected by modern modpacks. Confirm the active Java executable in the new latest.log rather than assuming the launcher selected the runtime you installed.
When more RAM does not solve it
A failure that returns at the same action or grows continuously during play may involve a mod bug, runaway chunk task, shader, resource pack or configuration. Reproduce it in a copied instance and compare behavior after disabling the smallest relevant group.
Do not remove content mods from an important world without a backup. For pack-specific recommendations, follow the pack author's documented memory range because its tested configuration is more useful than a universal number.
Quick troubleshooting checklist
- ✓Confirm OutOfMemoryError in the log
- ✓Note when the memory failure occurs
- ✓Use 64-bit Java
- ✓Increase allocation gradually
- ✓Leave RAM for the operating system
- ✓Investigate repeatable growth or leaks
Every launch creates a new result. After making one change, use the newly generated latest.log rather than continuing from an older report.