The stated goal of this JEP is to enhance the G1 garbage collector to automatically return Java heap memory to the operating system when idle
Since G1 tries hard to completely avoid full GCs, and only triggers a concurrent cycle based on Java heap occupancy and allocation activity, it will not return Java heap memory in many cases unless forced to do so externally.
So Is this disadvantageous in container environments where resources are paid by use ?
Can anyone please clarify this....
Ref: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8204089
If I'm not misunderstanding you, it seems that you're asking if it's disadvantageous to have the GC reclaim memory in containerized environments, as the user may not be fully utilizing the memory and thus is overcharged for resources.
The link that you provided actually states the following:
This behavior is particularly disadvantageous in container environments where resources are paid by use. Even during phases where the VM only uses a fraction of its assigned memory resources due to inactivity, G1 will retain all of the Java heap. This results in customers paying for all resources all the time, and cloud providers [not being able to fully utilize their hardware][4].
If the VM were able to detect phases of Java heap under-utilization ("idle" phases), and automatically reduce its heap usage during that time, both would benefit.
The designers of this JEP seem to believe that both the user and cloud provider would benefit from the reclamation of unused memory, and it seems to make sense from the above statement.
However, if your program is running in a timed-environment (such as AWS Lambda) and it's short-lived, you may want to even utilize the Epsilon GC where no memory is reclaimed whatsoever, as that could benefit you even more in certain cases (why spend CPU cycles reclaiming memory if the container will just be destroyed?).