[jdk17u-dev] RFR: 8289524: Add JFR JIT restart event

[Erik Gahlin]

On Thu, 3 Nov 2022 18:06:53 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Having a couple of additional interesting (and not too complex !) events in the latest LTS is not a bad thing but this is my personal impression.  On the other hand I do not care that much, if it is rejected than probably all additional events would be rejected because the others I looked at that were interesting were more complex.
>> Our users will avoid non-LTS releases because of the effort and investment costs , so this means Sept 2023 + probably ~ one more year of testing etc. , until they can consume other interesting JFR events that came in after 17 , quite a long time I think.
>
>> Having a couple of additional interesting (and not too complex !) events in the latest LTS is not a bad thing but this is my personal impression. On the other hand I do not care that much, if it is rejected than probably all additional events would be rejected because the others I looked at that were interesting were more complex.
> 
> I think the bar should be high and there should be a good reason, for example to support new hardware or OS versions. Improve security.  Things that are essential to be able to use the existing JDK release.  I don't see this JFR event fall into that category.

> @egahlin do you have any concrete concerns regarding the safety or risk of this patch? Or would it make the produced JFR output incompatible with JMC or other readers in any way?
> 

I don't know the impact on JMC or other tools consuming JFR data.

To know, one would need to try them out, but any modification of the event metadata, or what is enabled in the default configuration, risks being a problem. 

When backporting events several releases back, it also becomes confusing for JFR API users since the event will be missing in releases between. In this case, JDK 18 and JDK 19.

> If it is just a general concern about downporting practices, I vote for downporting it. As maintainers we have a high interest in keeping 17u stable, but we also need to have tools to analyze problems in the field.

I like to know what problem this event solves? 

If there have been say 3-5 JVM bugs where this event would have resolved them significant faster, I think an argument can be made (and explained to a customer why it was added in a security update). It contributes to stability (faster fixes). On the other hand, adding events to get features 10 months faster into a LTS release doesn't sound like the right reason to me.

-------------

PR: https://git.openjdk.org/jdk17u-dev/pull/853