One motivation for creating StackWalker was to provide equivalent functionality to sun.reflect.Reflection.getCallerClass().

At the time that StackWalker was under development, it was easy to benchmark Reflection.getCallerClass() performance, for comparison.

With Reflection.getCallerClass()'s relocation to jdk.internal.reflect,
more setup is needed to call it, so the benchmark was left out of JDK-8221623.

Reflection.getCallerClass() must now be called from within java.base. One can, for example, create a .class/.jar that calls getCallerClass(), and patch it into java.base using --patch-module.

I ran into complications getting such .class file creation/cleanup and extra VM args to work in JMH. AFAICT, @Setup method(s) happen after JMH forks. So if one tries to create the .class file using @Setup, the .class file will not yet exist at the time that the --patch-module VM arg is processed by @Fork, so the --patch-module doesn't take.

One solution could be to use JMH's OptionsBuilder and Runner to run the benchmark from main(), but I see several downsides to this approach:

* The benchmark class must be launched directly (instead of the standard '-jar benchmarks.jar'. But how user know that ? Also, launching this way won't understand standard JMH configuration options for controlling warmups/iterations/etc.

JMH would still list it with other @Benchmark when running with '-jar benchmarks.jar', but the benchmark wouldn't work, so that would be confusing.