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

[Liang Mao]

Hi Developers,
I would like to refresh this backport too. As Ruslan's description, this JEP provides
a very convenient way to save significant memory for popular applications like Jenkins.
Alibaba's JDK11 already had this feature and used it in workloads like big data
engines for months. The effect of memory saving is impressive. 

Alibaba keeps migrating our Java applications to JDK11 and G1. We will surely maintain
 the quality of the feature as we continues to report/discuss issues of G1 and
 backport G1 bug fixes. SAP and Microsoft are interested in this feature during last
 discussion and willing to maintain it as well. The JEP only contains 4 small to medium
 patches and 6 tiny to small fixes. With communitie's review(Oracle G1 team agreed to
 help)  and experienced JVM developers from several big companies and testing on
 various  workloads and scenarios, I believe the quality is definitely controllable.

I have been managing thousands of Java applications/millions of Java instances and
 helping them to upgrade JDK and GC including different types of worloads like online
 services, big data platforms, batch jobs, etc. It's really painful for owners of Java 
applications to upgrate their JDK version to a larger number, especially for those big
 applications with a lot of 3rd party packages.  Letting JDK11 LTS have such small
 feature with significant effect would benifit most of users.

All changes of the JEP only contains of hunderds lines of code:
http://cr.openjdk.java.net/~lmao/jep346.11u/all.webrev.00/

Here are the 10 changesets needs backport and 3 of them have conflicts:
1) JDK-8071913
http://cr.openjdk.java.net/~lmao/jep346.11u/8071913.webrev.00/
2) JDK-6490394
3) JDK-8213898
4) JDK-8212657
http://cr.openjdk.java.net/~lmao/jep346.11u/8212657.webrev.00/
5) JDK-8215120
6) JDK-8215149
7) JDK-8215548
8) JDK-8216490
9) JDK-8218880
http://cr.openjdk.java.net/~lmao/jep346.11u/8218880.webrev.00/
10) JDK-8212883

Tested with tier1/fastdebug.

BTW, I will file an CSR for the new options added if maintainers agree.
Any questions?

Thanks,
Liang
> -----Original Message-----
> From: jdk-updates-dev [mailto:jdk-updates-dev-retn at openjdk.java.net] On
> Behalf Of Ruslan Synytsky
> Sent: 2020年8月7日 1:00
> To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> Subject: Re: [11u] Backport JEP 346 : Promptly Return Unused Committed
> Memory from G1
> 
> 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/>