Proposal for back-porting JFR to OpenJDK8u

[Hohensee, Paul]

My understand is that CSRs are not only for Java specification changes, but also for behavioral changes. E.g., I needed a CSR for a G1 JMX bugfix, see https://bugs.openjdk.java.net/browse/JDK-8195115 and the corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8196719.

Since backporting JFR will produce different JVM behavior (well, new JVM behavior), I thought it might be necessary. If not, it makes things easier.

Paul

On 12/7/18, 10:58 AM, "Daniel D. Daugherty" <daniel.daugherty at oracle.com> wrote:

    On 12/7/18 1:14 PM, Andrew Haley wrote:
    >> Imo JFR is both a feature and a backport, so it was a bit hazy
    >> how to proceed. The Alibaba folks will know better than me, but
    >> I expect the work won't be a clean backport in the sense
    >> that "normal" backports are. It's really new feature
    >> development in an update release that's based on a feature in
    >> tip.
    > I get that, but JEPs are work. If someone wants to create one for
    > their own reasons I'm not going to stand in their way but I can't
    > see the need for the paperwork.
    >
    >> There are multiple patches involved, starting with the initial
    >> push https://bugs.openjdk.java.net/browse/JDK-8199712, followed
    >> up by various fixes, all of which should be backported too. So
    >> the backport will actually be a series of
    >> backports. Alternatively, the 8199712 backport could include
    >> all the followup patches, but then there would be no formal
    >> record of those patches being backported.
    > I get that too, but I would prefer the whole import to be as
    > correct as we can make it. I'd rather not make it look as though
    > bugs were fixed in the JDK 8 sources. I know there are differing
    > opinions about this, but I'd rather the JDK 8 sources were not
    > cluttered with JFR bug fixes.
    >
    >> Alibaba presumably has a large initial patch that they'd like
    >> to publish as the basis for the backport. Do we manually create
    >> a backport issue for 8199712 and attach it to that and then
    >> work together by exchanging patches? Would a project repo be
    >> more efficient?
    > When we've done big imports in the past (e.g. an entire CPU port)
    > we've done it with a few large patches.
    
    I would think you could list the original bug for the JFR open
    port and all the bug fixes that you knowingly bring along in
    the same changeset. One changeset, multiple bugs listed.
    
    Dan
    
    >
    >> I believe a CSR will also be required, but there's no CSR to
    >> backport.
    > Can you indicate which part of the Java specification will be
    > affected by this?
    >
    >> Perhaps create a backport request for the JEP
    >> https://bugs.openjdk.java.net/browse/JDK-8193393 and get that
    >> approved first? Or, manually create an 8199712 backport issue,
    >> then an associated new CSR, and get the latter approved first?
    > I can't see any overpowering reason that this is any different
    > from any other feature backport, unless there really is a
    > compatibility issue, in which case we really do need a JEP and a
    > CSR. But as far as I know there are no compatibility issues, so I
    > don't know where you're going with this.
    >
    > One other thing: I don't think this should happen soon. We'll
    > be backporting bug fixes first, letting them bake in JDK 8 trunk,
    > and developing our test processes. We should do this gently.
    >