[jdk17u-dev] RFR: 8266936: Add a finalization JFR event [v2]

[Lindenmaier, Goetz]

Hi,

> > My point is if the event is already being used successfully in an already
> publicly released JDK version _AND_ the changes are trivial enough to be
> able to reason about the correctness, I find an a-priori refusal of backporting
> events a bit heavyhanded.
Another problem is that this obviously does not hold:
You claimed testing would be fine, but there were 
errors that slipped your testing, i.e. this is so complicated
you neither get it right by reasoning nor by testing.

If it was trivial, I would have considered the _substantial benefit_
argument ... but this is not trivial enough.

Best regards,
  Goetz.


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Andrew Haley
> Sent: Tuesday, May 3, 2022 12:49 PM
> To: jdk-updates-dev at openjdk.java.net
> Subject: Re: [jdk17u-dev] RFR: 8266936: Add a finalization JFR event [v2]
> 
> On Mon, 2 May 2022 10:18:55 GMT, Jaroslav Bachorik
> <jbachorik at openjdk.org> wrote:
> 
> >> Backport of https://github.com/openjdk/jdk/pull/4731
> >
> > Jaroslav Bachorik has refreshed the contents of this pull request, and
> previous commits have been removed. The incremental views will show
> differences compared to the previous content of the PR. The pull request
> contains one new commit since the last revision:
> >
> >   Fix the monitor locker incoma
> 
> > My point is if the event is already being used successfully in an already
> publicly released JDK version _AND_ the changes are trivial enough to be
> able to reason about the correctness, I find an a-priori refusal of backporting
> events a bit heavyhanded.
> 
> That's not a valid argument. Updates releases are not for feature
> enhancements.
> Here's what the guidelines say:
> 
> _Fix Approvals
> In general we follow the [common rules for the jdk-updates
> project](http://openjdk.java.net/projects/jdk-updates/approval.html).
> In addition this list, we will consider_
> 
> _Build system improvements, particularly for stability and reproducibility
> Changes necessary to make 17u work on new operating systems and
> hardware_
> 
> _However, if there is an enhancement that provides substantial benefit to
> OpenJDK 17u users and it is of low risk, we will consider it._
> 
> The crucial wording here is _trivial enough_, which this isn't, and _substantial
> benefit_. I think that @egahlin has called this one correctly.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk17u-dev/pull/351