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

[Jorn Vernee]

On Wed, 14 Sep 2022 17:17:46 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`.

Thanks for the link. John says this:


Thus, Java booleans
in non-Java data structures are by convention represented as
8-bit containers containing either zero (for false) or any non-zero
value (for true).


I think that convinces me.

Though, my first instinct was to say that `segment.get(JAVA_BOOLEAN, 0)` is reading a Java boolean, therefore the value should be 0 or 1, therefore we normalize it by masking off all the other bits. But, it seems that even Java booleans have different storage conventions depending on the situation :)

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

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