[zlynx]

Your other choices are:

- Never GC via using object pools. This code is nastier than C++ because Java is not intended to be used this way.

- GC whenever needed randomly. The game will just pause occasionally. Very annoying as a player.

- Write the actual game in C++. Make a few JNI calls here and there. On feature phones I only remember this being possible for some vendor apps.

[kaba0]

Depends on when. If we are talking about modern day JVM, than even the non-latency optimized default GC would have <10ms stop-the-world pauses for up to gigantic allocation rates, much less for the presumably minor one of a simple game. And then there are two latency optimized ones, Shenandoah and ZGC, with the latter having <1ms, meaning that your OS introduces more latency with thread switches.

So I think writing a game while profiling allocation rates and paying a bit of attention to not spam new everywhere, one should get decent performance without any framedrops. At most, optimize the hot loops with primitives, arrays.

[banana_giraffe]

If these phones were still around, I'd imagine there'd be another option now:

- Write your game in C++ and transpile it to Java using some fancy framework that dances around never using GC.

[kllrnohj]

You'd have to do something like allocate a single byte[] for everything you'll ever need, and reading & writing data would just be a constant tax since you can't just in-place cast that to an int or whatever. It wouldn't be very fun.

[zlynx]

But it would be transpiled so the programmer would never need to look at the very ugly stuff. The idea reminds me of the original asm.js