Updated JVM Settings for RR 2.8.x

For those people who don't want to know the nitty gritty details, just go to the bottom of the post to get the latest settings.

Nosebleed ensues...


When I upgraded to, I noticed a huge performance drop as compared to the last 2.7.x. So I put on my detective hat to investigate.

There are 2 major problems with 2.8.x.

First: the JVM is running out of code cache. Code cache is a separate memory space in the JVM (apart from the heap) that stores all the natively compiled methods. Getting methods to natively compile is what speeds things up. If the code cache gets full, the JVM turns of the native compiler, and will never turn on until you restart the process. Result is a loss of speed, which can manifest as either FPS lag or tick lag.

When I first did the tuning for 2.5.x and 2.7.x, I disabled a feature called code cache flushing. Runtime compilation is an expensive operation, even with the tiered compilation feature introduced in Java 7. This is why you get good speed/framerate as time goes by: it does not need to do any recompilation. Also note that we are using the default code cache size, and it never gets full.

With 2.8.x, the code cache size fills up. And it fills up at an insane pace. Even after increasing the code cache to about 4 times the original size, it still gets filled up! It may be due to the sheer number of mods, or maybe due to one or two mods leaking memory. Unfortunately, I don't have the time to figure that out. But what I do know is that 2.8.x introduced something to cause this problem.

Second: RR cannot be played with 2GB of heap for extended periods of time. One of the things I do to test my JVM settings is to have RR run for at least half a day without any restart. I am reaching the 2GB limit in less than an hour. Not good.

If you reach the limit, the JVM's garbage collectors will go crazy. It'll try to continuously free up memory, even if it cannot. And this slows down the game significantly.

So this is a decision of stability vs performance. And in this case, I went with the former.

So, here's a summary of the changes to the settings:

1. Increased the code cache size from the default 48(?) MB to 256 MB.
2. Turned on code cache flushing.
3. Requires 3GB of heap (Memory/RAM setting in ATLauncher).



These changes result to a more consistent FPS and better stability for 2.8.x, but at a lower framerate: about 5-10% lower than what it was in 2.7.x.

RR now requires 3GB Memory. You can still go lower, but be prepared to deal with some serious lag over time. Nothing I can do about it.

You can use these settings for RR-Lite, but I think this would be overkill.


-server -XX:+TieredCompilation -XX:CompileThreshold=1500 -XX:-DontCompileHugeMethods -XX:+UseCodeCacheFlushing -XX:ReservedCodeCacheSize=256m -XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0 -XX:NewRatio=3 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+DisableExplicitGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:+CMSParallelRemarkEnabled -XX:+UseCompressedOops -XX:CMSInitiatingOccupancyFraction=30 -XX:+UseCMSInitiatingOccupancyOnly


-server -XX:+TieredCompilation -XX:-DontCompileHugeMethods -XX:+UseCodeCacheFlushing -XX:ReservedCodeCacheSize=256m -XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0 -XX:NewRatio=3 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+DisableExplicitGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:+CMSParallelRemarkEnabled -XX:+UseCompressedOops -XX:CMSInitiatingOccupancyFraction=30 -XX:+UseCMSInitiatingOccupancyOnly

Feedback is highly appreciated.
Shared publiclyView activity