[foreign-memaccess+abi] RFR: 8278151: Heap segments should handle alignment constraints in a deterministic fashion [v2]

[Maurizio Cimadamore]

On Thu, 2 Dec 2021 18:04:28 GMT, Radoslaw Smogura <duke at openjdk.java.net> wrote:

>> No problem - this is quite tricky. In general, `skipAlignmentMaskCheck` still does _something_ when accessing native segments (as the max align mask is zero there), but in general you are morally correct in observing that it's less useful than it used to be. My hope is that with the right VM fixes, we can get rid of `skipAlignmentMaskCheck` completely, and simplify all this.
>> 
>> For the records, the difference between unaligned and aligned access is as follows:
>> 
>> 
>> Benchmark                                                Mode  Cnt  Score   Error  Units
>> LoopOverNonConstant.segment_loop_instance                avgt   30  0.229 ? 0.002  ms/op
>> LoopOverNonConstant.segment_loop_instance_aligned        avgt   30  0.335 ? 0.001  ms/op
>> 
>> 
>> It's not terrible, but could of course be better.
>
> Hmm...
> 
> I wonder a bit if this code can be optimized `if (((address | maxAlignMask) & alignmentMask) != 0) {`
> 
> Max `maxAlignMask`, can be 1,2,4 (if I see it correctly) so if `maxAlignMask` `alignmentMask` and will not be correct, than exception will be thrown regardless of address? I wonder if making static check could be more performant as VM move such check before loop, than we could only focus on `address & alignmentMask != 0`. Or something like this.

The max align check is already moved out of the loop (as it only depends on the segment, which is a loop invariant). The problematic check, which is not moved outside the loop is exactly `address & alignmentMask != 0`. That check cannot be hoisted, because `address` is made up of `offset` and the segment base address; the latter is a loop invariant, but the former isn't.

Of course C2 should be able to detect that offset is a function of the loop variable, and prove that the check can never fail - but this pattern is currently not detected (hence JDK-8277850).

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

PR: https://git.openjdk.java.net/panama-foreign/pull/622