It really wasn't and was always dubious.

A lot of the advice, for example, suggested using CMS. Which has been a terrible garbage collector almost since it was added to the JVM. When G1GC landed in 8, that was the correct GC to select for minecraft. Even the parallel collector would have been a better option than CMS in a lot of cases (sub 4gb heaps).

It was placebo. People wanted there to be SOMETHING that made things better so they reached for the billion different flags on the JVM (rather than fixing the underlying code). I've seen the same sort of mentality professionally and it's basically always been wrong.

It was more like Minecraft code was horrible, than anything else.

Creating objects like crazy, range for in hot paths, not caring about data representation, chosen algorithms,....

JIT and GC were already doing heroic efforts.

Yet, it settled Notch for life, which is something to take into account in the usual question regarding which technical stack for games.

It depends on the GC, with ZGC no. Particularly if you enable generational mode.

For other GCs like G1 and the parallel collector, when new gen is filled up the GC pauses the application in order to run a minor collection. For G1, major collections are ran in the background until the heap fully fills up. When that happens, the GC triggers stop the world GC.

A smaller heap size would cause those pauses to be more frequent but because the heap is smaller it means that ultimately the pauses will be limited in length.

ZGC is different. Without generational mode, ZGC is collecting the entire heap every time with it, ZGC will do the young old collections.

When a collection is triggered, ZGC flips a field to indicate a collection in progress, that flip is the only pause for the application under zgc (except the case that the heap fully fills) it typically finishes in microseconds. Once collection starts, the ZGC collector threads and the in progress application are running collections. The size of the heap really doesn't change much other than the background collection could last longer (slowing down the server, but not totally stopping it from being responsive).

The payment you make with ZGC is that you do burn more CPU cycles doing collections especially while the app is running. But for a game server, that hardly matters. What matters is that the server remains responsive in a timely fashion, which ZGC enables.

8 GB is simply not enough for most modpacks, at least the 200+ mods one. I know, I've tried, although it was years ago. You run at consistently 95% GC usage and get constant, very heavy, collections because of it. Like every second you get lag spikes due to GC pressure. And because of the usage these look to be full collections, which are stop-the-world last I checked.

This was ~5 years ago, so I'm sure it's gotten better. But not that much better 8gb would cut it, either client or server side.

I would generally not call modpack that runs well on 8gb heavy

Wow. When I played Minecraft, 1GB was enough and 4GB was a lot. I know that since 1.8 Microsoft rewrote large parts of the engine to make them less efficient and more ivory-tower, but I didn't know it was that bad.