How does JME handle GC pauses etc.?

I’ve ready so many posts and articles that claim Java just isn’t suitable for making a game engine for a variety of reasons but mainly because of “unwanted and unpredictable GC pauses”.

Does JME employ any special techniques to either reduce or eliminate these pauses or is this simply not a real issue in practice?

This is both partially true and partially false. The JVM is perfectly fine for making game engines (as Minecraft and countless smaller projects have proven over and over and over and over and over and…) but like any tool it has its gotchas. A lot of articles I’ve read that claim Java is slow or suffers from hiccups due to GC are either (a) dreadfully outdated, or (b) dreadfully misinformed (“it’s interpreted from bytecode so it CAN’T be as fast as a native language!”). It’s true that older versions of Java (i.e. Java 1.0) had speed issues, but modern (6, 7, 8, etc.) VMs are blazingly fast at runtime. The same is also true of the garbage collectors - the older ones were simple (comparatively!) and were a lot more likely to do full stop-the-world pauses than newer ones are. Newer GCs like CMS (Concurrent-Mark-and-Sweep) and G1 (Garbage 1st) are a lot more careful about reducing the number of stop-the-world pauses and the minimizing the duration of them. Sure, it’s still possible to produce vast amounts of garbage and cause your FPS to stutter because of the GC doing a stop-the-world pause. That said, Java’s GC is actually more efficient than C/C++ malloc()/free()/new/delete over the long run - i.e., if you create and toss lots of objects in a Java program, the CPU spends less time managing memory than if you create and toss lots of objects/memory regions in C++/C. If you’re being sloppy in C++ with your memory, you’re just as likely (in practice, much more likely) to get into trouble with performance (or worse, crashes) than with Java. The only thing you gain by manual memory management is that you do get to control when the pauses happen, but I find that in practice that advantage is lost in the noise to the horrendous complexity of efficient memory management and the likelihood of very subtle bugs brought by C++. Writing a game in C++ because you can control memory pauses is kind of like jumping off the side of a ship in the middle of a storm at sea because you want to go swimming with your new rubber ducky. Sure, it sounds fun, but it’s gonna be awfully unpleasant in practice and you’re going to get hit with a lot of things you weren’t expecting. (Unless , of course, you’re a hardened C++ expert, or, to keep up the analogy, an extreme sports swimmer. :wink: )

Yes. jME’s Vector3f and other math classes have GC-friendly methods that allow you to perform math operations without creating garbage. Instances of things like Vector3f.ZERO are shared too. jME itself is very GC friendly.

Almost always yes. If you’re experiencing stutters and your benchmarks show that they’re caused by GC pauses, find out what’s creating so much garbage. It’s pretty unlikely that a game needs to be creating/throwing away so many objects that the GC starts pausing like that. You can also often eliminate these by setting a few GC parameters (but be careful, don’t do that unless you know what you’re doing) without even touching code. For example, if I recall correctly, @frozenshade was able to eliminate any noticeable pauses by switching the GC to CMS.

3 Likes

Thanks very much for the informative answer.

I suspected that many of the criticisms aimed at Java from C/C++ fanboys today may be somewhat outdated… to put it mildly.

I love that jME is implemented in Java. Java can do just about anything in the hands of a true craftsman. And, as is often noted, coding something large in C++ is almost always a nightmare.

As for “hardened C++ experts”, I doubt any really exist. There is just so many way things can go wrong, the language itself has become unbearably complex & unwieldy and it is possible to write numerous varieties of perfectly valid syntax that have completely undefined behaviour.

Plus… the productivity of programming in Java with the language features itself and the outstanding array of tools and libraries is orders of magnitude greater than with C++.

I’ll stick with Java :slight_smile:

1 Like

And it seems to be always projected towards Java. C# gets free out of jail pass :slight_smile: War for the Overworld, made with Unity, suffered from GC at some point after the release. Made it in modern terms: unplayable. There was a few second pause every “payday”. But this has been patched and probably nowadays everything is ok with the title.

Bad code is bad code. No matter the language it is written in.

When our title OpenKeeper was “featured” in Reddit. Almost everybody’s concern was Java. The interest to the project itself seemed to vanish after few posts. Then it was just about how retarded Java is. And I’ve seen comments like “too bad I can’t play it since it is made in Java. I wont install JRE because it is a security hole”. So, prepare for a fight :smiley:

1 Like

laughs in embedded jre

4 Likes

Well, fortunately there are ways to package a Java app with the appropriate JRE and distribute it as an EXE for example.

So fior all the biased snobs out there, none of them need ever know that my awesome game uses Java at all…

2 Likes

Yes. The end user will happily use it without knowing it is Java. But if you tell them, they stop using it because suddenly it is slow and requires them to install JRE plugin for browser and upgrade their computer to a super computer and buy 1000TB of memory. I can feel their pain, knowledge is pain.

With other languages the needed runtime libraries are ok, and a blessing to one’s computer. So lucky to have a sediment of 100 different versions of DLLs.

FunFact: .net is really similar to java and would hit the same gc problems (as has been pointed out), but no one complains about using Unity.

For the sake of modability I can’t hide java, so I might be arrogant to say that if someone believes Games being unable to work with java he can either ignore the game or try it and refund if he really has performance issues

The ONLY way to decide on a language is on personal preference. I like writing in java. Id have more fun writing it in java. Sure id probably get ten more frames out of a c++ variant, but man… what a wild ride that would be. If it aint fun, it aint gonna get done.

2 Likes

Just look at other game engines, almost all of them have high level languages with some kind of garbage collection for at least parts of the engine.

1 Like

Don’t mess C# and Unity. C# is a language made for .NET platform, which is really fast, at least on PC, AFAIK there is a lot of issues with Core on devices. Unity uses C# with Mono as its VM. Mono i slow as hell.

2 Likes

No beef against either. I have fond memories of C# development dating 10 years back, and just started it again this year. With .NET.

Potentially Unity could change to Core 2? Is the reason for Mono the multi-OS support?

I do not know, but because Microsoft took Unity, things could only get worse.

1 Like

I’m sure there are some “hardened C++ experts,” and probably a fairly significant number, actually. But… they’re probably a very small minority of C++ users. My dad used to do a lot of scientific/engineering programming in C++ back in the 80s or 90s or so, and I would put him in the category of a hardened expert (although I will grant that there’s bias there :wink: ). You’re absolutely right though - C++ is so complex that mastering it takes many years (that was the case for my dad back when it was significantly simpler, too).

Yeah, I find Java to really hit a sweet spot. The language itself is a little verbose sometimes, but not so much that I find it to be a detractor. Some other JVM languages that aren’t so verbose (like Kotlin or Groovy) are nice but I also find extremely succinct code to be hard to follow since there’s so much going on in one line. And the Java standard library itself almost counts as one of the seven wonders of the computer world. Right now I’m developing a new scripting language, runtime, and compiler on the JVM, and I have no external dependencies. The JDK has enough that it’s not nearly so tough as it sounds (regular expressions are AWESOME!), but I’d cringe at making anything like that outside of Java (or, to be fair, .NET). For my day job I recently was working on developing a pseudo-realtime renderer in C++/OpenGL. It was a fun project, but… yikes. Coding in C++ is like pulling hens’ teeth, both because of the language and because of the lack of libraries that Java programmers take for granted.

Like you, I’ll stick with Java. :wink:

1 Like

Lambdas and Functional Interfaces go a long way to reducing verbocity. Im kinda lost without them these days.

3 Likes

https://projectlombok.org/ just to put my 2 cents on the verbocity topic. That and slf4j are my default dependencies in any project.

1 Like

sigh…

Lombok looks awesome, but it just looks… un-Java-ish? Having said that, the amount of boilerplate saved is quite possibly worth it.