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

[Jaroslav Bachorík]

Hello, see my replies inline below

On Wed, Oct 30, 2019 at 4:59 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.
>

I agree with feature work being mostly rejected for backports. But,
unfortunately, some of the more complex backports are bug fixes for
features already present in JDK 11 but not working correctly. There, the
motivation is only to offer a bug-free experience and not to bring new
features from later releases. Of course, we can specify that only P1 and P2
bugs should be backported etc. But it would be good to know the rules
beforehand such that a backporter does not spend a lot of time preparing
the backport just to have it rejected on the grounds of being too complex
and not critical enough.

Cheers,

-JB-


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