RFR(L): 8132547: [AOT] support invokedynamic instructions
dean.long at oracle.com
Tue Sep 12 23:52:39 UTC 2017
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:  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 .
> 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 :-)
>  https://en.wikipedia.org/wiki/Referential_transparency_(computer_science)
>>> ----- 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:  RFR(L): 8132547: [AOT] support invokedynamic instructions
>>>> 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
>>>> 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.
More information about the hotspot-compiler-dev