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

[Jaroslav Bachorík]

So, if we would happen to agree that having bug fixes backported to JDK
11u, especially for the JFR effort, is a good idea what would be the
preferred backport format?
- minimizing the changes required in the original changeset bug accepting a
potentially big fan-out of prerequisite backports?
- minimizing the number of not directly related backports for the price of
more extensive changes to the original changeset?

Cheers,

-JB-

On Thu, Oct 31, 2019 at 8:46 AM Ben Evans <bevans at newrelic.com> wrote:

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