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

[Dean Long]

Inline comments below...

On 9/12/2017 1:23 PM, forax at univ-mlv.fr wrote:
> ----- 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.

I did try to anticipate a situation like that.  At runtime, we run the 
bootstrap method and check the types of the appendix and adapter method 
using a "fingerprint", which is an md5 of the bytecodes.  The AOT 
library contains the fingerprints that were found at compile time.  If a 
mismatch is detected then we deoptimize the method.

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

That would be a great test case, to see if a non-transparent BSM can get 
past the fingerprint checks already in place.  If so, then I agree we 
need to file a bug and address it.  Perhaps once the code is pushed, you 
could help write such as test case :-)

dl

> 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