[11u] Discussion: Backporting features and larger fixes for JFR to JDK 11 Update releases

[Ben Evans]

I think that's an excellent summary, Paul.

I'd like to call out what I think is a special case, though. JFR as it
stands in 8 and 11 is pretty good. However it is not
particularly well-suited to containerized environments. Some of the later
JFR features, including the upcoming JEP 349, substantially mitigate this
issue.

Given that we expect 8 and 11 to be around for a long time (and the amount
of 8 and 11 running in containers seems likely to only ramp up over time)
this amount of future-proofing for OpenJDK users makes sense to me. They
aren't super-critical features outside of their use case so we can afford
to take more time and care over them and only release them when we're sure
they're fully baked.

At New Relic, we're already testing the JFR 8 backport and would be happy
to help with other QA efforts for these types of features if it would help.

I'd be in favour of taking these JFR features, but I'm also in favour of a
strictly-worded policy about not accepting extensive feature backports in
general.

Thanks,

Ben

On Wed, Oct 30, 2019 at 5:00 PM Hohensee, Paul <hohensee at amazon.com> wrote:

> I'm generally not in favor of extensive feature backports, especially
> those that require manual modification and prerequisite backports. The
> stability risk is too high. The end game is a stream of prerequisite
> backports that amount to an ad-hoc global upgrade to a later release. The
> result will almost certainly be missing necessary patches. It should also
> be tested to the same degree as the later release, but we (the OpenJDK
> development community) don't have the QA resources/regime to do that. E.g.,
> the reason we're ok with taking Oracle backports en masse is that we depend
> on Oracle's update release development and QA regime to verify their
> stability.
>
> Exceptions to the above are features that already exist in a fork of an
> update release, are supported in production, and are fairly isolated (i.e.,
> are strict extensions and don't modify how existing code works). For 8u,
> examples are JFR, the aarch64 port, and Shenandoah. For 11u, an example is
> Shenandoah. But, once they're upstreamed and stable, upgrading them in a
> major way to be equivalent to later releases is imo ill-advised.
>
> Using the above paradigm, in this particular case I'd likely reject the
> request.
>
> Thanks,
>
> Paul
>
> On 10/30/19, 4:05 AM, "jdk-updates-dev on behalf of Langer, Christoph" <
> jdk-updates-dev-bounces at openjdk.java.net on behalf of
> christoph.langer at sap.com> wrote:
>
>     Dear all,
>
>     Andrew and I have been discussing what we should do regarding incoming
> requests to backport JFR features to JDK 11 Updates.
>
>     For example, there are currently wishes to backport:
>     JDK-8185525: Add JFR event for DictionarySizes [0]
>     JDK-8225797: OldObjectSample event creates unexpected amount of
> checkpoint data [1]
>
>     While the first one introduces a new (probably useful) JFR event, the
> second one makes the existing 'Old Object Sample ' usable at all for memory
> leak analysis.
>
>     Bot have in common that the changes are quite extensive and need
> manual modifications. Especially the latter one also has quite some
> prerequisite changes which ought to be backported as well.
>
>     So, apart from the decision about letting these very bugfixes into
> jdk11u, there's a general question about how to handle incoming JFR related
> backport requests that go beyond simple bugfixes. Shall we rather try to
> pull in more stuff to make the JFR tooling more usable while putting
> stability of JDK updates at higher risk? Or shall we be conservative here
> and rather reject things if in doubt? Any thoughts or comments from the
> community?
>
>     Thanks
>     Christoph
>
>     [0] https://bugs.openjdk.java.net/browse/JDK-8185525
>     [1] https://bugs.openjdk.java.net/browse/JDK-8225797
>
>
>
>