RFR: 8254693: Add Panama feature to pass heap segments to native code [v2]

[Jorn Vernee]

On Wed, 18 Oct 2023 11:12:43 GMT, Maurizio Cimadamore <mcimadamore at 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