Hacker News Reader

Comment by zlynx | Hacker News Reader

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.

View on HN

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.

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.

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.

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

Reply on news.ycombinator.com