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

Tue Apr 7 10:30:35 UTC 2020

Hi,

Agree with Ruslan that the elasticity of memory footprint of Java application is really important.
 As far as I know, not only Jelastic and Alibaba, Google has its own similar feature. But much more
 users don't have the ability to make such customization to JDK. In the meanwhile most of users are
 still using JDK8 and migrating to JDK11 is a noticeable trend. I totally agree stability is
the most important factor for any changes against stable versions. But if a feature has been tested
 through several releases(the JEP and related bug fixes were pushed in JDK12/13), we are able to take
 it into the consideration as a stable change. Anyway, do you think we shall get some more technical
 comments from Thomas before make the decision?

Thanks,
Liang

------------------------------------------------------------------
From:Ruslan Synytsky <rs at jelastic.com>
Send Time:2020 Apr. 7 (Tue.) 17:37
To:Andrew Haley <aph at redhat.com>
Cc:Gil Tene <gil at azul.com>; "MAO, Liang" <maoliang.ml at alibaba-inc.com>; jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
Subject:Re: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1

100% agree that stability should be #1 acceptance criteria of any backporting. Is there a good enough process in place to make sure that stability does not degrade? 

> why don't you just move to using one of the three already-GA'ed OpenJDK versions that followed 11 and have this
If we talk about our company - we do offer new releases to the end users, it's easy to get a standalone JDK runtime or "some" middleware stacks that support the newest versions. However while number of jdk11+ installations is growing the number of jdk8 environments is still high. We can't force people to move to the latest versions... We can motivate and promote it, but no way to force it. And, I assume many companies would prefer to use LTS versions and the next LTS is planned to be released with Java SE 17 in September 2021.   

> Maybe there is an argument to be made for a "jdk11u-performance"
Motivation of this topic is simple - to make Java applications (including Java middleware stacks) less greedy on the RAM usage, in other words make it elastic. This problem exists many years as the default GC was not aligned well with the widely adopted elastic cloud technologies, specifically with containers. People used to live with this issue... But some cloud vendors tried to come up with different solutions. For example, Alibaba and Jelastic had own internal customization for bringing more efficiency to java workloads. There is also an old article from RedHat OpenShift related to the same issue https://developers.redhat.com/blog/2014/07/15/dude-wheres-my-paas-memory-tuning-javas-footprint-in-openshift-part-1/. I hope many of us understand that cost of consumed cloud resources is carefully counted at small and medium sized projects and even large enterprises that care about infrastructure use optimization may benefit from it.

Now finally the elasticity is available in the open source core. The new GC implementations took into account the importance of the resource usage efficiency (Shenandoah, ZGC) . We have a solution for G1 as well, so no need to give up on efficiency with the default GC. Can we accept this backport as a performance improvement? I believe it depends on what people put behind the "performance" word. The improvement will not speed up anything while it can help to get the same results with smaller amount of used resources.  

On Mon, 6 Apr 2020 at 13:43, Andrew Haley <aph at redhat.com> wrote:
On 4/4/20 8:24 AM, Gil Tene wrote:

 > - Are there any indications that Oracle is backporting this into
 > their Oracle JDK 11?
 >
 > - Do we have input from the GC team on the complexity and potential
 > tie-in or dependence [explicit or implied] of this JEP
 > implementation on other post-11 G1 improvements, changes,
 > assumptions, or invariant modifications?
 >
 > - What level of extensive review by GC experts and exhaustive GC
 > stress-testing are we willing to put in to gain confidence that this
 > will not regress the stability of 11u?

 All good questions.

 The idea of the rolling updates model of OpenJDK is to allow the rapid
 development and release of features such as these, and because Java is
 almost entirely backwards compatible, users can choose a modern but
 less-tested release or a stable long-term release. If we were to
 backport substantial changes such as this to the stable 11u branch we
 would take away that choice from our users. Reluctantly, therefore, I
 must say no, because our users need to be able to make that choice.

 Maybe there is an argument to be made for a "jdk11u-performance"
 release of OpenJDK 11, which would be distinct from the stable
 release.

 -- 
 Andrew Haley  (he/him)
 Java Platform Lead Engineer
 Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
 EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

-- 
Ruslan Synytsky
CEO @ Jelastic Multi-Cloud PaaS