Proposal for back-porting JFR to OpenJDK8u

[Andrew Haley]

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

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671