Thoughts on JFR events for reflection usage?

[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 at 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 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/42fefeaa/attachment-0001.htm>