[Zulu-eng] Proposal for back-porting JFR to OpenJDK8u

Fri Feb 8 18:00:47 UTC 2019

Hi Andrey,

Thanks for the patch!

As we discussed during the Committer Workshop I'll be happy to help
coordinate the efforts to integrate this work into 8. I think at this
point the best approach would be to create a separate jdk8u-jfr
repository and proceed from there. We need to be absolutely sure that
when disabled JFR is fully disabled, as in no code path ever touches
JFR.

Then I think we would start with your patch since it support more
platforms, but I would like to add G1 support as in the Alibaba patch.
We then need to discuss about testing, this is most likely something
to do with the AdoptOpenJDK team. Long term maintenance is also of
critical importance, we need to be sure that the patch is alive for
the time a maintainer is leading 8u, so I hope Azul and Alibaba will
contribute fix and help maintaining the port for a reasonable amount
of time.

Andrew, do you think we can have a repository created for this purpose?

Cheers,
Mario

Il giorno ven 8 feb 2019 alle ore 18:39 Andrey Petushkov
<andrey at azul.com> ha scritto:
>
> Dear team!
>
> It happened that in the meanwhile Azul was also working on preparing the backport of JFR to jdk8 codebase. We as well have finished the implementation recently and would like to contribute it to the community. Our approach and platform coverage is a bit different so patches are definitely not the same. One might want to compare and merge somehow to get most of both. We are performing difference analysis but not yet finished. Will update once we have full information.
> The following is different to your approach:
> - We did not add EnableJFR flag, JFR could be used in the same way as in jdk11
> - we have added —enable-jfr parameter to configure script to control inclusion of JFR into binary
> - -XX:+/-LogJFR VM parameter to control JFR logging (analogous to -Xlog:jfr*=info), with -XX:+Verbose acting like -Xlog:jfr*=trace
> - we have removed the “trace*” build files while adding “jfr*” files. We believe such approach makes it easier to backport further jfr fixes from jdk11+
> - we have the following platforms supported: Linux x86, ppc, arm, all in both 32-bit and 64-bit variants. Also Mac and Windows x86 32/64 are supported (Solaris on x86 and sparc have some bugs which are not resolved yet)
> We as well have JFR test suite passed with some limitations coming from missing VM features (we did not add some missing WhiteBox APIs so test coverage is a bit smaller than yours)
> There might be as well difference in data being supported, e.g. Azul implementation does not support G1 memory types, while Alibaba seem to have added missing G1 functionality to get this data
>
> The webrev is at
> http://cr.openjdk.java.net/~apetushkov/jfr8/
> Baseline is 8u202.
> The changes to aarch64- and aarch32-port projects are delta on top of generic hotspot patch.
> Shenandoah GC is not integrated with JFR. BTW, related question to RedHat, I see that aarch64-port/jdk8u repos are stale for ~5 months, and latest update level is u181. Does that mean that OpenJDK aarch64-jdk8u mainline is considered to be hosted in http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ repos (where 8u192 is propagated for some time already)? Just in case I’ve posted integration patches for both repos
>
> Regards,
> Andrey
>
>
> Begin forwarded message:
>
> From: "guangyu.zhu" <guangyu.zhu at aliyun.com>
> Subject: Re: Proposal for back-porting JFR to OpenJDK8u
> Date: January 29, 2019 at 3:41:35 AM PST
> To: "Andrew Haley" <aph at redhat.com>, "Mario Torre" <neugens.limasoftware at gmail.com>, "jdk8u-dev" <jdk8u-dev-bounces at openjdk.java.net>
> Cc: 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>
> Reply-To: guangyu.zhu <guangyu.zhu at aliyun.com>
>
> Hi there,
>
> JFR backport patch has been uploaded to cr.openjdk. Please have a review for the patch.
>
> Webrev:
> http://cr.openjdk.java.net/~luchsh/hs_jfr_cr/
> http://cr.openjdk.java.net/~luchsh/jdk_jfr_cr/
>
> The original patch comes from webrev: http://cr.openjdk.java.net/~mgronlun/JEP328_FlightRecorder/Preview/webrev/index.html . We ported it to jdk8u192-b26 and passed most of the jfr jtreg tests on Linux/x86-64 platform. Some features related to Module, AOT and log level are removed because jdk8 does not support them.
>
> We have added a new option ‘EnableJFR’ to enable or disable the JFR feature. It’s disabled by default. To enable it, you can start java with ‘-XX:+EnableJFR’.  For example:
> java -XX:+EnableJFR -XX:StartFlightRecording=duration=1m,filename=rec.jfr MyApp
>
> When running the jtreg test, please add the extra option '-vmoption:-XX:+EnableJFR'. Otherwise the test case will not execute correctly. Here is an example of running jfr jtreg test:
> make test JTREG_TEST_EXTRA_OPTIONS=-vmoption:-XX:+EnableJFR TEST=jdk_jfr
>
> There is one more thing worth noting, please use jmc version 7.0 or later to open the jfr record file.
>
> Your suggestions and comments are welcome.
>
> Thanks,
> Guangyu Zhu
> ------------------------------------------------------------------
> Sender:李三红(三红) <sanhong.lsh at alibaba-inc.com>
> Sent At:2018 Dec. 17 (Mon.) 21:21
> Recipient:Andrew Haley <aph at redhat.com>; Mario Torre <neugens.limasoftware at gmail.com>
> Cc:jdk8u-dev <jdk8u-dev at openjdk.java.net>
> Subject:Re: Proposal for back-porting JFR to OpenJDK8u
>
> Thanks for comments, we are preparing our internal patches for webrev.
> In the meantime, Martijn/ Andrew mentioned we can use AdoptOpenJDK to produce technical preview build.
> Would like to know this... can Martijn point us some guide somewhere?
>
> Thanks!
> Sanhong
> -----邮件原件-----
> 发件人: Andrew Haley [mailto:aph at redhat.com]
> 发送时间: 2018年12月13日 3:03
> 收件人: Mario Torre <neugens.limasoftware at gmail.com>; 李三红(三红) <sanhong.lsh at alibaba-inc.com>
> 抄送: Volker Simonis <volker.simonis at gmail.com>; jdk8u-dev at openjdk.java.net
> 主题: Re: Proposal for back-porting JFR to OpenJDK8u
>
> On 12/12/18 1:44 PM, Mario Torre wrote:
>
> 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.
>
>
> Yes, exactly. That's the normal process, and it's the best place to start.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
>
>
>
>

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

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/