From doug.simon at oracle.com Wed May 3 16:03:15 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 3 May 2017 18:03:15 +0200 Subject: JVMCI 0.26 released Message-ID: <58BDA5A2-C3D6-4E1F-868A-DFD6BE6E42C3@oracle.com> JVMCI 0.26 includes some new JVMCI API added in the context of https://bugs.openjdk.java.net/browse/JDK-8177845. JVMCI JDK8 binaries will soon be available on OTN[1]. There is no OpenJDK8 based binary as we're still waiting for an openjdk8_121 package to be available in Travis[2]. -Doug [1] http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html [2] https://github.com/travis-ci/travis-ci/issues/6483#issuecomment-278981775 From adinn at redhat.com Thu May 18 09:53:42 2017 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 18 May 2017 10:53:42 +0100 Subject: Working version of AArch64 Address Lowering that uses reg + immediate addresses Message-ID: <37490bf1-fee3-5723-1831-add1cf6920d9@redhat.com> I have just posted a PR for a version of AArch64 Address Lowering that takes into account usage, allowing it to use SCALED_IMMEDIATE (also UNSCALED_IMMEDIATE) addressing. https://github.com/graalvm/graal-core/pull/275 The patch is composed of a series of commits the first two of which pave the way for the implementation. The 2nd commit involves introducing a distinct lowering phase for AArch64 AddressLoweringByUsePhase which is used instead of the usual AddressLoweringPhase. As a consequence the installation of the phase has been factored out into three subclasses of HotSpotSuitesProvider: AArch64HotSpotSuitesProvider AMD64HotSpotSuitesProvider SPARCHotSpotSuitesProvider Achieving that required renaming DefaultSuitesProvider and several of its subclasses that implement SuitesCreator to use Creator instead of Provider. This avoids a name clash over use of AMD64HotSpotSuitesProvider and is the reason for the first commit. The rest of the commits implement AArchAddressLoweringByUse which is used in place of AArchAddressLowering. It extends the interface AddressLoweringByUse defined by AddressLoweringByUsePhase. The code in AArch64AddressNode.generate does not attempt to compute a sensible LIRKind for the AArch64AddressValue. Instead it simply follows the path used by the previous code. This code was and still is broken in that the address kind does not actually reflect the kind of the addressed value. Unfortunately, that caused a catastrophic and horribly opaque problem in the AArch64 code generation. At one specific point the (load address) code was relying on the address kind to identify the transfer size for the associated address access. In the case of a narrow object store the write barrier snippet ended up treating the address of the previous value as a 64 bit word (which turns out to be the LIRKind of almost all addresses and is always the LIRKind of a field access). That error was unimportant when there was no offset to be scaled. However, as soon as I started using scaled displacement addressing the code blew up because it scaled the displacement wrongly. The last commit fixes this by relying on the scaling stored in the address rather than the address LIRKind. This error in computing LIRKind for addresses is, perhaps, a trap lying in wait for the future and might profit from either an overhaul or a redesign. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From doug.simon at oracle.com Thu May 18 10:23:47 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 18 May 2017 12:23:47 +0200 Subject: Working version of AArch64 Address Lowering that uses reg + immediate addresses In-Reply-To: <37490bf1-fee3-5723-1831-add1cf6920d9@redhat.com> References: <37490bf1-fee3-5723-1831-add1cf6920d9@redhat.com> Message-ID: Hi Andrew, Sorry to have to ask you to do this, but as a result of the graal-core+truffle repo consolidation[1] can you please move your PR to https://github.com/graalvm/graal. -Doug [1] http://mail.openjdk.java.net/pipermail/graal-dev/2017-April/004960.html > On 18 May 2017, at 11:53, Andrew Dinn wrote: > > I have just posted a PR for a version of AArch64 Address Lowering that > takes into account usage, allowing it to use SCALED_IMMEDIATE (also > UNSCALED_IMMEDIATE) addressing. > > https://github.com/graalvm/graal-core/pull/275 > > The patch is composed of a series of commits the first two of which pave > the way for the implementation. > > The 2nd commit involves introducing a distinct lowering phase for > AArch64 AddressLoweringByUsePhase which is used instead of the usual > AddressLoweringPhase. > > As a consequence the installation of the phase has been factored out > into three subclasses of HotSpotSuitesProvider: > > AArch64HotSpotSuitesProvider > AMD64HotSpotSuitesProvider > SPARCHotSpotSuitesProvider > > Achieving that required renaming DefaultSuitesProvider and several of > its subclasses that implement SuitesCreator to use Creator instead of > Provider. This avoids a name clash over use of > AMD64HotSpotSuitesProvider and is the reason for the first commit. > > > The rest of the commits implement AArchAddressLoweringByUse which is > used in place of AArchAddressLowering. It extends the interface > AddressLoweringByUse defined by AddressLoweringByUsePhase. > > The code in AArch64AddressNode.generate does not attempt to compute a > sensible LIRKind for the AArch64AddressValue. Instead it simply follows > the path used by the previous code. This code was and still is broken in > that the address kind does not actually reflect the kind of the > addressed value. > > Unfortunately, that caused a catastrophic and horribly opaque problem in > the AArch64 code generation. At one specific point the (load address) > code was relying on the address kind to identify the transfer size for > the associated address access. In the case of a narrow object store the > write barrier snippet ended up treating the address of the previous > value as a 64 bit word (which turns out to be the LIRKind of almost all > addresses and is always the LIRKind of a field access). That error was > unimportant when there was no offset to be scaled. However, as soon as I > started using scaled displacement addressing the code blew up because it > scaled the displacement wrongly. The last commit fixes this by relying > on the scaling stored in the address rather than the address LIRKind. > > This error in computing LIRKind for addresses is, perhaps, a trap lying > in wait for the future and might profit from either an overhaul or a > redesign. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Thu May 18 11:50:11 2017 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 18 May 2017 12:50:11 +0100 Subject: Working version of AArch64 Address Lowering that uses reg + immediate addresses In-Reply-To: References: <37490bf1-fee3-5723-1831-add1cf6920d9@redhat.com> Message-ID: On 18/05/17 11:23, Doug Simon wrote: > Hi Andrew, > > Sorry to have to ask you to do this, but as a result of the > graal-core+truffle repo consolidation[1] can you please move your PR > to https://github.com/graalvm/graal. Sure, no problem. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Thu May 18 16:32:43 2017 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 18 May 2017 17:32:43 +0100 Subject: Working version of AArch64 Address Lowering that uses reg + immediate addresses In-Reply-To: References: <37490bf1-fee3-5723-1831-add1cf6920d9@redhat.com> Message-ID: <2b9bad5c-4b51-9870-67cd-d1373bd67034@redhat.com> Hi Doug, I have reapplied my patches to a clone of the new repo. Unfortunately, I am seeing this error when I try to build . . . /home/adinn/openjdk/graal/graal/compiler/src/org.graalvm.compiler.api.test/src/org/graalvm/compiler/api/test/Graal.java:43: error: cannot find symbol Services.initializeJVMCI(); ^ symbol: method initializeJVMCI() location: class Services . . . 1 error Compiling org.graalvm.compiler.api.test with javac-daemon failed Any helpful hints you can provide? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From doug.simon at oracle.com Thu May 18 17:23:04 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 18 May 2017 19:23:04 +0200 Subject: Working version of AArch64 Address Lowering that uses reg + immediate addresses In-Reply-To: <2b9bad5c-4b51-9870-67cd-d1373bd67034@redhat.com> References: <37490bf1-fee3-5723-1831-add1cf6920d9@redhat.com> <2b9bad5c-4b51-9870-67cd-d1373bd67034@redhat.com> Message-ID: <665103B8-DACB-4665-BBAD-E4C9BE186691@oracle.com> > On 18 May 2017, at 18:32, Andrew Dinn wrote: > > Hi Doug, > > I have reapplied my patches to a clone of the new repo. Unfortunately, I > am seeing this error when I try to build > > . . . > > /home/adinn/openjdk/graal/graal/compiler/src/org.graalvm.compiler.api.test/src/org/graalvm/compiler/api/test/Graal.java:43: > error: cannot find symbol > Services.initializeJVMCI(); > ^ > symbol: method initializeJVMCI() > location: class Services > . . . > 1 error > > Compiling org.graalvm.compiler.api.test with javac-daemon failed > > > Any helpful hints you can provide? This means you aren't using a JDK8 binary with the latest jvmci changes (i.e., jvmci-0.26). You can download these from http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html. -Doug From adinn at redhat.com Fri May 19 08:00:53 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 19 May 2017 09:00:53 +0100 Subject: Working version of AArch64 Address Lowering that uses reg + immediate addresses In-Reply-To: <665103B8-DACB-4665-BBAD-E4C9BE186691@oracle.com> References: <37490bf1-fee3-5723-1831-add1cf6920d9@redhat.com> <2b9bad5c-4b51-9870-67cd-d1373bd67034@redhat.com> <665103B8-DACB-4665-BBAD-E4C9BE186691@oracle.com> Message-ID: On 18/05/17 18:23, Doug Simon wrote: > >> On 18 May 2017, at 18:32, Andrew Dinn wrote: . . >> . Any helpful hints you can provide? > > This means you aren't using a JDK8 binary with the latest jvmci > changes (i.e., jvmci-0.26). You can download these from > http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html. Hmm, well yes. I'm running this on Linux AArch64. So, I can't use a jdk8 binary built for Linux x86_64. When testing the old repo I have actually been building and running using the latest jdk9 built for AArch64. Do I really need to use jdk8? Or is there some way of getting the correct classes when running under jdk9? If necessary, I can build whatever jdk8 image is needed on AArch64 (it looks like it is supposed to work with 8u121?). Would any image I build form the jdk8u tree need supplementing with extra JVMCI classes? If so then can you provide sources or a jar containing the compiled code? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From doug.simon at oracle.com Fri May 19 08:24:07 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 19 May 2017 10:24:07 +0200 Subject: Working version of AArch64 Address Lowering that uses reg + immediate addresses In-Reply-To: References: <37490bf1-fee3-5723-1831-add1cf6920d9@redhat.com> <2b9bad5c-4b51-9870-67cd-d1373bd67034@redhat.com> <665103B8-DACB-4665-BBAD-E4C9BE186691@oracle.com> Message-ID: <968A3B49-A2CB-4F3D-9AAE-0D3F8DEF5E4C@oracle.com> > On 19 May 2017, at 10:00, Andrew Dinn wrote: > > On 18/05/17 18:23, Doug Simon wrote: >> >>> On 18 May 2017, at 18:32, Andrew Dinn wrote: . . >>> . Any helpful hints you can provide? >> >> This means you aren't using a JDK8 binary with the latest jvmci >> changes (i.e., jvmci-0.26). You can download these from >> http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html. > > Hmm, well yes. I'm running this on Linux AArch64. So, I can't use a jdk8 > binary built for Linux x86_64. Ah yes, of course. Sorry for the noise. > When testing the old repo I have actually been building and running > using the latest jdk9 built for AArch64. Do I really need to use jdk8? > Or is there some way of getting the correct classes when running under jdk9? It should work under jdk9 as of 9-ea+168 (which includes https://bugs.openjdk.java.net/browse/JDK-8177845). > If necessary, I can build whatever jdk8 image is needed on AArch64 (it > looks like it is supposed to work with 8u121?). Would any image I build > form the jdk8u tree need supplementing with extra JVMCI classes? If so > then can you provide sources or a jar containing the compiled code? You can avoid this work by using the most recent jdk9 bits. -Doug From dean.long at oracle.com Mon May 22 22:41:02 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 22 May 2017 15:41:02 -0700 Subject: Some JVMCI/Graal questions related to AOT Message-ID: 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)? 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? dl From doug.simon at oracle.com Tue May 23 07:29:30 2017 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 23 May 2017 09:29:30 +0200 Subject: Some JVMCI/Graal questions related to AOT In-Reply-To: References: Message-ID: > 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 From dean.long at oracle.com Tue May 23 19:11:37 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 23 May 2017 12:11:37 -0700 Subject: Some JVMCI/Graal questions related to AOT In-Reply-To: References: Message-ID: <22330f24-9bbe-3055-41e4-35b1f6854fa4@oracle.com> 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 From dean.long at oracle.com Thu May 25 22:02:26 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 25 May 2017 15:02:26 -0700 Subject: Some JVMCI/Graal questions related to AOT In-Reply-To: <22330f24-9bbe-3055-41e4-35b1f6854fa4@oracle.com> References: <22330f24-9bbe-3055-41e4-35b1f6854fa4@oracle.com> Message-ID: <1f1b91ba-2c0f-ddd2-d822-64ca81c554c5@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 > From thomas.wuerthinger at oracle.com Fri May 26 17:44:16 2017 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Fri, 26 May 2017 19:44:16 +0200 Subject: Some JVMCI/Graal questions related to AOT In-Reply-To: <1f1b91ba-2c0f-ddd2-d822-64ca81c554c5@oracle.com> References: <22330f24-9bbe-3055-41e4-35b1f6854fa4@oracle.com> <1f1b91ba-2c0f-ddd2-d822-64ca81c554c5@oracle.com> Message-ID: <2108DEBD-0FE7-4F78-AC4D-52950F8C6D15@oracle.com> 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 >> > From dean.long at oracle.com Fri May 26 20:10:19 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 26 May 2017 13:10:19 -0700 Subject: Some JVMCI/Graal questions related to AOT In-Reply-To: <2108DEBD-0FE7-4F78-AC4D-52950F8C6D15@oracle.com> References: <22330f24-9bbe-3055-41e4-35b1f6854fa4@oracle.com> <1f1b91ba-2c0f-ddd2-d822-64ca81c554c5@oracle.com> <2108DEBD-0FE7-4F78-AC4D-52950F8C6D15@oracle.com> Message-ID: <8ed3398b-84ec-9ae2-95f1-f53902dd6238@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 From srinirao55 at gmail.com Thu May 11 17:54:38 2017 From: srinirao55 at gmail.com (Srini Rao) Date: Thu, 11 May 2017 17:54:38 -0000 Subject: mx build issue Message-ID: Hi Getting this error during build Building HotSpot[product, server]... [C:\Users\SRAO\graal\graal-jvmci-8\build\vs-amd64/compiler2/generated/jvmtifiles/jvmti.h[does not exist] does not exist] Could not find Windows SDK : 'C:\Program Files\Microsoft SDKs\Windows\v7.1\' does not exist Tried changing path setting "MSsdk" in cross_build.bat and it did not work Thanks Srini