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

[Mandy Chung]

Hi Remi,

Thanks for the feedback.  We can take this off from this review thread 
and roll it into JDK-8230501.

Mandy

On 4/30/20 11:03 AM, forax at univ-mlv.fr wrote:
> Hi Mandy,
> i've taken a look to the code,
> i think it's better to have two methods, one for List and one for Map 
> to avoid to have a bootstrap argument (classDataType) and to have a 
> code more straightforward.
>
> Rémi
>
> ------------------------------------------------------------------------
>
>     *De: *"mandy chung" <mandy.chung at oracle.com>
>     *À: *"Remi Forax" <forax at univ-mlv.fr>, "Jorn Vernee"
>     <jorn.vernee at oracle.com>
>     *Cc: *"Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>,
>     "core-libs-dev" <core-libs-dev at openjdk.java.net>
>     *Envoyé: *Jeudi 30 Avril 2020 01:05:46
>     *Objet: *Re: RFR 8243491: Implementation of Foreign-Memory Access
>     API (Second Incubator)
>
>
>
>     On 4/29/20 2:30 PM, forax at univ-mlv.fr wrote:
>
>             I think the problem with perf might be caused by the fact that while the
>             array is now a constant, the elements are not (the array is mutable
>             after all). For fields you can fix this by using @Stable, but not for CP
>             entries :)
>
>         I think you're right,
>
>
>     Ah, I missed that!
>
>             I think what could work is; rather than ldc'ing the array, and then
>             looking up the values with 'normal' Java code, we could have another
>             dynamic constant that does the the array lookup as well. Then the
>             resolved value is stored in a separate CP slot as a true constant. We
>             probably want to have a bootstrap method in ConstantBootstraps that can
>             do an arbitrary array lookup given an array and an index for that.
>
>
>     FYI.  I'm exploring is `classDataAt` to get a specific
>     element/entry from a class data of immutable List or Map.
>
>     [1]
>     http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8239578/webrev.00/src/java.base/share/classes/java/lang/invoke/MethodHandles.java.frames.html
>
>                 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 agree to keep the code per last iteration.  We can always
>     improve this in the future with performance measurement.
>
>     Mandy
>
>