[11u] RFR: Backport of 8216041: [Event Request] - Deoptimization

[Erik Gahlin]

Hi Yang,

I'm not sure I understand what you mean with an essential JFR event, or how customer can use this event to "estimate their code" in a new architecture that they can't do with a later release, but we like to avoid backporting of events.  Besides bugs introduced by the event itself, it can also lead to unexpected problems in tools/libraries that consume the data.

Thanks
Erik
________________________________
From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> on behalf of Yang Yi <qingfeng.yy at alibaba-inc.com>
Sent: Tuesday, February 23, 2021 3:20 AM
To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-dev at openjdk.java.net <jdk-updates-dev at openjdk.java.net>; Mario Torre <neugens at redhat.com>; Andrew Haley <aph at redhat.com>
Subject: Re: [11u] RFR: Backport of 8216041: [Event Request] - Deoptimization

Hi Christoph,

Thanks for sharing the information, it's really useful, I will withdraw other JFR feature backports. However, as for Deoptimization event, the reason why deoptimization event probably could be considered are as follows:

1. It's actually an essential JFR event rather than a feature/enhancement event
2. There are customers who really need this event to estimate their code on the new architecture.(That's why I did this backport)

Just IMHO, please let me know more inputs :-)

Cheers,
Yang Yi
, I think we could carefully consider it.

,我认为我们可以仔细考虑它。


------------------------------------------------------------------
From:Langer, Christoph <christoph.langer at sap.com>
Send Time:2021 Feb. 23 (Tue.) 06:28
To:"YANG, Yi" <qingfeng.yy at alibaba-inc.com>; jdk-updates-dev at openjdk.java.net <jdk-updates-dev at openjdk.java.net>; Mario Torre <neugens at redhat.com>; Andrew Haley <aph at redhat.com>
Subject:RE: [11u] RFR: Backport of 8216041: [Event Request] - Deoptimization

Hi Yang Yi,

thanks for proposing this backport. I don't have a review, rather a maintainers comment.

There was an earlier discussion regarding JFR feature backports, e.g. additional events. See [0] and its predecessor mails. At the time we were reluctant to accept a proposed JFR event backport and I think it hasn't changed until today.

There was a list compiled by Azul about potentially interesting JFR backports [1] which also contains the Deoptimization event but afterwards nothing happened. Since then I believe only bug fixes for JFR were accepted. I don't know whether we should change that for the Deoptimization event.

Any thoughts by people involved with JFR?

Best regards
Christoph

[0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-December/002276.html
[1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-January/002427.html

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Yang Yi
> Sent: Donnerstag, 18. Februar 2021 06:27
> To: Yang Yi <qingfeng.yy at alibaba-inc.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: [11u] RFR: Backport of 8216041: [Event Request] -
> Deoptimization
>
> Gentle Ping :-)
>  ------------------Original Mail ------------------
> Sender:Yang Yi <qingfeng.yy at alibaba-inc.com>
> Send Date:Sun Feb 7 16:54:52 2021
> Recipients:jdk-updates-dev at openjdk.java.net <jdk-updates-
> dev at openjdk.java.net>
> Subject:[11u] RFR: Backport of 8216041: [Event Request] - Deoptimization
>
> Hi,
>
> Please can I request a review of this webrev for the backport of
> https://bugs.openjdk.java.net/browse/JDK-8216041 ?
>
> Webrev: http://cr.openjdk.java.net/~ddong/yiyang/11u-
> 8216041/webrev.00/
>
> This patch doesn't apply cleanly but is fairly trivial. The signature of
> method `Atomic::cmpxchg` and `register_static_type(jfrTypeManager.cpp)`
> is
> not different comparing to upstream and jdk11u. Simply adjusting the
> argument position and adding extra parameters can solve this problem.
>
> Best,Yang Yi