JVM Tuning?

I’m considering migrating a first person shooter project I’ve been working on for the past several years (custom engine) to jmonkeyengine. After a quick review of the structure and api, it looks to have everything I require, AND is very simple and easy to understand.

One thing I’m hoping someone could confirm for me though is JVM tuning and optimization ability (if it were ever to be required). I’ve written and supported a few java web applications in the past, but have never had to dig too deep into how the JVM manages memory, or do any custom tuning myself, therefore I’m unsure of how easy/difficult it would be to ship a finished game and have the optimizations take effect on a user’s installed jvm, or if rather you would want to package a jvm with the production release?

I simply need to know that if I sink months worth of time into a prototype and discover that there are micro glitches due to GC, that I would have some avenue to be able to smooth these out.

I understand that if I follow best practices and write optimized code that this will probably not be an issue, and I may be concerned for no reason…I just want to confirm that if I get to the level of requiring JVM optimizations to accomplish something, that it’s possible.

Thanks! :slight_smile:

Sure it’s possible.

I think this is certainly the modern way. Else you potentially send your users down a maze of twisty packages to get and install the correct JVM.

This is almost always an application problem. Modern GC keeps up pretty well and you don’t even have to try very hard. In fact, most folks get into trouble trying to out-think it.

Your frame drops will come from other things: bad scene management, unnecessary shader recompiles, overly complex physics/animation * too many objects, etc…

4 Likes

Excellent! That all makes perfect sense. Thanks for the reply :smiley:

1 Like

The only thing that I have seen make a difference (and not a very big one) is to use the shenandoah gc. The key reason for this is it has several optimizations for jni calls, which JME uses LWJGL, which in turn is just a wrapper around thousands of jni calls. In theory one may gain from 1 to 2 ns of performance per jni call. And depending on the number of jni calls in a frame, this may become a slight optimization. But keep in mind, any optimization done at this level will have little difference compared to optimizations at your code level. Also using a newer JDK usually helps with performance. For example, using JDK 17 over 11.

EDIT: Spasi, who is the maintainer of LWJGL has some benchmarks for different GCs with JNI calls buried somewhere in one of the many jdk mailing lists. I did not find it from a quick search, but perhaps someone has a quick link to it on hand.

4 Likes

By the way, you might also find this interesting. Seems to make a speed up of around 7ns per JNI call.

5 Likes

That is very interesting. It looks like that patch will be in JDK 20. Maybe if we are lucky it will get backported to 19 in an upcoming update.

1 Like