[foreign] Panama EA - August 2019 edition

[Ty Young]

On 8/30/19 12:54 PM, Maurizio Cimadamore wrote:
>
> 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?


Yes.


The function calls for a **char(documented as a string) but there is no 
obvious way to wrap the type returned by allocateCString(Pointer<Byte>) 
into another Pointer(Pointer<Pointer<Byte>>), hence the wasteful code above.


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