[foreign-memaccess+abi] RFR: 8311594: Avoid GlobalSession liveness check [v2]

[Maurizio Cimadamore]

On Mon, 10 Jul 2023 16:59:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Good point. Something I also realized over the weekend. I had thought bimorphic inlining would save us (and we override other methods such as acquire/release already). But, we have 3 concrete implementation classes of MemorySessionImpl: confined, shared, and global. This blows up inlining it seems, causing a big regression when all three session kinds are used (see [latest push I did](https://github.com/openjdk/panama-foreign/pull/844/commits/f366dc34d590f53f7e792ac6a178f1c6decf7dca)):
>> 
>> 
>> Before:
>> 
>> Benchmark                                              Mode  Cnt  Score    Error  Units
>> LoopOverPollutedSegments.heap_segment_floats_VH        avgt   30  0.311 ±  0.001  ms/op
>> LoopOverPollutedSegments.heap_segment_floats_instance  avgt   30  0.311 ±  0.001  ms/op
>> LoopOverPollutedSegments.heap_segment_ints_VH          avgt   30  0.311 ±  0.001  ms/op
>> LoopOverPollutedSegments.heap_segment_ints_instance    avgt   30  0.311 ±  0.001  ms/op
>> LoopOverPollutedSegments.heap_unsafe                   avgt   30  0.217 ±  0.001  ms/op
>> LoopOverPollutedSegments.native_segment_VH             avgt   30  0.237 ±  0.005  ms/op
>> LoopOverPollutedSegments.native_segment_instance       avgt   30  0.245 ±  0.005  ms/op
>> LoopOverPollutedSegments.native_unsafe                 avgt   30  0.221 ±  0.007  ms/op
>> 
>> After:
>> 
>> Benchmark                                              Mode  Cnt  Score    Error  Units
>> LoopOverPollutedSegments.heap_segment_floats_VH        avgt   30  3.310 ±  0.005  ms/op
>> LoopOverPollutedSegments.heap_segment_floats_instance  avgt   30  3.333 ±  0.004  ms/op
>> LoopOverPollutedSegments.heap_segment_ints_VH          avgt   30  3.305 ±  0.007  ms/op
>> LoopOverPollutedSegments.heap_segment_ints_instance    avgt   30  3.439 ±  0.106  ms/op
>> LoopOverPollutedSegments.heap_unsafe                   avgt   30  0.217 ±  0.001  ms/op
>> LoopOverPollutedSegments.native_segment_VH             avgt   30  3.595 ±  0.043  ms/op
>> LoopOverPollutedSegments.native_segment_instance       avgt   30  3.696 ±  0.006  ms/op
>> LoopOverPollutedSegments.native_unsafe                 avgt   30  0.204 ±  0.001  ms/op
>> 
>> 
>> If I remove the use of one of the other 2 session kinds again (e.g. the shared one), performance is back to normal.
>
> I've also tried another solution which puts an `instanceof` check in the existing `checkValidStateRaw`. This does improve the case with the special `ALL` segment, but it also regresses the polluted case by about just as much it seems.
> 
> I think this is a dead end.

IMHO, the only sane way to add support for this is to have a well-known constant - e.g. MemorySegment::allNative (which should be a restricted factory of course). Then special case this constant w.r.t. bound checks and temporal checks (since there's a well-known constant to compare against, I'm confident that pollution will not rear its ugly head). But that brings in a lot of API questions: for instance, if this segment is unbounded, what happens if you slice (of course one possible answer might be to throw). While we *might* add something like that in the future, I don't think we have enough evidence yet that something like this is really required.

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

PR Review Comment: https://git.openjdk.org/panama-foreign/pull/844#discussion_r1258636859