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

[Ruslan Synytsky]

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 <https://jelastic.com/>