Setting a min and max heap size for a garbage collected language in 2020. Just figure it out for me?

There's a black box optimizer for databases, which is designed to take the user away from having to find and tweak all the hundreds of possible tunables in the database, https://github.com/cmu-db/ottertune / https://ottertune.cs.cmu.edu/

I keep wanting the same for JVM. It's probably nice that there are so many ways to adjust the JVM to best suit a very wide range of workloads, but from a practical perspective I rarely have spare time to go diving through the guts to experiment. Let me point something at a one-box, and it can tweak parameters to its hearts content, so I can export and apply to the rest of the fleet.

Well, ART auto tunes and probably not everyone will agree it does it perfectly.

There are also plenty JVMs to pick and some are better than others working with their defaults.

But Go doesn't "figure it out" for you. It decides for you - there's no "figure it out" step.

That's the power of having tunables.

Then they chose better defaults because I never have to think about it.

Just because the defaults are better for you doesn't mean they're better for everyone.

There's nothing to figure out. If you want to use all your ram (like in go) just set -Xmx<all_your_ram>.

If you haven't done -Xmx=<all memory> before, you may not be aware that you're giving a bum steer here.

But to know whether you want that, you need to understand the application. Elasticsearch, for example, recommends using at most 50% of physical memory for heap:

https://www.elastic.co/guide/en/elasticsearch/reference/curr...

You also often want to stay below 32 gb to get compressed OOPs

That is a terrible idea. The JVM basically never returns RAM to the OS, and in my experience, if you run a java process long enough, the max heap size ends up being the used heap size.

G1 the default allocator returns heap to the os only when you set -G1PeriodicGCInterval and both ZGC and Shenandoah do it automatically.

Why isn’t that the default? Unless I say otherwise, use it.

Imagine launching every app and having to say ok you get 300mb but not more!

It’s the default because Java has a history, and it was set when everyone was deploying war files to machines with 512mb total memory and the default worked for 95% of people for the past 25 years. In fact, it’s still good enough for the chocolate factory that has brainwashed you into drinking the static binary milkshake.

Of course there are ways to use all the available ram when you deploy your kubernetes pods, you just have to consult the documentation.

Honestly this criticism is ridiculous I can’t believe I even bothered to reply.

Normally you just run your one JVM app on your VM. The real balance is basically between the heap size and page cache size. You might want to tweak it, as much as the GC algorithm and other memory details. This applies if you understand them.

If you don't, you just start the JVM with defaults, and it configures itself for optimal performance, using its idea of optimal.

Sometimes having more control over GC is useful tho, could save a re-write.

https://blog.discord.com/why-discord-is-switching-from-go-to...

They rewrote to get away from garbage collection full-stop, so I don't think this is quite the argument for the JVM that you're making it out to be.

Not to mention: they resolved their Go GC problem, and rewrote the service in Rust as part of a wave of moving services to Rust because they just liked Rust.

I'm an active Go user and I've been working almost exclusively in Go since 2011. I have a feeling that over time, the number of knobs on Go will increase much like it has in Java. I'm trying to think back to my first experiences with Java in 1995. It was so simple compared to the overhead of getting things working in C/C++. So Java's got like 25+ years on Go and I would speculate that the number of knobs on Go in 25 years will be significantly higher. On the one hand, I don't like seeing all the crazy configurable stuff, e.g. CGO_....=1 until I actually need it.

Go is already 10yo, so I suppose this will be in 15 years?

Oops. Ya, 15. Off by 10 error!

yep so not 100% the same, but my point with linking to it is tunables / levers / control is useful. In other scenarios maybe you could get by without having to do a rewrite in Rust, maybe you could keep it in golang and tune the GC a bit.

Whilst I like the memory ballast as a clever solution, it does smell like a workaround to a solvable problem if a parameter existed to tune it directly.

It's totally a workaround and I'm jumping on that last comment when I shouldn't be; it's just a reaction to the hyperbolic "you might have to rewrite" conclusion, because you won't have to rewrite, but indeed you might be annoyed by the lack of tunables.