Let’s be honest: I only use Java for Minecraft. So I only debugged with it. But all version, server or client, all launchers. All of them use double (or more) RAM. In the game the correctly allocated amount is used, but on my system double or more is allocated. Thus my other apps don’t get enough memory, causing crashes, while the game is suffering as well.
I’m not wise enough to know what logs or versions or whatever I should post here as a cry for help, but I’ll update this with anything that’ll help, just tell me. I have no idea how to approach the problem. One idea I have is to run a non-Minecraft java application, but who has( or knows about) one of those?
@jrgd@lemm.ee’s request:
launch arguments [-Xms512m, -Xmx1096m, -Duser.language=en] (it’s this little, so that the difference shows clearly. I have a modpack that I give 8gb to and uses way more as well. iirc around 12)
game version 1.18.2
total system memory 32gb
memory used by the game
I’m using KDE’s default system monitor, but here’s Btop as well:
this test was on max render distance, with 1gb of ram, it crashed ofc, but it crashed at almost 4gbs, what the hell! That’s 4 times as much
I’m on arch (btw) (sry)
Depending on version and if modded with content mods, you can easily expect Minecraft to utilize a significant portion memory more than what you give for its heap. Java processes have a statically / dynamically (with bounds) allocated heap from system memory as well as memory used in the stack of the process. Additionally Minecraft might show using more memory in some process monitors due to any external shared libraries being utilized by the application.
My recommendation: don’t allocate more memory to the game than you need to run it without noticeable stutters from garbage collection. If you are running modded Minecraft, one or more mods might be causing stack-related memory leaks (or just being large and complex enough to genuinely require large amounts of memory. We might be able to get a better picture if you shared your launch arguments, game version, total system memory, memory used by the game in the process monitor you are using (and modlist if applicable).
In general, it’s also a good idea to setup and enable ZRAM and disable Swap if in use.
Big modpacks that add a lot of different blocks will also always explode the memory usage as at the start, Minecraft pre-bakes all the 3d models of the blocks.
also: this test was on max render distance, with 1gb of ram, it crashed ofc, but it crashed at almost 4gbs, what the hell! That’s 4 times as much
For clarification, this is Vanilla, a performance mod Fabric pack, a Fabric content modpack, Forge modpack, etc. that you are launching? If it’s the modpack that you describe needing 8gb of heap memory allocated, I wouldn’t be surprised the java stack memory taking ~2.7 GiB. If it’s plain vanilla, that memory usage does seem excessive.
This was Vanilla.
Running the same memory constraints on a 1.18 vanilla instance, most of the stack memory allocation largely comes from ramping the render distance from 12 chunks to 32 chunks. The game only uses ~0.7 GiB memory non-heap at a sane render distance in vanilla whereas ~2.0 GiB at 32 chunks. I did forget the the render distance no longer caps out in vanilla at 16 chunks. Far render distances like 32 chunks will naturally balloon the stack memory size.
That you’d think that random game objects aren’t stored on the stack. Well, thanks for the info. Guess there isn’t anything to do, as others have said as well.
It looks like you’re looking at the entire PolyMC process group so in this case memory usage also includes PolyMC itself, which buffers a chunk of the logs. It shouldn’t be using that much, but it will add a hundred MB or two to your total here as well.