On Wed, 18 Oct 2023 11:12:43 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
>> 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. Not sure... The `callNotPinned` variant is meant as a typical use case where the native segment needs to be allocated. I think TWR belongs in that typical use-case. This is really about measuring the difference between 2 idiomatic code patterns. If non-scalarization is part of one of those patterns, then I think that is something that should be included in the measurement. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1363694139
