Hacker News Reader

Comment by nicetryguy | Hacker News Reader

GC every frame? Jesus. Gamedevs jump though hoops to avoid it.

Probably added after profiling on that system found that the GC pauses would fit within frame budget, whereas not running it every frame would have a long pause eventually drop frames

This! If you GC every frame, you can almost guarantee that it runs fast enough to not cause a frame skip.

Only true for Java runtimes at the time. With modern JVMs with generational GCs, it is detrimental even. Profile it, and only let allocation rate increase to an acceptable level that can be reclaimed easily. Or nowadays one can use a low latency GC as well.

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.

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

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.

These phones had like 1 MB, 2 MB, 4 MB of RAM. And these were 3D-accelerated games running on them. A GC language was definitely the wrong choice for the platform, but J2ME was the industry standard because portable. So if you're allocating a dozen objects in a frame it's best to GC them in the same frame or you're going to lose tens of frames later.

Even in modern times, for the longest time Android Java apps had laggy scrolling due to GC hitches that the refcounting iOS Obj-C apps avoided.

Refcounting has glitches as well.

The refcounting isn't so bad but freeing and running destructors can pause. There's also memory fragmentation from not having a compacting GC. It's all fixable though.

Though nowadays GC is also “fixable”, and probably more performant than refcounting, at least for non-single-threaded code.

Cross-thread refcounting is not that common and the CPU has very fast atomics anyway. It's still a better tradeoff than having to sweep (which might need to page in), make all pointers visible, accept the occasional peak memory increase, etc.

What are the options for sharing an object between threads then? And even with having good atomics, it is a very significant overhead. Also, the primary reason for modern GCs having significantly better performance than refcounting is that with GC one can move the majority of work to another thread, letting them continue the work.

Refcounting is good for some simple programs where ownership is not trivial, and the language doesn’t support a GC/or when memory is constrained, etc. But it is not an accident that high level languages with GC doesn’t choose refcounting, and having the cost of destruction at the given thread is just one point, afaik circular references are similarly not an easily solved problem. And basically with every single “solution” to these problems you are moving towards a full-blown GC.

> What are the options for sharing an object between threads then?

It works fine, it’s just not done that often. (Specifically contended refcount changing isn’t done, which is why having fast uncontended atomic helps.) Transferring between threads happens and just works.

ObjC has explicit weak pointers and ways to move destructors to another thread and it all works. Though you could use C# or JavaScript in your app, many people do.

Actually, PHP and Python do use refcounting internally, I think PHP only GCs on exits from functions…

I don’t get your point. Of course refcounting is a possible and working solution, but it’s not an accident that Java, JS, and C#, languages with the best GCs, doesn’t use it.

Yes, C# is the best language to write a phone OS in if you want to go out of business.

Other languages need special hardware to beat C#, so I guess the language wasn't the issue.

https://github.com/ixy-languages/ixy-languages

https://blog.metaobject.com/2020/11/m1-memory-and-performanc...

There is no "special refcounting hardware" in the M1, it has exactly what I said it has above this. Alas, nobody trusts me…

Java and .NET also have weak references.

Also C# can do everything that Objective-C is capable of, provided one actually knows how to use the language.

CPython uses a mix of refcounting with a cycle collector tracing GC, other Python implementations use tracing GCs.

The language does not specify GC semantics and counting on them is a recipe to break code when moving across implementations.

Sure, but it's glitches you control. Everything is deterministic. With a GC, your only solution is to call the GC explicitly on every frame and pray for the best.

These games are turn and grid based like Legend of Grimrock or Chess where input lag is much less important.

Reply on news.ycombinator.com