On Sat, 27 Sep 2025 15:35:13 GMT, Erik Gahlin <[email protected]> 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
