> I think your information is outdated. Java has had lightweight threads for several releases now.

Well, yes. It was released as a part of JDK 21 a year ago. So far, the adoption has been spotty. They are also implemented not in the best possible way.

> Xmx is mostly a thing if you have very small RAM, or some sort of grievously misconfigured container setup. By default it grow up to 25% of the system RAM, which is a relatively sane default.

Other more sane runtimes (like Go) do not even have developers care about the heap sizing. It just works.

It’s valid criticism because you do need to think about it less in other runtimes, but it doesn’t always just work. There’s a reason why GOMEMLIMIT and other knobs for high allocation programs were introduced.

IIRC .NET just sets it to 75% of available memory.

> IIRC .NET just sets it to 75% of available memory.

Out of all three Go one is the least configurable. .NET GC is host-memory aware and adjusts heap size automatically. It does not need Xmx as it targets to keep host memory pressure low but the hard limit really is only available memory unless you override it with configuration.

It has been further improved as of recently to dynamically scale heap size based on allocation rate, GC % time and throughput targets to further reduce sustained heap size.

Java does the sane thing within containers, and you definitely not have to set memory settings anywhere else, unless you want some very specific behavior.

I thought this was the case but actually couldn’t find any documentation on it. The best I could find was that the vm is aware it is in a container and will correctly set the heap %’s based on the containers memory. It still looked like it was defaulting to 25%.