Some JVMCI/Graal questions related to AOT

[dean.long at oracle.com]

OK, it makes sense now :-)

dl


On 5/26/17 10:44 AM, Thomas Wuerthinger wrote:
> Dean,
>
> Those intermediate objects are not actually created when the code is compiled with a compiler supporting escape analysis (e.g., Graal ;)). This pattern is useful for flags that are only set at initialisation time, because it allows to declare those flags as “final".
>
> - thomas
>
>
>> On 26 May 2017, at 00:02, dean.long at oracle.com wrote:
>>
>> I have something mostly working, but I noticed that checkcasts on the appendix object are getting folded away.  Eventually I want to support that, by adding the type as a dependency that AOT can check at runtime, but for this initial phase I'll probably just wrap the object constant in a LoadConstantIndirectlyNode and return that to the parser.
>>
>> I played around with guarding my changes with (EnableJVMCI && !UseJVMCICompiler) via HotSpotVMConfig, but I want more fine-level control over how invokedynamic constant pool slots are resolved and the adapter and appendix types exposed to the parser, so I'm thinking about adding more flags to GraphBuilderConfiguration or even better introducing a new StaticCompilationPlugin.  Does a new plugin sound reasonable? Then I can move the hooks out of HotSpotConstantPool.
>>
>> dl
>>
>> PS - adding new flag fields to GraphBuilderConfiguration looks painful, with all the flags getting passed to the constructor and needing to change all the other withFlag methods.  I'm tempted to rewrite it to use setFlag methods.  I don't see why we need to create intermediate objects just to set fields.
>>
>> On 5/23/17 12:11 PM, dean.long at oracle.com wrote:
>>> Thanks, I'll try that.
>>>
>>> dl
>>>
>>>
>>> On 5/23/17 12:29 AM, Doug Simon wrote:
>>>
>>>>> On 23 May 2017, at 00:41, dean.long at oracle.com wrote:
>>>>>
>>>>> 1) I'm working on "8132547: [AOT] support invokedynamic instructions" and I've hacked up jdk.vm.ci.hotspot.HotSpotConstantPool.java to handle things like the invokedynamic appendix differently.  However, since this will only be used by AOT, I'm thinking I need to put my changes in an AOTHotSpotConstantPool subclass.  My question is, where is a good place to put such as class (which hopefully won't require messing with modules)?
>>>> Depending on the nature of the changes, I suspect they can simply be added to HotSpotConstantPool, guarded by a VM flag exposed by HotSpotVMConfig if necessary. HotSpotConstantPool is currently final and I don't see a natural place for an AOT specific subclass
>>>>
>>>>> 2) How can I tell if a ResolvedJavaType corresponds to a VM anonymous class (Klass::is_anonymous())? I can't rely on getFingerprint() returning 0, because I want fingerprints for anonymous classes.  Is there something existing, or do I need to add something to JVMCI?
>>>> You'd need to add something to JVMCI by exposing the required flags and fields in HotSpotVMConfig.
>>>>
>>>> -Doug