[11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1
Andrew Haley
aph at redhat.com
Thu Apr 9 10:18:17 UTC 2020
On 4/7/20 2:51 PM, Lindenmaier, Goetz wrote:
> 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.
Sure. The issue at base here is that it requires a determination of
what kind of thing JDK 11 is. For example, JDK 8 is a stable,
long-term release; it is clear to me that a change like this would not
be appropriate for JDK 8.
So, when will JDK 11 be a stable, long-term release? By your logic
above, perhaps not until JDK 17 is released, and perhaps not until it
has stabilized for a release cycle. Or perhaps we should think of it
as a sliding scale, where JDK 11 becomes more and more stable over
time, and the back pressure against changes becomes gradually
stronger. But it's very hard to turn that into an understandable, let
alone enforceable, policy.
When I took up the job of project lead, I knew that the pressure to
accept feature backports would be very strong, and that it would take
all of my moral fibre to resist it. I know that, as a group,
developers tend to want features, and so do their managers. But the
more we do that, the more we risk an update crashing services in
production.
Having fixed a few hard-to-find GC bugs, I know that serious problems
can be undetected for years.
Remember this?
https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-June/026193.html
That serious bug languished from 2005 until I fixed it last year. I'm
sure that's not a record, either. It was an example of the kind of
mistake that is made by serious, expert, concurrent GC developers, the
best people in the business. How many mistakes of that kind are there
in the patch we're proposing to back-port? I don't know, and I doubt
that you do either. :-)
--
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
mailing list