4 ms·

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

• papercrane 5y ago
  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.
  • chongli 5y ago
    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?
    • papercrane 5y ago
      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.
    • kaba0 5y ago
      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.