Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u]

[Mario Torre]

On Mon, Feb 17, 2020 at 4:42 PM Claes Redestad
<claes.redestad at oracle.com> wrote:

> Sure, such tools *should* work transparently by upgrading to the latest
> JMC, but there might be any number of such surprises where tools need to
> be altered/updated that is hard to foresee.

Yes, we want to ensure that things are properly tested and keep
working for everybody. Of course, this is difficult for an open source
project and its community, given the nature of the licensing of the
proprietary builds for 8u, so I assume that Oracle keeps working on
JMC upstream and help us ensure that their downstream distribution
keeps working properly. If there's a strong divergency, we will need
to find solutions together, hopefully one that doesn't end up holding
an open source project on a proprietary feature.

> The fragmentation I primarily had in mind is that rather than one JFR
> variant there will now be (at least) two different implementations of
> JFR in various versions of 8u which have any number of subtle
> differences in behavior (different set of events, different default
> settings, etc.). There might also be OpenJDK distros that opt-out of
> building with JFR due concerns about stability, performance, etc...
>
> There is also a more insidious difference in that the backport means the
> code for OpenJDK 8u takes a big step away from the state of the fork of
> OpenJDK 8u Oracle maintains for Oracle JDK 8u.

Well, yeah... I mean... well... I won't discuss on the merit on why
using JFR as an "added value" for the past years in the closed version
did lead to this exact situation, and I won't do that because I'm
extremely grateful to Oracle for JFR and for the fact that they did
the right thing with the JFR release and I stated this in public
multiple times. But this is an unfortunate consequence of not
releasing the tool in time for one of the most popular JDK versions
out there. Eventually if we didn't have JFR and JMC we would have had
our own version of it, and somebody would have proposed to merge them
in the JDK.

Now, given the licensing nature of Oracle JDK I don't think it's a
problem if OpenJDK has JFR as it comes from 11. This is because:

1. Only Oracle customers would know the difference, but if they are
Oracle customers it doesn't matter, they are already using Oracle
2. Oracle JDK will eventually have discrepancy between 11 and 8
anyway, in fact, an 8 with the same infrastructure and events as 11
may help more when migrating from previous versions to later, even in
the closed world universe. This is actually a good thing for Oracle.
3. The Events definition aren't really that different, if you look at
the code in 8u that changed when the merge patch arrived (and also at
the same 11 code where this is even more clear) you see that most of
it is based on the now obsolete logging framework and the event
changes are trivial. Most of the events are generated from XML
descriptions anyway. I don't really think this is a huge matter, and I
always assumed that the logging stuff was introduced in 8 to help back
and forth patching between the proprietary code and the open one.

I consider the issue of having JFR more important than the issue of
what events are around, especially since the JFR file is self
contained and self specified, if an event isn't there, it just isn't
there.

>
> Perhaps a bitter pill to swallow, but I think the players involved need
> to take the steps necessary to upgrade to 11+ and stop demanding
> backports that risk destabilizing 8u
>

I agree, but it's not my call :)

Btw, I'm really not advocating for the backport, but I don't think the
Open vs Closed is an argument for not doing it.

Cheers,
Mario
-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898