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

[Lindenmaier, Goetz]

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