[foreign-memaccess+abi] RFR: 8291873: Implement return value normalization in Java [v2]

[Jorn Vernee]

On Thu, 15 Sep 2022 12:40:18 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch moves value normalization code from the downcall stub (where it was hard coded) to Java, and also adds it for upcall arguments where it was missing.
>> 
>> There is a slight change in behavior with this. The previous hard-coded conversion from a native value to Java `boolean` checked if the least significant byte was non-zero, i.e. `boolean result = value & 0xFF != 0`. While the new conversion only looks at the least significant bit, i.e. `boolean result = value & 0b1 != 0`. I think the new behavior is more correct. It means that the Linker will just do the "dumb" thing when mapping anything to `boolean`, and the native representation is really expected to be like a Java `boolean` i.e. only using the least significant bit. On the other hand I think it means that e.g. jextract will have to map the C `bool` as `byte` and then do a non-zero check to convert to `boolean`.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Non-zero byte test

I've implemented the non-zero byte test.

Thinking more on the discussion, the way it makes sense to me to think about is:
- carrier types of layouts determine classification/semantics
- different linker implementations can have different interpretations for the same carrier type
- our current linker implementations, which all target C, choose to interpret `boolean` as having the semantics of `jboolean`
- `jboolean` has non-zero-first-byte-true semantics, so that's what we implement

(On a side note: if we want other semantics in the future for other linkers, we can add an additional bit of steering info to the `Cast` operator)

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

PR: https://git.openjdk.org/panama-foreign/pull/720