----- Mail original -----
De: "Maurizio Cimadamore" <maurizio.cimadamore@oracle.com> À: "mandy chung" <mandy.chung@oracle.com>, "Remi Forax" <forax@univ-mlv.fr> Cc: "core-libs-dev" <core-libs-dev@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@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