Hacker News Reader

Comment by mukesh610 | Hacker News Reader

Is there any disadvantage to limiting the emulator's JVM heap size to match the original execution environment (in this case what seems to be 128k), instead of explicitly disabling GC?

View on HN

Ultimately it's just as complicated as disabling explicit GC calls, and since we have a lot more RAM to use now you'll get better performance if you just let Java have a bigger heap.

To be clear as well, the flag he added doesn't explicitly disable GC, it disables asking for GC explicitly, e.g. it makes "System.gc()" a no-op. The JVM will still garbage collect when it's heuristics decide it should.

Ultimately it's just as complicated as disabling explicit GC calls, and since we have a lot more RAM to use now you'll get better performance if you just let Java have a bigger heap.

Will you get better performance? Or will it end up using a large amount of memory and then having a long GC pause that causes your game to drop a frame every now and then?

The JVM heuristics are quite good, and the GCs are state-of-the-art and a beast, so I doubt you would have frame drops because of GC. More often than not you are better off not tuning the JVM.

Every application is different, but I'd wager it would strictly be better. The current GC implementions are very good, especially ZGC for pause times, I'd be surprised if a j2me game had a max GC pause time over 1ms with ZGC.

Reply on news.ycombinator.com