Hacker News Reader

Comment by na85 | Hacker News Reader

When discussing games, where players demand excellent performance but are tolerant of initial startup times (i.e. launching the game from Steam or the Start Menu) being long, then I question why Java isn't the future.

By all accounts Java has the most sophisticated runtime out there, it has all the safety features of Rust without fucking around with the borrow checker which seems like a huge piece of complexity just to avoid garbage collection.

Plus, now that Mozilla has gutted the Rust team, one wonders what future Rust has, if any.

View on HN

GC is a no-go, as it causes unacceptable frame-rate dips. The kind of people who buy 120Hz screens are unlikely to be impressed. Even Shenandoah etc. are very unlikely to fix that.

>GC is a no-go, as it causes unacceptable frame-rate dips.

Does it, though? I've played titles written in Java and achieved smooth 60 fps back in 2008.

I play a lot of minecraft and GC related framerate issues are usually not a problem, but when they are a problem they can be quite annoying. You tune gc performance for your gameplay workload to a certain extent but obviously most players don't.

Those games will have been written in such a way as to avoid allocations like the plague, giving the GC very little to do. Sometimes your game can be written that way -- sometimes it can't.

Just like you have to avoid malloc() in C written games.

First, you don't have to avoid malloc() or similar allocators in games necessarily. You should avoid it in performance constrained situations. And you only should avoid calling malloc. It's not necessarily a problem to use these allocations in those situations. That's quite unlike Java, unless you're a GC wizard, and I'm not sure how far even those wizards can circumvent problems.

Second, to my knowledge it's still very cumbersome to avoid GC allocations in Java. By comparison, it's easy to reduce calls to global heap allocators in C.

First, also possible in GC enabled languages. That is what profilers are for.

Second, it is relatively easy to do native memory allocation in Java, but apparently people keep forgetting to learn their toolbox properly.

Third, calling malloc() is such an issue that there used to be companies specialised in selling optimised versions of malloc()/free().

Oh, come on.

Advanced garbage collectors have short pause times. In [1], the author cites Twitter statistics showing approximately two 0.5ms "pause" times per GC cycle for the go language garbage collector, and during the GC cycle only 25% of the CPU was used by the GC. It doesn't seem like this is going to cause frame-rates to dip.

To be fair, every application is going to differ, and perhaps games need tighter control of memory than a high performance GC is capable of, but automatic GC does make programming a lot easier.

[1] https://blog.golang.org/ismmkeynote

There is nothing wrong with Java except the issues surrounding protecting your code from reverse engineering.

That applies to any language.

Hex-Rays and similar are also a thing for native compiled code.

Yes/no, what hex-rays ida gives you is not worth the effort. It is a guess, and it doesn't do well with complex algorithms. Go try it on libjpeg. Compile it to release, no symbols, and let me know what you can extract. That is what I tested it with, and I didn't get much.

Reply on news.ycombinator.com