On Wed, 18 Oct 2023 10:48:58 GMT, Jorn Vernee <jver...@openjdk.org> wrote:
>> Good point. I made this benchmark a while ago, before we had the more >> optimized allocate variants > > This had a pretty big impact, actually. Especially on the larger sizes: > > > Benchmark (size) Mode Cnt Score Error Units > CriticalCalls.callNotPinned 100 avgt 30 84.818 � 0.729 ns/op > CriticalCalls.callNotPinned 10000 avgt 30 2966.918 � 39.898 ns/op > CriticalCalls.callNotPinned 1000000 avgt 30 952864.052 � 34996.156 ns/op > CriticalCalls.callPinned 100 avgt 30 30.640 � 0.173 ns/op > CriticalCalls.callPinned 10000 avgt 30 2241.403 � 35.473 ns/op > CriticalCalls.callPinned 1000000 avgt 30 221152.247 � 1697.968 ns/op > CriticalCalls.callRecycled 100 avgt 30 40.205 � 0.458 ns/op > CriticalCalls.callRecycled 10000 avgt 30 2845.316 � 13.331 ns/op > CriticalCalls.callRecycled 1000000 avgt 30 287752.178 � 2322.382 ns/op I also notice that the non pinned variant of the `100` benchmark is slow compared to the others. This might be due to try with resources inhibiting scalarization. I suggest to call Arena::close explicitly in that benchmark and repeat the test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1363689027
