Thoughts on JFR events for reflection usage?

[Erik Gahlin]

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 at openjdk.org> on behalf of Robert Toyonaga <rtoyonag at redhat.com>
Sent: Tuesday, July 30, 2024 8:01 PM
To: hotspot-jfr-dev at openjdk.org <hotspot-jfr-dev at openjdk.org>
Cc: Francesco Nigro <fnigro at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-jfr-dev/attachments/20240731/cfb4fd52/attachment.htm>