Proposal for back-porting JFR to OpenJDK8u

[Volker Simonis]

On Mon, Dec 10, 2018 at 7:35 PM Andrew Haley <aph at redhat.com> wrote:
>
> On 12/10/18 4:54 PM, Hohensee, Paul wrote:
>
> > Having got that out of the way, how should we proceed with
> > starting work? Maybe one of the Alibaba folks can post a
> > webrev?
>
> It'd be a start.
>
> We need to be very careful about how we plan this. To begin with,
> we need to get our processes, especially testing processes, up to
> speed. We're going to have to work together as a community to
> make sure that we have a good test regime working and some
> experience under our belts before we can even think about pushing
> JFR to mainline jdk8u.
>

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). The staging repository was regularly (not sure if
daily, but at least weekly) synced and merged with its upstream
repository. In the end, we did some more extensive testing on the
staging repo and finally merged it into upstream. This was possible,
because all the new changes in the staging repo complied to the
upstream policy already.

For the s390 port we directly created a staging repository because the
changes have not been that big and especially the shared changes have
been minimal.

Depending on the number and size of the changes I'd therefore propose
to either create two repositories (i.e. a working repo with relaxed
push policy and a stage repo which has the same push policy like
8u-dev) or just one stage repository under
http://hg.openjdk.java.net/jdk8u.

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. If
we want to get started right away, I'd suggest to ask Oracle to create
these repositories for us. Otherwise we'd probably have to wait until
Red Hat officially takes the project leader hat :)

> Also, let's keep in mind that we might decide that JFR is too
> much of a risk to go into stable jdk8u at all.
>
> I'm thinking that this would be a good candidate for a tech
> preview. We do this a fair bit at Red Hat, and it works well. We
> could get AdoptOpenJDK to host some candidate binaries: I expect
> they'd be willing.
>
> In the meantime, we should start reviewing and testing smaller
> and simpler patches for bug fixes. I believe there are some good
> ones from Amazon.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671