Costs of caught exceptions during method handle resolve

[Claes Redestad]

Hi,

We have observed similar issues over the years. In a past life I made a failed attempt at making the VM omit creation of various exceptions when doing speculative lookups:  https://bugs.openjdk.org/browse/JDK-8161588

In the end I dialed things back, pulled of a partial, less intrusive enhancement in the area and moved on: https://bugs.openjdk.org/browse/JDK-8200238

I’d welcome anyone to try and re-attempt a fix to JDK-8161588 - but be aware that this might be a major undertaking with many subtleties and corner cases. I think for many use cases caching results of failed lookups is the sane and reasonable thing to do.

/Claes

9 aug. 2024 kl. 13:15 skrev Jan Bernitt <jaanbernitt at gmail.com>:

Hi everyone!

I recently found a performance issue in my library that goes back to large numbers of exceptions being thrown and caught where the costs are dominated by filling in the stack trace and resolving method handles.

So I investigated ways to avoid causing the exceptions. One of the reasons for the exceptions
was somewhere internally in the method handle resolve. I ended up caching the method handles to avoid this happening over and over again as my library uses method handles all the time :D

As far as I can tell this should be something the JDK can solve differently internally to avoid the cost of throwing and catching the exception which should improve performance of method handles significantly if you use them (including the lookup) in a hot loop. You can find more details here https://github.com/dhis2/json-tree/pull/66

If this is of interest to some feel free to ask for more details.
Also if anyone sees that I am just using methods handles wrong and therefore cause the internal exception please let me know.

Best
Jan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/discuss/attachments/20240813/5579d8a5/attachment.htm>