MC-3256Memory leak when starting large TNT chain reactions
This bug has been in Minecraft for a good while. When starting a chain reaction with several hundreds of TNT blocks involved, the game will start to allocate massive amounts of memory until the virtual machine heap space (-Xmx) is fully exhausted, with the well-known "Out of memory" screen as a result.
Steps to reproduce: create a superflat world, preset "2;128x46", ignite any TNT block, wait a few seconds.
This is caused by the dynamic object pooling for vector and bounding box objects combined with very expensive explosion damage/propulsion calculations.
Each explosion potentially requires some thousand vectors and a few hundred bounding boxes, whose instances are all stored in a pool for the duration of the current tick.
Since the pool size isn't imitated in any way, it stores every single instance in its list. (Update: vector lists seem to be controlled in some way since 1.4.x, but it still doesn't stop them from collecting all objects in one single tick) So if many TNT explosions produce 100 million temporary objects during a tick, everything will be kept in memory and unreachable for the garbage collector until the next tick starts.
The solution is pretty simple: set a per-tick limit for the object pool list. If a certain limit is passed (I'd recommend 10-20k), return any additional objects always newly constructed so they can be garbage-collected once they're no longer being used. This also allows the use of fixed-size arrays, which could be a little faster than lists. The attachments below contain some example code that allows me to perform explosions like on a TNT superflat world as above with just 4 GB RAM without any known side effects. (of course, the enormous amount of entities and TNT block meshes will also produce out of memory errors at some point, but much later than in vanilla)
This obviously won't fix the FPS performance issues during mass explosions, but at least you'll be able to see the result after some time without having 32+ GB RAM.
Environment
Windows 7 x64, Java 1.7.0_09-b05
Linked Issues
Created Issue:
Memory leak when starting large TNT chain reactions
This bug has been in Minecraft for a good while. When starting a chain reaction with several hundreds of TNT blocks involved, the game will start to allocate massive amounts of memory until the virtual machine heap space (-Xmx) is fully exhausted, with the well-known "Out of memory" screen as a result.
This is caused by the dynamic object pooling for vector and bounding box objects combined with very expensive explosion damage/propulsion calculations.
Each explosion potentially requires some thousand vectors and a few hundred bounding boxes, whose instances are all stored in the pool for the current tick.
Since the pool size isn't imitated in any way, it stores every single instance in its list. So if many TNT explosions produce 100 million temporary objects during a tick, everything will be kept in memory and unreachable for the garbage collector until the next tick starts.The solution is pretty simple: set a per-tick limit for the object pool list. If a certain limit is passed (I'd recommend 10-20k), return any additional objects always newly constructed so they can be garbage-collected once they're no longer being used. This also allows the use of fixed-size arrays, which could be a little faster than lists.
This obviously won't fix the FPS performance issues during mass explosions, but at least you'll be able to see the result after some time without having 32+ GB RAM.
Environment
Windows 7 x64, Java 1.7.0_09-b05
This bug has been in Minecraft for a good while. When starting a chain reaction with several hundreds of TNT blocks involved, the game will start to allocate massive amounts of memory until the virtual machine heap space (-Xmx) is fully exhausted, with the well-known "Out of memory" screen as a result.
This is caused by the dynamic object pooling for vector and bounding box objects combined with very expensive explosion damage/propulsion calculations.
Each explosion potentially requires some thousand vectors and a few hundred bounding boxes, whose instances are all stored in the pool for the current tick.
Since the pool size isn't imitated in any way, it stores every single instance in its list.So if many TNT explosions produce 100 million temporary objects during a tick, everything will be kept in memory and unreachable for the garbage collector until the next tick starts.The solution is pretty simple: set a per-tick limit for the object pool list. If a certain limit is passed (I'd recommend 10-20k), return any additional objects always newly constructed so they can be garbage-collected once they're no longer being used. This also allows the use of fixed-size arrays, which could be a little faster than lists.
This obviously won't fix the FPS performance issues during mass explosions, but at least you'll be able to see the result after some time without having 32+ GB RAM.
This bug has been in Minecraft for a good while. When starting a chain reaction with several hundreds of TNT blocks involved, the game will start to allocate massive amounts of memory until the virtual machine heap space (-Xmx) is fully exhausted, with the well-known "Out of memory" screen as a result.
This is caused by the dynamic object pooling for vector and bounding box objects combined with very expensive explosion damage/propulsion calculations.
Each explosion potentially requires some thousand vectors and a few hundred bounding boxes, whose instances are all stored in the pool for the current tick.
Since the pool size isn't imitated in any way, it stores every single instance in its list.(Update: vector lists seem to be controlled in some way since 1.4.x, but it still doesn't stop them from collecting all objects in one single tick) So if many TNT explosions produce 100 million temporary objects during a tick, everything will be kept in memory and unreachable for the garbage collector until the next tick starts.The solution is pretty simple: set a per-tick limit for the object pool list. If a certain limit is passed (I'd recommend 10-20k), return any additional objects always newly constructed so they can be garbage-collected once they're no longer being used. This also allows the use of fixed-size arrays, which could be a little faster than lists.
This obviously won't fix the FPS performance issues during mass explosions, but at least you'll be able to see the result after some time without having 32+ GB RAM.
This bug has been in Minecraft for a good while. When starting a chain reaction with several hundreds of TNT blocks involved, the game will start to allocate massive amounts of memory until the virtual machine heap space (-Xmx) is fully exhausted, with the well-known "Out of memory" screen as a result.
This is caused by the dynamic object pooling for vector and bounding box objects combined with very expensive explosion damage/propulsion calculations.Each explosion potentially requires some thousand vectors and a few hundred bounding boxes, whose instances are all stored in the pool for the current tick.
Since the pool size isn't imitated in any way, it stores every single instance in its list.(Update: vector lists seem to be controlled in some way since 1.4.x, but it still doesn't stop them from collecting all objects in one single tick) So if many TNT explosions produce 100 million temporary objects during a tick, everything will be kept in memory and unreachable for the garbage collector until the next tick starts.The solution is pretty simple: set a per-tick limit for the object pool list. If a certain limit is passed (I'd recommend 10-20k), return any additional objects always newly constructed so they can be garbage-collected once they're no longer being used. This also allows the use of fixed-size arrays, which could be a little faster than lists.
This obviously won't fix the FPS performance issues during mass explosions, but at least you'll be able to see the result after some time without having 32+ GB RAM.
This bug has been in Minecraft for a good while. When starting a chain reaction with several hundreds of TNT blocks involved, the game will start to allocate massive amounts of memory until the virtual machine heap space (-Xmx) is fully exhausted, with the well-known "Out of memory" screen as a result.
Steps to reproduce: create a superflat world, preset "2;128x46", ignite any TNT block
This is caused by the dynamic object pooling for vector and bounding box objects combined with very expensive explosion damage/propulsion calculations.
Each explosion potentially requires some thousand vectors and a few hundred bounding boxes, whose instances are all stored in the pool for the current tick.
Since the pool size isn't imitated in any way, it stores every single instance in its list.(Update: vector lists seem to be controlled in some way since 1.4.x, but it still doesn't stop them from collecting all objects in one single tick) So if many TNT explosions produce 100 million temporary objects during a tick, everything will be kept in memory and unreachable for the garbage collector until the next tick starts.The solution is pretty simple: set a per-tick limit for the object pool list. If a certain limit is passed (I'd recommend 10-20k), return any additional objects always newly constructed so they can be garbage-collected once they're no longer being used. This also allows the use of fixed-size arrays, which could be a little faster than lists.
This obviously won't fix the FPS performance issues during mass explosions, but at least you'll be able to see the result after some time without having 32+ GB RAM.
This bug has been in Minecraft for a good while. When starting a chain reaction with several hundreds of TNT blocks involved, the game will start to allocate massive amounts of memory until the virtual machine heap space (-Xmx) is fully exhausted, with the well-known "Out of memory" screen as a result.
Steps to reproduce: create a superflat world, preset "2;128x46", ignite any TNT block.
This is caused by the dynamic object pooling for vector and bounding box objects combined with very expensive explosion damage/propulsion calculations.
Each explosion potentially requires some thousand vectors and a few hundred bounding boxes, whose instances are all stored in the pool for the current tick.
Since the pool size isn't imitated in any way, it stores every single instance in its list.(Update: vector lists seem to be controlled in some way since 1.4.x, but it still doesn't stop them from collecting all objects in one single tick) So if many TNT explosions produce 100 million temporary objects during a tick, everything will be kept in memory and unreachable for the garbage collector until the next tick starts.The solution is pretty simple: set a per-tick limit for the object pool list. If a certain limit is passed (I'd recommend 10-20k), return any additional objects always newly constructed so they can be garbage-collected once they're no longer being used. This also allows the use of fixed-size arrays, which could be a little faster than lists.
This obviously won't fix the FPS performance issues during mass explosions, but at least you'll be able to see the result after some time without having 32+ GB RAM.
This bug has been in Minecraft for a good while. When starting a chain reaction with several hundreds of TNT blocks involved, the game will start to allocate massive amounts of memory until the virtual machine heap space (-Xmx) is fully exhausted, with the well-known "Out of memory" screen as a result.
Steps to reproduce: create a superflat world, preset "2;128x46", ignite any TNT block, wait a few seconds.
This is caused by the dynamic object pooling for vector and bounding box objects combined with very expensive explosion damage/propulsion calculations.
Each explosion potentially requires some thousand vectors and a few hundred bounding boxes, whose instances are all stored in the pool for the current tick.
Since the pool size isn't imitated in any way, it stores every single instance in its list.(Update: vector lists seem to be controlled in some way since 1.4.x, but it still doesn't stop them from collecting all objects in one single tick) So if many TNT explosions produce 100 million temporary objects during a tick, everything will be kept in memory and unreachable for the garbage collector until the next tick starts.The solution is pretty simple: set a per-tick limit for the object pool list. If a certain limit is passed (I'd recommend 10-20k), return any additional objects always newly constructed so they can be garbage-collected once they're no longer being used. This also allows the use of fixed-size arrays, which could be a little faster than lists.
This obviously won't fix the FPS performance issues during mass explosions, but at least you'll be able to see the result after some time without having 32+ GB RAM.
This bug has been in Minecraft for a good while. When starting a chain reaction with several hundreds of TNT blocks involved, the game will start to allocate massive amounts of memory until the virtual machine heap space (-Xmx) is fully exhausted, with the well-known "Out of memory" screen as a result.
Steps to reproduce: create a superflat world, preset "2;128x46", ignite any TNT block, wait a few seconds.
This is caused by the dynamic object pooling for vector and bounding box objects combined with very expensive explosion damage/propulsion calculations.
Each explosion potentially requires some thousand vectors and a few hundred bounding boxes, whose instances are all stored in the pool for the current tick.
Since the pool size isn't imitated in any way, it stores every single instance in its list.(Update: vector lists seem to be controlled in some way since 1.4.x, but it still doesn't stop them from collecting all objects in one single tick) So if many TNT explosions produce 100 million temporary objects during a tick, everything will be kept in memory and unreachable for the garbage collector until the next tick starts.The solution is pretty simple: set a per-tick limit for the object pool list. If a certain limit is passed (I'd recommend 10-20k), return any additional objects always newly constructed so they can be garbage-collected once they're no longer being used. This also allows the use of fixed-size arrays, which could be a little faster than lists. The attachments show a simple example that allows me to perform explosions like on a TNT superflat world as above with just 4 GB RAM.
This obviously won't fix the FPS performance issues during mass explosions, but at least you'll be able to see the result after some time without having 32+ GB RAM.
This bug has been in Minecraft for a good while. When starting a chain reaction with several hundreds of TNT blocks involved, the game will start to allocate massive amounts of memory until the virtual machine heap space (-Xmx) is fully exhausted, with the well-known "Out of memory" screen as a result.
Steps to reproduce: create a superflat world, preset "2;128x46", ignite any TNT block, wait a few seconds.
This is caused by the dynamic object pooling for vector and bounding box objects combined with very expensive explosion damage/propulsion calculations.
Each explosion potentially requires some thousand vectors and a few hundred bounding boxes, whose instances are all stored in the pool for the current tick.
Since the pool size isn't imitated in any way, it stores every single instance in its list.(Update: vector lists seem to be controlled in some way since 1.4.x, but it still doesn't stop them from collecting all objects in one single tick) So if many TNT explosions produce 100 million temporary objects during a tick, everything will be kept in memory and unreachable for the garbage collector until the next tick starts.The solution is pretty simple: set a per-tick limit for the object pool list. If a certain limit is passed (I'd recommend 10-20k), return any additional objects always newly constructed so they can be garbage-collected once they're no longer being used. This also allows the use of fixed-size arrays, which could be a little faster than lists. The attachments
show a simple example that allows me to perform explosions like on a TNT superflat world as above with just 4 GB RAM.This obviously won't fix the FPS performance issues during mass explosions, but at least you'll be able to see the result after some time without having 32+ GB RAM.
This bug has been in Minecraft for a good while. When starting a chain reaction with several hundreds of TNT blocks involved, the game will start to allocate massive amounts of memory until the virtual machine heap space (-Xmx) is fully exhausted, with the well-known "Out of memory" screen as a result.
Steps to reproduce: create a superflat world, preset "2;128x46", ignite any TNT block, wait a few seconds.
This is caused by the dynamic object pooling for vector and bounding box objects combined with very expensive explosion damage/propulsion calculations.
Each explosion potentially requires some thousand vectors and a few hundred bounding boxes, whose instances are all stored in the pool for the current tick.
Since the pool size isn't imitated in any way, it stores every single instance in its list.(Update: vector lists seem to be controlled in some way since 1.4.x, but it still doesn't stop them from collecting all objects in one single tick) So if many TNT explosions produce 100 million temporary objects during a tick, everything will be kept in memory and unreachable for the garbage collector until the next tick starts.The solution is pretty simple: set a per-tick limit for the object pool list. If a certain limit is passed (I'd recommend 10-20k), return any additional objects always newly constructed so they can be garbage-collected once they're no longer being used. This also allows the use of fixed-size arrays, which could be a little faster than lists. The attachments below contain some example code that allows me to perform explosions like on a TNT superflat world as above with just 4 GB RAM without any known side-effects.
This obviously won't fix the FPS performance issues during mass explosions, but at least you'll be able to see the result after some time without having 32+ GB RAM.
This bug has been in Minecraft for a good while. When starting a chain reaction with several hundreds of TNT blocks involved, the game will start to allocate massive amounts of memory until the virtual machine heap space (-Xmx) is fully exhausted, with the well-known "Out of memory" screen as a result.
Steps to reproduce: create a superflat world, preset "2;128x46", ignite any TNT block, wait a few seconds.
This is caused by the dynamic object pooling for vector and bounding box objects combined with very expensive explosion damage/propulsion calculations.
Each explosion potentially requires some thousand vectors and a few hundred bounding boxes, whose instances are all stored in the pool for the current tick.
Since the pool size isn't imitated in any way, it stores every single instance in its list.(Update: vector lists seem to be controlled in some way since 1.4.x, but it still doesn't stop them from collecting all objects in one single tick) So if many TNT explosions produce 100 million temporary objects during a tick, everything will be kept in memory and unreachable for the garbage collector until the next tick starts.The solution is pretty simple: set a per-tick limit for the object pool list. If a certain limit is passed (I'd recommend 10-20k), return any additional objects always newly constructed so they can be garbage-collected once they're no longer being used. This also allows the use of fixed-size arrays, which could be a little faster than lists. The attachments below contain some example code that allows me to perform explosions like on a TNT superflat world as above with just 4 GB RAM without any known side-effects. (of course, the enormous amount of entities and TNT block meshes will also produce out of memory errors at some point, but much later than in vanilla)
This obviously won't fix the FPS performance issues during mass explosions, but at least you'll be able to see the result after some time without having 32+ GB RAM.
This bug has been in Minecraft for a good while. When starting a chain reaction with several hundreds of TNT blocks involved, the game will start to allocate massive amounts of memory until the virtual machine heap space (-Xmx) is fully exhausted, with the well-known "Out of memory" screen as a result.
Steps to reproduce: create a superflat world, preset "2;128x46", ignite any TNT block, wait a few seconds.
This is caused by the dynamic object pooling for vector and bounding box objects combined with very expensive explosion damage/propulsion calculations.
Each explosion potentially requires some thousand vectors and a few hundred bounding boxes, whose instances are all stored in
thepool for the current tick.
Since the pool size isn't imitated in any way, it stores every single instance in its list.(Update: vector lists seem to be controlled in some way since 1.4.x, but it still doesn't stop them from collecting all objects in one single tick) So if many TNT explosions produce 100 million temporary objects during a tick, everything will be kept in memory and unreachable for the garbage collector until the next tick starts.The solution is pretty simple: set a per-tick limit for the object pool list. If a certain limit is passed (I'd recommend 10-20k), return any additional objects always newly constructed so they can be garbage-collected once they're no longer being used. This also allows the use of fixed-size arrays, which could be a little faster than lists. The attachments below contain some example code that allows me to perform explosions like on a TNT superflat world as above with just 4 GB RAM without any known side-effects. (of course, the enormous amount of entities and TNT block meshes will also produce out of memory errors at some point, but much later than in vanilla)
This obviously won't fix the FPS performance issues during mass explosions, but at least you'll be able to see the result after some time without having 32+ GB RAM.
This bug has been in Minecraft for a good while. When starting a chain reaction with several hundreds of TNT blocks involved, the game will start to allocate massive amounts of memory until the virtual machine heap space (-Xmx) is fully exhausted, with the well-known "Out of memory" screen as a result.
Steps to reproduce: create a superflat world, preset "2;128x46", ignite any TNT block, wait a few seconds.
This is caused by the dynamic object pooling for vector and bounding box objects combined with very expensive explosion damage/propulsion calculations.
Each explosion potentially requires some thousand vectors and a few hundred bounding boxes, whose instances are all stored in a pool for the duration of the current tick.
Since the pool size isn't imitated in any way, it stores every single instance in its list.(Update: vector lists seem to be controlled in some way since 1.4.x, but it still doesn't stop them from collecting all objects in one single tick) So if many TNT explosions produce 100 million temporary objects during a tick, everything will be kept in memory and unreachable for the garbage collector until the next tick starts.The solution is pretty simple: set a per-tick limit for the object pool list. If a certain limit is passed (I'd recommend 10-20k), return any additional objects always newly constructed so they can be garbage-collected once they're no longer being used. This also allows the use of fixed-size arrays, which could be a little faster than lists. The attachments below contain some example code that allows me to perform explosions like on a TNT superflat world as above with just 4 GB RAM without any known side-effects. (of course, the enormous amount of entities and TNT block meshes will also produce out of memory errors at some point, but much later than in vanilla)
This obviously won't fix the FPS performance issues during mass explosions, but at least you'll be able to see the result after some time without having 32+ GB RAM.
This bug has been in Minecraft for a good while. When starting a chain reaction with several hundreds of TNT blocks involved, the game will start to allocate massive amounts of memory until the virtual machine heap space (-Xmx) is fully exhausted, with the well-known "Out of memory" screen as a result.
Steps to reproduce: create a superflat world, preset "2;128x46", ignite any TNT block, wait a few seconds.
This is caused by the dynamic object pooling for vector and bounding box objects combined with very expensive explosion damage/propulsion calculations.
Each explosion potentially requires some thousand vectors and a few hundred bounding boxes, whose instances are all stored in a pool for the duration of the current tick.
Since the pool size isn't imitated in any way, it stores every single instance in its list.(Update: vector lists seem to be controlled in some way since 1.4.x, but it still doesn't stop them from collecting all objects in one single tick) So if many TNT explosions produce 100 million temporary objects during a tick, everything will be kept in memory and unreachable for the garbage collector until the next tick starts.The solution is pretty simple: set a per-tick limit for the object pool list. If a certain limit is passed (I'd recommend 10-20k), return any additional objects always newly constructed so they can be garbage-collected once they're no longer being used. This also allows the use of fixed-size arrays, which could be a little faster than lists. The attachments below contain some example code that allows me to perform explosions like on a TNT superflat world as above with just 4 GB RAM without any known side
-effects. (of course, the enormous amount of entities and TNT block meshes will also produce out of memory errors at some point, but much later than in vanilla)This obviously won't fix the FPS performance issues during mass explosions, but at least you'll be able to see the result after some time without having 32+ GB RAM.
This bug has been in Minecraft for a good while. When starting a chain reaction with several hundreds of TNT blocks involved, the game will start to allocate massive amounts of memory until the virtual machine heap space (-Xmx) is fully exhausted, with the well-known "Out of memory" screen as a result.
Steps to reproduce: create a superflat world, preset "2;128x46", ignite any TNT block, wait a few seconds.
This is caused by the dynamic object pooling for vector and bounding box objects combined with very expensive explosion damage/propulsion calculations.
Each explosion potentially requires some thousand vectors and a few hundred bounding boxes, whose instances are all stored in a pool for the duration of the current tick.
Since the pool size isn't imitated in any way, it stores every single instance in its list.(Update: vector lists seem to be controlled in some way since 1.4.x, but it still doesn't stop them from collecting all objects in one single tick) So if many TNT explosions produce 100 million temporary objects during a tick, everything will be kept in memory and unreachable for the garbage collector until the next tick starts.The solution is pretty simple: set a per-tick limit for the object pool list. If a certain limit is passed (I'd recommend 10-20k), return any additional objects always newly constructed so they can be garbage-collected once they're no longer being used. This also allows the use of fixed-size arrays, which could be a little faster than lists. The attachments below contain some example code that allows me to perform explosions like on a TNT superflat world as above with just 4 GB RAM without any known side effects. (of course, the enormous amount of entities and TNT block meshes will also produce out of memory errors at some point, but much later than in vanilla)
This obviously won't fix the FPS performance issues during mass explosions, but at least you'll be able to see the result after some time without having 32+ GB RAM.
is duplicated by
relates to
is duplicated by
![[Mod] CubeTheThird](../../../data/assets/gravatar/cubethethird.jpeg){kind=small}
Is this still a concern in the current Minecraft version? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
Is this still a concern in the current Minecraft version 1.6.4 / Launcher version 1.2.5 ? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
I saw this problem in 1.6.4, although I haven't exactly duplicated the
original poster's superflat world--I was just trying to make an interesting
world that I could have a big explosion in. When I searched for the problem
I had, MC-3256 seemed to be the same.
I don't yet feel familiar enough with Atlassian to have posted my report
file and bug description. I didn't find the current version lists, for
example.
If you haven't gotten 50 more useful replies by the time you read this, let
me know, and I'll be happy to either send my report file as is, or exactly
duplicate mc-3256 and attach that file, in the morning (I'm in Mountain
time).
HTH,
Carl Feitler
On Wed, Sep 25, 2013 at 10:42 PM, [Mod] CubeTheThird (JIRA) <
Added MCP-style code example for fixed object pooling
Yes, it is still present in 1.5. I updated the version tags.
There's a way to remove all of the Primed TNT Entities so you can de-activate the TNT and go back into your world safely, if you have got MCEdit!
1. Open your world in MCEdit
2. Find all of the Primed TNT entities
3. Delete the Primed TNT entities
4. Also delete whatever triggered the TNT to ensure it doesn't happen again
5. Save the world
6. Open the world in Minecraft
7. No TNT is activated, so there won't be any explosions
8. Enjoy
I saw this problem in 1.6.4, although I haven't exactly duplicated the
original poster's superflat world--I was just trying to make an interesting
world that I could have a big explosion in. When I searched for the problem
I had,
MC-3256seemed to be the same.I don't yet feel familiar enough with Atlassian to have posted my report
file and bug description. I didn't find the current version lists, for
example.
If you haven't gotten 50 more useful replies by the time you read this, let
me know, and I'll be happy to either send my report file as is, or exactly
duplicate mc-3256 and attach that file, in the morning (I'm in Mountain
time).
HTH,
Carl Feitler
On Wed, Sep 25, 2013 at 10:42 PM, [Mod] CubeTheThird (JIRA) <
Crash report from Launcher 1.2.5, Minecraft version 1.6.4.
Created superflat world with 64 layers of TNT, ignited with a redstone torch. A few seconds later, "Out of Memory" dialog window, "Minecraft could not continue, as it has run out of memory."
Yes, it's still happening, although the game now shuts down the internal server properly instead of crashing altogether.
still happens. i tried it with tnt minecarts (more than about 20) and it lags a bit then crashes
Is this still a concern in the current Minecraft version 14w21b / Launcher version 1.4.4 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
I've repeated the test with 14w30b and it looks like it won't run out of memory anymore. I think it has been fixed in 1.7.10 already, since there's no object pool for vectors anymore, which essentially fixes this issue.
Just well this happens for reasons:
-You have too much mods
-You're using fast as light machines using tons of mechanism
-Large tnt chains
-You're using a pissed buff(such as absorption 127)
i was using a ipod mod and i used the app explosion and i did explosion power:2000 and my game lagged like freak heck and i tryed loading another world and it crashed with the error: out of ram.