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

Tue Mar 2 05:10:52 UTC 2021

Hi Yang,

> I mean, deoptimization is an important mechanism of VM, so deoptimization is also an important event. However, there are no quantitative indicators to measure what is "important". Given some JFR events like GCReferenceStatistics, G1MMU, G1GarbageCollection, OldGarbageCollection, I would like to say that G1GarbageCollection and OldGarbageCollection are more important than GCReferenceStatistics and G1MMU .

About 15 events have been added between JDK 11 and JDK 17, several of them more important than the Deoptimization event (in my opinion).

If we start adding events/features, it's likely to lead to issues at some point.

> Our customer has an application that uses code generation, the generated code contains many if statements that might cause unstable_if deoptimization, and the generated code shows a significant performance degradation. They hope to continuously monitor what is causing the performance degradation of the generated code, so they need to monitor some indicators like full gc, deoptimize, etc.

It doesn't seem like a very common use case. It has to weighted against all the people who will not benefit from the event. You can always run on a more recent JDK release if you want to get the information.

It's important to build confidence in the technology, so users are not hesitant to use JFR on production servers. If a bug is introduced in a security upgrade, users may decide to remove -XX:StartFlightRecording going forward. It would be unfortunate.

Thanks
Erik
________________________________
From: Yang Yi <qingfeng.yy at alibaba-inc.com>
Sent: Wednesday, February 24, 2021 3:45 AM
To: Erik Gahlin <erik.gahlin at oracle.com>; 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: [External] : Re: [11u] RFR: Backport of 8216041: [Event Request] - Deoptimization

Hi Erik,

Let me clarify the previous response and add some content.

> I'm not sure I understand what you mean with an essential JFR event,

I mean, deoptimization is an important mechanism of VM, so deoptimization is also an important event. However, there are no quantitative indicators to measure what is "important". Given some JFR events like GCReferenceStatistics, G1MMU, G1GarbageCollection, OldGarbageCollection, I would like to say that G1GarbageCollection and OldGarbageCollection are more important than GCReferenceStatistics and G1MMU .

> how customer can use this event to "estimate their code" in a new architecture that they can't do with a later release

Our customer has an application that uses code generation, the generated code contains many if statements that might cause unstable_if deoptimization, and the generated code shows a significant performance degradation. They hope to continuously monitor what is causing the performance degradation of the generated code, so they need to monitor some indicators like full gc, deoptimize, etc.
There are advantages and disadvantages to introducing a new event. Whether we are worth backporting is a question that needs broad consideration. If the community believes that the benefits of this backport are less than the risk, I will only backport it in the internal fork.

Thanks,
Yang

------------------------------------------------------------------
From:Erik Gahlin <erik.gahlin at oracle.com>
Send Time:2021 Feb. 24 (Wed.) 01:14
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>; "YANG, Yi" <qingfeng.yy at alibaba-inc.com>
Subject:Re: [11u] RFR: Backport of 8216041: [Event Request] - Deoptimization

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