A DESCRIPTION OF THE REQUEST :
Given that the guidelines for server applications are to set Xms == Xmx, the JVM is typically not a very good citizen in a container world (i.e. when multiple applications are running in separate containers, e.g. on kubernetes) because it conservatively allocates all heap space at startup and never deallocates it.

On POSIX systems the common way to do this is by using madvise with MADV_FREE (or MADV_DONTNEED; there are some semantic differences between the two, but they are largely designed to achieve the same goal). Other platforms have similar mechanisms in place (e.g. Windows has VirtualFree with MEM_DECOMMIT).

By using these, applications can signal to the OS that the *contents* of an allocated memory range are not needed, and the OS is free to discard them. Note that this doesn't unmap the memory range from the process: when the process attempts to access the range again it will either contain all zeros or some undefined content.

This mechanism is already in use e.g. by the nodejs and golang runtimes:
- https://github.com/nodejs/node/blob/990959d2f6bbcb42a437381bb2f435ec5d8067e6/deps/v8/src/base/platform/platform-posix.cc#L142-L164
-
https://github.com/golang/go/blob/193088b246f4bbe9a7d3a84ec7f4cc6786dac043/src/runtime/mem_darwin.go#L21-L24
-
 https://github.com/golang/go/blob/193088b246f4bbe9a7d3a84ec7f4cc6786dac043/src/runtime/mem_linux.go#L77-L146
-
 https://github.com/golang/go/blob/193088b246f4bbe9a7d3a84ec7f4cc6786dac043/src/runtime/mem_windows.go#L32-L60

It seems a few years ago there was already a patch to implement this (at least for linux initially) but it was never merged: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-January/005664.html

I found a similar request that again was for a single OS, so it was dismissed (the argument being that the specific OS in question was not a target for perf enhancements: https://bugs.openjdk.java.net/browse/JDK-7129726).




JUSTIFICATION :
The reason I'm bringing this up now is twofold:
- Because the server computing landscape has changed in the meanwhile (containers) and adding such capability would help make the JVM a better citizen in such a scenario
- Because AFAICT most (all?) server OSes now support this kind of capability, so implementing this wouldn't increase the difference between OSes

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The JVM readily deallocates unused memory (even when using Xmx == Xms)
ACTUAL -
The JVM does not deallocate unused memory, it only frees memory (by shrinking the heap) if Xmx > Xms.