3 ms·

My main advice, ignore all advice online about JVM tuning minecraft. It's dated and often just wrong. The best thing you can do is run on the latest JVM, set

My main advice, ignore all advice online about JVM tuning minecraft. It's dated and often just wrong. The best thing you can do is run on the latest JVM, set your max memory as high as you can tolerate, and use ZGC. That's it. The JVM tuning guides for minecraft will have you switching and toggling every JVM flag under the sun with extremely dubious "evidence" of the payout for the flags they switch. In some cases, they will set contradictory flags. For example, setting eden size and target pause time. The fine tuning flags disable the heuristic flags like target pause time. KISS. ZGC has very low latency and the larger the heap you give it the less it'll slow things down (though, do keep it under 32gb. Object header compression works on heaps less than 32gb). And using the latest JVM reduces the memory needed and increases the performance in general of the JVM. Win-win.

Night_Thastus 3mo ago
It did used to be required. Older Java versions performed pretty terrible. However, Java 17+ completely fixed that. Even the heaviest modded setups run buttery smooth, even on older versions which are not well optimized.
- cogman10 3mo ago
  It really wasn't and was always dubious. A lot of the advice, for example, suggested using CMS. Which has been a terrible garbage collector almost since it was added to the JVM. When G1GC landed in 8, that was the correct GC to select for minecraft. Even the parallel collector would have been a better option than CMS in a lot of cases (sub 4gb heaps). It was placebo. People wanted there to be SOMETHING that made things better so they reached for the billion different flags on the JVM (rather than fixing the underlying code). I've seen the same sort of mentality professionally and it's basically always been wrong.
  - Quekid5 3mo ago
    Yep, once people discover the multitude of JVM flags the cargo culting begins... It really applies to anything with a huge number of options, I remember similar things from back when I used Gentoo and the wild suggestions I'd get for what exact CC/C++ compiler options to use...
  - nananana9 3mo ago
    > rather than fixing the underlying code There's not much you can do to fix the underlying code if the language doesn't allow you to declare a struct Vector3 { float x, y, z; } without heap-allocating it.
- pjmlp 3mo ago
  It was more like Minecraft code was horrible, than anything else. Creating objects like crazy, range for in hot paths, not caring about data representation, chosen algorithms,.... JIT and GC were already doing heroic efforts. Yet, it settled Notch for life, which is something to take into account in the usual question regarding which technical stack for games.
  - hwyadenlaw 3mo ago
    For sure. The tech only needs to be good enough to support the game design. For some games that means very high optimisation is needed, and for others it's enough that the screen can refresh before the user gets tired of waiting.
  - Night_Thastus 3mo ago
    Minecraft 1.7.10, covered in mods, can run fantastic (300+ FPS) if Java 25 is used. That used to be impossible.
    - vintermann 3mo ago
      Thanks to the Gregtech New Horizon folks.
  - 0x3444ac53 3mo ago
    Yeah at the time it was bad. Now, it's a pretty nice codebase
int0x29 3mo ago
Set JVM heap to half available memory. Mincraft is very much the kind of appication that benifits from filesystem cache to help with loading chunks. Also if for some reason you are setting the heap size high avoid going past 32 gb unless you tune object alignment. Allocating between 32 and 47 gb will result in an effectively smaller heap. Allocating more than 32 gb can result in performance penalties.
- inigyou 3mo ago
  Wow. When I played Minecraft, 1GB was enough and 4GB was a lot. I know that since 1.8 Microsoft rewrote large parts of the engine to make them less efficient and more ivory-tower, but I didn't know it was that bad.
  - atomicnumber3 3mo ago
    We're talking for servers, which almost always means modded (even if only server side mods like the bukkit family). Pretty common for servers with more than a dozen people to be running heaps in the 8-16GB range. And one reason for the "large" size is that they can often run with a lot less but when memory isn't that constricted you can tune for smaller GC pause times
  - mudkipdev 3mo ago
    FWIW I still run a server for 5 people with 2GB ram and the performance is fine.
  - int0x29 3mo ago
    This was more a hasty response with modding in mind to the parent comment of "set it as high as you are comfortable with." There are limits to how high you should go. If you are running vanilla you may not need to set the heap to 50%. Anything past 50% or 32 gb isn't a great idea generally.
Velocifyer 3mo ago
Do not set the heap size to more than 8GiB, even if using heavy modpacks. Anything above 8GiB actually makes the game run worse, unless you have tons of players, because of GC lag.
- preg_match 3mo ago
  8 GB is simply not enough for most modpacks, at least the 200+ mods one. I know, I've tried, although it was years ago. You run at consistently 95% GC usage and get constant, very heavy, collections because of it. Like every second you get lag spikes due to GC pressure. And because of the usage these look to be full collections, which are stop-the-world last I checked. This was ~5 years ago, so I'm sure it's gotten better. But not that much better 8gb would cut it, either client or server side.
- cogman10 3mo ago
  It depends on the GC, with ZGC no. Particularly if you enable generational mode. For other GCs like G1 and the parallel collector, when new gen is filled up the GC pauses the application in order to run a minor collection. For G1, major collections are ran in the background until the heap fully fills up. When that happens, the GC triggers stop the world GC. A smaller heap size would cause those pauses to be more frequent but because the heap is smaller it means that ultimately the pauses will be limited in length. ZGC is different. Without generational mode, ZGC is collecting the entire heap every time with it, ZGC will do the young old collections. When a collection is triggered, ZGC flips a field to indicate a collection in progress, that flip is the only pause for the application under zgc (except the case that the heap fully fills) it typically finishes in microseconds. Once collection starts, the ZGC collector threads and the in progress application are running collections. The size of the heap really doesn't change much other than the background collection could last longer (slowing down the server, but not totally stopping it from being responsive). The payment you make with ZGC is that you do burn more CPU cycles doing collections especially while the app is running. But for a game server, that hardly matters. What matters is that the server remains responsive in a timely fashion, which ZGC enables.
  - acpdev 3mo ago

Night_Thastus 3mo ago

It did used to be required. Older Java versions performed pretty terrible. However, Java 17+ completely fixed that. Even the heaviest modded setups run buttery smooth, even on older versions which are not well optimized.

cogman10 3mo ago
It really wasn't and was always dubious. A lot of the advice, for example, suggested using CMS. Which has been a terrible garbage collector almost since it was added to the JVM. When G1GC landed in 8, that was the correct GC to select for minecraft. Even the parallel collector would have been a better option than CMS in a lot of cases (sub 4gb heaps). It was placebo. People wanted there to be SOMETHING that made things better so they reached for the billion different flags on the JVM (rather than fixing the underlying code). I've seen the same sort of mentality professionally and it's basically always been wrong.
- Quekid5 3mo ago
  Yep, once people discover the multitude of JVM flags the cargo culting begins... It really applies to anything with a huge number of options, I remember similar things from back when I used Gentoo and the wild suggestions I'd get for what exact CC/C++ compiler options to use...
- nananana9 3mo ago
  > rather than fixing the underlying code There's not much you can do to fix the underlying code if the language doesn't allow you to declare a struct Vector3 { float x, y, z; } without heap-allocating it.
pjmlp 3mo ago
It was more like Minecraft code was horrible, than anything else. Creating objects like crazy, range for in hot paths, not caring about data representation, chosen algorithms,.... JIT and GC were already doing heroic efforts. Yet, it settled Notch for life, which is something to take into account in the usual question regarding which technical stack for games.
- hwyadenlaw 3mo ago
  For sure. The tech only needs to be good enough to support the game design. For some games that means very high optimisation is needed, and for others it's enough that the screen can refresh before the user gets tired of waiting.
- Night_Thastus 3mo ago
  Minecraft 1.7.10, covered in mods, can run fantastic (300+ FPS) if Java 25 is used. That used to be impossible.
  - vintermann 3mo ago
    Thanks to the Gregtech New Horizon folks.
- 0x3444ac53 3mo ago
  Yeah at the time it was bad. Now, it's a pretty nice codebase

int0x29 3mo ago

Set JVM heap to half available memory. Mincraft is very much the kind of appication that benifits from filesystem cache to help with loading chunks. Also if for some reason you are setting the heap size high avoid going past 32 gb unless you tune object alignment. Allocating between 32 and 47 gb will result in an effectively smaller heap. Allocating more than 32 gb can result in performance penalties.

inigyou 3mo ago
Wow. When I played Minecraft, 1GB was enough and 4GB was a lot. I know that since 1.8 Microsoft rewrote large parts of the engine to make them less efficient and more ivory-tower, but I didn't know it was that bad.
- atomicnumber3 3mo ago
  We're talking for servers, which almost always means modded (even if only server side mods like the bukkit family). Pretty common for servers with more than a dozen people to be running heaps in the 8-16GB range. And one reason for the "large" size is that they can often run with a lot less but when memory isn't that constricted you can tune for smaller GC pause times
- mudkipdev 3mo ago
  FWIW I still run a server for 5 people with 2GB ram and the performance is fine.
- int0x29 3mo ago
  This was more a hasty response with modding in mind to the parent comment of "set it as high as you are comfortable with." There are limits to how high you should go. If you are running vanilla you may not need to set the heap to 50%. Anything past 50% or 32 gb isn't a great idea generally.

Velocifyer 3mo ago

Do not set the heap size to more than 8GiB, even if using heavy modpacks. Anything above 8GiB actually makes the game run worse, unless you have tons of players, because of GC lag.

preg_match 3mo ago
8 GB is simply not enough for most modpacks, at least the 200+ mods one. I know, I've tried, although it was years ago. You run at consistently 95% GC usage and get constant, very heavy, collections because of it. Like every second you get lag spikes due to GC pressure. And because of the usage these look to be full collections, which are stop-the-world last I checked. This was ~5 years ago, so I'm sure it's gotten better. But not that much better 8gb would cut it, either client or server side.
cogman10 3mo ago
It depends on the GC, with ZGC no. Particularly if you enable generational mode. For other GCs like G1 and the parallel collector, when new gen is filled up the GC pauses the application in order to run a minor collection. For G1, major collections are ran in the background until the heap fully fills up. When that happens, the GC triggers stop the world GC. A smaller heap size would cause those pauses to be more frequent but because the heap is smaller it means that ultimately the pauses will be limited in length. ZGC is different. Without generational mode, ZGC is collecting the entire heap every time with it, ZGC will do the young old collections. When a collection is triggered, ZGC flips a field to indicate a collection in progress, that flip is the only pause for the application under zgc (except the case that the heap fully fills) it typically finishes in microseconds. Once collection starts, the ZGC collector threads and the in progress application are running collections. The size of the heap really doesn't change much other than the background collection could last longer (slowing down the server, but not totally stopping it from being responsive). The payment you make with ZGC is that you do burn more CPU cycles doing collections especially while the app is running. But for a game server, that hardly matters. What matters is that the server remains responsive in a timely fashion, which ZGC enables.
- acpdev 3mo ago