Pointer/Scope API questions

[Maurizio Cimadamore]

On 07/01/2020 13:47, Ty Young wrote:
> On 12/22/19 3:10 PM, Maurizio Cimadamore wrote:
>
>>
>> On 21/12/2019 23:59, Ty Young wrote:
>>> Hi,
>>>
>>>
>>> There are a few questions I'd like to ask after using it for awhile:
>>>
>>>
>>> A. the implementation of equals on Pointers and Scopes... How is it 
>>> implemented? In the case of Pointers, does the scope of which the 
>>> pointer was allocated matter? Is comparing Pointers to a struct of a 
>>> given type as reliable as comparing the structs themselves?
>> Pointer equality just compares the addresses - not the scopes; that 
>> is, if two pointers p1 and p2 point to the same memory location, they 
>> are considered equals. 
>
>
> Is there no way to fix this?

At this point we'd prefer to invest our resources in the foreign memory 
access and foreign abi efforts (and the minimal jextract). The Pointer 
API was an experiment on how a pointer class might have looked like in 
Java - I think it was successful to some extents - but failed in others, 
as discussed other times.

I don't plan we will be changing Pointer equality in the foreign branch 
in the near future.

>
>
>> As to your question about differences w/r/t struct comparison, I 
>> don't think the API support struct comparison.
>
>
> Regardless of whether the API supports it or not, equals is apart of 
> every Object. Maybe an unchecked exception should be thrown?
you mean calling equals() on two struct objects? Well, the default 
behavior will compare just the Java references. I suppose this could be 
enhanced to compare layouts + base pointers - but again, this is not 
something that I think it's worth investing on at this point.
>
>
>>>
>>>
>>> B. Is mixing allocated native types from different scopes and using 
>>> them together safe? Will it result in any weird side affects?
>>
>> You can allocate pointers from different scopes and mix them. The 
>> general rule of thumb (described here [1]) is that you can only write 
>> a pointer p1 into a memory pointed by p2 if p1 is guaranteed to 
>> outlive p2.
>
>
> Thanks for the clarification.
>
>
>>
>>
>>>
>>>
>>> C. What scope are Pointers from C from exactly? The libraries 
>>> specific scope? Are there exceptions like If a function returns a 
>>> Pointer which is derived from function argument Pointer data, is the 
>>> scope the same as the input arguments?
>>
>> Pointers that come from C have the 'unchecked' scope - as such they 
>> are 'unmanaged' pointers. As such you can do whatever you like with 
>> them, as the Panama/foreign branch doesn't restrict use of native 
>> pointers in any way - which also means that it's not easy to make 
>> them safer also (e.g. if you happen to know more about the native 
>> pointer bounds). All the work in the Pointer API predates some of the 
>> discussions on how to make native pointer safer, which we had more 
>> recently.
>
>
> So once Pointer is rebased on the memory access API, you'll be able to 
> get the underlying MemoryAddress from it and do with it as you will?

I cannot guarantee you that Pointer will ever be rebased on top of the 
memory access API. From the experiments we have done working with 
lower-level bindings I can't exactly say that we're missing Pointer much 
- and the fact that Pointer would definitively need at least specialized 
generics to be considered 'good enough' (so that I can say Pointer<int> 
and not Pointer<Integer>) is a big impediment.

It will be up to custom extractors to decide how to model pointers - the 
minimal one will just model them as MemoryAddress. Clients will of 
course be free to use the jextract API to define extensions which will 
wrap MemoryAddress to something more similar to Pointer - but I don't 
see Pointer belonging to the JDK (at least not in the way it currently 
is defined).

Maurizio

>
>
>>
>> Maurizio
>>
>> [1] - http://cr.openjdk.java.net/~mcimadamore/panama/scopes.html
>>
>>>
>>>
>>> Thanks for any clarity.
>>>