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

Wed Nov 6 15:35:13 UTC 2019

Hi,

my personal opinion is that we should generally be very careful about backports that are too large and extensive and rather reject them.

As for JFR, however, there's one thing I'd like to put out for consideration: Given that the JDK8 JFR backport will be merged into JDK8 updates soon, we should not have less features in 11 than in 8. If people want to migrate from 8 to 11, their blocker shouldn't be missing features in JFR.

@Jaroslav Bachorík: If you need to bring in a backport of a fix that is very large and could potentially be shrinked or requires quite some dependendy, I guess it's within your personal judgement to propose the most sensible approach. Other reviewers/maintainers might have a different opinion, though, and there could be some discussion needed. We'll see...

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Jaroslav Bachorík
> Sent: Dienstag, 5. November 2019 13:25
> To: Ben Evans <bevans at newrelic.com>
> Cc: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> Subject: [DMARC FAILURE] Re: [11u] Discussion: Backporting features and
> larger fixes for JFR to JDK 11 Update releases
> 
> 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
> > >
> > >
> > >
> > >
> >