On Thu, 24 Aug 2023 23:55:28 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org>
wrote:
>> src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 695:
>>
>>> 693: * Negative [shiftAmount] shifts right and converts to int if
>>> needed.
>>> 694: */
>>> 695: record ShiftLeft(int shiftAmount, Class<?> type) implements
>>> Binding {
>>
>> Given the situation you are facing, perhaps adding the new binding here is
>> unavoidable. Let's wait to hear from @JornVernee. In the meantime, can you
>> point me to a document which explains this behavior? I'm curious and I'd
>> like to know more :-)
>
> Maybe I'm starting to see it - it's not a special rule, as much as it is a
> consequence of the endianness. E.g. if you have a struct that is 64 + 32
> bytes, you can store the first 64 bytes as a long. Then, there's an issue as
> we have to fill another long, but we have only 32 bits of value. Is it the
> problem that if we just copy the value into the long word "as is" it will be
> stored in the "wrong" 32 bits? So the shift takes care of that, I guess?
If my assumption above is correct, then maybe another way to solve the problem,
would be to, instead of adding a new shift binding, to generalize the VM store
binding we have to allow writing a smaller value into a bigger storage, with an
offset. Correct?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1304982593
