[foreign-abi] RFR 8232628: foreign-abi usability issues

[Henry Jen]

As I mentioned before, we do need a test about if an MemoryAddress is null or not. So we need with a function or some constant to compare against in public API to avoid using ForeignUnsafe.

The fact we often need to check for null address, I am not sure why we not just have Java null(as it represent nothing), and the only place we need to translate for memory address 0 to Java null and vice versa is at  the ABI level. However, that does assume all address 0 will be ’nothing’ instead of a meaningful address 0.

I recently also encounter a case where a pointer with value 1 is used as a special constant value on mac, What can I do in public API to get this without ForeignUnsafe?

Cheers,
Henry

> On Oct 22, 2019, at 4:50 AM, Jorn Vernee <JORN.VERNEE at ORACLE.COM> wrote:
> 
> Looks good,
> 
> Cheers,
> Jorn
> 
> On 22/10/2019 12:14, Maurizio Cimadamore wrote:
>> P.S.
>> 
>> The changes in DIrectSignatureShuffler are necessary to fix an exception (the current code is trying to call returnBindings when returnsInMemory is set)
>> 
>> Maurizio
>> 
>> On 22/10/2019 11:12, Maurizio Cimadamore wrote:
>>> Whoops - forget the link
>>> 
>>> http://cr.openjdk.java.net/~mcimadamore/panama/8232628/
>>> 
>>> Maurizio
>>> 
>>> On 18/10/2019 18:23, Maurizio Cimadamore wrote:
>>>> Hi,
>>>> as an experiment/test I tried to write a port of libclang which uses the low level MH and VH as a backbone. I discovered few usability issues in foreign-abi, which I tried to resolve with this patch; more specifically:
>>>> 
>>>> - there's no way to get the null address
>>>> - the null address is not stable, so it's hard to test
>>>> 
>>>> For now, I've added a method to ForeignUnsafe - an alternative would be to add a NULL address constant in the MemoryAddress API, but if we do that, we need to make sure that the user can't do anything with it (which means we should probably create a NOTHING memory segment to prevent slicing).
>>>> 
>>>> I'm open to experiment if there's a feeling this might be a better approach (e.g. to avoid relying on ForeignUnsafe too much).
>>>> 
>>>> Maurizio
>>>> 
>>>>