Proposal for back-porting JFR to OpenJDK8u

Tue Feb 26 13:41:47 UTC 2019

On 26 Feb 2019, at 12:13, Mario Torre <neugens at redhat.com<mailto:neugens at redhat.com>> wrote:

> 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.
We thought that it is a good idea to at watch them, at least to don't miss anything important. And given the number of such fixes happened in last 10 months it looks like having the JFR implementation open-sourced brought significant interest which possibly indicates there were number of bugs which deserve to be fixed

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.
No problem, we can submit additional changes as a separate review requests so community can decide whether and what to take

Regards,
Andrey

Cheers,
Mario

On Tue, Feb 26, 2019 at 10:12 AM Andrey Petushkov <andrey at azul.com<mailto: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<mailto: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><mailto: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><mailto: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><mailto:neugens at redhat.com<mailto:neugens at redhat.com>>>; Andrew Haley <aph at redhat.com<mailto:aph at redhat.com><mailto:aph at redhat.com<mailto:aph at redhat.com>>>; Severin Gehwolf <sgehwolf at redhat.com<mailto:sgehwolf at redhat.com><mailto:sgehwolf at redhat.com<mailto:sgehwolf at redhat.com>>>; Mario Torre <neugens.limasoftware at gmail.com<mailto:neugens.limasoftware at gmail.com><mailto: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><mailto: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><mailto:yumin.qi at gmail.com<mailto:yumin.qi at gmail.com>>>; kingsum.chow <kingsum.chow at gmail.com<mailto:kingsum.chow at gmail.com><mailto: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><mailto: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><mailto:denghui.ddh at antfin.com<mailto:denghui.ddh at antfin.com>>>; guangyu.zhu <guangyu.zhu at aliyun.com<mailto:guangyu.zhu at aliyun.com><mailto: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><mailto: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><mailto: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><mailto: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/><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<https://www.redhat.com/>>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898