> How do you find a reasonably small Xmx that doesn't lead to OutOfMemoryError exceptions?

That's tough to figure out. In new versions of Java, I think 14+, if you use ZGC collector it will return unused memory to the OS. Memory options vary depending on collector, but new versions of ZGC support "soft max" heap size and uncommit. Together it might be close to what you're looking for https://malloc.se/blog/zgc-softmaxheapsize

I should mention the GC situation was worse until the last few years. Until ZGC and Shenandoah came around, Java still didn't collect frequently but when it did there were long pauses. This is what V8 and Go's collectors were designed to avoid. They have more overhead from collecting frequently, but low pauses. With the new Java collectors you get the best of both worlds.

You can set heap ratios and such for older collectors to decrease Java memory use with those, but IMO you're better off using ZGC and uncommit these days

> That's tough to figure out.

Indeed. That fact obviates this option in most cases. You have to spend time tweaking obscure, unstable knobs (the X in Xmx means Oracle is free to alter its meaning at any time) and risk either a.) serious failures in production or b.) poor results because the conservative choices necessary to avoid 'a' achieved little improvement and you wasted your time. The real world for most enterprises is a vast heard of communicating components and toying with GC switches multiplied by N things is a nonstarter.

So while you're technically correct that excessive memory use by conventional JVMs is "not always true," in practice you are wrong. That reality comes with a real cost that appears on a real bill every single month.

The cost of setting a few command line args? They're not really obscure or unstable, just different depending on the GC you use. Turning on ZGC and setting the right options is like 4 command line flags. It's very easy, the reason it's not frequently done is that nobody reads documentation and it's not the default.

Go's approach of minimal knobs leads to unfixable problems in production. Java gives more options to tune GC for your use case

> Go's approach of minimal knobs leads to unfixable problems in production.

I didn't bring up Go, but since you did the thing I see is that Go -- a much younger language -- is going places Java never has, or did so only haltingly. Caddy is a case in point. Here is Go taking on nginx, haproxy, Envoy, etc.

The people that once imagined using Java for such things have retired or moved on to other battles. No one seriously ponders attempting 'systems' tasks with Java any longer; that whole space was ceded to more efficient languages. My opinion is that Java's poor efficiency -- a big part of which is its excessive memory consumption -- is the reason for this.

That's my opinion. What I know for fact is that today, when people are making design decisions about new services and their deployment, Java is a problem; it is understood that anything implemented in Java is going to sort right to the top of the list of memory pigs in the cluster, and you can only afford so many of those.

I think you're ignoring that people don't want to "tune" their GC. They just want it to work. So instead, they are going with the obvious route of just buying more RAM. This is perfectly fine on servers, which is where Java shines. As soon as Java has to be used for e.g. CLI scripts, daemons, or situations in which multiple process instances have to run at the same time, then Java is an incredibly poor choice and there is nothing you can do about that. If you are a genius at memory optimization in Java then you'll see even bigger gains in C++ or Go or Lua or Javascript or Python. Some of these options may not be as fast as the JVM but this discussion is purely about memory usage.

> I should mention the GC situation was worse until the last few years. Until ZGC and Shenandoah came around, Java still didn't collect frequently but when it did there were long pauses.

This feels like G1GC erasure. I'll also say we've tried out ZGC and while pause times were low, it had a huge CPU overhead and the performance of our application was notably worse and we went back to G1GC. We're still on Java 11, so maybe we'll see some magic when we eventually try the newer versions.

20th October, OpenJDK 11.0.9 will be released, with full-fledged Shenandoah GC. It has _very_ low pauses and has the `-XX:ShenandoahGCHeuristics=compact` option, which will promptly give unused memory back to the OS (thus keeping the whole memory profile low).

Give it a try.

https://wiki.openjdk.java.net/display/shenandoah/Main

https://www.slideshare.net/jelastic/choosing-right-garbage-c...

https://twitter.com/shipilev/status/1308320432404168705

Thanks for the advice. I'm stuck on 11 until the next LTS release but I'll definitely be trying ZGC next year. (ZGC is in 11 but still marked experimental, and I'm conservative about making changes.)

That's probably a good decision. When ZGC was first released it didn't support class unloading, including in 11. This will lead to puzzling memory leaks in applications that generate a lot of code at runtime.

Newer versions of ZGC support class unloading and have some other performance optimizations

Shenandoah might help you. See my other comment for more details:

https://news.ycombinator.com/item?id=24571054

Depends on your application and how much memory you actually need. I would also use ZGC as it returns unused memory to the system and low ms maximum pause times for terabytes of heap.