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

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Dean Long" <dean.long at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "hotspot compiler" <hotspot-compiler-dev at openjdk.java.net>
> Envoyé: Mardi 12 Septembre 2017 21:07:04
> Objet: Re: [10] RFR(L): 8132547: [AOT] support invokedynamic instructions

> Hi Remi,

Hi Dean,

> 
> 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?

A boostrap method can call any functions that does side effects, a BSM is not required to be transparent [1].
By example, a BSM can load some property files on the disk to see the value of a property as a constant (instead of compiling the property file into a .class).
There are other examples where you store the callsites in some runtime data structure to reuse them, control them, etc.

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

The LambdaMetaFactory and the StringConcatFactory BSMs are transparent.
Perhaps for the other BSMs, we need either some command line flags for jaotc (to opt out) or a way to annotate BSMs to say they are NOT transparent or perhaps both.  

Rémi

[1] https://en.wikipedia.org/wiki/Referential_transparency_(computer_science)

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