Hacker News new | ask | show | jobs
by pron 3201 days ago
There are better ways to eliminate GC pauses than manual memory management (even ignoring the relatively new "pauseless" GCs). See the new RTSJ (realtime Java) specification here: https://www.aicas.com/cms/en/rtsj. Not that it's designed for far stricter requirements than games (cases where even microseconds of unexpected latency may result in actual life safety concerns).

Manual memory management is a good choice if you have both worst-case latency concerns as well as very restricted RAM and/or severe energy constraints (basically, the kind of applications that Rust was designed to handle).

2 comments

JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector (http://openjdk.java.net/jeps/189) could help with that.
The RTSJ solution is to simply pre-allocate everything you could ever want and reuse that.

That’s horrible to use for game development.

> The RTSJ solution is to simply pre-allocate everything you could ever want and reuse that.

That's not the RTSJ solution. RTSJ uses arenas, which are great if you have regular allocation/deallocation cycles, like, say, a frame in a game.

> That's not the RTSJ solution. RTSJ uses arenas, which are great if you have regular allocation/deallocation cycles, like, say, a frame in a game.

So how do I get a user’s Oracle JRE installation to use arenas? The only realistic scenario is to preallocate and reuse.

You don't. You use an RTSJ JVM.
That’s not an option, that was the whole point of the discussion.
If changing the JVM spec is an option, then surely so is using an existing spec. IBM has an RTSJ JVM[1], which, I believe, is based on J9.

[1]: https://www.ibm.com/support/knowledgecenter/en/SSSTCZ_3.0.0/...

I'm not a game developer, so why is that horrible? consider I have an array/map of my game objects and the rest only works with methods, so most stuff does not lie on the heap, well that means basically no strings, since they would add to heap memory aswell, but only using basic datatypes and arrays.

why would some kind of that be problematic? I mean graphics programmic is kind of new to me, but considering that you could offload that to a c/c++ engine via jni (that's another horrible thing of some kind), but just the game code itself doesn't seems to be to bad, does it?

> why would some kind of that be problematic? I mean graphics programmic is kind of new to me, but considering that you could offload that to a c/c++ engine via jni (that's another horrible thing of some kind), but just the game code itself doesn't seems to be to bad, does it?

The whole point is not to offload anything. If you need to offload anything, even the render loop, the language has failed.

Isn't that what almost every game does during loading screens?