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

Wed Apr 8 05:24:17 UTC 2020

Hi,

I need to answer some decent questions from Gil and Andrew first.

> - Are there any indications that Oracle is backporting this into their Oracle JDK 11?
IMHO, I don't think we have to wait until Oracle has backported any attractive features. The 
community can make some differences since we have some very experienced experts like you and others
 from other companies beside Oracle who can provide very good advices. 

> - 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?
I have done the initial analysis and code merge. There are few dependences which are quite safe.
But we need G1 team's review after maintainer's pre-approval.

> - 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?
This answer still needs the G1 team's review after pre-approval. BTW, the main feature is 
guarded by a seperate option G1PeriodicGCInterval and won't affect the default flow.

> A question for you. Do you believe that there should be a version of
JDK 11 which does not change very much, except for occasional fixes
for remaining bugs?

I'm afaid I don't think so. Actually JDK11u is not so widely used and most of users are still using JDK8u. 
Migrating JDK versions is so painfull to them that most of users will not catch up latest versions for new
 features. An LTS version with evolved updates is always the best choice. To us JDK developers, both JDK11u
 and JDK12u are mature releases. We are trying to merge a mature feature in a mature release to another mature
 release. To most of users, JDK11u seems not mature enough until everybody uses it. If I was the user as I decided
 to take the risk to migrate from JDK8u to JDK11u, why cannot I get more attractive features? I have read some
 mails of your philosophy as a maintainer and I appreciate your thinking:

"One other thing: we must remember that people have a choice. They are
not prisoners to Java. If we withhold backports in order to persuade
them to jump to later JDK releases we're forcing them to do work, and
some of them might just port to some other platform altogether."

Thank Goetz for your insterest and voluntary in this. We Alibaba will surely take the responsibility of maintainence
 as well. Our internal customers already tried this and got very good result. Hope to see your findings in near
future. Beside the feature implementation changeset, there're several dependency changes and bug fixes. Here is
 the initial analysis.
https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002735.html

Thanks,
Liang

------------------------------------------------------------------
From:Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Send Time:2020 Apr. 7 (Tue.) 21:54
To:Rodrigo Bruno <rbruno at gsd.inesc-id.pt>; Andrew Haley <aph at redhat.com>
Cc:jdk-updates-dev <jdk-updates-dev at openjdk.java.net>; rs <rs at jelastic.com>
Subject:RE: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1

Hi, 

I would like to share our point of view as team supplying
the VMs used at SAP (not as maintainer of 11u).

We would appreciate if this change came to 11u.
It reduces the pressure on memory in the default
configuration.  This is an important issue to us.

We like to see SAP software lifted from 8 to 11. Any argument to go 
to 11 helps here. 17 will only be released within 17 months, and until
it finds adoption will take even longer. So improving the performance
of the default configuration of 11 is really helpful.

I understand the stability concerns. We are doing support for 
Java for roughly 15 years now.
But I think this is a rather small change, only a few 100 lines!
http://hg.openjdk.java.net/jdk/jdk/rev/f94c7929a44b
Thus, the risk of this change cannot be compared with 
downporting a whole GC algorithm, the graal compiler or 
similar. We should not be misled by this being a JEP. 
Also, we as part of the 11u maintenance team will take our 
part to address upcoming issues with this change.

Wrt. to testing, we would volunteer to test the required
changes in our infrastructure and push it to SapMachine
before they are brought to the OpenJDK 11u-dev repository.
It could run productive with SapMachine for one update
or so to collect feedback.

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Rodrigo Bruno
> Sent: Tuesday, April 7, 2020 1:42 PM
> To: Andrew Haley <aph at redhat.com>
> Cc: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>; rs
> <rs at jelastic.com>
> Subject: Re: [11u] Backport JEP 346 : Promptly Return Unused Committed
> Memory from G1
> 
> Hi everyone,
> 
> I globally agree with most of the discussion so far.
> 
> Just trying to answer Gil's question on why we want this in JDK11u; I think
> the main reason is that JDK11 is the current LST and the next one is still
> >1year away. IMHO and experience, people in the Java community tend to
> extensively rely on libraries and code that was not developed by
> themselves. A great percentage of this code is not updated regularly to
> keep up with non-LTS JDK releases and trying to move your project to a more
> recent JDK release is a huge headache, especially in large projects with
> 100s of dependencies. I've been in several projects where people are
> reluctant to deploy production code in non-LTS JDKs...
> 
> Andrew also mentioned the problem of testing experimental releases. I
> think
> here this is not a problem since we have two industry companies advocating
> for this patch. Would Alibaba and Jelastic be available to deploy an
> experimental version of JDK11u with this JEP? If so, maybe after a couple
> of months there would be enough convincing evidence that this JEP won't
> break anything significant.
> 
> cheers,
> rodrigo
> 
> 
> Andrew Haley <aph at redhat.com> escreveu no dia terça, 7/04/2020 à(s)
> 12:51:
> 
> > On 4/7/20 11:30 AM, Liang Mao wrote:
> >
> > > 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?
> >
> > I think we should keep talking. As far as I'm concerned this is still
> > a live issue for discussion, but I made my points in
> >
> > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-
> April/002977.html
> >
> > --
> > 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
> >
> >
> 
> --
> rodrigo-bruno.github.io