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

[Jorn Vernee]

On Mon, 10 Jul 2023 15:12:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/GlobalSession.java line 74:
>> 
>>> 72:     @ForceInline
>>> 73:     public void checkValidStateRaw() {
>>> 74:         // do nothing, avoid liveness check
>> 
>> This looks ok, although (see comments on MemorySessionImpl::checkValidStateRaw) sometimes having too many versions of this method can cause profile pollution issues (which is why we consolidated the impl at some point). I suggest trying other benchmarks, such as LoopOverPollutedXYZ
>
> 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.

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

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