Some JVMCI/Graal questions related to AOT
dean.long at oracle.com
dean.long at oracle.com
Thu May 25 22:02:26 UTC 2017
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.
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.
> 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.
More information about the hotspot-compiler-dev