回复: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1(Internet mail)

[kalinshi(施慧)]

Thanks Liang!
It would be great to have this feature in 11u.

Regards
Hui
-----邮件原件-----
发件人: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> 代表 Ruslan Synytsky
发送时间: 2020年10月12日 16:02
收件人: Liang Mao <maoliang.ml at alibaba-inc.com>; Andrew Haley <aph at redhat.com>
抄送: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Martijn Verburg <Martijn.Verburg at microsoft.com>
主题: Re: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1(Internet mail)

Dear Liang, thank you for the extra efforts on this improvement.

Dear Andrew, I assume we need your approval / confirmation. Can you please take a look and let us know your feedback?

Regards

On Fri, 25 Sep 2020 at 09:42, Liang Mao <maoliang.ml at alibaba-inc.com> wrote:

> 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-
> <https://raw.githubusercontent.com/siruslan/java-memory-usage/master/i
> mages/jenkins-memory-usage-diff.png>
>
> > usage/master/images/jenkins-memory-usage-diff.png
> <https://raw.githubusercontent.com/siruslan/java-memory-usage/master/i
> mages/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-
> <https://raw.githubusercontent.com/siruslan/java-memory-usage/master/i
> mages/jenkins-memory-usage-waste.png>
>
> > usage/master/images/jenkins-memory-usage-waste.png
> <https://raw.githubusercontent.com/siruslan/java-memory-usage/master/i
> mages/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/>
>


--
Ruslan Synytsky
CEO @ Jelastic Multi-Cloud PaaS