Some JVMCI/Graal questions related to AOT

[dean.long at oracle.com]

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
>