Proposal for back-porting JFR to OpenJDK8u

[David Holmes]

On 8/12/2018 7:54 am, Hohensee, Paul wrote:
> 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.

But note that it is up to each project to choose whether the CSR process 
applies to that project. [1] The new lead for the jdk8u project may or 
may not choose to use the CSR process.

David

[1] 
http://mail.openjdk.java.net/pipermail/gb-discuss/2017-January/000320.html

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