On Mon, 11 Sep 2023 17:27:15 GMT, Mandy Chung <mch...@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
