Proposal for back-porting JFR to OpenJDK8u

Daniel D. Daugherty daniel.daugherty at
Fri Dec 7 18:57:23 UTC 2018

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


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

More information about the jdk8u-dev mailing list