[11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1
shade at redhat.com
Tue Apr 7 12:20:29 UTC 2020
On 4/7/20 1:42 PM, Rodrigo Bruno wrote:
> 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.
Speaking as someone who does Shenandoah support in downstream JDK 11 for years now, I can tell that
backporting non-trivial JVM/GC features is only sane when you have the component/area developers'
buy-in for *supporting* it in the target release. LTS maintenance is not fire-and-forget kind of deal.
The non-exhaustive list of things that need to be covered:
a) When users of JDK 11 are reporting bugs, somebody needs to take a look at them. Indeed, you need
to have somebody interested in JDK 11 in addition to the latest release;
b) When related bugs in later releases get discovered, somebody needs to track them and backport
them to JDK 11;
c) When follow-up JDK 11 backports with bugfixes come, someone would need to look how to adapt them
properly without breaking stuff;
Unless somebody with relevant G1 development experience steps in and makes the above possible, I'd
be skeptical about backporting G1 features. Knowing the gist of Oracle's release cadence POV, I
don't believe we would get Oracle's G1 team buy-in for this. I cannot say Jelastic is experienced in
this kind of role. I have hopes for Alibaba, but we cannot count on that until they explicitly agree
Bottom-line: it is not about the technical feasibility of the backport and initial testing -- that
one is doable and pretty clear. What happens next is where the problem is.
More information about the jdk-updates-dev