[10] RFR(L): 8132547: [AOT] support invokedynamic instructions

[Dean Long]

Hi Remi,

On 9/11/2017 11:54 PM, Remi Forax wrote:
> Hi Dean,
> Java currently uses invokedynamic in two places, one is for lambda creation, the other is for string concatenation.
> Do you have tested string concatenation ? This patch should help right now because the StringConcatFactory do not uses any anonymous class.

Yes, what gets generated for AOT will be a call to 
MethodHandle.invokeBasic().  If StringConcatFactory was AOT-compiled, 
then we can take advantage of that as pre-compiled code, but not as 
inlined code.  To see an inlined string concatenation more work is required.

> and Java (the language) is not the only one to use invokedynamic, how thing works if the boostrap method requires data that are only available at runtime, data that comes from a dynamic language runtime by example ?

So the bootstrap method is using data other than constantpool 
constants?  Could you give an example?

What we do at compile time is to resolve the constant pool entry, which 
gives us the actual adapter and appendix objects, allowing some folding 
and inlining.  At runtime, we resolve again, and do some sanity checking 
to make sure the compile-time types are compatible with the runtime 
types.  If a dynamic language runtime can break those assumptions, then 
we would probably need to turn off the compile-time speculation and 
compile the code as if the adapter and appendix types were unknown.

dl

> cheers,
> Rémi
>
> ----- Mail original -----
>> De: "Dean Long" <dean.long at oracle.com>
>> À: "hotspot compiler" <hotspot-compiler-dev at openjdk.java.net>
>> Envoyé: Mardi 12 Septembre 2017 04:21:36
>> Objet: [10] RFR(L): 8132547: [AOT] support invokedynamic instructions
>> https://bugs.openjdk.java.net/browse/JDK-8132547
>>
>> http://cr.openjdk.java.net/~dlong/8132547/
>>
>> This enhancement is a first step in supporting invokedynamic
>> instructions in AOT.  Previously, when we saw an invokedynamic
>> instruction, or any anonymous class, we would generate code to bail out
>> and deoptimize.  With this changeset we go a little further and call
>> into the runtime to resolve the dynamic constant pool entry, running the
>> bootstrap method, and returning the adapter method and appendix object.
>> Like class initialization in AOT, we only do this the first time
>> through.  Because AOT double-checks classes using fingerprints and
>> symbolic names, special care was required to handle anonymous class
>> names.  The solution I chose was to name anonymous types with aliases
>> based on their constant pool location ("adapter<classid:cpi>" and
>> appendix<classid:cpi>").
>>
>> Future work is needed to AOT-compile the anonymous classes and/or inline
>> through them, so this change is not expected to affect AOT performance.
>> In my tests I was not able to measure any difference.
>>
>> Upstream Graal changes have already been pushed.  I broke the JVMCI and
>> hotspot changes into separate webrevs.
>>
>> dl