RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

[Maurizio Cimadamore]

On 28/04/2020 21:44, Maurizio Cimadamore wrote:
>
> On 28/04/2020 19:09, Mandy Chung wrote:
>> On 4/28/20 12:58 AM, forax at univ-mlv.fr wrote:
>>>
>>>
>>>
>>>
>>>         I don't think you need to store all the values into static 
>>> fields, you can directly do a ldc + aaload with the right index 
>>> right where you need it,
>>>
>>>
>>>     I think this is what you are thinking as reported in JDK-8243492:
>>> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8239578/webrev.01-accessor/
>>>
>>>
>>> if the accessors are declared ACC_STATIC, yes !
>>>
>>
>> Thanks for catching this and this way will not be hit JDK-824349.
>>
>> Here is the revised patch:
>> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8239578/webrev.02/
>>
>> Maurizio - do you mind remerge MemoryAccessVarHandleGenerator.java 
>> with webrev.02?
>
> I'll take care of that

Not going down this road, sorry :-)

I've added the changes (see attached patch), and all benchmarks are 
several order of magnitude slower. I think this is mostly caused by the 
fact that the addOffset/multiplyOffset handle are no  longer cached in 
static constants.

While I understand that there might be better ways to generate the code, 
I'd strongly prefer to leave the code as per last iteration. I can't 
honestly see in which way having 3-4 static fields in a synthetic 
VarHandle class is going to hurt (but I can see how much it hurts by not 
having said fields).

Cheers
Maurizio

>
> Maurizio
>
>>
>> thanks
>> Mandy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldcMemaccess.patch
Type: text/x-patch
Size: 8620 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20200429/d2646465/ldcMemaccess.patch>