RFR: 8311500: StackWalker.getCallerClass() throws UOE if invoked reflectively [v3]
Volker Simonis
simonis at openjdk.org
Fri Jul 14 15:43:12 UTC 2023
On Thu, 13 Jul 2023 19:27:01 GMT, Mandy Chung <mchung at openjdk.org> wrote:
> I wonder if we should move the check to throw UOE if called by caller-sensitive method in Java as a general guidance to implement the runtime in Java if desirable. That means it requires the VM to fill not only the class in the buffer but also need a flag to indicate the method is caller-sensitive or not. It's a tradeoff of the buffer size. The common case for `getCallerClass` is being invoked statically and should find the class from the first batch. Only if it's invoked reflectively and if filtered in the Java, it'll fetch more batches and hence the performance would not be as fast as filtered in VM but I think that's okay since it's uncommon.
>
> Would you have cycle to implement this alternative and determine any performance impact to common cases? Then evaluate this further.
>
> The benchmark is at `test/micro/org/openjdk/bench/java/lang/StackWalkBench.java`.
I'm open to investigate other approaches, but this is a real bug and I'd first like to fix it before thinking about implementation improvements. Notice also, that this issue impacts 17 and 21 as well, so the fix should be easily and quickly downportable. We already have [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447) for performance improvements of `getCallerClass()` (which I'm also working on).
I'd therefore suggest to first fix this and postpone further refactorings and improvements to [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447) or another follow-up issue.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/14773#issuecomment-1636039777
More information about the core-libs-dev
mailing list