[11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1
maoliang.ml at alibaba-inc.com
Wed Apr 8 05:24:17 UTC 2020
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.
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
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!
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.
> -----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
> 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.
> Andrew Haley <aph at redhat.com> escreveu no dia terça, 7/04/2020 à(s)
> > 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-
> > --
> > 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
More information about the jdk-updates-dev