[foreign] RFR 8222765: Implement foreign memory access through VarHandle

[Maurizio Cimadamore]

Fixed the template:

http://cr.openjdk.java.net/~mcimadamore/panama/8222765_v2/

I'd prefer to address the API issues in follow up issues, as we keep 
going through the API (also with Brian and others).

Cheers
Maurizio

On 19/04/2019 20:07, Jorn Vernee wrote:
> AFAIK it ensures that there is a unique name for the variables used in 
> the macro.
>
> e.g. if t = Byte then $1_Type expands to 
> VAR_HANDLE_BYTE_ARRAY_Byte_Type, as variable name. But, this currently 
> conflicts with the GenerateVarHandleByteArray macro for some types.
>
> Jorn
>
> Maurizio Cimadamore schreef op 2019-04-19 19:55:
>> After a closer look, it seems like the first parameter to the macro is
>> not used. The macro GenerateVarHandleXYZ does, as its first thing:
>>
>> $1_Type := $2
>>
>> And then keeps using $1_Type after that.
>>
>> Maybe the $1 parameter is some remains of older code.
>>
>> Maurizio
>> On 19/04/2019 17:42, Maurizio Cimadamore wrote:
>>
>>> On 19/04/2019 16:46, Jorn Vernee wrote:
>>>
>>>> - In GensrcVarHandles.gmk you seem to have a mistake in the
>>>> generation command:
>>>>
>>>> 274 # List the types to generate source for, with capitalized
>>>> first letter
>>>> 275 VARHANDLES_MEMORY_ADDRESS_TYPES := Byte Short Char Int Long
>>>> Float Double
>>>> 276 $(foreach t, $(VARHANDLES_MEMORY_ADDRESS_TYPES), \
>>>> 277   $(eval $(call
>>>> GenerateVarHandleMemoryAddress,VAR_HANDLE_BYTE_ARRAY_$t,$t)))
>>>>
>>>> You still have to change the name VAR_HANDLE_BYTE_ARRAY_ to
>>>> something else (probably forgotten when copy pasting?)
>>> Good point, I wonder why it  still works??? I'll take another look.
>>> The right classes are definitively generated.