Minecraft-Performance-Flags-Benchmarks
Minecraft-Performance-Flags-Benchmarks copied to clipboard
Java 8: EXCEPTION_ACCESS_VIOLATION if "-XX:+ParallelRefProcEnabled" is set using Client G1GC Args
This issue documents an issue brought up on the Discord Server linked in the README.
Using the current list of arguments for Java 8 + G1GC crashes the game shortly after its start, probably when the garbage collector runs for the first time.
The issue was first to believed to be caused by G1GC itself or the used Runtime GraalVM 21.3.4, but has since then reproduced on Adoptium 8.0.312, and stopped happening after the argument -XX:+ParallelRefProcEnabled
were removed.
The argument allows the Garbage Collector to use multiple cores to garbage collect and has a history of being used with G1GC on Java 8 versions of the game, including Aikar's famous arguments.
I am honestly stumped on what exactly could be causing it, with the most reasonable idea being that something in the G1GC Arguments could cause it to happen, whenever it's a rather unusual argument or values. Finding out whats going on could perhaps explain which thought processes others had when designing JVM arguments for Minecraft in the past.
I think I was seeing the a similar crash with adoptium and ended up removing -XX:+UseDynamicNumberOfGCThreads
instead.
I think I was seeing the a similar crash with adoptium and ended up removing
-XX:+UseDynamicNumberOfGCThreads
instead.
I will try to give that a shot. I am not that experienced with the arguments, but both seem to somewhat have in impact on the garbage collector's ability to use multiple cores/threads...?
Previously people removed -XX:+UseG1GC
to make it work... which ain't exactly the optimal solution to that. But it helped getting the idea that it may be caused by GC configuration.
both seem to somewhat have in impact on the garbage collector's ability to use multiple cores/threads...?
Yes: ParallelRefProcEnabled
enables multithreading for part of the gc process; UseDynamicNumberOfGCThreads
lets the gc adjust the number of threads it uses. Presumably they do work together in some cases, otherwise they wouldn't be in the list together. Both are disabled by default in java 8, but UseDynamicNumberOfGCThreads
is on by default since java 11, so maybe we're just hitting an edge case that's been fixed since.
Removing -XX:+UseG1GC
isn't a great solution in java 8. It means that it defaults to the parallel gc instead, which can struggle when the heap starts getting full.