From christian.humer at gmail.com Thu Jan 5 16:49:43 2017 From: christian.humer at gmail.com (Christian Humer) Date: Thu, 05 Jan 2017 16:49:43 +0000 Subject: GraalVM 0.19. release Message-ID: Hi guys, GraalVM 0.19 with the latest bits of Graal, Truffle, Graal.JS, Ruby+Truffle and FastR just landed on OTN. The bits are from early December and based on Truffle 0.21 and LabsJDK 8 with JVMCI 0.23. Get it here: http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html Next release should arrive mid February. Cheers, Christian Humer From adinn at redhat.com Thu Jan 12 12:02:00 2017 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 12 Jan 2017 12:02:00 +0000 Subject: Problem building graal on x86 Message-ID: <76607d23-e5bc-f793-dfb1-1960dd344fb4@redhat.com> I am seeing errors (see after sig for commands and error output) when I try to 'mx build' graal from the git repo on x86. The build JVM is from the latest jdk9-dev tree built by my own fair hand. It seems the truffle repo is missing definitions for various classes such as JavaObjectMessageResolutionForeign ToJavaNodeGen ArrayReadNodeGen etc Have I missed out a generation step which is supposed to provide definitions for these files? 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 $ git clone https://github.com/graalvm/graal-core.git $ cd graal-core $ mx --java-home /path/to/jdk9-dev/build/linux-x86_64-normal-server-release/images/jdk build Cloning https://github.com/graalvm/truffle.git revision 835a4eb7c5155e04c6c6579251616d2be327899b to /home/adinn/redhat/openjdk/graal/truffle with Git Cloning https://github.com/graalvm/truffle.git to /home/adinn/redhat/openjdk/graal/truffle with Git . . . Checking connectivity... done. Compiling com.oracle.mxtool.compilerserver with javac... [/home/adinn/redhat/openjdk/graal/mx/mxbuild/java/com.oracle.mxtool.compilerserver/bin/com/oracle/mxtool/compilerserver/JavacDaemon.class does not exist] warning: [options] bootstrap class path not set in conjunction with -source 1.7 . . . 1 warning /home/adinn/redhat/openjdk/graal/truffle/truffle/com.oracle.truffle.api.interop.java/src/com/oracle/truffle/api/interop/java/JavaObject.java:44: error: cannot find symbol return JavaObjectMessageResolutionForeign.createAccess(); ^ symbol: variable JavaObjectMessageResolutionForeign location: class JavaObject /home/adinn/redhat/openjdk/graal/truffle/truffle/com.oracle.truffle.api.interop.java/src/com/oracle/truffle/api/interop/java/JavaFunctionMessageResolution.java:64: error: cannot find symbol this.toJava[i] = ToJavaNodeGen.create(); ^ symbol: variable ToJavaNodeGen location: class DoExecuteNode /home/adinn/redhat/openjdk/graal/truffle/truffle/com.oracle.truffle.api.interop.java/src/com/oracle/truffle/api/interop/java/JavaFunctionObject.java:47: error: cannot find symbol return JavaFunctionMessageResolutionForeign.createAccess(); ^ symbol: variable JavaFunctionMessageResolutionForeign location: class JavaFunctionObject /home/adinn/redhat/openjdk/graal/truffle/truffle/com.oracle.truffle.api.interop.java/src/com/oracle/truffle/api/interop/java/ToJavaNode.java:158: error: cannot find symbol this.toJava = ToJavaNodeGen.create(); ^ symbol: variable ToJavaNodeGen location: class TemporaryRoot /home/adinn/redhat/openjdk/graal/truffle/truffle/com.oracle.truffle.api.interop.java/src/com/oracle/truffle/api/interop/java/JavaInterop.java:154: error: cannot find symbol RootNode root = new TemporaryConvertRoot(TruffleLanguage.class, ToJavaNodeGen.create(), foreignObject, type); ^ symbol: variable ToJavaNodeGen location: class JavaInterop /home/adinn/redhat/openjdk/graal/truffle/truffle/com.oracle.truffle.api.interop.java/src/com/oracle/truffle/api/interop/java/JavaInterop.java:263: error: cannot find symbol RootNode root = new TemporaryConvertRoot(TruffleLanguage.class, ToJavaNodeGen.create(), function, functionalType); ^ symbol: variable ToJavaNodeGen location: class JavaInterop 1 warning /home/adinn/redhat/openjdk/graal/truffle/truffle/com.oracle.truffle.api.interop.java/src/com/oracle/truffle/api/interop/java/JavaObjectMessageResolution.java:160: error: cannot find symbol @Child private ArrayReadNode read = ArrayReadNodeGen.create(); ^ symbol: variable ArrayReadNodeGen location: class ReadFieldNode /home/adinn/redhat/openjdk/graal/truffle/truffle/com.oracle.truffle.api.interop.java/src/com/oracle/truffle/api/interop/java/JavaObjectMessageResolution.java:187: error: cannot find symbol @Child private ToJavaNode toJava = ToJavaNodeGen.create(); ^ symbol: variable ToJavaNodeGen location: class WriteFieldNode /home/adinn/redhat/openjdk/graal/truffle/truffle/com.oracle.truffle.api.interop.java/src/com/oracle/truffle/api/interop/java/JavaObjectMessageResolution.java:206: error: cannot find symbol @Child private ArrayWriteNode write = ArrayWriteNodeGen.create(); ^ symbol: variable ArrayWriteNodeGen location: class WriteFieldNode 9 errors 1 warning Compiling org.graalvm.compiler.graph with javac-daemon... [dependency GRAAL_OPTIONS_PROCESSOR updated] warning: [options] bootstrap class path not set in conjunction with -source 1.8 1 warning Compiling com.oracle.truffle.api.interop.java with javac-daemon failed 1 build tasks failed $ From doug.simon at oracle.com Thu Jan 12 14:06:38 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 12 Jan 2017 15:06:38 +0100 Subject: Problem building graal on x86 In-Reply-To: <76607d23-e5bc-f793-dfb1-1960dd344fb4@redhat.com> References: <76607d23-e5bc-f793-dfb1-1960dd344fb4@redhat.com> Message-ID: <7118AD2A-1D5E-49C4-82AF-8C0AD8AA4DAE@oracle.com> Hi Andrew, Unfortunately there was a new JDK bug that prevented annotation processors from running: https://bugs.openjdk.java.net/browse/JDK-8172158 Since JDK9 is still under development, we?re bound to run into these issues so the JDK9 EA version Graal works with (currently b143) is more of an exact version requirement as opposed to a minimum version requirement. -Doug > On 12 Jan 2017, at 13:02, Andrew Dinn wrote: > > I am seeing errors (see after sig for commands and error output) when I > try to 'mx build' graal from the git repo on x86. The build JVM is from > the latest jdk9-dev tree built by my own fair hand. > > It seems the truffle repo is missing definitions for various classes such as > > JavaObjectMessageResolutionForeign > ToJavaNodeGen > ArrayReadNodeGen > etc > > Have I missed out a generation step which is supposed to provide > definitions for these files? > > 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 > > > $ git clone https://github.com/graalvm/graal-core.git > $ cd graal-core > $ mx --java-home > /path/to/jdk9-dev/build/linux-x86_64-normal-server-release/images/jdk build > Cloning https://github.com/graalvm/truffle.git revision > 835a4eb7c5155e04c6c6579251616d2be327899b to > /home/adinn/redhat/openjdk/graal/truffle with Git > Cloning https://github.com/graalvm/truffle.git to > /home/adinn/redhat/openjdk/graal/truffle with Git > . . . > Checking connectivity... done. > Compiling com.oracle.mxtool.compilerserver with javac... > [/home/adinn/redhat/openjdk/graal/mx/mxbuild/java/com.oracle.mxtool.compilerserver/bin/com/oracle/mxtool/compilerserver/JavacDaemon.class > does not exist] > warning: [options] bootstrap class path not set in conjunction with > -source 1.7 > . . . > 1 warning > /home/adinn/redhat/openjdk/graal/truffle/truffle/com.oracle.truffle.api.interop.java/src/com/oracle/truffle/api/interop/java/JavaObject.java:44: > error: cannot find symbol > return JavaObjectMessageResolutionForeign.createAccess(); > ^ > symbol: variable JavaObjectMessageResolutionForeign > location: class JavaObject > /home/adinn/redhat/openjdk/graal/truffle/truffle/com.oracle.truffle.api.interop.java/src/com/oracle/truffle/api/interop/java/JavaFunctionMessageResolution.java:64: > error: cannot find symbol > this.toJava[i] = ToJavaNodeGen.create(); > ^ > symbol: variable ToJavaNodeGen > location: class DoExecuteNode > /home/adinn/redhat/openjdk/graal/truffle/truffle/com.oracle.truffle.api.interop.java/src/com/oracle/truffle/api/interop/java/JavaFunctionObject.java:47: > error: cannot find symbol > return JavaFunctionMessageResolutionForeign.createAccess(); > ^ > symbol: variable JavaFunctionMessageResolutionForeign > location: class JavaFunctionObject > /home/adinn/redhat/openjdk/graal/truffle/truffle/com.oracle.truffle.api.interop.java/src/com/oracle/truffle/api/interop/java/ToJavaNode.java:158: > error: cannot find symbol > this.toJava = ToJavaNodeGen.create(); > ^ > symbol: variable ToJavaNodeGen > location: class TemporaryRoot > /home/adinn/redhat/openjdk/graal/truffle/truffle/com.oracle.truffle.api.interop.java/src/com/oracle/truffle/api/interop/java/JavaInterop.java:154: > error: cannot find symbol > RootNode root = new TemporaryConvertRoot(TruffleLanguage.class, > ToJavaNodeGen.create(), foreignObject, type); > ^ > symbol: variable ToJavaNodeGen > location: class JavaInterop > /home/adinn/redhat/openjdk/graal/truffle/truffle/com.oracle.truffle.api.interop.java/src/com/oracle/truffle/api/interop/java/JavaInterop.java:263: > error: cannot find symbol > RootNode root = new TemporaryConvertRoot(TruffleLanguage.class, > ToJavaNodeGen.create(), function, functionalType); > ^ > symbol: variable ToJavaNodeGen > location: class JavaInterop > 1 warning > /home/adinn/redhat/openjdk/graal/truffle/truffle/com.oracle.truffle.api.interop.java/src/com/oracle/truffle/api/interop/java/JavaObjectMessageResolution.java:160: > error: cannot find symbol > @Child private ArrayReadNode read = ArrayReadNodeGen.create(); > ^ > symbol: variable ArrayReadNodeGen > location: class ReadFieldNode > /home/adinn/redhat/openjdk/graal/truffle/truffle/com.oracle.truffle.api.interop.java/src/com/oracle/truffle/api/interop/java/JavaObjectMessageResolution.java:187: > error: cannot find symbol > @Child private ToJavaNode toJava = ToJavaNodeGen.create(); > ^ > symbol: variable ToJavaNodeGen > location: class WriteFieldNode > /home/adinn/redhat/openjdk/graal/truffle/truffle/com.oracle.truffle.api.interop.java/src/com/oracle/truffle/api/interop/java/JavaObjectMessageResolution.java:206: > error: cannot find symbol > @Child private ArrayWriteNode write = ArrayWriteNodeGen.create(); > ^ > symbol: variable ArrayWriteNodeGen > location: class WriteFieldNode > 9 errors > 1 warning > Compiling org.graalvm.compiler.graph with javac-daemon... [dependency > GRAAL_OPTIONS_PROCESSOR updated] > warning: [options] bootstrap class path not set in conjunction with > -source 1.8 > 1 warning > Compiling com.oracle.truffle.api.interop.java with javac-daemon failed > 1 build tasks failed > $ From adinn at redhat.com Thu Jan 12 15:34:07 2017 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 12 Jan 2017 15:34:07 +0000 Subject: Problem building graal on x86 In-Reply-To: <7118AD2A-1D5E-49C4-82AF-8C0AD8AA4DAE@oracle.com> References: <76607d23-e5bc-f793-dfb1-1960dd344fb4@redhat.com> <7118AD2A-1D5E-49C4-82AF-8C0AD8AA4DAE@oracle.com> Message-ID: <055e9a29-6a58-2987-3f4e-4ba50a409cad@redhat.com> Hi Doug, On 12/01/17 14:06, Doug Simon wrote: > Unfortunately there was a new JDK bug that prevented annotation > processors from running: > > https://bugs.openjdk.java.net/browse/JDK-8172158 > > Since JDK9 is still under development, we?re bound to run into these > issues so the JDK9 EA version Graal works with (currently b143) is > more of an exact version requirement as opposed to a minimum version > requirement. Thanks for the tip. I used an jdk9-ea-b148 release I happened to have downloaded last month and the missing classes have now been generated. 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 aph at redhat.com Thu Jan 12 17:06:39 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 12 Jan 2017 17:06:39 +0000 Subject: Problem building graal on x86 In-Reply-To: <7118AD2A-1D5E-49C4-82AF-8C0AD8AA4DAE@oracle.com> References: <76607d23-e5bc-f793-dfb1-1960dd344fb4@redhat.com> <7118AD2A-1D5E-49C4-82AF-8C0AD8AA4DAE@oracle.com> Message-ID: <1d76991b-2773-31a3-90b9-5390c3f08f6d@redhat.com> On 12/01/17 14:06, Doug Simon wrote: > Hi Andrew, > > Unfortunately there was a new JDK bug that prevented annotation processors from running: > > https://bugs.openjdk.java.net/browse/JDK-8172158 > > Since JDK9 is still under development, we?re bound to run into these issues so the JDK9 EA version Graal works with (currently b143) is more of an exact version requirement as opposed to a minimum version requirement. Even with that bug fixed, I get: Uncaught exception at /home/aph/hs/hotspot/src/share/vm/jvmci/jvmciCompiler.cpp:139 java.util.ServiceConfigurationError: jdk.vm.ci.services.JVMCIServiceLocator: Unable to get public provider() method at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:529) at java.base/java.util.ServiceLoader.access$200(ServiceLoader.java:340) at java.base/java.util.ServiceLoader$ProviderImpl.findStaticProviderMethod(ServiceLoader.java:673) at java.base/java.util.ServiceLoader$ProviderImpl.(ServiceLoader.java:617) at java.base/java.util.ServiceLoader$ModuleServicesLookupIterator.next(ServiceLoader.java:987) at java.base/java.util.ServiceLoader$ModuleServicesLookupIterator.next(ServiceLoader.java:895) at java.base/java.util.ServiceLoader$1.next(ServiceLoader.java:1160) at java.base/java.util.ServiceLoader$1.next(ServiceLoader.java:1152) at java.base/java.util.ServiceLoader$2.next(ServiceLoader.java:1257) at jdk.vm.ci/jdk.vm.ci.services.JVMCIServiceLocator.getProviders(JVMCIServiceLocator.java:75) at jdk.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCICompilerConfig.getCompilerFactory(HotSpotJVMCICompilerConfig.java:86) at jdk.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:287) at jdk.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:65) at jdk.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime$DelayedInit.(HotSpotJVMCIRuntime.java:73) at jdk.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:83) at jdk.vm.ci/jdk.vm.ci.runtime.JVMCI.initializeRuntime(Native Method) at jdk.vm.ci/jdk.vm.ci.runtime.JVMCI.(JVMCI.java:58) Caused by: java.lang.IllegalAccessError: superinterface check failed: class org.graalvm.compiler.api.runtime.GraalJVMCICompiler (in module org.graalvm.compiler.graal_core) cannot access class jdk.vm.ci.runtime.JVMCICompiler (in module jdk.vm.ci) because module jdk.vm.ci does not export jdk.vm.ci.runtime to module org.graalvm.compiler.graal_core at java.base/java.lang.ClassLoader.defineClass1(Native Method) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:977) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1054) at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:204) at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:710) at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:631) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:556) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:530) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:186) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:473) at java.base/java.lang.ClassLoader.defineClass1(Native Method) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:977) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1054) at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:204) at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:710) at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:631) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:556) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:530) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:186) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:473) at java.base/java.lang.Class.getDeclaredMethods0(Native Method) at java.base/java.lang.Class.privateGetDeclaredMethods(Class.java:2996) at java.base/java.lang.Class.privateGetMethodRecursive(Class.java:3340) at java.base/java.lang.Class.getMethod0(Class.java:3310) at java.base/java.lang.Class.getMethodOrNull(Class.java:2007) at java.base/java.lang.System$2.getMethodOrNull(System.java:1992) at java.base/java.util.ServiceLoader$ProviderImpl.findStaticProviderMethod(ServiceLoader.java:671) ... 14 more Andrew. From aph at redhat.com Thu Jan 12 17:51:40 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 12 Jan 2017 17:51:40 +0000 Subject: Problem building graal on x86 In-Reply-To: <1d76991b-2773-31a3-90b9-5390c3f08f6d@redhat.com> References: <76607d23-e5bc-f793-dfb1-1960dd344fb4@redhat.com> <7118AD2A-1D5E-49C4-82AF-8C0AD8AA4DAE@oracle.com> <1d76991b-2773-31a3-90b9-5390c3f08f6d@redhat.com> Message-ID: I'm still getting: > Caused by: java.lang.IllegalAccessError: superinterface check failed: class org.graalvm.compiler.api.runtime.GraalJVMCICompiler (in module org.graalvm.compiler.graal_core) cannot access class jdk.vm.ci.runtime.JVMCICompiler (in module jdk.vm.ci) because module jdk.vm.ci does not export jdk.vm.ci.runtime to module org.graalvm.compiler.graal_core even with a b148 build. I'll go back to b143 and see what happens. I guess there's a possibility that I'll have to figure out to fix Jigsaw- caused bugs. Andrew. From doug.simon at oracle.com Thu Jan 12 18:09:46 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 12 Jan 2017 19:09:46 +0100 Subject: Problem building graal on x86 In-Reply-To: References: <76607d23-e5bc-f793-dfb1-1960dd344fb4@redhat.com> <7118AD2A-1D5E-49C4-82AF-8C0AD8AA4DAE@oracle.com> <1d76991b-2773-31a3-90b9-5390c3f08f6d@redhat.com> Message-ID: <7D3C49CE-68BD-42D6-80BD-1438C35F3E82@oracle.com> > On 12 Jan 2017, at 18:51, Andrew Haley wrote: > > I'm still getting: > > >> Caused by: java.lang.IllegalAccessError: superinterface check failed: class org.graalvm.compiler.api.runtime.GraalJVMCICompiler (in module org.graalvm.compiler.graal_core) cannot access class jdk.vm.ci.runtime.JVMCICompiler (in module jdk.vm.ci) because module jdk.vm.ci does not export jdk.vm.ci.runtime to module org.graalvm.compiler.graal_core > > even with a b148 build. > > I'll go back to b143 and see what happens. Sorry, I should have stated the currently supported JDK9 build is b143[1] but was in a workspace where I?m trying to update Graal to support the latest JDK9 bits when I sent the earlier mail. > I guess there's a possibility that I'll have to figure out to fix Jigsaw- > caused bugs. The latest jigsaw refresh has caused quite some issues for Graal compatibility. So unless you have lots of spare time, I?d recommend sticking with b143 and wait until I complete the work mentioned above. -Doug [1] https://github.com/graalvm/graal-core/blob/949f9d4ead04f657232346bb4a3f76c8206c02df/graal/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/JVMCIVersionCheck.java#L43 From aph at redhat.com Thu Jan 12 18:51:54 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 12 Jan 2017 18:51:54 +0000 Subject: Problem building graal on x86 In-Reply-To: <7D3C49CE-68BD-42D6-80BD-1438C35F3E82@oracle.com> References: <76607d23-e5bc-f793-dfb1-1960dd344fb4@redhat.com> <7118AD2A-1D5E-49C4-82AF-8C0AD8AA4DAE@oracle.com> <1d76991b-2773-31a3-90b9-5390c3f08f6d@redhat.com> <7D3C49CE-68BD-42D6-80BD-1438C35F3E82@oracle.com> Message-ID: <52d93b2b-9a0f-f9bc-6662-0bb3f8093c16@redhat.com> On 12/01/17 18:09, Doug Simon wrote: > The latest jigsaw refresh has caused quite some issues for Graal > compatibility. So unless you have lots of spare time, I?d recommend > sticking with b143 and wait until I complete the work mentioned > above. b143 is from before the AArch64 JVMCI changes went in, so no can do that. I can't find any version of OpenJDK which works with the current Graal and works with AArch64. I can't think that I'm going to have any choice but to try to debug the Jigsaw-related bugs. I've tried b148, which Andrew Dinn says works for him on x86, but no luck. Andrew. From adinn at redhat.com Fri Jan 13 13:50:13 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 13 Jan 2017 13:50:13 +0000 Subject: Problem building graal on x86 In-Reply-To: <52d93b2b-9a0f-f9bc-6662-0bb3f8093c16@redhat.com> References: <76607d23-e5bc-f793-dfb1-1960dd344fb4@redhat.com> <7118AD2A-1D5E-49C4-82AF-8C0AD8AA4DAE@oracle.com> <1d76991b-2773-31a3-90b9-5390c3f08f6d@redhat.com> <7D3C49CE-68BD-42D6-80BD-1438C35F3E82@oracle.com> <52d93b2b-9a0f-f9bc-6662-0bb3f8093c16@redhat.com> Message-ID: On 12/01/17 18:51, Andrew Haley wrote: > On 12/01/17 18:09, Doug Simon wrote: > >> The latest jigsaw refresh has caused quite some issues for Graal >> compatibility. So unless you have lots of spare time, I?d recommend >> sticking with b143 and wait until I complete the work mentioned >> above. > > b143 is from before the AArch64 JVMCI changes went in, so no can do > that. > > I can't find any version of OpenJDK which works with the current Graal > and works with AArch64. I can't think that I'm going to have any > choice but to try to debug the Jigsaw-related bugs. I've tried b148, > which Andrew Dinn says works for him on x86, but no luck. I appear to have managed to get past the Jigsaw issues by running with b148 and adding some jigsaw config option to the command line: $ mx --java-home ~/jdk9-b148/j2sdk-image vm -XX:+UseJVMCICompiler -XX:+EnableJVMCI --add-exports jdk.vm.ci/jdk.vm.ci.runtime=org.graalvm.compiler.graal_core --add-opens java.base/jdk.internal.misc=org.graalvm.compiler.graal_core -cp ../../jdk9-dev HelloV This gets past the problems with package access by making package jdk.vm.ci.runtime public accessible for linking to graal_core code (that's the add-exports) and by making package jdk.internal.misc both public accessible for linking and also non-public accessible for reflection (that's the add-opens). With that I hit the following problem: # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (jvmciCodeInstaller_aarch64.cpp:65), pid=26777, tid=26805 # Error: Unimplemented() Of course proceeding beyond this may need a few more -add-exports or --add-opens but this may be all that is needed for now. 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 Jan 13 18:43:17 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 13 Jan 2017 19:43:17 +0100 Subject: Graal now requires jdk-9-ea+152 Message-ID: The recent jigsaw refreshes[1] to JDK 9 introduced backwards incompatible changes that impacted Graal. The major changes include: 1. The keyword for re-exporting dependencies changed[2] from `public` to `transitive`. 2. The signature for ModuleDescriptor.provides() changed[3]. 3. Reflection on non-public fields and methods requires the declaring package to be open to the caller's module[4]. 4. Trailing digits are dropped from the names of automatic modules[5]. Furthermore, a version of Graal has now been integrated into JDK9 as the module named `jdk.vm.compiler`. This complicates developing and deploying github Graal on JDK9 since we need to replace this module at compile and run time with the Graal sources under development. As detailed in JDK-8171448[6], achieving the latter is possible via use of --patch-module and --upgrade-module-path. The only way I've found to compile Graal sources (and Graal test sources) on JDK9 without the builtin jdk.vm.compiler getting in the way is to emulate --strict-compliance mode. As such, I've added support[7] to mx for projects to force this mode by appending `=` to the end of their javaCompliance attribute value (e.g., "javaCompliance" : "1.8=") in suite.py. The Graal changes to address the above issues are now in https://github.com/graalvm/graal-core[8]. After pulling them, you?ll need to download jdk9-ea+152 if you plan to develop Graal on JDK 9. Let?s hope this is the last major jigsaw update ;-) If you run into problems caused by these changes, please file issues at https://github.com/graalvm/graal-core -Doug [1] https://bugs.openjdk.java.net/browse/JDK-8169069, https://bugs.openjdk.java.net/browse/JDK-8170987 [2] http://hg.openjdk.java.net/jdk9/hs/jdk/rev/89ef4b822745#l18.37 [3] http://hg.openjdk.java.net/jdk9/hs/jdk/rev/89ef4b822745#l20.679 [4] http://download.java.net/java/jdk9/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible-boolean- [5] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/000393.html [6] https://bugs.openjdk.java.net/browse/JDK-8171448 [7] https://github.com/graalvm/mx/blob/master/mx.py#L2026 [8] https://github.com/graalvm/graal-core/commit/2e1fc7bcb1a5c02cc47218d9224fbfdc7563f789 From jaroslav.tulach at oracle.com Tue Jan 17 13:44:51 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Tue, 17 Jan 2017 14:44:51 +0100 Subject: FYI: Removing deprecated methods in Source In-Reply-To: <4490168.M3SVbxY2n3@pracovni> References: <4490168.M3SVbxY2n3@pracovni> Message-ID: <3217589.7re0FDunvi@pracovni> Hi guys, we have just removed long time deprecated methods from com.oracle.truffle.api.source package. The changes will be part of of upcoming GraalVM release scheduled for February 2017. Please update your languages and applications to not use these methods[1]. Thanks. -jt [1] There are Jackpot rules for automatic replacement of most of the methods - just open your project in NetBeans and Jackpot hints and fixes (Alt-Enter) shall be done for you. --- sigtest output follows --- Missing Methods --------------- com.oracle.truffle.api.source.Source: method public final com.oracle.truffle.api.source.Source com.oracle.truffle.api.source.Source.withMimeType(java.lang.String) anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.Source: method public final com.oracle.truffle.api.source.SourceSection com.oracle.truffle.api.source.Source.createSection(int,int,int,int) anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.Source: method public final com.oracle.truffle.api.source.SourceSection com.oracle.truffle.api.source.Source.createSection(java.lang.String,int) anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.Source: method public final com.oracle.truffle.api.source.SourceSection com.oracle.truffle.api.source.Source.createSection(java.lang.String,int,int) anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.Source: method public final com.oracle.truffle.api.source.SourceSection com.oracle.truffle.api.source.Source.createSection(java.lang.String,int,int,int) anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.Source: method public final com.oracle.truffle.api.source.SourceSection com.oracle.truffle.api.source.Source.createSection(java.lang.String,int,int,int,int) anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.Source: method public java.lang.String com.oracle.truffle.api.source.Source.getShortName() anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.Source: method public static com.oracle.truffle.api.source.Source com.oracle.truffle.api.source.Source.find(java.lang.String) anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.Source: method public static com.oracle.truffle.api.source.Source com.oracle.truffle.api.source.Source.fromAppendableText(java.lang.String) anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.Source: method public static com.oracle.truffle.api.source.Source com.oracle.truffle.api.source.Source.fromBytes(byte[],int,int,java.lang.String,java.nio.charset.Charset) anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.Source: method public static com.oracle.truffle.api.source.Source com.oracle.truffle.api.source.Source.fromBytes(byte[],java.lang.String,java.nio.charset.Charset) anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.Source: method public static com.oracle.truffle.api.source.Source com.oracle.truffle.api.source.Source.fromFileName(java.lang.CharSequence,java.lang.String) anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.Source: method public static com.oracle.truffle.api.source.Source com.oracle.truffle.api.source.Source.fromFileName(java.lang.String) anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.Source: method public static com.oracle.truffle.api.source.Source com.oracle.truffle.api.source.Source.fromFileName(java.lang.String,boolean) anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.Source: method public static com.oracle.truffle.api.source.Source com.oracle.truffle.api.source.Source.fromNamedAppendableText(java.lang.String) anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.Source: method public static com.oracle.truffle.api.source.Source com.oracle.truffle.api.source.Source.fromNamedText(java.lang.CharSequence,java.lang.String) anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.Source: method public static com.oracle.truffle.api.source.Source com.oracle.truffle.api.source.Source.fromReader(java.io.Reader,java.lang.String) anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.Source: method public static com.oracle.truffle.api.source.Source com.oracle.truffle.api.source.Source.fromText(java.lang.CharSequence,java.lang.String) anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.Source: method public static com.oracle.truffle.api.source.Source com.oracle.truffle.api.source.Source.fromURL(java.net.URL,java.lang.String) anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.Source: method public static com.oracle.truffle.api.source.Source com.oracle.truffle.api.source.Source.subSource(com.oracle.truffle.api.source.Source,int) anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.Source: method public static com.oracle.truffle.api.source.Source com.oracle.truffle.api.source.Source.subSource(com.oracle.truffle.api.source.Source,int,int) anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.Source: method public static void com.oracle.truffle.api.source.Source.setFileCaching(boolean) anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.Source: method public void com.oracle.truffle.api.source.Source.appendCode(java.lang.CharSequence) anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.SourceSection: method public final java.lang.String com.oracle.truffle.api.source.SourceSection.getIdentifier() anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.SourceSection: method public final java.lang.String com.oracle.truffle.api.source.SourceSection.getShortDescription() anno 0 java.lang.Deprecated() com.oracle.truffle.api.source.SourceSection: method public final static com.oracle.truffle.api.source.SourceSection com.oracle.truffle.api.source.SourceSection.createUnavailable(java.lang.String,java.lang.String) anno 0 java.lang.Deprecated() STATUS:Failed.26 errors From aph at redhat.com Wed Jan 18 18:43:20 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 18 Jan 2017 18:43:20 +0000 Subject: Updated everything, got this odd message: Message-ID: aph at arm64:/nfs/zebedee/home/graal/graal-core$ mx -v build /home/aph/hs/build/linux-aarch64-normal-server-release/images/jdk/bin/java -cp /nfs/zebedee/home/graal/graal-core/mxbuild/.jdk9-internal org.graalvm.compiler.hotspot.JVMCIVersionCheck Could not find any JDK for building projects with compliance 1.8 (version 1.8) Enter path of JDK: ...baffled. My JDK_HOME points to the latest JDK 9 build. What does it want? Andrew. From doug.simon at oracle.com Wed Jan 18 20:45:37 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 18 Jan 2017 21:45:37 +0100 Subject: Updated everything, got this odd message: In-Reply-To: References: Message-ID: <65CDB1C1-25B3-462D-89FB-F1D0BF29F0CA@oracle.com> From http://mail.openjdk.java.net/pipermail/graal-dev/2017-January/004793.html: "Furthermore, a version of Graal has now been integrated into JDK9 as the module named `jdk.vm.compiler`. This complicates developing and deploying github Graal on JDK9 since we need to replace this module at compile and run time with the Graal sources under development. As detailed in JDK-8171448[6], achieving the latter is possible via use of --patch-module and --upgrade-module-path. The only way I've found to compile Graal sources (and Graal test sources) on JDK9 without the builtin jdk.vm.compiler getting in the way is to emulate --strict-compliance mode. As such, I've added support[7] to mx for projects to force this mode by appending `=` to the end of their javaCompliance attribute value (e.g., "javaCompliance" : "1.8=") in suite.py." This explains why a jdk8 now needs to be also provided via --extra-java-homes mx option or the EXTRA_JAVA_HOMES env var. I may be missing some trick for incrementally compiling a replacement JDK module so any hints in that direction would be appreciated ;-) -Doug > On 18 Jan 2017, at 19:43, Andrew Haley wrote: > > aph at arm64:/nfs/zebedee/home/graal/graal-core$ mx -v build > /home/aph/hs/build/linux-aarch64-normal-server-release/images/jdk/bin/java -cp /nfs/zebedee/home/graal/graal-core/mxbuild/.jdk9-internal org.graalvm.compiler.hotspot.JVMCIVersionCheck > Could not find any JDK for building projects with compliance 1.8 (version 1.8) > Enter path of JDK: > > ...baffled. My JDK_HOME points to the latest JDK 9 build. > What does it want? > > Andrew. From juan.fumero at ed.ac.uk Thu Jan 19 11:08:53 2017 From: juan.fumero at ed.ac.uk (Juan Fumero) Date: Thu, 19 Jan 2017 11:08:53 +0000 Subject: CallTarget and DirectCallNode in Truffle Languages Message-ID: <1484824133.29706.4.camel@ed.ac.uk> Hi guys,? ???I am working with JRuby and R Truffle implementations. I have a few questions concerning the callTarget and the directCallNode, most probably I do not fully understand concepts here.? In R, I directly execute the function as follow: function.getTarget().call(args); Running with Graal, the callTarget will be an optimizedCallTarget.? Till here, everything ok,? In JRuby the callTarget is not directly executed and instead, a directCallNode is used. directCallNode.call(frame, args); The directCallNode encapsulates the callTarget. However, it is not the "original" callTarget I see in the signature in CallBlockNode#callBlock (cachedCallTarget).? This provokes I see a different object optimizedCallTarget when I compile ( and I was expecting the same in my implementation).? The difference is that, directCallNode.getCallTarget() is different to directCallNode.getCurrentCallTarget(). 1. Why two different strategies for calling a function (R vs JRuby) ?? 2. Should not be the same callTarget anyway?? Thanks a lot Regards Juan? -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From aph at redhat.com Thu Jan 19 11:40:39 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Jan 2017 11:40:39 +0000 Subject: Updated everything, got this odd message: In-Reply-To: <65CDB1C1-25B3-462D-89FB-F1D0BF29F0CA@oracle.com> References: <65CDB1C1-25B3-462D-89FB-F1D0BF29F0CA@oracle.com> Message-ID: <7cb7686c-15b7-19c4-4b27-0daa92de909d@redhat.com> On 18/01/17 20:45, Doug Simon wrote: > I may be missing some trick for incrementally compiling a replacement JDK module so any hints in that direction would be appreciated ;-) I guess we should take this to the Jigsaw list. Graal won't be the only module with problems of this kind. Andrew. From aph at redhat.com Thu Jan 19 11:46:16 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Jan 2017 11:46:16 +0000 Subject: Updated everything, got this odd message: In-Reply-To: <65CDB1C1-25B3-462D-89FB-F1D0BF29F0CA@oracle.com> References: <65CDB1C1-25B3-462D-89FB-F1D0BF29F0CA@oracle.com> Message-ID: On 18/01/17 20:45, Doug Simon wrote: > This explains why a jdk8 now needs to be also provided via --extra-java-homes mx option or the EXTRA_JAVA_HOMES env var. aph at arm64:/nfs/zebedee/home/graal/graal-core$ mx build Could not find any JDK for building projects with compliance 1.8 (version 1.8) Enter path of JDK: /home/aph/jdk8-images/j2sdk-image/ Persist this setting by adding "EXTRA_JAVA_HOMES=/home/aph/jdk8-images/j2sdk-image/" to /nfs/zebedee/home/graal/graal-core/mx.graal-core/env? [Yn]: n File "/nfs/zebedee/home/graal/graal-core/mx.graal-core/suite.py", line 293 in definition of org.graalvm.compiler.api.replacements: JDK library JVMCI_API required by org.graalvm.compiler.api.replacements not provided by Java 1.8.0-internal (1.8) from /home/aph/jdk8-images/j2sdk-image/ But there is no JVMCI_API for JDK8 on AArch64... Andrew. From doug.simon at oracle.com Thu Jan 19 12:13:49 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 19 Jan 2017 13:13:49 +0100 Subject: Updated everything, got this odd message: In-Reply-To: References: <65CDB1C1-25B3-462D-89FB-F1D0BF29F0CA@oracle.com> Message-ID: > On 19 Jan 2017, at 12:46, Andrew Haley wrote: > > On 18/01/17 20:45, Doug Simon wrote: >> This explains why a jdk8 now needs to be also provided via --extra-java-homes mx option or the EXTRA_JAVA_HOMES env var. > > aph at arm64:/nfs/zebedee/home/graal/graal-core$ mx build > Could not find any JDK for building projects with compliance 1.8 (version 1.8) > Enter path of JDK: /home/aph/jdk8-images/j2sdk-image/ > Persist this setting by adding "EXTRA_JAVA_HOMES=/home/aph/jdk8-images/j2sdk-image/" to /nfs/zebedee/home/graal/graal-core/mx.graal-core/env? [Yn]: n > File "/nfs/zebedee/home/graal/graal-core/mx.graal-core/suite.py", line 293 in definition of org.graalvm.compiler.api.replacements: > JDK library JVMCI_API required by org.graalvm.compiler.api.replacements not provided by Java 1.8.0-internal (1.8) from /home/aph/jdk8-images/j2sdk-image/ > > But there is no JVMCI_API for JDK8 on AArch64? You should be able to workaround this with: export JVMCI_VERSION_CHECK=ignore cp -R $JVMCI_JAVA_HOME/jre/lib/jvmci* /home/aph/jdk8-images/j2sdk-image/jre/lib where $JVMCI_JAVA_HOME is the location of where https://github.com/dougxc/openjdk8-jvmci-builder/releases/download/jvmci-0.23/jdk1.8.0_111-jvmci-0.23-linux-amd64.tar.gz has been unpacked. The second command above puts the JVMCI APIs into your JDK8 so that mx can resolve them. -Doug From eregontp at gmail.com Thu Jan 19 12:34:04 2017 From: eregontp at gmail.com (Benoit Daloze) Date: Thu, 19 Jan 2017 13:34:04 +0100 Subject: CallTarget and DirectCallNode in Truffle Languages In-Reply-To: <1484824133.29706.4.camel@ed.ac.uk> References: <1484824133.29706.4.camel@ed.ac.uk> Message-ID: Hello, DirectCallNode#cloneCallTarget() allows to clone/split a CallTarget so that its AST can specialize for a given call site. In Ruby, we force this mechanism for blocks so that the block is specialized to how a method calls the block. It can also happens automatically if Truffle decides so when using a DirectCallNode. Cheers, Benoit On Thu, Jan 19, 2017 at 12:08 PM, Juan Fumero wrote: > Hi guys, > > I am working with JRuby and R Truffle implementations. I have a few > questions concerning the callTarget and the directCallNode, most > probably I do not fully understand concepts here. > > In R, I directly execute the function as follow: > > function.getTarget().call(args); > > Running with Graal, the callTarget will be an optimizedCallTarget. > Till here, everything ok, > > > In JRuby the callTarget is not directly executed and instead, a > directCallNode is used. > > directCallNode.call(frame, args); > > The directCallNode encapsulates the callTarget. However, it is not the > "original" callTarget I see in the signature in CallBlockNode#callBlock > (cachedCallTarget). > This provokes I see a different object optimizedCallTarget when I > compile ( and I was expecting the same in my implementation). > > The difference is that, directCallNode.getCallTarget() is different to > directCallNode.getCurrentCallTarget(). > > 1. Why two different strategies for calling a function (R vs JRuby) ? > 2. Should not be the same callTarget anyway? > > Thanks a lot > > Regards > Juan > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > From aph at redhat.com Thu Jan 19 13:05:54 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Jan 2017 13:05:54 +0000 Subject: Updated everything, got this odd message: In-Reply-To: References: <65CDB1C1-25B3-462D-89FB-F1D0BF29F0CA@oracle.com> Message-ID: After rebuilding absolutely everything: aph at arm64:/nfs/zebedee/home/graal/graal-core$ mx -v unittest /home/aph/hs/build/linux-aarch64-normal-server-release/images/jdk/bin/java -cp /nfs/zebedee/home/graal/graal-core/mxbuild/.jdk9-internal org.graalvm.compiler.hotspot.JVMCIVersionCheck [all files are up to date - skipping com.oracle.mxtool.junit] /home/aph/hs/build/linux-aarch64-normal-server-release/images/jdk/bin/java -cp /home/aph/.mx/cache/HAMCREST_42a25dc3219429f0e5d060061f71acb49bf010a0.jar:/home/aph/.mx/cache/JUNIT_4e031bb61df09069aeb2bffb4019e7a5034a4ee0.jar:/nfs/zebedee/home/graal/mx/mxbuild/java/com.oracle.mxtool.junit/bin:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-api.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-dsl-processor.jar:/home/aph/.mx/cache/JLINE_9504d5e2da5d78237239c5226e8200ec21182040.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-debug.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-tck.jar:/home/aph/.mx/cache/JMH_df111ae8e92bfd84fe135b844c4e3a910e1b8497.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-test.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-nodeinfo.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-serviceprovider.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-serviceprovider-processor.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-options.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-api.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-compiler.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-runtime.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-hotspot.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-sl.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-sl-test.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-options-processor.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-compiler-match-processor.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-truffle.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-truffle-hotspot.jar:/home/aph/.mx/cache/JAVA_ALLOCATION_INSTRUMENTER_476d9a44cd19d6b55f81571077dfa972a4f8a083.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-test.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-dsl-processor-internal.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-nodeinfo-processor.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-replacements-verifier.jar com.oracle.mxtool.junit.FindClassesByAnnotatedMethods @Test @Parameters /nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-api.jar /nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-tck.jar /nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-dsl-processor.jar /nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-sl.jar /nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-sl-test.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-nodeinfo.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-options.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-serviceprovider.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-api.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-compiler.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-serviceprovider-processor.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-compiler-match-processor.jar /nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-debug.jar /nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-test.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-replacements-verifier.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-nodeinfo-processor.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-runtime.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-hotspot.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-truffle.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-truffle-hotspot.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-options-processor.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-test.jar /nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-dsl-processor-internal.jar /home/aph/hs/build/linux-aarch64-normal-server-release/images/jdk/bin/java -server -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -d64 --add-exports=java.base/jdk.internal.module=jdk.vm.compiler --module-path=/nfs/zebedee/home/graal/truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/modules/jdk.vm.compiler.jar -esa -ea -Djava.awt.headless=true -cp /home/aph/.mx/cache/HAMCREST_42a25dc3219429f0e5d060061f71acb49bf010a0.jar:/home/aph/.mx/cache/JUNIT_4e031bb61df09069aeb2bffb4019e7a5034a4ee0.jar:/nfs/zebedee/home/graal/mx/mxbuild/java/com.oracle.mxtool.junit/bin:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-tck.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-dsl-processor.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-sl.jar:/home/aph/.mx/cache/JMH_df111ae8e92bfd84fe135b844c4e3a910e1b8497.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-sl-test.jar:/home/aph/.mx/cache/JAVA_ALLOCATION_INSTRUMENTER_476d9a44cd19d6b55f81571077dfa972a4f8a083.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-test.jar:/home/aph/.mx/cache/JLINE_9504d5e2da5d78237239c5226e8200ec21182040.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-debug.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-test.jar com.oracle.mxtool.junit.MxJUnitWrapper -JUnitEagerStackTrace @/tmp/mxtooleiq2HW.testclasses MxJUnitCore JUnit version 4.11 Exception in thread "main" java.lang.AssertionError: java.lang.IllegalAccessException: class com.oracle.mxtool.junit.JLRModule cannot access class jdk.internal.module.Modules (in module java.base) because module java.base does not export jdk.internal.module to unnamed module @28dcca0c at com.oracle.mxtool.junit.JLRModule.addExports(JLRModule.java:167) at com.oracle.mxtool.junit.MxJUnitWrapper.addExports(MxJUnitWrapper.java:304) at com.oracle.mxtool.junit.MxJUnitWrapper.main(MxJUnitWrapper.java:221) Caused by: java.lang.IllegalAccessException: class com.oracle.mxtool.junit.JLRModule cannot access class jdk.internal.module.Modules (in module java.base) because module java.base does not export jdk.internal.module to unnamed module @28dcca0c at java.base/jdk.internal.reflect.Reflection.throwIllegalAccessException(Reflection.java:445) at java.base/jdk.internal.reflect.Reflection.throwIllegalAccessException(Reflection.java:436) at java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:112) at java.base/java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:407) at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:399) at java.base/java.lang.reflect.Method.invoke(Method.java:535) at com.oracle.mxtool.junit.JLRModule.addExports(JLRModule.java:165) Andrew. From doug.simon at oracle.com Thu Jan 19 13:50:24 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 19 Jan 2017 14:50:24 +0100 Subject: Updated everything, got this odd message: In-Reply-To: References: <65CDB1C1-25B3-462D-89FB-F1D0BF29F0CA@oracle.com> Message-ID: <01DE60F1-35F7-4984-86DF-9A0144C0AB2F@oracle.com> I suspect your truffle dependency is not up to date and is missing: https://github.com/graalvm/truffle/blob/master/mx.truffle/mx_truffle.py#L85-L87 Running `mx supdate` should resolve the issue. However, graal-core itself should take care to add the necessary --add-exports option. I?ll push a change that does that. -Doug > On 19 Jan 2017, at 14:05, Andrew Haley wrote: > > After rebuilding absolutely everything: > > > aph at arm64:/nfs/zebedee/home/graal/graal-core$ mx -v unittest > /home/aph/hs/build/linux-aarch64-normal-server-release/images/jdk/bin/java -cp /nfs/zebedee/home/graal/graal-core/mxbuild/.jdk9-internal org.graalvm.compiler.hotspot.JVMCIVersionCheck > [all files are up to date - skipping com.oracle.mxtool.junit] > /home/aph/hs/build/linux-aarch64-normal-server-release/images/jdk/bin/java -cp /home/aph/.mx/cache/HAMCREST_42a25dc3219429f0e5d060061f71acb49bf010a0.jar:/home/aph/.mx/cache/JUNIT_4e031bb61df09069aeb2bffb4019e7a5034a4ee0.jar:/nfs/zebedee/home/graal/mx/mxbuild/java/com.oracle.mxtool.junit/bin:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-api.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-dsl-processor.jar:/home/aph/.mx/cache/JLINE_9504d5e2da5d78237239c5226e8200ec21182040.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-debug.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-tck.jar:/home/aph/.mx/cache/JMH_df111ae8e92bfd84fe135b844c4e3a910e1b8497.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-test.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-nodeinfo.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-serviceprovider.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-serviceprovider-processor.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-options.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-api.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-compiler.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-runtime.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-hotspot.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-sl.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-sl-test.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-options-processor.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-compiler-match-processor.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-truffle.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-truffle-hotspot.jar:/home/aph/.mx/cache/JAVA_ALLOCATION_INSTRUMENTER_476d9a44cd19d6b55f81571077dfa972a4f8a083.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-test.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-dsl-processor-internal.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-nodeinfo-processor.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-replacements-verifier.jar com.oracle.mxtool.junit.FindClassesByAnnotatedMethods @Test @Parameters /nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-api.jar /nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-tck.jar /nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-dsl-processor.jar /nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-sl.jar /nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-sl-test.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-nodeinfo.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-options.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-serviceprovider.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-api.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-compiler.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-serviceprovider-processor.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-compiler-match-processor.jar /nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-debug.jar /nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-test.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-replacements-verifier.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-nodeinfo-processor.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-runtime.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-hotspot.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-truffle.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-truffle-hotspot.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-options-processor.jar /nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-test.jar /nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-dsl-processor-internal.jar > /home/aph/hs/build/linux-aarch64-normal-server-release/images/jdk/bin/java -server -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -d64 --add-exports=java.base/jdk.internal.module=jdk.vm.compiler --module-path=/nfs/zebedee/home/graal/truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/modules/jdk.vm.compiler.jar -esa -ea -Djava.awt.headless=true -cp /home/aph/.mx/cache/HAMCREST_42a25dc3219429f0e5d060061f71acb49bf010a0.jar:/home/aph/.mx/cache/JUNIT_4e031bb61df09069aeb2bffb4019e7a5034a4ee0.jar:/nfs/zebedee/home/graal/mx/mxbuild/java/com.oracle.mxtool.junit/bin:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-tck.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-dsl-processor.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-sl.jar:/home/aph/.mx/cache/JMH_df111ae8e92bfd84fe135b844c4e3a910e1b8497.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-sl-test.jar:/home/aph/.mx/cache/JAVA_ALLOCATION_INSTRUMENTER_476d9a44cd19d6b55f81571077dfa972a4f8a083.jar:/nfs/zebedee/home/graal/graal-core/mxbuild/dists/graal-test.jar:/home/aph/.mx/cache/JLINE_9504d5e2da5d78237239c5226e8200ec21182040.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-debug.jar:/nfs/zebedee/home/graal/truffle/mxbuild/dists/truffle-test.jar com.oracle.mxtool.junit.MxJUnitWrapper -JUnitEagerStackTrace @/tmp/mxtooleiq2HW.testclasses > MxJUnitCore > JUnit version 4.11 > Exception in thread "main" java.lang.AssertionError: java.lang.IllegalAccessException: class com.oracle.mxtool.junit.JLRModule cannot access class jdk.internal.module.Modules (in module java.base) because module java.base does not export jdk.internal.module to unnamed module @28dcca0c > at com.oracle.mxtool.junit.JLRModule.addExports(JLRModule.java:167) > at com.oracle.mxtool.junit.MxJUnitWrapper.addExports(MxJUnitWrapper.java:304) > at com.oracle.mxtool.junit.MxJUnitWrapper.main(MxJUnitWrapper.java:221) > Caused by: java.lang.IllegalAccessException: class com.oracle.mxtool.junit.JLRModule cannot access class jdk.internal.module.Modules (in module java.base) because module java.base does not export jdk.internal.module to unnamed module @28dcca0c > at java.base/jdk.internal.reflect.Reflection.throwIllegalAccessException(Reflection.java:445) > at java.base/jdk.internal.reflect.Reflection.throwIllegalAccessException(Reflection.java:436) > at java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:112) > at java.base/java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:407) > at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:399) > at java.base/java.lang.reflect.Method.invoke(Method.java:535) > at com.oracle.mxtool.junit.JLRModule.addExports(JLRModule.java:165) > > Andrew. > > From aph at redhat.com Thu Jan 19 15:14:57 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Jan 2017 15:14:57 +0000 Subject: Updated everything, got this odd message: In-Reply-To: <01DE60F1-35F7-4984-86DF-9A0144C0AB2F@oracle.com> References: <65CDB1C1-25B3-462D-89FB-F1D0BF29F0CA@oracle.com> <01DE60F1-35F7-4984-86DF-9A0144C0AB2F@oracle.com> Message-ID: On 19/01/17 13:50, Doug Simon wrote: > Running `mx supdate` should resolve the issue. OK, sorry. I forgot about the separate truffle repo. Andrew. From aph at redhat.com Thu Jan 19 17:44:34 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Jan 2017 17:44:34 +0000 Subject: Bug in Truffle: parent is accessed racily Message-ID: <653e564d-34c7-cd4c-5e05-bd46820016c7@redhat.com> I've been seeing some odd failures in InstrumentationMultiThreadingTest. I occasionally get NullPointerExceptions on Node.getRootNode(). I think the real problem is in class Node, where Node.parent is accessed racily by multiple threads. parent really needs to be volatile: diff --git a/truffle/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java b/truffle/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java index e153bc6..52a2c95 100644 --- a/truffle/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java +++ b/truffle/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java @@ -55,7 +55,7 @@ import com.oracle.truffle.api.utilities.JSONHelper; public abstract class Node implements NodeInterface, Cloneable { private final NodeClass nodeClass; - @CompilationFinal private Node parent; + @CompilationFinal private volatile Node parent; /** * Marks array fields that are children of this node. Andrew. From doug.simon at oracle.com Thu Jan 19 21:49:01 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 19 Jan 2017 22:49:01 +0100 Subject: Updated everything, got this odd message: In-Reply-To: <7cb7686c-15b7-19c4-4b27-0daa92de909d@redhat.com> References: <65CDB1C1-25B3-462D-89FB-F1D0BF29F0CA@oracle.com> <7cb7686c-15b7-19c4-4b27-0daa92de909d@redhat.com> Message-ID: > On 19 Jan 2017, at 12:40, Andrew Haley wrote: > > On 18/01/17 20:45, Doug Simon wrote: >> I may be missing some trick for incrementally compiling a replacement JDK module so any hints in that direction would be appreciated ;-) > > I guess we should take this to the Jigsaw list. Graal won't be the > only module with problems of this kind. Well, I suspect the answer will be that with jdk9 javac, one simply has to compile everything in a module at once. This is not how the Graal module is built since it is decomposed into smaller mx projects compiled separately and is finally assembled into a module. -Doug From dawclarke at gmail.com Thu Jan 19 23:55:40 2017 From: dawclarke at gmail.com (David Clarke) Date: Fri, 20 Jan 2017 10:55:40 +1100 Subject: Target Environment - Cross-compilation Message-ID: <3020544E-9D9D-48F4-8F0C-BA236EC5DD4F@gmail.com> Good People, I am researching using Graal to host code that optimises the implementation of memory fences. On x86 architectures, the CompareAndSet functionality is implemented with lock:xchg. Because of the way x86 works, the lock prefix is compulsory for shared variables so weakCompareAndSet has to be over-approximated by using lock:xchg. On ARM, the LL/SC combination is a weakCompareAndSet so a CompareAndSet must be implemented with weakCompareAndSet followed by a fullFence. So on x86 we want to optimise away a full fence that immediately follows a weakCompareAndSet and on ARM, we don?t. This could be delayed until the code generation phase, but I would like to keep the optimisations at the IR or LIR level so that we retain the greatest generality for as long as possible and avoid repeating similar code in several distinct code generation phases. So my questions are ?How can the code within a Node find out the target environment?" and ?Can we fiddle this so that the target environment is different from the actual host environment?? I am interested in the prospect of cross-compilation so that I can defer the need to perform experimentation on multiple different platforms. Can anyone point me to the relevant code/documentation/examples ? Thank you for your indulgent assistance. David (Knobby) CLARKE 6 Coptfold Court Glen Waverley VIC 3150 Australia +61 408 793 793 dawclarke at gmail.com From aph at redhat.com Fri Jan 20 09:31:19 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 20 Jan 2017 09:31:19 +0000 Subject: Target Environment - Cross-compilation In-Reply-To: <3020544E-9D9D-48F4-8F0C-BA236EC5DD4F@gmail.com> References: <3020544E-9D9D-48F4-8F0C-BA236EC5DD4F@gmail.com> Message-ID: <0389da83-ecb1-9b1c-a277-b0e2466e8d44@redhat.com> On 19/01/17 23:55, David Clarke wrote: > So on x86 we want to optimise away a full fence that immediately > follows a weakCompareAndSet and on ARM, we don?t. This could be > delayed until the code generation phase, but I would like to keep > the optimisations at the IR or LIR level so that we retain the > greatest generality for as long as possible and avoid repeating > similar code in several distinct code generation phases. There's a related problem on ARMv8. At the present time we emit fences very early, which means that we don't generate the STLR/LDAR instructions we really want for Java volailes. At the very least this is inefficient. > So my questions are ?How can the code within a Node find out the > target environment?" and ?Can we fiddle this so that the target > environment is different from the actual host environment?? I think that the real answer is to handle all of this properly in the Graal IR by lowering the nodes in a way that is controlled by the back end. This will mean that the compiler will have to be taught about how to handle the nodes appropriately. Andrew. From doug.simon at oracle.com Fri Jan 20 09:42:15 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 20 Jan 2017 10:42:15 +0100 Subject: Target Environment - Cross-compilation In-Reply-To: <0389da83-ecb1-9b1c-a277-b0e2466e8d44@redhat.com> References: <3020544E-9D9D-48F4-8F0C-BA236EC5DD4F@gmail.com> <0389da83-ecb1-9b1c-a277-b0e2466e8d44@redhat.com> Message-ID: <939443FA-521A-40E0-A40F-55459AD4A816@oracle.com> > On 20 Jan 2017, at 10:31, Andrew Haley wrote: > > On 19/01/17 23:55, David Clarke wrote: > >> So on x86 we want to optimise away a full fence that immediately >> follows a weakCompareAndSet and on ARM, we don?t. This could be >> delayed until the code generation phase, but I would like to keep >> the optimisations at the IR or LIR level so that we retain the >> greatest generality for as long as possible and avoid repeating >> similar code in several distinct code generation phases. > > There's a related problem on ARMv8. At the present time we emit > fences very early, which means that we don't generate the STLR/LDAR > instructions we really want for Java volailes. At the very least this > is inefficient. > >> So my questions are ?How can the code within a Node find out the >> target environment?" and ?Can we fiddle this so that the target >> environment is different from the actual host environment?? > > I think that the real answer is to handle all of this properly in the > Graal IR by lowering the nodes in a way that is controlled by the back > end. This will mean that the compiler will have to be taught about > how to handle the nodes appropriately. Yes, you will need something like the AddressLowering/AddressLoweringPhase mechanism Graal currently has. -Doug From aph at redhat.com Fri Jan 20 14:46:27 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 20 Jan 2017 14:46:27 +0000 Subject: truffle.test.OptimizedCallTargetTest Message-ID: <8919c466-4acf-7662-7019-616facd801fb@redhat.com> I've now passed all of the Truffle tests except for one, and that's a timeout waiting for an OSR loop counter to trigger. The test actually takes 17 seconds to run; does anyone mind if I increase the timeout to, say, 30s? Thanks, Andrew. diff --git a/graal/org.graalvm.compiler.truffle.test/src/org/graalvm/compiler/truffle/test/OptimizedCallTargetTest.java b/graal/org.graalvm.compiler.truffle.test/src/org/graalvm/compiler/truffle/test/OptimizedCallTargetTest.java index 8329e17..4a84b70 100644 --- a/graal/org.graalvm.compiler.truffle.test/src/org/graalvm/compiler/truffle/test/OptimizedCallTargetTest.java +++ b/graal/org.graalvm.compiler.truffle.test/src/org/graalvm/compiler/truffle/test/OptimizedCallTargetTest.java @@ -86,7 +86,7 @@ public class OptimizedCallTargetTest { private static void assertCompiled(OptimizedCallTarget target) { assertNotNull(target); try { - runtime.waitForCompilation(target, 10000); + runtime.waitForCompilation(target, 30_000); } catch (ExecutionException | TimeoutException e) { fail("timeout"); } From doug.simon at oracle.com Fri Jan 20 16:21:45 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 20 Jan 2017 17:21:45 +0100 Subject: truffle.test.OptimizedCallTargetTest In-Reply-To: <8919c466-4acf-7662-7019-616facd801fb@redhat.com> References: <8919c466-4acf-7662-7019-616facd801fb@redhat.com> Message-ID: <84154766-B951-40C9-877F-A0C0188BA38B@oracle.com> Hi Andrew, We?re looking into why it requires even 10s, let alone 30s. In the mean time, you can increase the timeout when running on Aarch64. -Doug > On 20 Jan 2017, at 15:46, Andrew Haley wrote: > > I've now passed all of the Truffle tests except for one, and that's a > timeout waiting for an OSR loop counter to trigger. The test actually > takes 17 seconds to run; does anyone mind if I increase the timeout > to, say, 30s? > > Thanks, > > Andrew. > > > diff --git a/graal/org.graalvm.compiler.truffle.test/src/org/graalvm/compiler/truffle/test/OptimizedCallTargetTest.java b/graal/org.graalvm.compiler.truffle.test/src/org/graalvm/compiler/truffle/test/OptimizedCallTargetTest.java > index 8329e17..4a84b70 100644 > --- a/graal/org.graalvm.compiler.truffle.test/src/org/graalvm/compiler/truffle/test/OptimizedCallTargetTest.java > +++ b/graal/org.graalvm.compiler.truffle.test/src/org/graalvm/compiler/truffle/test/OptimizedCallTargetTest.java > @@ -86,7 +86,7 @@ public class OptimizedCallTargetTest { > private static void assertCompiled(OptimizedCallTarget target) { > assertNotNull(target); > try { > - runtime.waitForCompilation(target, 10000); > + runtime.waitForCompilation(target, 30_000); > } catch (ExecutionException | TimeoutException e) { > fail("timeout"); > } From christian.humer at gmail.com Fri Jan 20 16:53:37 2017 From: christian.humer at gmail.com (Christian Humer) Date: Fri, 20 Jan 2017 16:53:37 +0000 Subject: truffle.test.OptimizedCallTargetTest In-Reply-To: <84154766-B951-40C9-877F-A0C0188BA38B@oracle.com> References: <8919c466-4acf-7662-7019-616facd801fb@redhat.com> <84154766-B951-40C9-877F-A0C0188BA38B@oracle.com> Message-ID: Hi Andrew, I did not imagine that there could be a platform that compiles so slowly. OptimizedCallTargetTest as a whole runs in 3.5s locally and it does hundreds of compilations on my machine. I pushing your suggested fix. Cheers, Christian Humer On 20.01.2017 17:21:45, "Doug Simon" wrote: >Hi Andrew, > >We?re looking into why it requires even 10s, let alone 30s. In the mean >time, you can increase the timeout when running on Aarch64. > >-Doug > >> On 20 Jan 2017, at 15:46, Andrew Haley wrote: >> >> I've now passed all of the Truffle tests except for one, and that's a >> timeout waiting for an OSR loop counter to trigger. The test >>actually >> takes 17 seconds to run; does anyone mind if I increase the timeout >> to, say, 30s? >> >> Thanks, >> >> Andrew. >> >> >> diff --git >>a/graal/org.graalvm.compiler.truffle.test/src/org/graalvm/compiler/truffle/test/OptimizedCallTargetTest.java >>b/graal/org.graalvm.compiler.truffle.test/src/org/graalvm/compiler/truffle/test/OptimizedCallTargetTest.java >> index 8329e17..4a84b70 100644 >> --- >>a/graal/org.graalvm.compiler.truffle.test/src/org/graalvm/compiler/truffle/test/OptimizedCallTargetTest.java >> +++ >>b/graal/org.graalvm.compiler.truffle.test/src/org/graalvm/compiler/truffle/test/OptimizedCallTargetTest.java >> @@ -86,7 +86,7 @@ public class OptimizedCallTargetTest { >> private static void assertCompiled(OptimizedCallTarget target) { >> assertNotNull(target); >> try { >> - runtime.waitForCompilation(target, 10000); >> + runtime.waitForCompilation(target, 30_000); >> } catch (ExecutionException | TimeoutException e) { >> fail("timeout"); >> } > From aph at redhat.com Fri Jan 20 17:08:17 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 20 Jan 2017 17:08:17 +0000 Subject: truffle.test.OptimizedCallTargetTest In-Reply-To: References: <8919c466-4acf-7662-7019-616facd801fb@redhat.com> <84154766-B951-40C9-877F-A0C0188BA38B@oracle.com> Message-ID: <44b4262a-ef4f-60a1-1df3-8c634bebec64@redhat.com> On 20/01/17 16:53, Christian Humer wrote: > I did not imagine that there could be a platform that compiles so > slowly. OptimizedCallTargetTest as a whole runs in 3.5s locally and it > does hundreds of compilations on my machine. I have no idea why either. But it's not worth investigating right now. Andrew. From christian.humer at gmail.com Fri Jan 20 17:41:52 2017 From: christian.humer at gmail.com (Christian Humer) Date: Fri, 20 Jan 2017 17:41:52 +0000 Subject: Bug in Truffle: parent is accessed racily In-Reply-To: <653e564d-34c7-cd4c-5e05-bd46820016c7@redhat.com> References: <653e564d-34c7-cd4c-5e05-bd46820016c7@redhat.com> Message-ID: Hi Andrew, Thanks for the report! Interesting that this problem never occurred on x86 or sparc yet. Will investigate a bit more, why it was not volatile in the first place. Cheers, Christian Humer On 19.01.2017 18:44:34, "Andrew Haley" wrote: >I've been seeing some odd failures in >InstrumentationMultiThreadingTest. >I occasionally get NullPointerExceptions on Node.getRootNode(). > >I think the real problem is in class Node, where Node.parent is >accessed >racily by multiple threads. parent really needs to be volatile: > >diff --git >a/truffle/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java >b/truffle/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java >index e153bc6..52a2c95 100644 >--- >a/truffle/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java >+++ >b/truffle/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java >@@ -55,7 +55,7 @@ import com.oracle.truffle.api.utilities.JSONHelper; > public abstract class Node implements NodeInterface, Cloneable { > > private final NodeClass nodeClass; >- @CompilationFinal private Node parent; >+ @CompilationFinal private volatile Node parent; > > /** > * Marks array fields that are children of this node. > >Andrew. From aph at redhat.com Fri Jan 20 17:45:51 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 20 Jan 2017 17:45:51 +0000 Subject: Bug in Truffle: parent is accessed racily In-Reply-To: References: <653e564d-34c7-cd4c-5e05-bd46820016c7@redhat.com> Message-ID: <515a4623-7588-ebb3-76bf-7782e9e47741@redhat.com> On 20/01/17 17:41, Christian Humer wrote: > Thanks for the report! > Interesting that this problem never occurred on x86 or sparc yet. > > Will investigate a bit more, why it was not volatile in the first place. I suspect that's because all the machines you've used have been TSO. The AArch64 systems I test on are (extremely) weakly ordered. Andrew. From aph at redhat.com Fri Jan 20 17:46:53 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 20 Jan 2017 17:46:53 +0000 Subject: Bug in Truffle: parent is accessed racily In-Reply-To: <515a4623-7588-ebb3-76bf-7782e9e47741@redhat.com> References: <653e564d-34c7-cd4c-5e05-bd46820016c7@redhat.com> <515a4623-7588-ebb3-76bf-7782e9e47741@redhat.com> Message-ID: <28d62e3f-8738-8639-d3f7-e32424567987@redhat.com> On 20/01/17 17:45, Andrew Haley wrote: > I suspect that's because all the machines you've used have been TSO. > The AArch64 systems I test on are (extremely) weakly ordered. BTW, I've found bugs in HotSpot garbage collectors that have been in there for many years, and nobody ever noticed. Andrew. From christian.humer at gmail.com Fri Jan 20 17:55:31 2017 From: christian.humer at gmail.com (Christian Humer) Date: Fri, 20 Jan 2017 17:55:31 +0000 Subject: truffle.test.OptimizedCallTargetTest In-Reply-To: <44b4262a-ef4f-60a1-1df3-8c634bebec64@redhat.com> References: <8919c466-4acf-7662-7019-616facd801fb@redhat.com> <84154766-B951-40C9-877F-A0C0188BA38B@oracle.com> <44b4262a-ef4f-60a1-1df3-8c634bebec64@redhat.com> Message-ID: Here you go: https://github.com/graalvm/graal-core/commit/30498e77c6d83df754f074e0bedb8c5502b7b2b5 - Christian Humer On 20.01.2017 18:08:17, "Andrew Haley" wrote: >On 20/01/17 16:53, Christian Humer wrote: >> I did not imagine that there could be a platform that compiles so >> slowly. OptimizedCallTargetTest as a whole runs in 3.5s locally and >>it >> does hundreds of compilations on my machine. > >I have no idea why either. But it's not worth investigating right now. > >Andrew. > From aph at redhat.com Mon Jan 23 15:26:13 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 23 Jan 2017 15:26:13 +0000 Subject: Printing assembly language from truffle tests Message-ID: How do you do it? -Dgraal.PrintLIRWithAssembly=true doesn't work. JVMCI provides CompilationResultBuilder.disassembleCodeBlob but nothing seems to call it. Andrew. From tom.rodriguez at oracle.com Mon Jan 23 23:35:09 2017 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 23 Jan 2017 15:35:09 -0800 Subject: Printing assembly language from truffle tests In-Reply-To: References: Message-ID: <5886932D.1020000@oracle.com> You should be able to use -XX:CompileCommand=print,\*OptimizedCallTarget,callRoot to get the assembly. The truffle name of the should be included in the output. The .cfg files produced by the dump option should contain the assembly as well, though I don't know if that works with aarch64. You can view those files using the C1Visualizer which you can launch using "mx c1visualizer". tom Andrew Haley wrote: > How do you do it? -Dgraal.PrintLIRWithAssembly=true doesn't work. JVMCI > provides CompilationResultBuilder.disassembleCodeBlob but nothing seems > to call it. > > Andrew. From aph at redhat.com Tue Jan 24 14:27:41 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 24 Jan 2017 14:27:41 +0000 Subject: What is Method::_jfr_towrite ? Message-ID: <3dc4e7dc-5f81-53ff-eaf3-c0cac8d66b04@redhat.com> diff --git a/graal/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java b/graal/o index e6ce448..2d9d145 100644 --- a/graal/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java +++ b/graal/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java @@ -486,7 +486,7 @@ public class GraalHotSpotVMConfig extends HotSpotVMConfigAccess { public final int methodCompiledEntryOffset = getFieldOffset("Method::_from_compiled_entry", Integer.class, "add public final int methodCodeOffset = getFieldOffset("Method::_code", Integer.class, isJDK8 ? "nmethod*" : "Compi - public final int methodFlagsJfrTowrite = getConstant("Method::_jfr_towrite", Integer.class); + // public final int methodFlagsJfrTowrite = getConstant("Method::_jfr_towrite", Integer.class); public final int methodFlagsCallerSensitive = getConstant("Method::_caller_sensitive", Integer.class); public final int methodFlagsForceInline = getConstant("Method::_force_inline", Integer.class); public final int methodFlagsDontInline = getConstant("Method::_dont_inline", Integer.class); It was removed by # Date 1484666283 -3600 # Tue Jan 17 16:18:03 2017 +0100 # Node ID 254d5e3a021f447582c5d892ba829672208809a7 # Parent ad7a201398318e99d25fcb24f5566570c7c2e49b 8171960: Event-based tracing needs separate flag representation for Method In any case, Graal doesn't use it, and doesn't work unless I remove it. Andrew. From doug.simon at oracle.com Tue Jan 24 14:54:03 2017 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 24 Jan 2017 15:54:03 +0100 Subject: What is Method::_jfr_towrite ? In-Reply-To: <3dc4e7dc-5f81-53ff-eaf3-c0cac8d66b04@redhat.com> References: <3dc4e7dc-5f81-53ff-eaf3-c0cac8d66b04@redhat.com> Message-ID: I don?t know what that field is (was). I have an internal patch that makes the change you have below but I'm waiting for a new version of jdk9 that doesn?t crash due to https://bugs.openjdk.java.net/browse/JDK-8173195 before integrating it. -Doug > On 24 Jan 2017, at 15:27, Andrew Haley wrote: > > diff --git a/graal/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java b/graal/o > index e6ce448..2d9d145 100644 > --- a/graal/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java > +++ b/graal/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java > @@ -486,7 +486,7 @@ public class GraalHotSpotVMConfig extends HotSpotVMConfigAccess { > public final int methodCompiledEntryOffset = getFieldOffset("Method::_from_compiled_entry", Integer.class, "add > public final int methodCodeOffset = getFieldOffset("Method::_code", Integer.class, isJDK8 ? "nmethod*" : "Compi > > - public final int methodFlagsJfrTowrite = getConstant("Method::_jfr_towrite", Integer.class); > + // public final int methodFlagsJfrTowrite = getConstant("Method::_jfr_towrite", Integer.class); > public final int methodFlagsCallerSensitive = getConstant("Method::_caller_sensitive", Integer.class); > public final int methodFlagsForceInline = getConstant("Method::_force_inline", Integer.class); > public final int methodFlagsDontInline = getConstant("Method::_dont_inline", Integer.class); > > It was removed by > > # Date 1484666283 -3600 > # Tue Jan 17 16:18:03 2017 +0100 > # Node ID 254d5e3a021f447582c5d892ba829672208809a7 > # Parent ad7a201398318e99d25fcb24f5566570c7c2e49b > 8171960: Event-based tracing needs separate flag representation for Method > > In any case, Graal doesn't use it, and doesn't work unless I remove it. > > Andrew. From aph at redhat.com Tue Jan 24 16:35:52 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 24 Jan 2017 16:35:52 +0000 Subject: More git weirdness Message-ID: <43a53337-708f-2ecc-564f-def6de7cd19b@redhat.com> Just when I think I'm over the bumps: mercury:aph $ git clone https://git at github.com/theRealAph/graal-core Initialized empty Git repository in /home/graal/aph/graal-core/.git/ remote: Counting objects: 304672, done. remote: Total 304672 (delta 0), reused 0 (delta 0), pack-reused 304672 Receiving objects: 100% (304672/304672), 36.80 MiB | 4.60 MiB/s, done. Resolving deltas: 100% (142045/142045), done. mercury:aph $ cd graal-core/ mercury:graal-core $ git remote add master https://github.com/graalvm/graal-core mercury:graal-core $ git fetch master remote: Counting objects: 4292, done. remote: Compressing objects: 100% (322/322), done. remote: Total 4292 (delta 1767), reused 1640 (delta 1640), pack-reused 2034 Receiving objects: 100% (4292/4292), 1.06 MiB | 916 KiB/s, done. Resolving deltas: 100% (1819/1819), completed with 419 local objects. >From https://github.com/graalvm/graal-core * [new branch] master -> master/master * [new tag] JDK-8166417 -> JDK-8166417 * [new tag] graal-vm-0.18 -> graal-vm-0.18 mercury:graal-core $ git merge master/master Updating 03d3f8c..576bb34 Checking out files: 100% (5285/5285), done. Fast-forward ... mercury:graal-core $ git push error: The requested URL returned error: 403 Forbidden while accessing https://git at github.com/theRealAph/graal-core/info/refs fatal: HTTP request failed Umm, what? Is there something else I should know? Thanks, Andrew. From doug.simon at oracle.com Tue Jan 24 16:45:33 2017 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 24 Jan 2017 17:45:33 +0100 Subject: More git weirdness In-Reply-To: <43a53337-708f-2ecc-564f-def6de7cd19b@redhat.com> References: <43a53337-708f-2ecc-564f-def6de7cd19b@redhat.com> Message-ID: <5EAC1D4A-83BF-4948-BDE3-F07D52C52083@oracle.com> > On 24 Jan 2017, at 17:35, Andrew Haley wrote: > > Just when I think I'm over the bumps: > > mercury:aph $ git clone https://git at github.com/theRealAph/graal-core > Initialized empty Git repository in /home/graal/aph/graal-core/.git/ > remote: Counting objects: 304672, done. > remote: Total 304672 (delta 0), reused 0 (delta 0), pack-reused 304672 > Receiving objects: 100% (304672/304672), 36.80 MiB | 4.60 MiB/s, done. > Resolving deltas: 100% (142045/142045), done. > > mercury:aph $ cd graal-core/ > > mercury:graal-core $ git remote add master https://github.com/graalvm/graal-core > > mercury:graal-core $ git fetch master > remote: Counting objects: 4292, done. > remote: Compressing objects: 100% (322/322), done. > remote: Total 4292 (delta 1767), reused 1640 (delta 1640), pack-reused 2034 > Receiving objects: 100% (4292/4292), 1.06 MiB | 916 KiB/s, done. > Resolving deltas: 100% (1819/1819), completed with 419 local objects. > From https://github.com/graalvm/graal-core > * [new branch] master -> master/master > * [new tag] JDK-8166417 -> JDK-8166417 > * [new tag] graal-vm-0.18 -> graal-vm-0.18 > > mercury:graal-core $ git merge master/master > Updating 03d3f8c..576bb34 > Checking out files: 100% (5285/5285), done. > Fast-forward > ... > > mercury:graal-core $ git push > error: The requested URL returned error: 403 Forbidden while accessing https://git at github.com/theRealAph/graal-core/info/refs > > fatal: HTTP request failed > > Umm, what? Is there something else I should know? I think you need to push with ssh URLs (e.g., ssh://git at github.com:graalvm/graal-core.git). -Doug From aph at redhat.com Tue Jan 24 16:51:50 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 24 Jan 2017 16:51:50 +0000 Subject: More git weirdness In-Reply-To: <5EAC1D4A-83BF-4948-BDE3-F07D52C52083@oracle.com> References: <43a53337-708f-2ecc-564f-def6de7cd19b@redhat.com> <5EAC1D4A-83BF-4948-BDE3-F07D52C52083@oracle.com> Message-ID: <27945ef1-1dff-aa00-2e31-73d8b77df089@redhat.com> On 24/01/17 16:45, Doug Simon wrote: > I think you need to push with ssh URLs (e.g., ssh://git at github.com:graalvm/graal-core.git). Ah, right, so I can pull from my private dir with a username and a password, but not push. OK. Thanks, Andrew. From aph at redhat.com Tue Jan 24 16:53:16 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 24 Jan 2017 16:53:16 +0000 Subject: More git weirdness In-Reply-To: <27945ef1-1dff-aa00-2e31-73d8b77df089@redhat.com> References: <43a53337-708f-2ecc-564f-def6de7cd19b@redhat.com> <5EAC1D4A-83BF-4948-BDE3-F07D52C52083@oracle.com> <27945ef1-1dff-aa00-2e31-73d8b77df089@redhat.com> Message-ID: <73a91ec4-81da-a490-78ea-4faf782f3be0@redhat.com> Oh, bother. That push worked, but the web page still says "This branch is 362 commits behind graalvm:master." :-( Andrew. From aph at redhat.com Tue Jan 24 17:01:29 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 24 Jan 2017 17:01:29 +0000 Subject: More git weirdness In-Reply-To: <73a91ec4-81da-a490-78ea-4faf782f3be0@redhat.com> References: <43a53337-708f-2ecc-564f-def6de7cd19b@redhat.com> <5EAC1D4A-83BF-4948-BDE3-F07D52C52083@oracle.com> <27945ef1-1dff-aa00-2e31-73d8b77df089@redhat.com> <73a91ec4-81da-a490-78ea-4faf782f3be0@redhat.com> Message-ID: <6468aa48-a25a-6719-e37a-c8ce10bc37c6@redhat.com> On 24/01/17 16:53, Andrew Haley wrote: > Oh, bother. That push worked, but the web page still says > > "This branch is 362 commits behind graalvm:master." Never mind: was no more than a propagation delay within GitHub. I'm good. Andrew. From aph at redhat.com Tue Jan 24 17:10:22 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 24 Jan 2017 17:10:22 +0000 Subject: Library dependencies Message-ID: <4a2d7b6a-9922-a2e4-6909-ff6c7efb1dd3@redhat.com> I'm having a problem where I need to import a library into one of the AArch64 projects. I can tell Eclipse to do this and Eclipse is happy, but it doesn't seem to work with "mx build". Is there something I need to do to tell mx that I have a new library dependency? Thanks, Andrew. From adinn at redhat.com Tue Jan 24 17:50:10 2017 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 24 Jan 2017 17:50:10 +0000 Subject: More git weirdness In-Reply-To: <5EAC1D4A-83BF-4948-BDE3-F07D52C52083@oracle.com> References: <43a53337-708f-2ecc-564f-def6de7cd19b@redhat.com> <5EAC1D4A-83BF-4948-BDE3-F07D52C52083@oracle.com> Message-ID: <51b375d7-3569-bbff-e74d-e0bba2435163@redhat.com> On 24/01/17 16:45, Doug Simon wrote: > >> On 24 Jan 2017, at 17:35, Andrew Haley wrote: >> >> Just when I think I'm over the bumps: >> >> mercury:aph $ git clone https://git at github.com/theRealAph/graal-core >> Initialized empty Git repository in /home/graal/aph/graal-core/.git/ >> remote: Counting objects: 304672, done. >> remote: Total 304672 (delta 0), reused 0 (delta 0), pack-reused 304672 >> Receiving objects: 100% (304672/304672), 36.80 MiB | 4.60 MiB/s, done. >> Resolving deltas: 100% (142045/142045), done. >> >> mercury:aph $ cd graal-core/ >> >> mercury:graal-core $ git remote add master https://github.com/graalvm/graal-core >> >> mercury:graal-core $ git fetch master >> remote: Counting objects: 4292, done. >> remote: Compressing objects: 100% (322/322), done. >> remote: Total 4292 (delta 1767), reused 1640 (delta 1640), pack-reused 2034 >> Receiving objects: 100% (4292/4292), 1.06 MiB | 916 KiB/s, done. >> Resolving deltas: 100% (1819/1819), completed with 419 local objects. >> From https://github.com/graalvm/graal-core >> * [new branch] master -> master/master >> * [new tag] JDK-8166417 -> JDK-8166417 >> * [new tag] graal-vm-0.18 -> graal-vm-0.18 >> >> mercury:graal-core $ git merge master/master >> Updating 03d3f8c..576bb34 >> Checking out files: 100% (5285/5285), done. >> Fast-forward >> ... >> >> mercury:graal-core $ git push >> error: The requested URL returned error: 403 Forbidden while accessing https://git at github.com/theRealAph/graal-core/info/refs >> >> fatal: HTTP request failed >> >> Umm, what? Is there something else I should know? > > I think you need to push with ssh URLs (e.g., ssh://git at github.com:graalvm/graal-core.git). Indeed you really ought to have cloned it in the first place using the ssh://.../ format URL then our repo's origin URL would be in ssh format. You can use command 'git remote' to reset your origin URL. Run $ git remote --help for details. n.b. details of what remot repos are in use is actually stored in file .git/config so if you are feeling brave you could just tweak that by hand to replace https://github.com:/theRealAph/graal-core.git with git at github.com:theRealAph/graal-core.git 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 tom.rodriguez at oracle.com Wed Jan 25 04:31:14 2017 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 24 Jan 2017 20:31:14 -0800 Subject: Library dependencies In-Reply-To: <4a2d7b6a-9922-a2e4-6909-ff6c7efb1dd3@redhat.com> References: <4a2d7b6a-9922-a2e4-6909-ff6c7efb1dd3@redhat.com> Message-ID: <58882A12.2050309@oracle.com> Andrew Haley wrote: > I'm having a problem where I need to import a library into one of > the AArch64 projects. I can tell Eclipse to do this and Eclipse is > happy, but it doesn't seem to work with "mx build". > > Is there something I need to do to tell mx that I have a new library > dependency? All dependencies have to be described in the suite.py file. Do you really mean a new library or a new project? I'm assuming you really project. There are cross project dependencies described in the suite.py and it's reasonably self explanatory. Are you update them, you have to rerun "mx ideinit" to regenerate the project files with the new project dependencies. mx requires that the suite dependencies are canonically formed so it might complain and what you to rearrange them. It should tell you what to do about it. But if you are just adding a project dependency to some leaf project it's very easy. tom > > Thanks, > > Andrew. From doug.simon at oracle.com Wed Jan 25 09:01:44 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 25 Jan 2017 10:01:44 +0100 Subject: Library dependencies In-Reply-To: <4a2d7b6a-9922-a2e4-6909-ff6c7efb1dd3@redhat.com> References: <4a2d7b6a-9922-a2e4-6909-ff6c7efb1dd3@redhat.com> Message-ID: <8F2D0337-48A7-4391-A069-21E432708363@oracle.com> What library do you need? If you want to add the dependency to Graal on github, we will need to go through an inbounding evaluation process before considering to integrate it. If you just want a local change, then put the jar file on a server you can reach and follow the pattern for the pattern of the DACAPO library in graal?s suite.py. -Doug > On 24 Jan 2017, at 18:10, Andrew Haley wrote: > > I'm having a problem where I need to import a library into one of > the AArch64 projects. I can tell Eclipse to do this and Eclipse is > happy, but it doesn't seem to work with "mx build". > > Is there something I need to do to tell mx that I have a new library > dependency? > > Thanks, > > Andrew. From doug.simon at oracle.com Thu Jan 26 19:57:04 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 26 Jan 2017 20:57:04 +0100 Subject: Developing Graal now requires JDK 8 In-Reply-To: References: <66B338A3-FA66-4629-B2E0-035BF5409755@oracle.com> <65df73f2-c37c-b0fc-82e8-df0794860990@oracle.com> <6EFE43BA-F95A-4F65-8EE6-3E4881F417ED@oracle.com> <81EE9F09-533F-45C1-A13D-A80696BA57BA@oracle.com> <2996CB5E-7BD3-453F-AFE8-6FE21A0541B4@oracle.com> <9CD62237-F8F3-4288-9C90-F30AF33A55A8@oracle.com> <5851D5F8.5070707@oracle.com> <2E37DE96-50C4-4977-9000-56199AF76546@oracle.com> <0b772725-d84a-9f5c-c225-f1b59998816a@oracle.com> <5cb5ee72-39f1-9046-0533-de1e94c866b9@oracle.com> <5852E6CE.7020309@oracle.com> <47022D62-D217-4B0B-AFB8-85606423530D@oracle.com> <046305c5-274d-78e6-d42d-c74a5574f22d@oracle.com> <322A844D-1EC0-450E-8F7A-8AFEE1E26A27@oracle.com> <2ac63b0a-c10f-eb41-b9f3-8a84f3776a6c@oracle.com> <3F0509E2-AFE0-4013-8BF7-A2FAD1F5469A@oracle.com> Message-ID: <9DF5B9C3-63CA-4F3A-A1E6-A6423DBB358F@oracle.com> Hi jigsaw experts, As detailed in https://bugs.openjdk.java.net/browse/JDK-8171448, we are now in the unfortunate position of being forced to use a JDK 8 in the ongoing development of Graal. In particular, given the fine grained way we compose the jdk.vm.compiler module[1] (i.e., we don?t compile all its sources in one javac compilation) we now need to compile Graal (sources and tests) with javac from JDK 8. Using javac from JDK 9 always picks up the jdk.vm.compiler classes in the JDK instead of the newer version of the classes. It may be a naive suggestion, but what we?d really like is support for module exclusion (e.g., --exclude-modules=jdk.vm.compiler). To help me understand if there?s an existing solution I?m missing, can someone please tell me how a change in some java.base API would be developed. For example, suppose that this method is added to String: String truncate(int trailingCharsToChop) { ... } How would other code in the java.base module be compiled against the new API? By virtue of being compiled along with the new String source file? What about compiling code in other modules (or tests) that wants to use the new method? That is, how does one convince javac to see the new API? Note that this constraint is particular painful for the AArch64 Graal port. The version of JDK 8 we use[2] includes a port of JVMCI (that we hope to get into an official JDK 8u backport). However, there is no such bundle for AArch64 so hacky workarounds are required[3][4]. Any light you can shed on how we can develop Graal with (only) a JDK >8 would be much appreciated. -Doug [1] Which is complicated enough due to https://bugs.openjdk.java.net/browse/JDK-8155851 [2] labsjdk* at http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html [3] http://mail.openjdk.java.net/pipermail/graal-dev/2017-January/004796.html [4] http://mail.openjdk.java.net/pipermail/graal-dev/2017-January/004800.html From Alan.Bateman at oracle.com Thu Jan 26 22:06:36 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 26 Jan 2017 22:06:36 +0000 Subject: Developing Graal now requires JDK 8 In-Reply-To: <9DF5B9C3-63CA-4F3A-A1E6-A6423DBB358F@oracle.com> References: <66B338A3-FA66-4629-B2E0-035BF5409755@oracle.com> <65df73f2-c37c-b0fc-82e8-df0794860990@oracle.com> <6EFE43BA-F95A-4F65-8EE6-3E4881F417ED@oracle.com> <81EE9F09-533F-45C1-A13D-A80696BA57BA@oracle.com> <2996CB5E-7BD3-453F-AFE8-6FE21A0541B4@oracle.com> <9CD62237-F8F3-4288-9C90-F30AF33A55A8@oracle.com> <5851D5F8.5070707@oracle.com> <2E37DE96-50C4-4977-9000-56199AF76546@oracle.com> <0b772725-d84a-9f5c-c225-f1b59998816a@oracle.com> <5cb5ee72-39f1-9046-0533-de1e94c866b9@oracle.com> <5852E6CE.7020309@oracle.com> <47022D62-D217-4B0B-AFB8-85606423530D@oracle.com> <046305c5-274d-78e6-d42d-c74a5574f22d@oracle.com> <322A844D-1EC0-450E-8F7A-8AFEE1E26A27@oracle.com> <2ac63b0a-c10f-eb41-b9f3-8a84f3776a6c@oracle.com> <3F0509E2-AFE0-4013-8BF7-A2FAD1F5469A@oracle.com> <9DF5B9C3-63CA-4F3A-A1E6-A6423DBB358F@oracle.com> Message-ID: <43981878-d3aa-d74e-d578-4b106b678d4f@oracle.com> On 26/01/2017 19:57, Doug Simon wrote: > Hi jigsaw experts, > > As detailed in https://bugs.openjdk.java.net/browse/JDK-8171448, we are now in the unfortunate position of being forced to use a JDK 8 in the ongoing development of Graal. In particular, given the fine grained way we compose the jdk.vm.compiler module[1] (i.e., we don?t compile all its sources in one javac compilation) we now need to compile Graal (sources and tests) with javac from JDK 8. Using javac from JDK 9 always picks up the jdk.vm.compiler classes in the JDK instead of the newer version of the classes. It may be a naive suggestion, but what we?d really like is support for module exclusion (e.g., --exclude-modules=jdk.vm.compiler). > > To help me understand if there?s an existing solution I?m missing, can someone please tell me how a change in some java.base API would be developed. For example, suppose that this method is added to String: > > String truncate(int trailingCharsToChop) { ... } > > How would other code in the java.base module be compiled against the new API? By virtue of being compiled along with the new String source file? > > What about compiling code in other modules (or tests) that wants to use the new method? That is, how does one convince javac to see the new API? This should do it: javac -Xmodule:java.base -d patch String.java // compile module against the patched java.base javac --patch-module java.base=patch ... // run with the patched java.base java --patch-module java.base=patch ... > Note that this constraint is particular painful for the AArch64 Graal port. The version of JDK 8 we use[2] includes a port of JVMCI (that we hope to get into an official JDK 8u backport). However, there is no such bundle for AArch64 so hacky workarounds are required[3][4]. > > Any light you can shed on how we can develop Graal with (only) a JDK >8 would be much appreciated. > It seems to me that you really want to override jdk.vm.compiler and maybe we should explore again making this an upgradeable module. -Alan From doug.simon at oracle.com Sun Jan 29 20:13:54 2017 From: doug.simon at oracle.com (Doug Simon) Date: Sun, 29 Jan 2017 21:13:54 +0100 Subject: Developing Graal now requires JDK 8 In-Reply-To: <43981878-d3aa-d74e-d578-4b106b678d4f@oracle.com> References: <66B338A3-FA66-4629-B2E0-035BF5409755@oracle.com> <65df73f2-c37c-b0fc-82e8-df0794860990@oracle.com> <6EFE43BA-F95A-4F65-8EE6-3E4881F417ED@oracle.com> <81EE9F09-533F-45C1-A13D-A80696BA57BA@oracle.com> <2996CB5E-7BD3-453F-AFE8-6FE21A0541B4@oracle.com> <9CD62237-F8F3-4288-9C90-F30AF33A55A8@oracle.com> <5851D5F8.5070707@oracle.com> <2E37DE96-50C4-4977-9000-56199AF76546@oracle.com> <0b772725-d84a-9f5c-c225-f1b59998816a@oracle.com> <5cb5ee72-39f1-9046-0533-de1e94c866b9@oracle.com> <5852E6CE.7020309@oracle.com> <47022D62-D217-4B0B-AFB8-85606423530D@oracle.com> <046305c5-274d-78e6-d42d-c74a5574f22d@oracle.com> <322A844D-1EC0-450E-8F7A-8AFEE1E26A27@oracle.com> <2ac63b0a-c10f-eb41-b9f3-8a84f3776a6c@oracle.com> <3F0509E2-AFE0-4013-8BF7-A2FAD1F5469A@oracle.com> <9DF5B9C3-63CA-4F3A-A1E6-A6423DBB358F@oracle.com> <43981878-d3aa-d74e-d578-4b106b678d4f@oracle.com> Message-ID: <912AB610-843E-47B1-8F29-3CF4160EBCAB@oracle.com> > On 26 Jan 2017, at 23:06, Alan Bateman wrote: > > On 26/01/2017 19:57, Doug Simon wrote: > >> Hi jigsaw experts, >> >> As detailed in https://bugs.openjdk.java.net/browse/JDK-8171448, we are now in the unfortunate position of being forced to use a JDK 8 in the ongoing development of Graal. In particular, given the fine grained way we compose the jdk.vm.compiler module[1] (i.e., we don?t compile all its sources in one javac compilation) we now need to compile Graal (sources and tests) with javac from JDK 8. Using javac from JDK 9 always picks up the jdk.vm.compiler classes in the JDK instead of the newer version of the classes. It may be a naive suggestion, but what we?d really like is support for module exclusion (e.g., --exclude-modules=jdk.vm.compiler). >> >> To help me understand if there?s an existing solution I?m missing, can someone please tell me how a change in some java.base API would be developed. For example, suppose that this method is added to String: >> >> String truncate(int trailingCharsToChop) { ... } >> >> How would other code in the java.base module be compiled against the new API? By virtue of being compiled along with the new String source file? >> >> What about compiling code in other modules (or tests) that wants to use the new method? That is, how does one convince javac to see the new API? > > This should do it: > > javac -Xmodule:java.base -d patch String.java > > // compile module against the patched java.base > javac --patch-module java.base=patch ? But --patch-module doesn?t allow you to replace module-info.class. Consider separate javac compilations, A and B where A compiles the core Graal packages and B compiles subsequent Graal packages that depend on the packages in compilation A. Since the jdk.vm.compiler module-info.class in the JDK does not publicly export the packages in A, compilation B will fail with access violations. Even if --patch-module could replace module-info.class, the way we compile the packages in Graal means we?d need to synthesize intermediate versions of module-info.class, representing the packages currently available on the argument to --patch-module. All this reenforces my feeling that one simply cannot compose a module from separate javac compilations when that module is already in the JDK and visible to javac. Hence the need for an option like --exclude-modules. > > // run with the patched java.base > java --patch-module java.base=patch ? > >> Note that this constraint is particular painful for the AArch64 Graal port. The version of JDK 8 we use[2] includes a port of JVMCI (that we hope to get into an official JDK 8u backport). However, there is no such bundle for AArch64 so hacky workarounds are required[3][4]. >> >> Any light you can shed on how we can develop Graal with (only) a JDK >8 would be much appreciated. >> > It seems to me that you really want to override jdk.vm.compiler and maybe we should explore again making this an upgradeable module. Would that help make it possible to do multi-javac-compilation construction of the upgradeable module as described above? -Doug From Alan.Bateman at oracle.com Mon Jan 30 10:40:01 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 30 Jan 2017 10:40:01 +0000 Subject: Developing Graal now requires JDK 8 In-Reply-To: <912AB610-843E-47B1-8F29-3CF4160EBCAB@oracle.com> References: <66B338A3-FA66-4629-B2E0-035BF5409755@oracle.com> <81EE9F09-533F-45C1-A13D-A80696BA57BA@oracle.com> <2996CB5E-7BD3-453F-AFE8-6FE21A0541B4@oracle.com> <9CD62237-F8F3-4288-9C90-F30AF33A55A8@oracle.com> <5851D5F8.5070707@oracle.com> <2E37DE96-50C4-4977-9000-56199AF76546@oracle.com> <0b772725-d84a-9f5c-c225-f1b59998816a@oracle.com> <5cb5ee72-39f1-9046-0533-de1e94c866b9@oracle.com> <5852E6CE.7020309@oracle.com> <47022D62-D217-4B0B-AFB8-85606423530D@oracle.com> <046305c5-274d-78e6-d42d-c74a5574f22d@oracle.com> <322A844D-1EC0-450E-8F7A-8AFEE1E26A27@oracle.com> <2ac63b0a-c10f-eb41-b9f3-8a84f3776a6c@oracle.com> <3F0509E2-AFE0-4013-8BF7-A2FAD1F5469A@oracle.com> <9DF5B9C3-63CA-4F3A-A1E6-A6423DBB358F@oracle.com> <43981878-d3aa-d74e-d578-4b106b678d4f@oracle.com> <912AB610-843E-47B1-8F29-3CF4160EBCAB@oracle.com> Message-ID: On 29/01/2017 20:13, Doug Simon wrote: >> On 26 Jan 2017, at 23:06, Alan Bateman wrote: >> >> On 26/01/2017 19:57, Doug Simon wrote: >> >>> Hi jigsaw experts, >>> >>> As detailed in https://bugs.openjdk.java.net/browse/JDK-8171448, we are now in the unfortunate position of being forced to use a JDK 8 in the ongoing development of Graal. In particular, given the fine grained way we compose the jdk.vm.compiler module[1] (i.e., we don?t compile all its sources in one javac compilation) we now need to compile Graal (sources and tests) with javac from JDK 8. Using javac from JDK 9 always picks up the jdk.vm.compiler classes in the JDK instead of the newer version of the classes. It may be a naive suggestion, but what we?d really like is support for module exclusion (e.g., --exclude-modules=jdk.vm.compiler). >>> >>> To help me understand if there?s an existing solution I?m missing, can someone please tell me how a change in some java.base API would be developed. For example, suppose that this method is added to String: >>> >>> String truncate(int trailingCharsToChop) { ... } >>> >>> How would other code in the java.base module be compiled against the new API? By virtue of being compiled along with the new String source file? >>> >>> What about compiling code in other modules (or tests) that wants to use the new method? That is, how does one convince javac to see the new API? >> This should do it: >> >> javac -Xmodule:java.base -d patch String.java >> >> // compile module against the patched java.base >> javac --patch-module java.base=patch ? > But --patch-module doesn?t allow you to replace module-info.class. Right, but that is not a concern for the String.truncate example. Patching was never intended to replace the module declaration, it is instead the approximate equivalent of -Xbootclasspath/p to override classes. When patching a module then the module declaration can be augmented with --add-reads and --add-exports at either compile or run time. > Consider separate javac compilations, A and B where A compiles the core Graal packages and B compiles subsequent Graal packages that depend on the packages in compilation A. Since the jdk.vm.compiler module-info.class in the JDK does not publicly export the packages in A, compilation B will fail with access violations. Even if --patch-module could replace module-info.class, the way we compile the packages in Graal means we?d need to synthesize intermediate versions of module-info.class, representing the packages currently available on the argument to --patch-module. All this reenforces my feeling that one simply cannot compose a module from separate javac compilations when that module is already in the JDK and visible to javac. Hence the need for an option like --exclude-modules. I think the separate compilation just means there is series of complicated commands but ultimately you are looking to build and run with a completely different version of jdk.vm.compiler. All I can suggest is that we look again at making jdk.vm.compiler an upgradeable module and part of that would be working through whatever issues there are with the separate compilation. -Alan From adinn at redhat.com Mon Jan 30 13:03:04 2017 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 30 Jan 2017 13:03:04 +0000 Subject: Problem adding match rule for (ReadNode address) Message-ID: I have been trying to add a match rule for a ReadNode to the AArch64 graal LIRGenerator and was foiled by the following bug (which has been accidentally side-stepped by the x86 implementation -- details below). If I add a match rule/handler method to the end of class AArch64NodeMatchRules as follows graal/org.graalvm.compiler.core.aarch64/src/org/graalvm/compiler/core/aarch64/AArch64NodeMatchRules.java @@ -33,6 +33,8 @@ import org.graalvm.compiler.nodes.DeoptimizingNode; import org.graalvm.compiler.nodes.calc.SignExtendNode; import org.graalvm.compiler.nodes.calc.ZeroExtendNode; import org.graalvm.compiler.nodes.memory.Access; +import org.graalvm.compiler.nodes.memory.ReadNode; +import org.graalvm.compiler.nodes.ValueNode; import jdk.vm.ci.aarch64.AArch64Kind; @@ -75,4 +77,9 @@ public class AArch64NodeMatchRules extends NodeMatchRules { AArch64Kind memoryKind = getMemoryKind(access); return builder -> getArithmeticLIRGenerator().emitExtendMemory(true, memoryKind, root.getResultBits(), (AArch64AddressValue) operand(access.getAddress()), getState(access)); } + + @MatchRule("(Read address)") + public ComplexMatchResult checkRead(ReadNode root, ValueNode address) { + return null; + } } then the build process fails as follows. Compiling org.graalvm.compiler.replacements.amd64 with javac-daemon... [dependency GRAAL_NODEINFO_PROCESSOR updated] /home/adinn/openjdk/graal/graal-core/mxbuild/graal/org.graalvm.compiler.core.aarch64/src_gen/org/graalvm/compiler/core/aarch64/AArch64NodeMatchRules_MatchStatementSet.java:23: error: cannot find symbol return ((AArch64NodeMatchRules) nodeMatchRules).checkRead((ReadNode) args[0], (ValueNode) args[1]); ^ symbol: class ValueNode location: class MatchGenerator_checkRead 1 error The error happens because the generated matching engine code in AArch64NodeMatchRules_MatchStatementSet.java does not include an import declaration for class ValueNode. Imports are only generated for the packages to which root nodes of matched terms and subterms belong but not for packages containing Value arguments like address. Note that the corresponding x86 code successfully employs match rules which refer to ValueNode arguments because it includes rules (e.g. the ones for IfNode) whose root nodes lie in the same package as ValueNode. The fix is to modify class MatchProcessor so it always generates an import for ValueNode +++ b/graal/org.graalvm.compiler.core.match.processor/src/org/graalvm/compiler/core/match/processor/MatchProcessor.java @@ -521,6 +521,7 @@ public class MatchProcessor extends AbstractProcessor { out.println("import " + NodeMatchRules.class.getName() + ";"); out.println("import " + Position.class.getName() + ";"); out.println("import " + ServiceProvider.class.getName() + ";"); + out.println("import " + ValueNode.class.getName() + ";"); for (String p : info.requiredPackages) { out.println("import " + p + ".*;"); } Do you need this patch to be submitted via a github pull request? Do I need to raise an associated issue? 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 Mon Jan 30 13:12:25 2017 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 30 Jan 2017 14:12:25 +0100 Subject: Problem adding match rule for (ReadNode address) In-Reply-To: References: Message-ID: <25FE0423-B67B-450A-A55E-D6F26024EB16@oracle.com> Hi Andrew, > On 30 Jan 2017, at 14:03, Andrew Dinn wrote: > > I have been trying to add a match rule for a ReadNode to the AArch64 > graal LIRGenerator and was foiled by the following bug (which has been > accidentally side-stepped by the x86 implementation -- details below). > > If I add a match rule/handler method to the end of class > AArch64NodeMatchRules as follows > > graal/org.graalvm.compiler.core.aarch64/src/org/graalvm/compiler/core/aarch64/AArch64NodeMatchRules.java > @@ -33,6 +33,8 @@ import org.graalvm.compiler.nodes.DeoptimizingNode; > import org.graalvm.compiler.nodes.calc.SignExtendNode; > import org.graalvm.compiler.nodes.calc.ZeroExtendNode; > import org.graalvm.compiler.nodes.memory.Access; > +import org.graalvm.compiler.nodes.memory.ReadNode; > +import org.graalvm.compiler.nodes.ValueNode; > > import jdk.vm.ci.aarch64.AArch64Kind; > > @@ -75,4 +77,9 @@ public class AArch64NodeMatchRules extends > NodeMatchRules { > AArch64Kind memoryKind = getMemoryKind(access); > return builder -> > getArithmeticLIRGenerator().emitExtendMemory(true, memoryKind, > root.getResultBits(), (AArch64AddressValue) > operand(access.getAddress()), getState(access)); > } > + > + @MatchRule("(Read address)") > + public ComplexMatchResult checkRead(ReadNode root, ValueNode address) { > + return null; > + } > } > > then the build process fails as follows. > > Compiling org.graalvm.compiler.replacements.amd64 with javac-daemon... > [dependency GRAAL_NODEINFO_PROCESSOR updated] > /home/adinn/openjdk/graal/graal-core/mxbuild/graal/org.graalvm.compiler.core.aarch64/src_gen/org/graalvm/compiler/core/aarch64/AArch64NodeMatchRules_MatchStatementSet.java:23: > error: cannot find symbol > return ((AArch64NodeMatchRules) > nodeMatchRules).checkRead((ReadNode) args[0], (ValueNode) args[1]); > > ^ > symbol: class ValueNode > location: class MatchGenerator_checkRead > 1 error > > The error happens because the generated matching engine code in > AArch64NodeMatchRules_MatchStatementSet.java does not include an import > declaration for class ValueNode. Imports are only generated for the > packages to which root nodes of matched terms and subterms belong but > not for packages containing Value arguments like address. > > Note that the corresponding x86 code successfully employs match rules > which refer to ValueNode arguments because it includes rules (e.g. the > ones for IfNode) whose root nodes lie in the same package as ValueNode. > > The fix is to modify class MatchProcessor so it always generates an > import for ValueNode > > +++ > b/graal/org.graalvm.compiler.core.match.processor/src/org/graalvm/compiler/core/match/processor/MatchProcessor.java > @@ -521,6 +521,7 @@ public class MatchProcessor extends AbstractProcessor { > out.println("import " + NodeMatchRules.class.getName() + ";"); > out.println("import " + Position.class.getName() + ";"); > out.println("import " + ServiceProvider.class.getName() + ";"); > + out.println("import " + ValueNode.class.getName() + ";"); > for (String p : info.requiredPackages) { > out.println("import " + p + ".*;"); > } > > Do you need this patch to be submitted via a github pull request? Do I > need to raise an associated issue? Thanks for finding and reporting the bug, complete with a fix. For such a small fix, it?s easiest for you to raise an issue on github instead of creating a pull request. Once you?ve opened the github issue, I?ll assign it to someone. -Doug From gilles.m.duboscq at oracle.com Mon Jan 30 13:13:01 2017 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Mon, 30 Jan 2017 14:13:01 +0100 Subject: Problem adding match rule for (ReadNode address) In-Reply-To: References: Message-ID: Hi Andrew, If you can make a pull-request on the github repo that would be ideal. Thanks, Gilles On 01/30/2017 02:03 PM, Andrew Dinn wrote: > I have been trying to add a match rule for a ReadNode to the AArch64 > graal LIRGenerator and was foiled by the following bug (which has been > accidentally side-stepped by the x86 implementation -- details below). > > If I add a match rule/handler method to the end of class > AArch64NodeMatchRules as follows > > graal/org.graalvm.compiler.core.aarch64/src/org/graalvm/compiler/core/aarch64/AArch64NodeMatchRules.java > @@ -33,6 +33,8 @@ import org.graalvm.compiler.nodes.DeoptimizingNode; > import org.graalvm.compiler.nodes.calc.SignExtendNode; > import org.graalvm.compiler.nodes.calc.ZeroExtendNode; > import org.graalvm.compiler.nodes.memory.Access; > +import org.graalvm.compiler.nodes.memory.ReadNode; > +import org.graalvm.compiler.nodes.ValueNode; > > import jdk.vm.ci.aarch64.AArch64Kind; > > @@ -75,4 +77,9 @@ public class AArch64NodeMatchRules extends > NodeMatchRules { > AArch64Kind memoryKind = getMemoryKind(access); > return builder -> > getArithmeticLIRGenerator().emitExtendMemory(true, memoryKind, > root.getResultBits(), (AArch64AddressValue) > operand(access.getAddress()), getState(access)); > } > + > + @MatchRule("(Read address)") > + public ComplexMatchResult checkRead(ReadNode root, ValueNode address) { > + return null; > + } > } > > then the build process fails as follows. > > Compiling org.graalvm.compiler.replacements.amd64 with javac-daemon... > [dependency GRAAL_NODEINFO_PROCESSOR updated] > /home/adinn/openjdk/graal/graal-core/mxbuild/graal/org.graalvm.compiler.core.aarch64/src_gen/org/graalvm/compiler/core/aarch64/AArch64NodeMatchRules_MatchStatementSet.java:23: > error: cannot find symbol > return ((AArch64NodeMatchRules) > nodeMatchRules).checkRead((ReadNode) args[0], (ValueNode) args[1]); > > ^ > symbol: class ValueNode > location: class MatchGenerator_checkRead > 1 error > > The error happens because the generated matching engine code in > AArch64NodeMatchRules_MatchStatementSet.java does not include an import > declaration for class ValueNode. Imports are only generated for the > packages to which root nodes of matched terms and subterms belong but > not for packages containing Value arguments like address. > > Note that the corresponding x86 code successfully employs match rules > which refer to ValueNode arguments because it includes rules (e.g. the > ones for IfNode) whose root nodes lie in the same package as ValueNode. > > The fix is to modify class MatchProcessor so it always generates an > import for ValueNode > > +++ > b/graal/org.graalvm.compiler.core.match.processor/src/org/graalvm/compiler/core/match/processor/MatchProcessor.java > @@ -521,6 +521,7 @@ public class MatchProcessor extends AbstractProcessor { > out.println("import " + NodeMatchRules.class.getName() + ";"); > out.println("import " + Position.class.getName() + ";"); > out.println("import " + ServiceProvider.class.getName() + ";"); > + out.println("import " + ValueNode.class.getName() + ";"); > for (String p : info.requiredPackages) { > out.println("import " + p + ".*;"); > } > > Do you need this patch to be submitted via a github pull request? Do I > need to raise an associated issue? > > 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 Mon Jan 30 14:29:11 2017 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 30 Jan 2017 14:29:11 +0000 Subject: Problem adding match rule for (ReadNode address) In-Reply-To: <25FE0423-B67B-450A-A55E-D6F26024EB16@oracle.com> References: <25FE0423-B67B-450A-A55E-D6F26024EB16@oracle.com> Message-ID: <3b5bf36f-82e6-5bfa-6256-47172cfb5dcb@redhat.com> On 30/01/17 13:12, Doug Simon wrote: > Thanks for finding and reporting the bug, complete with a fix. > > For such a small fix, it?s easiest for you to raise an issue on github instead of creating a pull request. Once you?ve opened the github issue, I?ll assign it to someone. Thanks for looking at this Doug. Here is the issue complete with link to the original post and the one line fix. https://github.com/graalvm/graal-core/issues/247 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