As Java is generally the fastest GC'd language, what's the current state of Java gamedev?
Once upon a time, this indie Java game called Minecraft became the most successful game of all time.
But from the few minutes of research I just did, Java cannot be deployed to many commercially important systems
- Nintendo Switch
- PlayStation
- iOS
It appears Java is only still viable for Windows and Android, and the 1% Linux desktop market.
There used to be the GCJ project which would in theory let you run Java anywhere you had a C/C++ compiler, but Oracle's litigiousness killed that because the Java[TM] "platform" must run the official Java[TM] bytecode.
It appears C# via Monogame lets you deploy to all desktops (Win/Mac/Linux), mobiles (iOS/Android), and consoles (PS/Switch/Xbox). So ironically C# seems to now be the "write once, run anywhere" fulfillment of the original Java promise.
> Don't confuse Java having the fastest GC with Java being the fastest GC'd language
I've always wondered, it's likely that Java has the fastest GC because it needs to have the fastest GC, otherwise it would be a bottleneck. Other popular languages probably don't depend as much on the performance of their memory allocation primitives.
Java’s new better FFI is almost ready with project Panama and value types will come, but it is exceedingly hard to retrofit into a language (but the idea for the exact semantics might have formed already!)
It sounds very nice but if more than half an indie game's revenue comes from Nintendo Switch then you need a low friction way to get your .java files running there. You also need a proven audio mixer stack so you can load background_music.mp3 and play bang.wav and boom.wav without any popping or leaks. Right now Java seems sort of iffy on consoles, as in, you could maybe spend a ton of time and/or money to get an effort like GraalVM production-grade working there, but no one has bothered to do it yet. It seems to be much lower friction to just use C#/MonoGame, or SDL2 with your scripting language of choice that compiles with a C/C++ compiler, or a proven game engine.
A pause does not correspond to a full GC, of course. The work of GC is split into a lot of concurrent work and a lot of really tiny pauses on each application thread. The entire GC cycle might be split over hundreds or thousands of tiny pauses and take many seconds--there's just no particularly big pause. During the GC cycle the application is still running and allocating, and there is enough slack space that it doesn't run out of memory before the GC cycle finishes and transparently adds freed memory back into the usable pools.
It would be great if the whole cycle were that fast! But alas, there simply isn't enough memory bandwidth to GC 128GB of memory in 0.1 millisecond :)
Well, Minecraft is notoriously slow, but I guess that's very much nothing to do with Java, but the un-optimized code... Have seen quite some developers criticizing Mojang for this.
Is it really, though? Just for kicks, last year I got an ibook g4 for a few dollars, and I got Minecraft running on it, not the absolute latest version, but one a few years old (Minecraft dropped 32 bit LWJGL support a bit ago). With some tweaking, I managed a solid 40-50 FPS, on what would have been a pretty anemic processor back in ... 2002, 2003?
Although, maybe it doesn't count as I used mods like Optifine, which are made to ... replace said un-optimized code, but I thought it was a good showing for Minecraft and the JVM anyway.
> but I guess that's very much nothing to do with Java, but the un-optimized code
You guess right. There are some few fan made mods (optifine, sodium/etc) that often improve performance by an order of magnitude, from tens of frames a second to hundreds.
Minecraft Bedrock, which is written in C++, runs dramatically faster than Minecraft Java. (That's the impression I get from the comparisons I watched on YouTube at least.)
It's a shame for Java since the increase in render distance makes the game much more immersive.
Did Java already beat Common Lisp and C#? I doubt so. Esp. since the commercial lisps with much better GC's are not listed on the benchmarkgame. But also not Shenandoah, and the other commercial Java GC's
Sure, many out there enjoy developing games in a code first approach, or even writing their own engines (e.g. Randy, whose videos are pretty interesting and comedic: https://www.youtube.com/c/RandytheSequel/videos or https://www.youtube.com/c/RandallThomas/videos), but i'd argue that the success of an engine largely depends on the popularity that it gains, which is largely influenced by how easily approachable it is.
Java game development doesn't have such a tool or set of tools, even the activity on jMonkeyEngine's GitHub (https://github.com/jMonkeyEngine) is really low, compared to that of Godot (https://github.com/GodotEngine), even if the technologies themselves could be used to similar degrees of success in many situations.
Come to think of it, it would be nice to actually benchmark something like Unity (C#), Godot (C#), Godot (GDScript) and jMonkeyEngine (Java) in similar real world applications, to see how they fare, performance, resource usage and development speed wise.
My intuition tells me that Java would be faster than GDScript, which would make talking about its (and also Java's, and thus also C#'s) performance a moot point for many of the indie games out there, since GDScript's slowness doesn't prevent many wonderful games from being developed in Godot, here's their latest showcase reel: https://www.youtube.com/watch?v=iAceTF0yE7I
I love functional languages but is anyone actually using Haskell to develop for Nintendo Switch and PlayStation? Can you use Haskell on the Nintendo Switch to access a robust audio mixer stack?
F# can be used with C#/MonoGame which seems to run well everywhere so that's one route to functional programming gamedev. Another route appears to be to use SDL2 with a functional language that supports ANSI C bytecode runtime fallback. E.g. OCaml has a bytecode compiler and an ocamlrun runtime that can be compiled with an ANSI C compiler. But I don't know what the GC latency guarantees are for the bytecode runtime. OCaml's native low latency GC benefits from Jane Street's contributions because Jane Street uses OCaml for high frequency trading. But bytecode OCaml running on Nintendo Switch isn't the same thing as native Linux OCaml.
Shame this doesn't show the CMS collector, which was present in 8 and 11, but removed before 17. CMS was the go-to option for low-latency collection for a long time, so it would be good to see how it compares to the modern options.
It would be particularly interesting from the perspective of someone working in a shop which still has lots of latency-sensitive-ish workloads running on JDK 8 with CMS!
I'm curious what your applications' allocation patterns are like.
I've worked on a couple projects where switching from CMS to G1 was a pretty big latency win. Most of the were pretty strongly request-response-based. Pretty quickly G1 would converge on having most of the regions being young, and, by the time G1 wanted to do a mixed collection, most of them would have no live objects and would be summarily killed.
Also, it would be interesting to see this progression from at least 1.4. By the time 1.8 was released I had the impression that GC is already pretty well optimized for throughput.
Although if your ulterior motive is to persuade people to upgrade beyond 8 and 11, you probably don't want to suggest that performance has basically plateaued.
I've used Shenandoah GC with great success and I recommend anyone considering ZGC (specially on Kube and container environments) to try Shenandoah first. You won't have to do additional work to enable large pages, yet your performance is pretty close.
As a .NET developer I am a little envious of all the GC knobs that Java developers get to play with.
If I could have only 1 new GC thing from Microsoft, it would be the ability to totally disable GC during the lifetime of a process. I don't even want to be able to turn it back on.
I have a lot of scenarios where I could get away with the cruise missile approach to garbage collection. No reason to keep things tidy if the whole world is gonna get vaporized after whatever activity completes. Why waste cycles cleaning things up when you could be providing less jitter to your users or otherwise processing more things per unit time?
Honestly this is the most frustrating thing about Jetbrains. Stop investigating shit and just use the new JVMs already. There is no excuse for using deprecated JVMs.
The GC might help, but it doesn't do magic when threads aren't used the correct way, too much stuff lands on the UI thread or synchronous IO is used all over the place.
That’s the magic of HN (or maybe it’s a form of the Baader-Meinhof Phenomenon.) When one topic reaches the front page it seems like a couple more based around it hit the front page the same or next day, which allows us to expand on what we’ve learned.
Snappiness problems are often due to lazy loading Java classes.
For example first time loading project settings takes 1+ seconds while next less than 0.5. This value might get lower later if JVM decides to optimize more some parts of UI application.
This is what I've noticed too. Intellij has never exactly been speedy, but it had so many great features that it was worth it compared to other slow IDEs like Eclipse. And using a basic text editor like VIM or even VS Code with a big Java project isn't really feasible like it might be in other languages like Python or Node.
However, now it is really bogging down. I'm sure it doesn't help that I've got several IDEs open along with some monstrosity of a "microservice" framework running half a dozen docker services and DBs on an older Macbook Pro, but it's true that app and OS devs tend to use all increases in CPU and ram, and so absolute performance and battery life never seems to get better over the years, regardless of how much the underlying hardware itself has improved.
Not just slower, also energy hugry. My m1 max running pycharm loses about 10pct of charge an hour on their crappy bundled jvm, and around 4% on the latest java17-based ones, but does act weird at times when using them. Its probably down to metal vs opengl. Disappointing.
Since 2020.x it's definitely slower. The addition of jetbrains space doesn't seem to help either and removing the plugin itself makes the whole ide unstable
Well, jdk17 was released just few months ago so I doubt anyone has real experience with it for gamedev. But considering that game heaps are relatively small (as in <100G) and modern Java GCs can manage consistent <1ms pause times, I'd imagine Java is more viable for gamedev from that point of view. I'd also emphasize that there is large spectrum of performance requirements for games and you can make quite a lot these days with relatively poor performance characteristics, and on the other hand in the top end Java probably is still not good enough.
IMO java for gamedev is pretty much un-viable due to the lack of control over memory layout. You clearly can make it work (see Minecraft), but it just sounds painful, and there isn't a clear benefit.
Readit News
Once upon a time, this indie Java game called Minecraft became the most successful game of all time.
But from the few minutes of research I just did, Java cannot be deployed to many commercially important systems
It appears Java is only still viable for Windows and Android, and the 1% Linux desktop market.There used to be the GCJ project which would in theory let you run Java anywhere you had a C/C++ compiler, but Oracle's litigiousness killed that because the Java[TM] "platform" must run the official Java[TM] bytecode.
It appears C# via Monogame lets you deploy to all desktops (Win/Mac/Linux), mobiles (iOS/Android), and consoles (PS/Switch/Xbox). So ironically C# seems to now be the "write once, run anywhere" fulfillment of the original Java promise.
[EDIT: grammar.]
Don't confuse Java having the fastest GC with Java being the fastest GC'd language (especially not in all situations)
I've always wondered, it's likely that Java has the fastest GC because it needs to have the fastest GC, otherwise it would be a bottleneck. Other popular languages probably don't depend as much on the performance of their memory allocation primitives.
There are some engines, frameworks: https://jmonkeyengine.org/, https://litiengine.com/, https://libgdx.com/, https://www.lwjgl.org/.
But I have no real experience with any of those.
LibGDX appears to support iOS/Android and HTML5 desktop browsers, but not consoles (Switch/PS/Xbox).
https://www.codenameone.com
https://gluonhq.com/products/mobile/
They are also quite happy to sponsor possible console ports.
It would be great if the whole cycle were that fast! But alas, there simply isn't enough memory bandwidth to GC 128GB of memory in 0.1 millisecond :)
I've been doing this with a game I'm building that has a custom 3D OSM map renderer.
Although, maybe it doesn't count as I used mods like Optifine, which are made to ... replace said un-optimized code, but I thought it was a good showing for Minecraft and the JVM anyway.
You guess right. There are some few fan made mods (optifine, sodium/etc) that often improve performance by an order of magnitude, from tens of frames a second to hundreds.
It's a shame for Java since the increase in render distance makes the game much more immersive.
In my eyes, there are no truly viable options out there, mostly due to a lack of approachable GUI game development software or toolkits.
For example, compare the one option that comes close, jMonkeyEngine (https://jmonkeyengine.org/) to the likes of Unreal (https://www.unrealengine.com/en-US/) and Unity (https://unity.com/), or even Godot (https://godotengine.org/).
Sure, many out there enjoy developing games in a code first approach, or even writing their own engines (e.g. Randy, whose videos are pretty interesting and comedic: https://www.youtube.com/c/RandytheSequel/videos or https://www.youtube.com/c/RandallThomas/videos), but i'd argue that the success of an engine largely depends on the popularity that it gains, which is largely influenced by how easily approachable it is.
Java game development doesn't have such a tool or set of tools, even the activity on jMonkeyEngine's GitHub (https://github.com/jMonkeyEngine) is really low, compared to that of Godot (https://github.com/GodotEngine), even if the technologies themselves could be used to similar degrees of success in many situations.
Come to think of it, it would be nice to actually benchmark something like Unity (C#), Godot (C#), Godot (GDScript) and jMonkeyEngine (Java) in similar real world applications, to see how they fare, performance, resource usage and development speed wise.
My intuition tells me that Java would be faster than GDScript, which would make talking about its (and also Java's, and thus also C#'s) performance a moot point for many of the indie games out there, since GDScript's slowness doesn't prevent many wonderful games from being developed in Godot, here's their latest showcase reel: https://www.youtube.com/watch?v=iAceTF0yE7I
Deleted Comment
F# can be used with C#/MonoGame which seems to run well everywhere so that's one route to functional programming gamedev. Another route appears to be to use SDL2 with a functional language that supports ANSI C bytecode runtime fallback. E.g. OCaml has a bytecode compiler and an ocamlrun runtime that can be compiled with an ANSI C compiler. But I don't know what the GC latency guarantees are for the bytecode runtime. OCaml's native low latency GC benefits from Jane Street's contributions because Jane Street uses OCaml for high frequency trading. But bytecode OCaml running on Nintendo Switch isn't the same thing as native Linux OCaml.
Dead Comment
Funny how you frame Java "only" being available for some of the most popular platforms, which is billions of devices.
It would be particularly interesting from the perspective of someone working in a shop which still has lots of latency-sensitive-ish workloads running on JDK 8 with CMS!
(TLDR, ZGC is a huge improvement.)
I've worked on a couple projects where switching from CMS to G1 was a pretty big latency win. Most of the were pretty strongly request-response-based. Pretty quickly G1 would converge on having most of the regions being young, and, by the time G1 wanted to do a mixed collection, most of them would have no live objects and would be summarily killed.
If I could have only 1 new GC thing from Microsoft, it would be the ability to totally disable GC during the lifetime of a process. I don't even want to be able to turn it back on.
I have a lot of scenarios where I could get away with the cruise missile approach to garbage collection. No reason to keep things tidy if the whole world is gonna get vaporized after whatever activity completes. Why waste cycles cleaning things up when you could be providing less jitter to your users or otherwise processing more things per unit time?
GC.TryStartNoGCRegion Method
Attempts to disallow garbage collection during the execution of a critical path.
https://docs.microsoft.com/en-us/dotnet/api/system.gc.trysta...
https://jet-start.sh/blog/2020/06/23/jdk-gc-benchmarks-remat...
Moreover, are the significantly lower GC pause times help improve snappiness of GUI apps, such as IntelliJ IDEA?
For example first time loading project settings takes 1+ seconds while next less than 0.5. This value might get lower later if JVM decides to optimize more some parts of UI application.
However, now it is really bogging down. I'm sure it doesn't help that I've got several IDEs open along with some monstrosity of a "microservice" framework running half a dozen docker services and DBs on an older Macbook Pro, but it's true that app and OS devs tend to use all increases in CPU and ram, and so absolute performance and battery life never seems to get better over the years, regardless of how much the underlying hardware itself has improved.
Deleted Comment
Deleted Comment
"Hard Realtime Garbage Collection in Modern Object Oriented Programming Languages."
https://www.amazon.com/Realtime-Collection-Oriented-Programm...
The author is one of the founders of Aicas real time JVM, https://www.aicas.com/wp/products-services/jamaicavm/
"Distributed, Embedded and Real-time Java Systems"
https://link.springer.com/book/10.1007/978-1-4419-8158-5
PTC is the other company alongside Aicas, that still sells real time Java systems, https://www.ptc.com/en/products/developer-tools/perc
IBM J9 has the evolution of the Metronome GC, https://www.researchgate.net/publication/220829995_The_Metro...
And it has extensions for value types, via packed object data, https://www.ibm.com/docs/en/sdk-java-technology/7.1?topic=ob...
Someone else already referred Azul, they also have extensions for value types, called object layouts, https://www.slideshare.net/AzulSystems/jvm-language-summit-o...
Then there are special flavours like microEJ or the Android Java snowflake.