Re: Proposal for back-porting JFR to OpenJDK8u

Tue Feb 26 11:01:04 UTC 2019

Hi Andrey,

I can understand that you chose Azul's code as the baseline. Please let me know if you need help while merge the listed functions.

Thanks,
Guangyu
------------------------------------------------------------------
Sender:Andrey Petushkov <andrey at azul.com>
Sent At:2019 Feb. 26 (Tue.) 17:12
Recipient:guangyu.zhu <guangyu.zhu at aliyun.com>
Cc:jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net>; yumin qi <yumin.qi at gmail.com>; kingsum.chow <kingsum.chow at gmail.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
Subject:Re: Proposal for back-porting JFR to OpenJDK8u

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