[foreign] Panama EA - August 2019 edition

[Maurizio Cimadamore]

On 30/08/2019 18:41, Ty Young wrote:
>
> On 8/30/19 12:25 PM, Maurizio Cimadamore wrote:
>>
>> On 30/08/2019 17:59, Ty Young wrote:
>>>
>>> On 8/28/19 5:11 AM, Maurizio Cimadamore wrote:
>>>> I just want to clarify on this point below; the foreign memory 
>>>> access work does not, in any way, hinder the higher level 
>>>> functionalities provided by the foreign API/binder. We arrived at 
>>>> the foreign memory access API because we felt that something low 
>>>> level was missing - e.g. that the high level Pointer API was doing 
>>>> too much at once; and that users not interested in a high-level 
>>>> API, but still wanting to access off-heap data would not be served 
>>>> very well by the Pointer API alone.
>>>>
>>>> So, moving forward you can expect the bulk of the foreign API to be 
>>>> relatively stable (well, it's a prototype, so we might tweak things 
>>>> here and there); what will really change is how this API is 
>>>> _implemented_ - that is, moving forward the foreign API will be 
>>>> built _on top_ of the lower memory access and ABI layers. But 
>>>> high-level use cases using jextract need not to worry about this.
>>>>
>>>> I hope this clarifies better where we'd like to land.
>>>
>>>
>>> Yes, it does greatly. Thanks for clarifying.
>>>
>>>
>>> Speaking of the Pointer API, could a method be added to wrap a 
>>> pointer in another pointer for **char string pointers? AFAIK, the 
>>> only way to do that is:
>>>
>>>
>>> <LIB>.scope().allocate(<LIB>.scope().allocateCString("").type().pointer()); 
>>>
>>>
>>>
>>> ...which gets the Pointer<Pointer<Byte>> type that I need but I'm 
>>> not entirely sure if this is the correct way to go about getting the 
>>> type. Using the layout of a throwaway pointer layout just seems 
>>> wrong and wasteful.
>>
>> If you want to allocate a Pointer<Pointer<Byte>> you can do this:
>>
>>
>> <LIB>.scope().allocate(NativeTypes.UINT8.pointer());
>>
>
> Is the size the same as a C String with that?

When you allocate a C string using allocateCString, you get back a 
Pointer<Byte>; this has an 'address' layout - that is, the size of this 
value is platform dependent, but on x64 platforms you can assume it's 64 
bits.

So, when you have a Pointer<Byte> and call type() on it, as in your 
previous code, you get the pointee layout type - that for 'Byte' (which 
is 8 bits). At which point you are calling pointer() on it, which is 
sending you back to a pointer layout type, with size 64 (again assuming 
we're on x64). So, the outer allocate will allocate 64 bits.

The code I suggested does the same - but without the throwaway allocation.


That said - I think what you really wanted to ask, is another question, 
one that has been raised before: assuming I have a Pointer<Byte> 
representing a C string, how do I get a pointer to that?

Am I correct?

Maurizio

>
>
>>
>> Maurizio
>>
>>
>>>
>>>
>>>>
>>>> Cheers
>>>> Maurizio
>>>>
>>>> On 19/08/2019 10:33, sundararajan.athijegannathan at oracle.com wrote:
>>>>>>
>>>>>> All that said, how close is Panama? Is this foreign memory API 
>>>>>> going to stay going forward or will the project take a major 
>>>>>> shift? I'd *really* like to start putting this to use and am 
>>>>>> willing to make adjustment where needed if minor changes are 
>>>>>> made, but if the entire foreign API is scrapped it isn't worth it.
>>>>>
>>>>>
>>>>> Panama "memory access" ("memaccess" panama-dev branch) API is 
>>>>> expected to become stable first and then other parts of 
>>>>> java.foreign later ("foreign" branch stuff).