RFR 8238192: Reimplement MemoryAddress memory access handles on top of var handle combinators

[Maurizio Cimadamore]

Though about that too - I'm happy to add that change. I think the 
current behavior of MA::ofLong comes from a time where the understanding 
of the Nothing region, and overlapping with NULL was not as refines as 
it is today.

Maurizio

On 31/01/2020 12:12, Jorn Vernee wrote:
> Hi,
>
> This looks good overall, but when looking at the impl of 
> Utils::longToAddress, I think MemoryAddress.ofLong should just be made 
> to return MemoryAddress.NULL if the passed value is '0'.
>
> Jorn
>
> On 29/01/2020 21:37, Maurizio Cimadamore wrote:
>> Hi,
>> this is another use case for VarHandle combinators - we have added 
>> support for VarHandles whose carrier is a MemoryAddress - but the way 
>> we did this was to spin dedicated var handle classes for this. Since 
>> we now have the ability to adapt VarHandle we no longer need to spin 
>> dedicated code, so we can revert much of the code and implement 
>> MemoryAddress-bearing VarHandles as adapters, on top.
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~mcimadamore/panama/8238192/
>>
>> P.S.
>> I couldn't quite simplify the code as much as I'd have liked - 
>> because we support another kind of combinators in the MemoryHandles 
>> class which take apart an existing memory access handle and 
>> "repackage it" with different coordinates. These combinators will be 
>> eventually superseded by the official VarHandle combinators, so they 
>> will go away in the long term - but for now there is a concern that 
>> removing those combinators might be too soon (given that performances 
>> of an adapter using MemoryAddress::addOffset will be worse than what 
>> we have with MemoryHandles.withOffset).
>>
>> Maurizio
>>