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

Andrew Haley aph at redhat.com
Tue Apr 7 10:30:23 UTC 2020


On 4/7/20 10:37 AM, Ruslan Synytsky wrote:

> 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?

Not really. No test plan can ever be perfect for such things, and
simply adding tests makes the test suite run for longer, meaning it
gets run less frequently.

In practice, most of the subtle bugs have been reported in production.
The only effective way to test new major features (AFAIK) would be to
have an experimental release of JDK 11. We'd then put it out and get
people to test it in real applications, then very carefully merge it
back into mainline. The problem with this plan, of course, is that
it's very hard in practice to get people to use experimental releases
in production!

This is the perennial problem with Beta testing, as we all know.

>> 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.

These days I think of little else. I'm sure that's true for many of
us; we all understand this. However, it's a balance of risk and
reward.

I am aware that JDK 11u has many downstream variants, with varying
features. JDK 11u, therefore, has to be the lowest common denominator,
the most conservative baseline.

> 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.

"Performance" is a very broad term. If it's using less memory to get
the same throughput, that's what I call better performance.

The question for us to answer is this: what is JDK 11u for? It's a
maturing piece of software, approaching stability. And how do you
determine that a piece of software is stable? In my opinion, that's
when it's changing very little while meeting the needs of its
users. No surprises, in other words.

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?

-- 
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