RFR: 8285447: StackWalker minimal batch size should be optimized for getCallerClass [v2]

[Mandy Chung]

On Mon, 11 Sep 2023 17:27:15 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Typically it will find the caller class at the second stack frame from the frame of executing `StackWalker::getCallerClass`.   The initial size of the buffer can be changed from 8 to 4 (the top 2 elements are reserved for implementation use).   If it fetches another batch, `getCallerClass` may be invoked via core reflection, so subsequent batches can be increased to a larger size.   This PR also moves the benchmark for `getCallerClass` in its own file because it does not need to test with different depth and can be separated from StackWalkBench.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

> In general looks good. But once you on this, I suggest to add the following additional optimizations:
> 
> * `FrameBuffer.START_POS` is `2` but as far as I can see, currently only the 0th element is reserved for passing a "magic" object passed between the JVM and Java code. So this should be set to `1`.
>    ....
> 
> With these changes you would:
> 
>  * save one more frame for the `getCallerClass()` case

Note that this only affects the number of elements allocated.   `getCallerClass` only walks 2 frames in the first batch regardless of the number of reserved elements.


Benchmark                        Mode  Cnt  Score   Error  Units
CallerClassBench.getCallerClass  avgt   15  0.361 ? 0.003  us/op   // num of reserved elements = 1
CallerClassBench.getCallerClass  avgt   15  0.370 ? 0.009  us/op  // num of reserved elements = 2

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

PR Comment: https://git.openjdk.org/jdk/pull/15642#issuecomment-1714303844