[11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1

Ruslan Synytsky rs at jelastic.com
Thu Aug 6 17:00:20 UTC 2020


Hi All, I would like to refresh this topic by sharing a very simple example
that demonstrates why Java looks broken without this improvement.

Jenkins is one of the most popular CI/CD tools. Unfortunately it supports
only Java 8 and Java 11
<https://www.jenkins.io/doc/administration/requirements/java/>. If you
start a simple standalone Jenkins instance and *just sign in* inside the
admin panel then the JVM will start consuming a significant amount of
memory immediately. In my case I had the following limits: container limit
- 8G, heap limit (Xmx) - 6.5G and the memory consumption after the sign in
action got to 3G. By default all Java runtimes lower than Java 12 within
Jelastic are supplied with our Java agent (which is a workaround) that
tracks memory usage and if this agent detects a significant waste it calls
full GC. After this full GC call the memory consumption goes down to 0.5G
(check the screenshot)
<https://raw.githubusercontent.com/siruslan/java-memory-usage/master/images/jenkins-memory-usage-diff.png>.
If we disable our agent then the memory usage at the idle JVM will stay at
3G forever which is a waste of resources
<https://raw.githubusercontent.com/siruslan/java-memory-usage/master/images/jenkins-memory-usage-waste.png>.
If you put additional load on Jenkins the picture will look even worse.

Usually one large host node runs hundreds of containers, and one cloud
cluster may consist of tens, hundreds or thousands of host nodes, so the
issue multiplies. And the case with Jenkins is just one of the examples.
I'm pretty sure this inefficient memory usage issue was damaging the Java
brand for many years and a lot of developers believe that Java is too
heavy. Is not it a strong reason to bring the fix to Java 11?

Thanks
-- 
Ruslan Synytsky
CEO @ Jelastic Multi-Cloud PaaS <https://jelastic.com/>


More information about the jdk-updates-dev mailing list