RFR: 8314745: JFR: @StackFilter

[Erik Gahlin]

On Mon, 20 Nov 2023 08:41:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I wonder about how maintainable this is. I assume it would be easy for the code to be refactored and the frames listed in the StackFilter annotation value to get out of date. Are there any options to put an annotation on the methods to be filtered, kinda like what we do with `@Hidden`? I realise this might restrict it to JDK events in java.base initially but it seems more maintainable that having event having a method list that isn't checkable at compile time.

A Hidden annotation on the metod would make the filter more apparent when refactoring, but:

- it will not work if a third-party library sits between the commit method and the invocation by the end-user. For instance, a custom handler in a logging framework.
- a Hidden annotation would need to list event names, or it would be global and remove frames for all events.
- we might want to add other settings for a stack filter, for example, exclude/include native frames or support wildcards, which will not work with a Hidden annotation.
- the current implementation has no performance impact when JFR is not in use. In use, the cost is O(1) for events that are not filtered. It does have a high cost if there are many filters for an event, since we need to step through them for each frame, and a reason we wanted to make the annotation internal first. A more performant implementation can be created before wider use.

I think the maintenance aspect can be mitigated by checking the top frame in the JFR unit tests and perhaps add a comment about filtering where the method is committed. Would that be OK?

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

PR Comment: https://git.openjdk.org/jdk/pull/16726#issuecomment-1819468928