Proposal for back-porting JFR to OpenJDK8u

Mario Torre neugens at redhat.com
Tue Feb 26 11:13:28 UTC 2019


> We are carrying analysis of what following JFR-related code changes to
bring from jdk12+

I don't think we should do that for every new baseline, I think integrating
the platform changes from 11 to 8 is already a really big step, without
endlessly backporting features from every other release down the line.

I also would like to proceed with the current patches before adding more to
the table as this is already a quite difficult patch to properly review and
test without thinking about changes in further releases.

Cheers,
Mario


On Tue, Feb 26, 2019 at 10:12 AM Andrey Petushkov <andrey at azul.com> wrote:

> Hi Guangyu,
>
> So ultimately there are the following things missing in Azul code which
> are present in Alibaba one:
> - thread sampling
> - G1 heap summary and region types
> - biased locking events
> - -XX:+/-EnableJFR run time flag
>
> I'll proceed with integration of thread sampling functionality into Azul's
> baseline. Will update the webrev once finished. We are carrying analysis of
> what following JFR-related code changes to bring from jdk12+ (currently
> have identified ~80 candidate patches) so we think that having code laid
> out in jdk11-ish way will simplify that process. Hence choosing Azul's code
> as a baseline as opposed to other way around.
>
> Thanks,
> Andrey
>
> On 20 Feb 2019, at 14:35, Andrey Petushkov <andrey at azul.com> wrote:
> >
> > Dear Guangyu,
> >
> > On 20 Feb 2019, at 15:44, guangyu.zhu <guangyu.zhu at aliyun.com<mailto:
> guangyu.zhu at aliyun.com>> wrote:
> >
> > Hi Andrey,
> >
> > I'm just coming back from the Spring Festival holiday and sorry for the
> late response. I am very happy that Azul has ported jfr to multiple
> platforms. Are there any further updates to your difference analysis?
> > Not yet, sorry. Was distracted to do some other stuff
> > I quickly studied the patch and found some differences:
> >
> > - Your patch does not support thread sampling, and it looks like some
> code in jfrThreadSampler.cpp is commented out.
> > Absolutely. It's great you have implemented that in absence of threadSMR
> > - Your patch does not support the gc event on g1, Alibaba's patch
> supports g1 events, which you have already mentioned.
> > Not exactly. Azul code supports GC events for G1 however we miss some
> important information, like region types, heap occupancy etc
> > - Alibaba divides the test into two parts. The test relies on the
> hotspot whitebox being moved to the hotspot directory, while Azul saves all
> tests under jdk dircetory and adds the hotspot whitebox to the test library.
> > Right. I'm not sure what's the best way
> >
> > I will spend more time comparing these two patches. Anyway, it seems
> that the jfr patch will enter jdk8u faster than we originally expected.
> > Well, at least some jdk8u incubator repos ;)
> >
> > Regards,
> > Andrey
> >
> > Thanks,
> > Guangyu
> >
> > ------------------------------------------------------------------
> > Sender:Andrey Petushkov <andrey at azul.com<mailto:andrey at azul.com>>
> > Sent At:2019 Feb. 16 (Sat.) 00:41
> > Recipient:Mario Torre <neugens at redhat.com<mailto:neugens at redhat.com>>;
> Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>>; Severin Gehwolf <
> sgehwolf at redhat.com<mailto:sgehwolf at redhat.com>>; Mario Torre <
> neugens.limasoftware at gmail.com<mailto:neugens.limasoftware at gmail.com>>;
> jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net<mailto:
> jdk8u-dev-bounces at openjdk.java.net>>; yumin qi <yumin.qi at gmail.com<mailto:
> yumin.qi at gmail.com>>; kingsum.chow <kingsum.chow at gmail.com<mailto:
> kingsum.chow at gmail.com>>; jdk8u-dev <jdk8u-dev at openjdk.java.net<mailto:
> jdk8u-dev at openjdk.java.net>>; denghui.ddh <denghui.ddh at antfin.com<mailto:
> denghui.ddh at antfin.com>>; guangyu.zhu <guangyu.zhu at aliyun.com<mailto:
> guangyu.zhu at aliyun.com>>
> > Subject:Re: Proposal for back-porting JFR to OpenJDK8u
> >
> > [fixed subject, removed jfr-dev maillist]
> >
> > In the meanwhile I’ve updated webrev with a backports of JDK-8207392
> (JFR profiling for PPC) and shared part of (necessary for the latter)
> JDK-8159284
> >
> > Regards,
> > Andrey
> >
> > On 14 Feb 2019, at 14:20, Mario Torre <neugens at redhat.com<mailto:
> neugens at redhat.com>> wrote:
> >
> >
> >
> > On Tue, Feb 12, 2019 at 12:41 PM Andrew Haley <aph at redhat.com<mailto:
> aph at redhat.com>> wrote:
> > On 2/11/19 1:01 PM, Mario Torre wrote:
> >> On Mon, Feb 11, 2019 at 12:29 PM Severin Gehwolf <sgehwolf at redhat.com
> <mailto:sgehwolf at redhat.com>> wrote:
> >>>
> >>> On Fri, 2019-02-08 at 19:00 +0100, Mario Torre wrote:
> >>>> Andrew, do you think we can have a repository created for this
> >>>> purpose?
> >>>
> >>> At the OpenJDK Committers Workshop a JDK 8u sandbox repository was
> >>> discussed. Perhaps that would fit the bill for this backport in a more
> >>> generic way?  "jfr-8u" branch in a jdk8u-dev/sandbox forest, perhaps?
> >>
> >> My understanding was that this was dismissed, but I'm happy either way.
> >>
> >> If we have an agreement on how to call the repository then Andrew will
> >> create one right away.
> >>
> >> Btw, I think the discussion should move to jdk8u-dev alone. I'm not
> >> sure if we will want to coordinate this effort on a separate mailing
> >> list though, what do you think?
> >
> > I think it would be cleaner to have multiple repositories: having to deal
> > with branches make things pointlessly difficult. Maybe we should give
> this
> > some structure with subdirectories, so jdk8u/incubator/jfr. The advantage
> > of this is that a casual visitor is less likely to be confused.
> >
> > I like this proposal, it is future proof as it would make it clear also
> if we ever had to add more of such repositories what they are for.
> >
> > Cheers,
> > Mario
> >
> > --
> > Mario Torre
> > Associate Manager, Software Engineering
> > Red Hat GmbH <https://www.redhat.com<https://www.redhat.com/>>
> > 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
> >
> >
> >
>
>

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


More information about the jdk8u-dev mailing list