Proposal for back-porting JFR to OpenJDK8u

Mario Torre neugens.limasoftware at
Wed Dec 12 13:44:32 UTC 2018

I think the first thing to do would be to post the patch for review, a
shared repository would make the review process a bit more complex I
think, and only makes sense if there is a need to work further on the
patch collectively.

Someone of you has access to cr.openjdk? In that case, posting a
webrev there would make sense.

After that, we can think about filing a bug for the back port, or use
one of the existing ones, I'm not sure what's the best strategy here,
I forward this question to Andrew as he has better judgment on the

Il giorno mer 12 dic 2018 alle ore 14:32 李三红(三红)
<sanhong.lsh at> ha scritto:
> Hi,
> Thanks for all comments, let's concentrate a bit on how should we proceed further with this work.
> Maybe we can consider shared repo(Oracle helps on creating this?) so that Alibaba can post patches and hopefully everybody can collaboratively work on this.
> Thanks!
> Sanhong
> -----邮件原件-----
> 发件人: jdk8u-dev [mailto:jdk8u-dev-bounces at] 代表 Volker Simonis
> 发送时间: 2018年12月11日 22:47
> 收件人: Andrew Haley <aph at>
> 抄送: jdk8u-dev <jdk8u-dev at>
> 主题: Re: Proposal for back-porting JFR to OpenJDK8u
> On Tue, Dec 11, 2018 at 10:59 AM Andrew Haley <aph at> wrote:
> >
> > On 12/11/18 8:34 AM, Volker Simonis wrote:
> >
> > > I think it would be good to have a staging repository for this
> > > purpose. For the PowerPC/AIX port we had a "porting" repository
> > > where we freely committed changes and fixed bugs (without JBS bug
> > > IDs and without the usual review process). After that, when we were
> > > confident that the port is in a good shape, we created a staging
> > > repository. For pushes into the staging repository, we cut the
> > > changes from the "porting" repo into handy pieces, we created JBS
> > > issues for them and reviewed them on the corresponding mailing lists
> > > (e.g. hostspot-dev, core-libs-dev, etc).
> >
> > I see some advantages to doing that, but it'd be too much for us to do
> > to begin with. Let's concentrate for now on the smaller patches and
> > bug fixes that we have to do.
> >
> > > Repositories have to belong to a project but I don't think it makes
> > > sense to create a new project just for the sake of downporting JFR.
> >
> > Indeed not, no.
> >
> > > If we want to get started right away
> >
> > I don't, but we can certainly start thinking about it.
> >
> > I know that substantial feature backports like JFR are exciting and
> > interesting, but that's not the main part of the job. Let's not get
> > too distracted by JFR from the practical business of making jdk8u work
> > well: we're in this for the long haul.
> >
> I totally agree. JFR shouldn't be part of the first community-baked 8u release.
> But creating a new forest under jdk8u shouldn't be too complicated.
> And once it's there, the people interested in the JFR downport can start to work collaboratively on the downport without "disturbing" the main jdk8u work.
> > --
> > Andrew Haley
> > Java Platform Lead Engineer
> > Red Hat UK Ltd. <>
> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

pgp key: PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: - Twitter: @neugens
Proud GNU Classpath developer:

Please, support open standards:

More information about the jdk8u-dev mailing list