RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v3]

[Alan Bateman]

On Sat, 27 Sep 2025 15:35:13 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> The JFR changes look good, but by adding @jdk.jfr.internal.RemoveFields("duration") to the jdk.jfr.events.FinalFieldMutationEvent class, the event is emitted without a duration, and the threshold setting is not needed in default.jfc and profile.jfc and special handling in TestActiveSettingEvent.java can be avoided. 

Thanks, I wasn't aware of `@RemoveFields` to drop the duration from instant events.

> Is it known whether the top frame of the stack traces originates in the method that mutates the field, or in a JDK internal class?
> 
> There are two ways to control this. The cheapest is to set the stack trace offset in the jdk.jfr.internal.PlatformEventType::determineStackTraceOffset method, but this may not be feasible if the depth depends on how the call reaches the offer method. In those cases, the jdk.jfr.internal.StackFilter annotation can (also) be used on the jdk.jfr.events.FinalFieldMutationEvent class to filter out specific classes. To prevent bit rot, event.getStackTrace().getFrames().getFirst().getMethod().getName() may be checked in the test.

The top frame when recording is 4-5 frames from the API points. It would be too fragile to use the stack depth, esp. with instrumentation injected by tooling, so I'd prefer not use that approach. In addition, one of the API points will record at a different depth to the others so it makes it more awkward.

I'll add `@StackFilter` for now and add a test as you suggested to ensure that the event has the expected top frame. I can also add a test to check that the StackFilter value names methods that exist as it would be too easy to refactor and leave stale values in the filter value. We could potentially add a test that scans all events for this annotation and checks the values as this would be useful to do for all events, not just FinalFieldMutation.

Has there been any discussion about JFR respecting `@Hidden`? There's something a bit uncomfortable with having different filtering mechanisms, Ideally stack traces, JFR events, JVMTI, ... would use the same filters.

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

PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3343664490