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.
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.
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
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.
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?
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.
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.
These GCs have a 1GB overhead when working with a 16GB heap. That’s 6% of your available memory. I was expecting modern GCs to be way more efficient so I’m kinda shocked this is what state of the art is.
I also wonder how much of the progress to “Sub (200) millisecond” latency target is due us just having faster machines. I honestly have no model to tie this to actual performance of my code. I guess it translates but not really sure how.
Not bagging on Java —— I am just surprised how inefficient an industrial strength GC can be. I understand why manual memory management still holds its own now.
One of the graphs shows ZGC with almost 50% more overhead (in heap space) than G1, which could very well take some applications from "works fine" to "broken." So I can see why they'd leave it something to opt in to.
What is not shown is those benchmark is how much CPU is used for each GC.
For example the latency for ZGC is much lower but does it means it uses more CPU than G1.
Those latency and pause-time numbers are pretty sexy. 200ms is still probably too high for some applications, but for everything I work on, this is incredible.
The throughput & latency charts have JDK8 pegged at 100%. Since that's meaningless and the value is in the difference between the JDK versions, it should be represented as a delta.
[+] [-] dandotway|4 years ago|reply
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.]
[+] [-] kllrnohj|4 years ago|reply
Don't confuse Java having the fastest GC with Java being the fastest GC'd language (especially not in all situations)
[+] [-] JanecekPetr|4 years ago|reply
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.
[+] [-] pjmlp|4 years ago|reply
https://www.codenameone.com
https://gluonhq.com/products/mobile/
They are also quite happy to sponsor possible console ports.
[+] [-] admax88qqq|4 years ago|reply
[+] [-] winrid|4 years ago|reply
I've been doing this with a game I'm building that has a custom 3D OSM map renderer.
[+] [-] 3371|4 years ago|reply
[+] [-] rurban|4 years ago|reply
[+] [-] KronisLV|4 years ago|reply
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
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] aetherspawn|4 years ago|reply
[+] [-] The_rationalist|4 years ago|reply
[deleted]
[+] [-] chickenbane|4 years ago|reply
Funny how you frame Java "only" being available for some of the most popular platforms, which is billions of devices.
[+] [-] twic|4 years ago|reply
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!
[+] [-] jbellis|4 years ago|reply
(TLDR, ZGC is a huge improvement.)
[+] [-] jesboat|4 years ago|reply
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.
[+] [-] lmilcin|4 years ago|reply
[+] [-] zokier|4 years ago|reply
[+] [-] maxpert|4 years ago|reply
[+] [-] papercrane|4 years ago|reply
[+] [-] bob1029|4 years ago|reply
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?
[+] [-] akshat_h|4 years ago|reply
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...
[+] [-] google234123|4 years ago|reply
[+] [-] kaba0|4 years ago|reply
https://jet-start.sh/blog/2020/06/23/jdk-gc-benchmarks-remat...
[+] [-] vletal|4 years ago|reply
Moreover, are the significantly lower GC pause times help improve snappiness of GUI apps, such as IntelliJ IDEA?
[+] [-] Erlangen|4 years ago|reply
[+] [-] pjmlp|4 years ago|reply
[+] [-] edgyquant|4 years ago|reply
[+] [-] Sankozi|4 years ago|reply
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.
[+] [-] fnord123|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] msie|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] pjmlp|4 years ago|reply
[+] [-] tannhaeuser|4 years ago|reply
[+] [-] pkoperek|4 years ago|reply
[+] [-] seanwilson|4 years ago|reply
[+] [-] zokier|4 years ago|reply
[+] [-] jimsimmons|4 years ago|reply
I also wonder how much of the progress to “Sub (200) millisecond” latency target is due us just having faster machines. I honestly have no model to tie this to actual performance of my code. I guess it translates but not really sure how.
Not bagging on Java —— I am just surprised how inefficient an industrial strength GC can be. I understand why manual memory management still holds its own now.
[+] [-] gregaccount|4 years ago|reply
[+] [-] jbellis|4 years ago|reply
[+] [-] kaba0|4 years ago|reply
[+] [-] vips7L|4 years ago|reply
[+] [-] SureshG|4 years ago|reply
[+] [-] Rovanion|4 years ago|reply
[+] [-] Thaxll|4 years ago|reply
[+] [-] thomascgalvin|4 years ago|reply
[+] [-] mcdonje|4 years ago|reply
[+] [-] ozim|4 years ago|reply
[+] [-] slater|4 years ago|reply