Stop recommending https://flags.sh

[solonovamax]

Specifying a bunch of magic jvm flags you don't understand is not a good idea.

The jvm is extremely well optimized, and the defaults are what you should be sticking with.

The recommended flags on https://flags.sh fall into one of a few categories

1. Snake oil
2. Fluff
3. Does literally nothing
4. Bad idea

If you really want to recommend a website, you should recommend https://noflags.sh/. There are basically only 2 flags you should be adding:

• -XX:+UseZGC
• -XX:+ZGenerational if using java 21 or above

Related: #121

[funnykeyboardsymbols]

Ah, this thread again. Not like we've been testing and retesting these flags for 7 years or anything.

Aikar's are more performant at lower heap allocations. Once you pass around 16 to 20 Gigs, then GenZGC becomes preferable.

Also, the paper project ITSELF recommends Aikar's flags. https://docs.papermc.io/paper/aikars-flags

[YouHaveTrouble]

All 4 of your points apply more to ZGC than to G1GC. It's simply not as universal. It's very hit or miss. Yes, even on java 21+.

Aikars' are not "magic". They make sure your defaults are properly set. Which is worth noting, that most of the aikar's flags are now defaults in hotspot based distributions. There's a great reason for that, they work for like 99.9% of setups without issues, which I from experience cannot say about ZGC.

[solonovamax]

I'm just going to leave this here: https://garden.unascribed.com/jvm-args/

also,

MaxTenuringThreshold=1: Minecraft has a really high allocation rate of memory. Of that memory, most is reclaimed in the eden generation. However, transient data will overflow into survivor. Initially played with completely removing survivor and had decent results, but does result in transient data making its way to old which is not good. Max Tenuring 1 ensures that we do not promote transient data to old generation, but anything that survives 2 passes of GC is just going to be assumed as longer-lived.

Doing this greatly reduces pause times in young collections as copying data up to 15 times in survivor space for a tenured object really takes a lot of time for actually old memory. Ideally the GC engine would track average age for objects instead and tenure out data faster, but that is not how it works.

Considering average GC rate is 10s to the upwards of minutes per young collection, this does not result in any ‘garbage’ being promoted, and just delays longer lived memory to be collected in mixed GCs.

bad. do not do this. makes the promotion from the young gen EXTREMELY aggressive. the default is 15, if you really want to adjust it (don't), set it to like 8-10 or smth. but making it this aggressive can cause things to get promoted from the young gen even though they're shorter lived objects.

G1NewSizePercent: These are the important ones. You now can specify percentages of an overall desired range for the new generation. With these settings, we tell G1 to not use its default 5% for new gen, and instead give it 40%! Minecraft has an extremely high memory allocation rate, ranging to at least 800MB/second on a 30 player server! And this is mostly short-lived objects (Block Position).

Now, this means Minecraft really needs more focus on new gen to be able to even support this allocation rate. If your new gen is too small, you will be running new gen collections 1-2+ times per second, which is awful. You will have so many pauses that TPS has risk of suffering, and the server will not be able to keep up with the cost of GCs. Then combine the fact that objects will now promote faster, resulting in your old gen growing faster. Given more new gen, we are able to slow down the intervals of young gen collections, resulting in more time for short-lived objects to die young and overall more efficient GC behavior.

they claim that java uses by 'default 5% for new gen', which is false, it starts at 5% but grows up to 60%. however, aikar's flags in fact decrease the max to only 40%.

+ParallelRefProcEnabled: Optimizes the GC process to use multiple threads for weak reference checking. Not sure why this isn’t default…

this is false. ParallelRefProcEnabled is enabled by default in modern jvms. it is not enabled by default in java 8, but it is in java 11. unsure about versions between 8 and 11, but you should not be using such an old jvm that this matters.

MaxGCPauseMillis=200: This setting controls how much memory is used in between the minimum and maximum ranges specified for your new generation. This is a “goal” for how long you want your server to pause for collections. 200 is aiming for at most loss of 4 ticks. This will result in a short TPS drop, however the server can make up for this drop instantly, meaning it will have no meaningful impact on your TPS. 200ms is lower than players can recognize. In testing, having this value constrained to an even lower number results in G1 not recollecting memory fast enough and potentially running out of old gen triggering a full collection. Just because this number is 200 does not mean every collection will be 200. It means it can use up to 200 if it really needs it, and we need to let it do its job when there is memory to collect.

not useful on modern gcs which minimize STW collections

SurvivorRatio=32: Because we drastically reduced MaxTenuringThreshold, we will be reducing use of survivor space drastically. This frees up more regions to be used by eden instead.

completely useless. does not actually do anything unless you also set -XX:-UseAdaptiveSizePolicy (which is not set with aikar's flags) (also it's unclear but I believe this doesn't even apply to G1, and instead only to the old parallel gc)

G1ReservePercent=20: Minecraft memory allocation rate in up-to-date versions is really insane. We run the risk of a dreaded “to-space exhaustion” not having enough memory free to move data around. This ensures more memory is waiting to be used for this operation. Default is 10, so we are giving another 10 to it.

-XX:G1HeapWastePercent=5: this is the default value. does literally nothing.

-XX:InitiatingHeapOccupancyPercent=15: the default is 45. unsure if this actually makes any difference, but I don't believe it would. it just adjusts at what heap occupancy the jvm will perform the gc. if anything, it makes gcs happen more often.