My understanding was that a golang program's heap size will automatically grow as needed, and later (eventually) shrink as memory goes unused.
Is this true of java? Is it possible to run a java program in a way where it is allowed to use up all of the system's heap if needed, but also plays nicely with other processes on the system (i.e. yields the memory back to the OS after it becomes unused)?
Maybe this has been improved in the last 10 years but heap management imho is one of the not-great things about the JVM when I was using it. What is happening is quite invisible to sysadmins used to monitoring traditional unix processes. To them it looks like a giant memory hog, non-cooperative, when in reality the program might only be using a small % of what top is showing allocated to the process.
The original JVM philosophy seemed to be to cohost a bunch of stuff in one monolithic JVM process, rather than run a bunch of separate communicating processes. And in fact this "container" philosophy is what the original J2EE servers operated with.
Is this true of java? Is it possible to run a java program in a way where it is allowed to use up all of the system's heap if needed, but also plays nicely with other processes on the system (i.e. yields the memory back to the OS after it becomes unused)?