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

[Hohensee, Paul]

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