On Mon, 17 Jul 2023 11:02:38 GMT, Volker Simonis <simo...@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
