fast way to infer caller
forax at univ-mlv.fr
forax at univ-mlv.fr
Thu Apr 7 13:37:22 UTC 2022
> From: "Kasper Nielsen" <kasperni at gmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Ceki Gülcü" <ceki at qos.ch>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Sent: Thursday, April 7, 2022 2:42:46 PM
> Subject: Re: fast way to infer caller
> On Thu, 7 Apr 2022 at 13:33, Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:
>> ----- Original Message -----
>> > From: "Kasper Nielsen" < [ mailto:kasperni at gmail.com | kasperni at gmail.com ] >
>> > To: "Ceki Gülcü" < [ mailto:ceki at qos.ch | ceki at qos.ch ] >
>>> Cc: "core-libs-dev" < [ mailto:core-libs-dev at openjdk.java.net |
>> > core-libs-dev at openjdk.java.net ] >
>> > Sent: Thursday, April 7, 2022 1:53:33 PM
>> > Subject: Re: fast way to infer caller
>> >> MethodHandles.lookup().lookupClass() looks very promising except that
>> >> there is no way to specify the depth.
>> >> I am looking for a method to obtain the Nth caller at a cost of around
>> >> 100 to 200 nanoseconds of CPU time. Do you think the JDK could cater
>> >> for this use case?
>> > Hi Ceki,
>> > I don't think you will find the numbers you are looking for with
>> > StackWalker.
>> > Compared to something like Reflection.getCallerClass() which
>> > MethodHandles.lookup() uses.
>> > There is still a very large (>100x) performance gap between the two.
>> > public class StackWalkerPerf {
>> > static final StackWalker sw =
>> > StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE);
>> > @Benchmark
>> > public Class<?> stackWalkerCallerClass() {
>> > return sw.getCallerClass();
>> > }
>> > @Benchmark
>> > public Class<?> reflectionCallerClass() {
>> > return MethodHandles.lookup().lookupClass();
>> > }
>> > }
>> > Benchmark Mode Cnt Score Error Units
>> > StackWalkerPerf.reflectionCallerClass avgt 10 2,927 ± 0,012 ns/op
>> > StackWalkerPerf.stackWalkerCallerClass avgt 10 915,287 ± 9,565 ns/op
>>> The resulting class is not the same, so comparing the performance of two codes
>> > that does not do the same thing is dubious, no ?
> I think it is a fair test. MethodHandles.lookup() is basically just wrapping
> Reflection.getCallerClass(). So if anything
> calling Reflection.getCallerClass() directly would be even faster than calling
> MethodHandles.lookup().lookupClass();
nope, see my previous mail to Ceki, the VM is cheating here if it can inline the call to MethodHandles.lookup().
> /Kasper
Rémi
More information about the core-libs-dev
mailing list