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

forax at univ-mlv.fr forax at univ-mlv.fr
Wed Apr 29 21:28:02 UTC 2020



----- Mail original -----
> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> À: "mandy chung" <mandy.chung at oracle.com>, "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Mercredi 29 Avril 2020 03:13:35
> Objet: Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

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

I somehow miss that email,
ok, let's back to the black board :)

Rémi

> 
> Cheers
> Maurizio
> 
>>
>> Maurizio
>>
>>>
>>> thanks
> >> Mandy


More information about the core-libs-dev mailing list