Concurrent Chunk Management Engine (Fabric)

Concurrent Chunk Management Engine (Fabric)

231k Downloads

Compatibility for Shenandoah Garbage Collector

Atirtra opened this issue ยท 7 comments

commented

Minecraft's default G1 garbage collector causes inevitable extreme stuttering no matter the hardware when allocating over 4GB of RAM. Currently the alternative ShenandoahGC only causes even worse stutters, but the game works just fine.

ShenandoahGC handles everything concurrently with normally almost no frametime change. Now, I have no knowledge about these things, but would compatibility for ShenandoahGC be possible? Is there something interfering with it since the mod's name is literally "Concurrent" Chunk Management Engine.

I'd just like to enjoy smooth Minecraft with 32+ render distance, but currently there is no way for doing so other than OptiFine.

commented

C2me is compatible with any garbage collector ever created. So it will run with ShenandoahGC no problem. You can also try a few alternative GCs. For me, Java 21 has a in-development GC called ZGC Generational. It has done wonders to help with stutter while using less ram than G1GC.

commented

I just tested it with and without other mods. I also noticed that in both cases chunks sometimes stop rendering completely when using Shenandoah, with the crazy stuttering still present. G1 works perfectly excluding the humongous stutters.

commented

Are you sure the stuttering is due to GC collection? If you are running c2me on a client, it can cause massive resource usage from the CPU and cause stutters too.

commented

If you use Linux you can try CorrettoJDK's Shenandoah Generational GC which allows Shenandoah to easily handle heaps above 100GB https://github.com/corretto/corretto-17/tree/generational-shenandoah

It is known that c2me uses an unusually large amount of memory, hence why it lags a lot on the client. I'm fairly sure this is a pretty common occurrence on the client. You can try reducing the max ram allocated to the game in order to decrease the effects of the massive collection. Additionally, stock ShenandoahGC comes with an experimental mode called iu. You can enable it with -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=iu

See if this more aggressive mode can maybe help remove these spikes. If not, try running ZGC on the client and see if that helps.

commented

100% sure. The biggest stutter (could call it a lag spike as it's so bad) always happens right after the memory dropping from 8GB to 2GB, so the garbage collection of course. There are occasional small stutters in between, but that's just the nature of minecraft, those don't bother me. All of this is only happening with C2ME+ShenandoahGC even with less than 32 chunks. Any other combination is stutter free. Hell, even vanilla runs better with 32 chunks.

commented

Windows user. I still don't quite get how G1 runs exactly the way sodium does, but Shenandoah shatters the performance. Could try ZGC and iu but won't bother past that if they do nothing since in that case fixing this is out my reach. It's also definitely not a hardware problem so I'll just leave it at that.

commented

If the game works just fine, it is not an issue on our end. It could be a bad GC configuration or Shenandoah is just not designed to handle this kind of workload.