RFR: 8311500: StackWalker.getCallerClass() throws UOE if invoked reflectively [v3]

[Mandy Chung]

On Mon, 17 Jul 2023 11:02:38 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed case when calling getCallerClass() from a @CallerSensitive method reflectively
>
> We actually have two problems here:
> 1. If called refelctively, `getCallerClass()` can throw an UOE even if it was **not** called from a `@CallerSensitive` method (see inital test case).
> 2. If called reflectively from a  `@CallerSensitive` method, `getCallerClass()` will currently not throw a UOE as expected (see extended test in this PR).
> 
> `getCallerClass()` **is** performance sensitive and we want to improve its performance rather than slow it down (see [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447)). I think performance-wise it would be better to do all the filtering in the VM, where we have all the required information at hand and minimize the amount of data that needs to be passed between Java and the VM.
> 
> Before starting to implement a new version of the fix which moves all the checks to Java, I'd like to hear some more opinions about whether we agree to move all the filtering and checks from the VM to Java (even at the cost of performance regressions) or if we better want to go the other way and do all the filtering/checks in the JVM. @shipilev, @dholmes-ora, @dfuch, @AlanBateman - what do you think?

@simonis  please see #15370 to show the alternative fix for this issue and do the filtering in Java.  The benchmark shows about 30-60 ns slowdown.  I think it's acceptable with the benefit of keeping the filtering in the libraries rather than in VM.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14773#issuecomment-1686977577