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

[Claes Redestad]

On 2020-02-17 16:15, Mario Torre wrote:
> On Mon, Feb 17, 2020 at 3:39 PM Claes Redestad
> <claes.redestad at oracle.com> wrote:
>>
>> On 2020-02-14 15:56, Andrew Haley wrote:
>>> With regard to the TLS 1.3 and JFR backports to 8u, unless there is a
>>> substantial risk we must do these because some proprietary Javas have
>>> them and our mission is to make sure that our end users have the
>>> choice of using free software. We don't want our users to be forced
>>> into using proprietary software because our releases are missing some
>>> important features. For that reason, although these backports are more
>>> risky than Shenandoah would be, there is a broad consensus in favour
>>> of them.
>>
>> Except that the OpenJDK 11 implementation of JFR being backported to 8u
>> is in fact not perfectly compatible with JFR as it exists in Oracle JDK
>> 8. Apart from JFR in 11 being a major rewrite of the proprietary version
>> in 8, the set of events is substantially different and the
>> implementation in 11 relied on strong encapsulation to be correct and
>> secure.
>>
>> The JFR in OpenJDK 11 is of course backwards compatible with Oracle's
>> JFR 8, but tools built to deal with Oracle's JFR 8 are likely to not be
>> compatible with the JFR being backported to OpenJDK 8u.
> 
> JMC has been made aware of OpenJDK8u+JFR, and although there are still
> some issues we're fixing now, it works pretty well.
> 
> I don't know other tools that would not work, but it doesn't really
> matter. If a tool doesn't recognise JFR in OpenJDK8u it's not
> different than now where there is no JFR.

Anecdotally I've written tools to extract data from JFR recordings
using the JMC APIs.

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.

> 
>> So rather merely providing a plug-and-play free software alternative to
>> a proprietary solution - which I think is in our common interest going
>> forward - this backport is creating something new entirely that *will*
>> contribute to fragmenting the JDK landscape. And this with a feature
>> that is free software in OpenJDK from 11 and onwards.
> 
> How can a common backport that is fully based on the code currently in
> 11 create fragmentation where in fact there exist an alternative
> proprietary JDK with a different JFR plus a variety of downstream
> distribution that are shipping with some form of support for JFR? We
> aim to cure fragmentation, not make it worse, we don't like
> fragmentation.

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. This is of course
something the OpenJDK updates project is free to ignore, but it
significantly increases risk that critical bug fixes to Oracle's
proprietary fork will not be applicable to OpenJDK 8u and vice versa,
which will lead to more work for everyone, and increase risk that
serious bugs slip through.

On JDK11+ there is no subtle difference in behavior: if you want
something that is interchangeable with proprietary/commercial offerings,
it already exists!

> 
>> My personal opinion is that JFR should NOT be backported to 8u.
> 
> I don't disagree with this, in fact, although I've been working on the
> backport I've made my opinion known that I prefer if this isn't
> backported, even before the backport started I suggested we shouldn't
> do it, but not for the reasons you highlighted. I think the only
> reason why JFR may not be desirable is the high complexity of this
> patch and the areas it touches, with risks of destabilisation of the
> OpenJDK8u. On the other hand, testing done by the aforementioned
> downstream distribution seems to suggest this is relatively safe.
> Having reviewed most of the patches we are backporting I know there's
> subtleties that need to be carefully assessed before we can call it
> done, but it's not necessarily something that we don't want, and
> speaking with a lot of the players involved has convinced me that it
> warrants at least a proper try.

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

/Claes