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

[Maurizio Cimadamore]

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`.

I find the change in semantics a bit unsettling. In the VarHandle code we use this normalization:


    private static boolean byteToBoolean(byte b) {
        return b != 0;
    }


In this email [1] @rose00 said that JDK uses either `!= 0` or `&1`, and I think the difference is that the former works with external boolean values (e.g. not in the JVM), whereas the latter can be used when you know that you are dealing with normalized boolean values. In this case, we're dealing with native function, so I believe `!= 0` should be used for normalization (in a way that's consistent with what var handle does).

[1] - https://mail.openjdk.org/pipermail/panama-dev/2021-March/012580.html

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

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