Thoughts on JFR events for reflection usage?
Hi all! What are your thoughts on an event to record uses of reflection? The event could contain a field for the action being taken (accessing a field, invoking a method, etc). It would be an instant event with a stacktrace. In the case of Quarkus, it's useful to know where and how often reflection is being used so that we know where to focus efforts if we want to reduce reflection usage (for performance reasons and also for compatibility with Native Image). This information is probably helpful in other use cases as well. This is a specific case of the more general problem of method tracing: https://bugs.openjdk.org/browse/JDK-8249859 One potential problem is that if a Java program uses a lot of reflection, the overhead of such an event might be large, if we emit an event for every single usage. To avoid that, this event could be throttled similar to how allocation sampling is done. This would be ok if we want a general picture of reflection usage. And if a user doesn't want to miss any unique accesses, they could set the rate to unlimited. Are there any other foreseeable problems with an event like this? Thanks! Robert Toyonaga
Hi Robert, If it is feasible to perform reflection tracing with a general solution, I believe that would be preferable. I have submitted a JEP for a Method Tracer (not yet public). The plan is to not support interfaces, at least not initially, so something like this would not work: For stack trace: $ java -XX:StartFlightRecording:method-trace=jdk.internal.reflect.FieldAcessor::* For invocation count: $ java -XX:StartFlightRecording:method-invocation=jdk.internal.reflect.FieldAcessor::* A user would need to specify the fully qualified name of all the reflection methods that could be invoked, which are many. I also don't know how easily we could add bytecode instrumentation to reflection classes. There are probably optimizations around reflection that make it difficult. I think the biggest problem is avoiding overhead. A throttling mechanism can lower it, but there will still be a cost, which makes it hard to enable by default. The allocation sampling throttling only happens in the slow path (every TLAB), so it's not an issue. Erik ________________________________ From: hotspot-jfr-dev <hotspot-jfr-dev-retn@openjdk.org> on behalf of Robert Toyonaga <rtoyonag@redhat.com> Sent: Tuesday, July 30, 2024 8:01 PM To: hotspot-jfr-dev@openjdk.org <hotspot-jfr-dev@openjdk.org> Cc: Francesco Nigro <fnigro@redhat.com> Subject: Thoughts on JFR events for reflection usage? Hi all! What are your thoughts on an event to record uses of reflection? The event could contain a field for the action being taken (accessing a field, invoking a method, etc). It would be an instant event with a stacktrace. In the case of Quarkus, it's useful to know where and how often reflection is being used so that we know where to focus efforts if we want to reduce reflection usage (for performance reasons and also for compatibility with Native Image). This information is probably helpful in other use cases as well. This is a specific case of the more general problem of method tracing: https://bugs.openjdk.org/browse/JDK-8249859 One potential problem is that if a Java program uses a lot of reflection, the overhead of such an event might be large, if we emit an event for every single usage. To avoid that, this event could be throttled similar to how allocation sampling is done. This would be ok if we want a general picture of reflection usage. And if a user doesn't want to miss any unique accesses, they could set the rate to unlimited. Are there any other foreseeable problems with an event like this? Thanks! Robert Toyonaga
Hi Erik, Ok waiting to try out the general method tracing solution seems like a good plan. Thanks! Robert On Wed, Jul 31, 2024 at 5:56 AM Erik Gahlin <erik.gahlin@oracle.com> wrote:
Hi Robert,
If it is feasible to perform reflection tracing with a general solution, I believe that would be preferable. I have submitted a JEP for a Method Tracer (not yet public). The plan is to not support interfaces, at least not initially, so something like this would not work:
For stack trace: $ java -XX:StartFlightRecording:method-trace=jdk.internal.reflect.FieldAcessor::*
For invocation count: $ java -XX:StartFlightRecording:method-invocation=jdk.internal.reflect.FieldAcessor::*
A user would need to specify the fully qualified name of all the reflection methods that could be invoked, which are many.
I also don't know how easily we could add bytecode instrumentation to reflection classes. There are probably optimizations around reflection that make it difficult.
I think the biggest problem is avoiding overhead. A throttling mechanism can lower it, but there will still be a cost, which makes it hard to enable by default. The allocation sampling throttling only happens in the slow path (every TLAB), so it's not an issue.
Erik ------------------------------ *From:* hotspot-jfr-dev <hotspot-jfr-dev-retn@openjdk.org> on behalf of Robert Toyonaga <rtoyonag@redhat.com> *Sent:* Tuesday, July 30, 2024 8:01 PM *To:* hotspot-jfr-dev@openjdk.org <hotspot-jfr-dev@openjdk.org> *Cc:* Francesco Nigro <fnigro@redhat.com> *Subject:* Thoughts on JFR events for reflection usage?
Hi all!
What are your thoughts on an event to record uses of reflection? The event could contain a field for the action being taken (accessing a field, invoking a method, etc). It would be an instant event with a stacktrace. In the case of Quarkus, it's useful to know where and how often reflection is being used so that we know where to focus efforts if we want to reduce reflection usage (for performance reasons and also for compatibility with Native Image). This information is probably helpful in other use cases as well.
This is a specific case of the more general problem of method tracing: https://bugs.openjdk.org/browse/JDK-8249859
One potential problem is that if a Java program uses a lot of reflection, the overhead of such an event might be large, if we emit an event for every single usage. To avoid that, this event could be throttled similar to how allocation sampling is done. This would be ok if we want a general picture of reflection usage. And if a user doesn't want to miss any unique accesses, they could set the rate to unlimited.
Are there any other foreseeable problems with an event like this?
Thanks! Robert Toyonaga
participants (2)
-
Erik Gahlin
-
Robert Toyonaga