I've been scowering the web for the perfect JVM args for Java 21 modded minecraft forge 1.20.1 but I just can't seem to find any good or working flags. Please assist me, it would be for the best if we call so I can sharescreen. If you need more details, ask me
#Need help with JVM arguments for MC
rancid hearth
fathom skyBOT
<@&987246652869971988> please have a look, thanks.
Here is an AI assisted attempt to answer your question 🤖. Maybe it helps! In any case, a human is on the way 👍. To continue talking to the AI, you can use </chatgpt:1108714622413963314>.
TJ-Bot
rancid hearth
Here is an AI assisted attempt to answer your question 🤖. Maybe it helps! In an...
i already used AI and it just made slop
i tried both ChatGPT and deepseek, both with the reasoning enabled
rancid hearth
this is also more slop. I need low pause times and no stutters or microstutters and 5-6GB of ram allocated
rancid hearth
please help guys
formal perch
this is also more slop. I need low pause times and no stutters or microstutters ...
6Gb isn't much
rancid hearth
yeah but like
its for the client
not the server
and even the server, its gonna have 6-7GB
formal perch
6gb is a bit too low, especially for modded
formal perch
you could try to use zgc i guess
rancid hearth
i did
ZGC no real extra args is shit and stutters a lot
like way more than no ZGC or just G1
formal perch
but zgc needs more ram than usual
rancid hearth
G1 uses 9GB of ram and its shit
rancid hearth
but zgc needs more ram than usual
how much we talkin
formal perch
how much we talkin
no idea, but more, add ram until the amount of ram it takes doesn't increase over time
formal perch
yes ?
rancid hearth
no prob for me (64GB DDR4 3600mhz) im worried about the other ppl
formal perch
you can probably allocate up to 14gb in a 16gb system
rancid hearth
not really because theres overhead too
formal perch
no prob for me (64GB DDR4 3600mhz) im worried about the other ppl
try and see with different amount
formal perch
if you allocate 14gb it wont use JUST 14gb
wdym
formal perch
should i just use basic ZGC
basic zgc
formal perch
like for example i allocated 6GB, but with G1GC with some args it used 9GB
ah yes, that's 3gb offheap memory
formal perch
so the args dont really do the performance much justice?
good args are hard to find
rancid hearth
its half of what i allocated
and it still ran pretty shit
formal perch
GC default args are made so they work fine in most cases
You are trying to optimize for your specific case, so the only ways you have to find better args are a bit of what other tried, but mostly what you tried yourself, since your system is different than other people, so you can't really compare
rancid hearth
there are these like very praised github pages with 50 arg setups but like dude the game dont even launch it says unable to create the JVM shit 😭 and then i go to ai like wtf why doesnt this work and it says something like "yeah bro half the args dont exist in Java 21 anymore remove em itll work" still doesnt work
formal perch
so while you can take ideas from other people for args, you will have to find the best args yourself
rancid hearth
You are trying to optimize for your specific case, so the only ways you have to ...
yeahh well they need to run well for every1
i used to have like an arg meta
it ran PERFECTLY
on java 11 tho
formal perch
there are these like very praised github pages with 50 arg setups but like dude ...
what is the exact error message ?
formal perch
there are these like very praised github pages with 50 arg setups but like dude ...
And yes, java evolves, so things may change
formal perch
it cant create the java virtual machine
that's only a part of the error message
rancid hearth
nah but like the pages straightup eat shit they say "this works for java 21" when like no it doesnt
rancid hearth
that's only a part of the error message
okay lemme try some bs arg again so i can tell u the error
formal perch
nah but like the pages straightup eat shit they say "this works for java 21" whe...
first of, are you using java 21 ?
formal perch
okay lemme try some bs arg again so i can tell u the error
and send me the logs too please, just in case
rancid hearth
first of, are you using java 21 ?
ofc
im gonna be using
-XX:+UnlockExperimentalVMOptions
-XX:+UseShenandoahGC
-XX:ShenandoahGCMode=generational
-XX:ShenandoahGCHeuristics=compact
-XX:MaxGCPauseMillis=50
-XX:ShenandoahUncommitDelay=3000
-XX:+AlwaysPreTouch
-XX:+DisableExplicitGC
-XX:+PerfDisableSharedMem
-XX:-UseBiasedLocking
-Dsun.java2d.opengl=True
-Dforge.forceNoStencil=true
this dogshit
so it gets fucked up
formal perch
i want the internal error, the error it would throw if you executed by terminal
rancid hearth
exit code 1 no crash report or log
rancid hearth
i want the internal error, the error it would throw if you executed by terminal
where is that stored
formal perch
exit code 1 no crash report or log
no log at all ?
rancid hearth
-XX:+UnlockExperimentalVMOptions
-XX:+UseShenandoahGC
-XX:ShenandoahGCMode=gene...
iirc the generational shit just fucks it and the compact shit is bad anyway
here was the perfect args for my java 11 1.16.5 modpack :
-Xms5G -Xmx5G -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:+AlwaysPreTouch -XX:+PerfDisableSharedMem -XX:+ParallelRefProcEnabled -XX:+OptimizeStringConcat -XX:G1NewSizePercent=30 -XX:MaxGCPauseMillis=50 -XX:+DisableExplicitGC -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps -XX:+UseStringDeduplication -XX:+AggressiveOpts -XX:+UseLargePagesInMetaspace -XX:LargePageSizeInBytes=2M -Dsun.rmi.dgc.server.gcInterval=2147483646 -XX:+DisableAttachMechanism
(still client)
shit ran smooth as hell
brb
formal perch
so -XX:ShenandoahGCMode=generational doesn't exist
formal perch
-XX:+UnlockExperimentalVMOptions
-XX:+UseShenandoahGC
-XX:ShenandoahGCMode=gene...
where did you get the arg -XX:ShenandoahGCMode=generational ?
Also can you change your username please ?
rancid hearth
Also can you change your username please ?
Aight
rancid hearth
where did you get the arg -XX:ShenandoahGCMode=generational ?
Some article or Reddit post or ai
formal perch
So this is the wiki for Shenandoah : https://wiki.openjdk.org/display/shenandoah/Main
formal perch
yes
If you wish to learn how it works, how to understand its logging and to understand all the args you can use with it, you can just check this wiki
exevrything is explained
formal perch
as for -XX:ShenandoahGCMode=generational, there is this JEP : https://openjdk.org/jeps/404
This is a java enchancement proposal that will be released for java 24 and if you look at the bottom, you can see the -XX:ShenandoahGCMode=generational mentionned here
so it likely won't work for java 21
formal perch
What's better tho Shenandoah or ZGC?
If there was a better GC, you wouldn't be able to choose
rancid hearth
I mean I tested java 24 too it seems to run just fine but deep seek told me it made some changes that might fuck with Minecraft
formal perch
And I don't know which one would be better for minecraft
rancid hearth
I mean like what uses the least resources and has the lowest pause times of the two
Also everyone on the internet is like blah blah blah use graal VM for Minecraft it's the best distro but like deadass for me it runs like absolute dog shit
formal perch
I mean like what uses the least resources and has the lowest pause times of the ...
There are 3 metrics when evaluting a GC :
- Footprint (how much perf the GC use)
- GC Throughput (the speed at which the GC is able to collect garbage)
- GC Latency (the latency caused by the collection)
You can't have all 3
I know that ZGC is a GC specialised on Latency, it has the lowest latency of all GC, so the pause that it will cause are not noticeable
formal perch
So this is the wiki for Shenandoah : https://wiki.openjdk.org/display/shenandoah...
Afaik Shenandoah is also a low latency GC, but I don't know much about it, but if you really want, you can read about it ↑
rancid hearth
Found what deep seek said about java 24
Is this legit? It never crashed on world load and I didn't notice any jei corruption or memory leaks
formal perch
Found what deep seek said about java 24
Don't trust it too much
rancid hearth
Found what deep seek said about java 24
It says sodium is incompatible but it literally runs with embeddium which is forge sodium
🤡
So should I just use java 24 or should I stick with 21 just to be safe
formal perch
🤷
rancid hearth
I'm thinking going 24 and if it breaks going back to 21
formal perch
it is only a client right ? so even if it crash you can easily change it
rancid hearth
it is only a client right ? so even if it crash you can easily change it
Yeah
Also should I use different Args for my server?
formal perch
-XX:+UnlockExperimentalVMOptions
-XX:+UseShenandoahGC
-XX:ShenandoahGCMode=gene...
also did you try after removing -XX:ShenandoahGCHeuristics=compact ?
Or simply upgrading to java 24
formal perch
Also should I use different Args for my server?
Probably, which ones ? no idea
rancid hearth
Haven't tried generational Shenandoah with java 24 because I didn't know
But anyway you said I should add more ram
formal perch
Yes, if you have lags, it's probably because of not enough ram
you can verify that at least for some gc by looking at f3 the amount of ram you have and it being collected correspond to the game lagging
or well, that's only for certain GC, for ZGC you won't see that, but even if you can't see that happening, you can see that it uses nearly 100% which isn't good
rancid hearth
Yeah well
ZGC was unplayable
0 FPS
Stuttering like crazy
G1GC was using too much RAM and still had like the same microstutters and stutters as without any Args
Should I steer clear of ai generated Args?
formal perch
Stuttering like crazy
then check the ram ingame, it was probably stuck at 100%, you need to add more ram
formal perch
G1GC was using too much RAM and still had like the same microstutters and stutte...
if G1 was using "too much" ram, then don't expect ZGC to work lol
rancid hearth
then check the ram ingame, it was probably stuck at 100%, you need to add more r...
I couldn't even open F3 it was that bad
rancid hearth
if G1 was using "too much" ram, then don't expect ZGC to work lol
I mean dude g1 was using 9gb when I gave it only 6
That's what I meant by too much
formal perch
I mean dude g1 was using 9gb when I gave it only 6
If you tell 6, it will use 6
Those 3 are used by other stuff
Not managed by the gc
formal perch
Then why was it only doing that with those args
Where did you get this 9GB ?
rancid hearth
Task manager
formal perch
and you only saw that for g1, not other gc ? and did you run the same test ?
formal perch
which other gc did you test ?
rancid hearth
Shenandoah and zgc
formal perch
and really, try to increase ram, something like 10gb
rancid hearth
ZGC at one point ran on 4gb when I said 6 but with lots of stutters but somewhat playable if you're a masochist
And with some different Args it just stuttered like shit and was fucked
Shenandoah was fucking shit too it stuttered a lot which is weird because
The thing was saying gc was taking 3 ms
Maybe it needed more ram too?
formal perch
The thing was saying gc was taking 3 ms
wdym
formal perch
Maybe it needed more ram too?
probably yes, you should have checked f3
rancid hearth
wdym
I have a profiler mod called spark
I did /sparkc gc
And sparkc gc monitor
This constantly shits out logs in chat of the GC activity
formal perch
i don't know how often Shenandoah is supposed to run
for zgc it's a lot, that's normal
but idk for Shenandoah
formal perch
So this is the wiki for Shenandoah : https://wiki.openjdk.org/display/shenandoah...
might want to read the wiki
rancid hearth
i don't know how often Shenandoah is supposed to run
I've used it before
It does frequent collection
Like realtime
rancid hearth
I've used it before
On my 1.16.5 modpack
formal perch
Heap sizes: Shenandoah performance, like the performance of almost all other GCs, depends on heap size. It should perform better in cases when there is enough heap space to accommodate allocations while concurrent phases are running (see "Failure Modes" section below). The time for concurrent phases correlates with the live data set size (LDS) -- the space taken by live data. Therefore, the reasonable heap size is dependent on LDS and allocation pressure in the workload: for a given allocation rate, larger LDS-es require proportionally larger heap sizes; for a given LDS, larger allocation rates require larger heap sizes. For some workloads with minuscule live data sets and moderate allocation pressure, 1...2 GB heaps performs well. We routinely test on 4...128 GB heaps on various workloads with up to 80% LDS size. Don't be shy to try different heap sizes to see what fits your workload.
Pauses: Shenandoah's pause behavior is largely dominated by root set operations: scanning and updating the roots. Root set includes: local variables, references embedded in generated code, interned Strings, references from classloaders (e.g. static final references), JNI references, JVMTI references. Having larger root set generally means longer pauses with Shenandoah, unless concrete JDK version has the capabilities for doing parts of that work concurrently and Shenandoah is able to use it. Second-order effects are: a) weak reference processing (which happens in Final Mark pause), but only for those references that need processing; and b) class unloading and other JDK cleanups (which also happens in Final Mark pause). These second-order effects can be mitigated by configuring additional options that control processing frequency (including disabling it altogether) and/or modifying the applications to play a bit nicer.
Throughput: Since Shenandoah is concurrent GC, it employs barriers to maintain invariants during the collection cycle. Those barriers might induce the measurable throughput loss. See the diagnostic section below for the ways to dissect what is happening there. Some users report that the throughput loss due to barriers is paid off with naturally offloading concurrent GC work to spare and otherwise idle cores; in other words, in some cases it trades higher application+JVM utilization for higher application throughput.
In most cases, the pause times are within 0..10ms and throughput losses are within 0..15%. The actual performance numbers depend heavily on the actual application, load profile, etc. With applications that do not have a lot of roots, weak reference and/or class churn, the pauses can be in sub-millisecond range. With applications that do not mutate heap as much, or are well optimized by current compilers, the barrier overhead can be near zero. The rest of the section describes the approaches to test and diagnose performance behaviors with Shenandoah. If you suspect something is off on your concrete use case, consider letting developers know about them. Chances are, that is a manageable issue or a straight-away bug.
from the wiki
rancid hearth
So basically
If it doesn't have enough heap
It behaves like a starving homeless dude on heroin
Or nah that's too explicit
formal perch
Failure Modes
Concurrent GC like Shenandoah implicitly relies on collecting faster than application allocates. If allocation pressure is high, and there is not enough space to absorb the allocations while GC is running, Allocation Failure would eventually happen. Shenandoah has a graceful degradation ladder that helps to survive the cases like these. The ladder consists of:
Pacing (-XX:+ShenandoahPacing, enabled by default). When GC is running, it has the idea how much GC work is needed to be done, and how much free space is available for application. Pacer would try to stall allocating threads when the GC progress is not fast enough. In normal conditions, GC collects faster than application allocates, and pacer naturally does not stall. Note that pacing introduces the local per-thread latency that is not visible in usual profiling tools. This is why the stalls are not indefinite, and they are bounded by -XX:ShenandoahPacingMaxDelay=#ms. After max delay expires, the allocation would happen anyway. Most of the time, mild allocation spikes are absorbed by the pacer. When allocation pressure is very high, pacer would not be able to cope, and the degradation moves to the next step.
Usual latency induced: <10 ms
rancid hearth
It behaves like a dumb cat that eats too much then barfs
formal perch
Degenerated GC (-XX:+ShenandoahDegeneratedGC, enabled by default). If application runs into allocation failure, then Shenandoah would dive into stop-the-world pause, stop the entire application, and continue the cycle under the pause. Degenerated GC continues the in-progress "concurrent" cycle under stop-the-world. In many cases, allocation failure happens after a significant amount of GC work is already done, and a small part of GC work needs to be completed. This is why the STW pause is not usually large. It would be reported as GC pause in the GC log, all the usual monitoring and heartbeat threads: indeed, one of the reasons to induce STW pause is to make concurrent mode failures clearly observable. Degenerated GC may happen if GC cycle started too late, or if a very significant allocation spike had occurred. The Degenerated cycle might be faster than the concurrent one, because it does not contend with the application over the resources, and it uses -XX:ParallelGCThreads, not -XX:ConcGCThreads for thread pool sizing.
Usual latency induced: <100 ms, but can be more, depending on the degeneration point
Full GC. If nothing helped, for example, when Degenerated GC had not freed up enough memory, Full GC cycle would happen, and compact the heap to the max. Certain scenarios, like the unusually fragmented heap coupled with implementation performance bugs and overlooks, would be fixed only by Full GC. This last-ditch GC guarantees that application would not fail with OOM, if there is at least some memory is available.
Usual latency induced: >100 ms, but can be more, especially on a very occupied heap
In addition to usual GC log that would print individual Degenerated GC and Full GC events, -Xlog:gc+stats would show something like this at the end of the run:
So you need to see in the logs
if you have any stop-the-world or even a full gc
rancid hearth
Does it assign threads and cores automatically? Or do I need to do it myself
formal perch
Does it assign threads and cores automatically? Or do I need to do it myself
Yes, it's not a problem
rancid hearth
Okay good
Are there any extra flags I should add regardless of GC
On some article it just showed like
Wait look
formal perch
So I this point, I really advise to
- Read the wiki
- Increase ram and try different configs
- Enable GC logging and check what is wrong or if you want a simpler way, check F3
rancid hearth
https://github.com/Mukul1127/Minecraft-Java-Flags
Under base java flags
Are those legit
Or is it more slop that slows down the game and causes errors
rancid hearth
So I this point, I really advise to
- Read the wiki
- Increase ram and try diffe...
Alright, thanks for the help 🙏
formal perch
Or is it more slop that slows down the game and causes errors
no idea, try and see
and try to understand what each do
also remember that the result can be different for each machine
rancid hearth
also remember that the result can be different for each machine
True
I need like universal-ish args
Because I want to ship them with the modpack
So everyone can have a good experience
formal perch
i linked only shenandoah before
rancid hearth
I'll test them both out
Also on that GitHub page the guy said Shenandoah kills server throughput
On server I'll probably stick with G1 aikar's flags because server pause times aren't all that relevant
formal perch
Also on that GitHub page the guy said Shenandoah kills server throughput
so first of, that's for server, we are talking client here, and second, try and see
but it is true that you want to prefer throughput for servers
rancid hearth
Yeah but I also have a server and I was saying
On server I'm Def not using Shenandoah
Haven't tested anything on the server yet tho
Because I need to fix up the client first
rancid hearth
what the fuck
i enabled Java 24 ZGC
game runs perfect and uses only 3.5-4GB even tho i gave it 10
🤨
formal perch
game runs perfect and uses only 3.5-4GB even tho i gave it 10
Try to add -XX:-ZGenerational instead of -XX:+ZGenerational and see if still run as good
Also note that G1GC also received a lot of improvments between java 21 and 24, so you might want to try it again
rancid hearth
ZGenerational is on by default in Java 24
non generational is removed
you cant switch it between generational and non generational its generational by default in java 24
formal perch
non generational is removed
It wasn't removed
You can still switch
That's why I ask
maybe it's much better because it's the generational gc
Wait
no
you are right
rancid hearth
yeah