I think if you implicitly define "top-notch garbage collection" as "never requires any tweaking ever in any performance profile" you've limited your "top-notch garbage collection" down to the empty set. There aren't even any "manual" memory management techniques that can stand up to that definition, honestly. Even in "manual memory management" languages there are situations where you end up having to say "just give me a big slab of memory and walk away, please" (arena management, etc.).

(Not a defense of Go's GC, necessarily. I'm not sure I'd call it "top-notch". A lot of its advantage over Java was that it got to look at Java and make different decisions, and by having a lot more values in the language with fewer references, part of the reason it tends to do a lot better than Java in terms of memory usage is just that it gave itself an easier memory management problem in the first place. Java GCs are frightfully good, yes, but to some extent they are that good because they have to be. Java at the very, very beginning was not designed for the sort of usage it has today (it was very originally a set-top box language, not a Big Iron language), so the language does some things that stress its GC. Go's doesn't have to be that intricate to be still quite good, so it isn't. And note difference between "quite good" and "top notch".)

Ballast isn't gc tuning in the sense of changing some configuration, it's doing something nonsensical in the application code itself to alter gc behavior.

In java you would simply set -Xms to increase the min heap size and then that additional memory would also be available to the application and not wasted as in the Go case.

It's not "wasted" in the Go case. On modern systems, the ballast is only a few numbers in the virtual memory table as long as you don't touch it, which isn't that hard. The original blog post confirm it: https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i... search for "Now onto 2. Won’t this use up 10Gib of my precious RAM?"

It may be "nonsensical" but on the grand scale of "things done for memory management's sake" I find it unimpressive. (If 10GB were actually allocated and unavailable, I would find it impressive.)

Point is, with a mature GC, you don't need to change your code to change runtime GC behaviour - in fact, in JVM land, any usage of `System.gc` or similar in code is very much a code smell.

To give a broad example, and to repeat the parent comment, I can avoid "ballast" by setting -Xms. But it goes further, if I have an existing JVM code base, and want to run it using a GC that exhibits similar low GC pause time to the Go GC, assuming I'm compatible with Java 12+ I can use the command line option -XX:+UseShenandoahGC without changing my code.

If Shenandoah isn't producing the behaviour I want, I can change to another algorithm with -XX:+UseG1GC for example.

I totally understand that Go's trying to avoid such complexity, but to quote Python's zen, complex is better than complicated. And I consider writing code to influence underlying runtime behaviour to be needlessly complicated.