From aph at redhat.com Wed Feb 1 18:42:33 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 1 Feb 2017 18:42:33 +0000 Subject: Deprecation warnings Message-ID: /nfs/zebedee/home/graal/aph/truffle/truffle/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Scanner.java:388: warning: [deprecation] Integer(int) in Integer has been deprecated literals.put("return", new Integer(17)); There are too many of these. Shall I just fix them all? Andrew. From doug.simon at oracle.com Wed Feb 1 18:51:52 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 1 Feb 2017 19:51:52 +0100 Subject: Deprecation warnings In-Reply-To: References: Message-ID: > On 1 Feb 2017, at 19:42, Andrew Haley wrote: > > /nfs/zebedee/home/graal/aph/truffle/truffle/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Scanner.java:388: warning: [deprecation] Integer(int) in Integer has been deprecated > literals.put("return", new Integer(17)); > > There are too many of these. Shall I just fix them all? No - we?re stuck with those because these methods are not deprecated on jdk8. So if you use SuppressWarnings, you?ll get a warning on jdk8 about an unnecessary suppression! -Doug From tom.rodriguez at oracle.com Wed Feb 1 18:55:57 2017 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 01 Feb 2017 10:55:57 -0800 Subject: Deprecation warnings In-Reply-To: References: Message-ID: <58922F3D.90600@oracle.com> Doug Simon wrote: >> On 1 Feb 2017, at 19:42, Andrew Haley wrote: >> >> /nfs/zebedee/home/graal/aph/truffle/truffle/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Scanner.java:388: warning: [deprecation] Integer(int) in Integer has been deprecated >> literals.put("return", new Integer(17)); >> >> There are too many of these. Shall I just fix them all? > > No - we?re stuck with those because these methods are not deprecated on jdk8. So if you use SuppressWarnings, you?ll get a warning on jdk8 about an unnecessary suppression! Well they can be changed to use valueOf instead, though for test cases I think we'll need to make sure we don't actually care about object identity. Those I think we're stuck with. That's going to be a very painful deprecation warning for lots of people. tom From aph at redhat.com Wed Feb 1 19:12:36 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 1 Feb 2017 19:12:36 +0000 Subject: mx canonicalizeprojects Message-ID: <0a4b93ba-112a-a62f-f0b8-ab9e85b2d057@redhat.com> gate: 01 Feb 2017 17:00:25: ABORT: Canonicalization Check [0:00:00.221677] [disk (free/total): 11.4GB/29.5GB] gate: 01 Feb 2017 17:00:25: END: Canonicalization Check [0:00:00.221808] [disk (free/total): 11.4GB/29.5GB] Traceback (most recent call last): File "/home/travis/build/graalvm/mx/mx_gate.py", line 337, in gate t.abort('Rerun "mx canonicalizeprojects" and check-in the modified mx/suite*.py files.') File "/home/travis/build/graalvm/mx/mx_gate.py", line 162, in abort mx.abort(codeOrMessage) File "/home/travis/build/graalvm/mx/mx.py", line 9521, in abort raise SystemExit(codeOrMessage) SystemExit: Rerun "mx canonicalizeprojects" and check-in the modified mx/suite*.py files. gate: 01 Feb 2017 17:00:25: ABORT: Gate [0:00:07.782852] [disk (free/total): 11.4GB/29.5GB] Rerun "mx canonicalizeprojects" and check-in the modified mx/suite*.py files. So I do this: aph at arm64:/nfs/zebedee/home/graal/aph/graal-core$ mx canonicalizeprojects File "/nfs/zebedee/home/graal/aph/graal-core/mx.graal-core/suite.py", line 1237 in definition of org.graalvm.compiler.truffle.hotspot.aarch64: Canonical dependencies for project org.graalvm.compiler.truffle.hotspot.aarch64 are: [ "org.graalvm.compiler.hotspot.aarch64", "org.graalvm.compiler.truffle.hotspot", ], When I run "mx canonicalizeprojects", suite.py does not change. So what is it complaining about? Andrew. From doug.simon at oracle.com Wed Feb 1 19:13:04 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 1 Feb 2017 20:13:04 +0100 Subject: Deprecation warnings In-Reply-To: <58922F3D.90600@oracle.com> References: <58922F3D.90600@oracle.com> Message-ID: <206E78D6-EE41-41C9-8096-B61B9619AB49@oracle.com> > On 1 Feb 2017, at 19:55, Tom Rodriguez wrote: > > > > Doug Simon wrote: >>> On 1 Feb 2017, at 19:42, Andrew Haley wrote: >>> >>> /nfs/zebedee/home/graal/aph/truffle/truffle/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Scanner.java:388: warning: [deprecation] Integer(int) in Integer has been deprecated >>> literals.put("return", new Integer(17)); >>> >>> There are too many of these. Shall I just fix them all? >> >> No - we?re stuck with those because these methods are not deprecated on jdk8. So if you use SuppressWarnings, you?ll get a warning on jdk8 about an unnecessary suppression! > > Well they can be changed to use valueOf instead, though for test cases I think we'll need to make sure we don't actually care about object identity. Those I think we're stuck with. That's going to be a very painful deprecation warning for lots of people. Yes, we can change the ones where identity doesn?t matter. I hadn?t looked closely and assumed most uses require identity semantics. -Doug From doug.simon at oracle.com Wed Feb 1 19:15:04 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 1 Feb 2017 20:15:04 +0100 Subject: mx canonicalizeprojects In-Reply-To: <0a4b93ba-112a-a62f-f0b8-ab9e85b2d057@redhat.com> References: <0a4b93ba-112a-a62f-f0b8-ab9e85b2d057@redhat.com> Message-ID: The error message is (now) wrong. It was written when the suite.py format was a properties files and so mx could easily fix the issues in place. You need to make the recommended edits manually. I?ll fix the error message. -Doug > On 1 Feb 2017, at 20:12, Andrew Haley wrote: > > gate: 01 Feb 2017 17:00:25: ABORT: Canonicalization Check [0:00:00.221677] [disk (free/total): 11.4GB/29.5GB] > gate: 01 Feb 2017 17:00:25: END: Canonicalization Check [0:00:00.221808] [disk (free/total): 11.4GB/29.5GB] > Traceback (most recent call last): > File "/home/travis/build/graalvm/mx/mx_gate.py", line 337, in gate > t.abort('Rerun "mx canonicalizeprojects" and check-in the modified mx/suite*.py files.') > File "/home/travis/build/graalvm/mx/mx_gate.py", line 162, in abort > mx.abort(codeOrMessage) > File "/home/travis/build/graalvm/mx/mx.py", line 9521, in abort > raise SystemExit(codeOrMessage) > > SystemExit: Rerun "mx canonicalizeprojects" and check-in the modified mx/suite*.py files. > gate: 01 Feb 2017 17:00:25: ABORT: Gate [0:00:07.782852] [disk (free/total): 11.4GB/29.5GB] > Rerun "mx canonicalizeprojects" and check-in the modified mx/suite*.py files. > > So I do this: > > aph at arm64:/nfs/zebedee/home/graal/aph/graal-core$ mx canonicalizeprojects > File "/nfs/zebedee/home/graal/aph/graal-core/mx.graal-core/suite.py", line 1237 in definition of org.graalvm.compiler.truffle.hotspot.aarch64: > Canonical dependencies for project org.graalvm.compiler.truffle.hotspot.aarch64 are: [ > "org.graalvm.compiler.hotspot.aarch64", > "org.graalvm.compiler.truffle.hotspot", > ], > > When I run "mx canonicalizeprojects", suite.py does not change. So > what is it complaining about? > > Andrew. From aph at redhat.com Wed Feb 1 19:16:58 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 1 Feb 2017 19:16:58 +0000 Subject: mx canonicalizeprojects In-Reply-To: References: <0a4b93ba-112a-a62f-f0b8-ab9e85b2d057@redhat.com> Message-ID: <8771d6c4-98f2-52a1-7e2d-3fc9c9f36e33@redhat.com> On 01/02/17 19:15, Doug Simon wrote: > The error message is (now) wrong. It was written when the suite.py format was a properties files and so mx could easily fix the issues in place. You need to make the recommended edits manually. I?ll fix the error message. OK, but I don't know what the recommended edits are. I already edited that file and the build succeeds; what more can it possibly want? Andrew. From doug.simon at oracle.com Wed Feb 1 19:30:55 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 1 Feb 2017 20:30:55 +0100 Subject: mx canonicalizeprojects In-Reply-To: <8771d6c4-98f2-52a1-7e2d-3fc9c9f36e33@redhat.com> References: <0a4b93ba-112a-a62f-f0b8-ab9e85b2d057@redhat.com> <8771d6c4-98f2-52a1-7e2d-3fc9c9f36e33@redhat.com> Message-ID: <94C31528-036B-4E66-90F3-71BE0984A1B3@oracle.com> > On 1 Feb 2017, at 20:16, Andrew Haley wrote: > > On 01/02/17 19:15, Doug Simon wrote: >> The error message is (now) wrong. It was written when the suite.py format was a properties files and so mx could easily fix the issues in place. You need to make the recommended edits manually. I?ll fix the error message. > > OK, but I don't know what the recommended edits are. I already edited that > file and the build succeeds; what more can it possibly want? So are the dependencies for org.graalvm.compiler.truffle.hotspot.aarch64 exactly: [ "org.graalvm.compiler.hotspot.aarch64?, ?org.graalvm.compiler.truffle.hotspot? ] -Doug From forax at univ-mlv.fr Wed Feb 1 22:10:26 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 01 Feb 2017 22:10:26 +0000 Subject: Deprecation warnings In-Reply-To: <58922F3D.90600@oracle.com> References: <58922F3D.90600@oracle.com> Message-ID: yes, it's in preparation of the addition of value type. Being able to retrofit Integer to a value type may never occur (you loose the identity) but if we want to have a chance to try, the direct call to its constructor has to be deprecated. Remi On February 1, 2017 7:55:57 PM GMT+01:00, Tom Rodriguez wrote: > > >Doug Simon wrote: >>> On 1 Feb 2017, at 19:42, Andrew Haley wrote: >>> >>> >/nfs/zebedee/home/graal/aph/truffle/truffle/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Scanner.java:388: >warning: [deprecation] Integer(int) in Integer has been deprecated >>> literals.put("return", new Integer(17)); >>> >>> There are too many of these. Shall I just fix them all? >> >> No - we?re stuck with those because these methods are not deprecated >on jdk8. So if you use SuppressWarnings, you?ll get a warning on jdk8 >about an unnecessary suppression! > >Well they can be changed to use valueOf instead, though for test cases >I >think we'll need to make sure we don't actually care about object >identity. Those I think we're stuck with. That's going to be a very >painful deprecation warning for lots of people. > >tom -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From thomas.wuerthinger at oracle.com Wed Feb 1 23:11:41 2017 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Thu, 2 Feb 2017 00:11:41 +0100 Subject: Deprecation warnings In-Reply-To: <58922F3D.90600@oracle.com> References: <58922F3D.90600@oracle.com> Message-ID: We could define our own Integer class and avoid using java.lang.Integer. - thomas > On 01 Feb 2017, at 19:55, Tom Rodriguez wrote: > > > > Doug Simon wrote: >>> On 1 Feb 2017, at 19:42, Andrew Haley wrote: >>> >>> /nfs/zebedee/home/graal/aph/truffle/truffle/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Scanner.java:388: warning: [deprecation] Integer(int) in Integer has been deprecated >>> literals.put("return", new Integer(17)); >>> >>> There are too many of these. Shall I just fix them all? >> >> No - we?re stuck with those because these methods are not deprecated on jdk8. So if you use SuppressWarnings, you?ll get a warning on jdk8 about an unnecessary suppression! > > Well they can be changed to use valueOf instead, though for test cases I think we'll need to make sure we don't actually care about object identity. Those I think we're stuck with. That's going to be a very painful deprecation warning for lots of people. > > tom From tom.rodriguez at oracle.com Thu Feb 2 01:47:01 2017 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 01 Feb 2017 17:47:01 -0800 Subject: Deprecation warnings In-Reply-To: References: <58922F3D.90600@oracle.com> Message-ID: <58928F95.1060107@oracle.com> Thomas Wuerthinger wrote: > We could define our own Integer class and avoid using java.lang.Integer. From what I can see, most places will happily work with Integer.valueOf instead. There are some places where we are testing things like boxing elimination and we want to actually create an Integer instance that's different than the one boxing would return. I think fixing all the deprecations and then seeing which unit tests fail and reverting it in those would probably find most of the issues. We're still stuck with some of the deprecation warnings though. We could do something hacky like have a deprecrated function we call from those same locations just so a SuppressWarning("deprecation") isn't an error, like our own wrapper around new Integer(v) that we always deprecate. Horrible but so are the deprecation warnings. tom > > - thomas > >> On 01 Feb 2017, at 19:55, Tom Rodriguez wrote: >> >> >> >> Doug Simon wrote: >>>> On 1 Feb 2017, at 19:42, Andrew Haley wrote: >>>> >>>> /nfs/zebedee/home/graal/aph/truffle/truffle/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Scanner.java:388: warning: [deprecation] Integer(int) in Integer has been deprecated >>>> literals.put("return", new Integer(17)); >>>> >>>> There are too many of these. Shall I just fix them all? >>> No - we?re stuck with those because these methods are not deprecated on jdk8. So if you use SuppressWarnings, you?ll get a warning on jdk8 about an unnecessary suppression! >> Well they can be changed to use valueOf instead, though for test cases I think we'll need to make sure we don't actually care about object identity. Those I think we're stuck with. That's going to be a very painful deprecation warning for lots of people. >> >> tom > From jaroslav.tulach at oracle.com Thu Feb 2 13:46:42 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Thu, 02 Feb 2017 14:46:42 +0100 Subject: NetBeans hints per MX project Message-ID: <45032961.3Q7RqVnTCI@pracovni> Dear users of mx and NetBeans, if you use $ mx netbeansinit from time to time you may want to know that I have just pushed a slight improvement to mx https://github.com/graalvm/mx/commit/aa2320a2fb0951ca1e15e7ecaafe811118840f78 which allows us to configure NetBeans hints globally, per suite and per individual mx project and thus have them standardized across all users. It is a small step for Graal project, but huge leap forward for NetBeans mx users. There is just one thing missing - we need to properly select right hints to match settings used by our Eclipse using colleagues. The main configuration file is at https://github.com/graalvm/mx/blob/aa2320a2fb0951ca1e15e7ecaafe811118840f78/ netbeans-settings/cfg_hints.xml any improvement to it is more than welcomed. Thanks in advanced for making NetBeans experience when using mx-based projects better! -jt From aph at redhat.com Thu Feb 2 18:00:05 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 2 Feb 2017 18:00:05 +0000 Subject: mx canonicalizeprojects In-Reply-To: <94C31528-036B-4E66-90F3-71BE0984A1B3@oracle.com> References: <0a4b93ba-112a-a62f-f0b8-ab9e85b2d057@redhat.com> <8771d6c4-98f2-52a1-7e2d-3fc9c9f36e33@redhat.com> <94C31528-036B-4E66-90F3-71BE0984A1B3@oracle.com> Message-ID: On 01/02/17 19:30, Doug Simon wrote: > So are the dependencies for org.graalvm.compiler.truffle.hotspot.aarch64 exactly: > > [ "org.graalvm.compiler.hotspot.aarch64?, ?org.graalvm.compiler.truffle.hotspot? ] Sorry, I figured it out. Not only did I have to add my dependency, but also remove one that was already there. Passes now. Andrew. From aph at redhat.com Thu Feb 2 18:02:35 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 2 Feb 2017 18:02:35 +0000 Subject: mx unittest failure Message-ID: I'm seeing this: https://travis-ci.org/graalvm/graal-core/jobs/197719905 But I can't reproduce it locally on x86 or AArch64. Any guesses? Thanks, Andrew. From tom.rodriguez at oracle.com Thu Feb 2 18:17:57 2017 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 02 Feb 2017 10:17:57 -0800 Subject: mx unittest failure In-Reply-To: References: Message-ID: <589377D5.4060007@oracle.com> That's definitely weird. It looks like the assignment of hello=world is also causing the variable a to disappear from the frame. I also see this in another github PR https://travis-ci.org/graalvm/graal-core/jobs/197549612, so I don't think it's you. The travis gate doesn't get run very often so it's probably something that's only showing up on the travis machines. I'll see if I can reproduce it. tom Andrew Haley wrote: > I'm seeing this: > > https://travis-ci.org/graalvm/graal-core/jobs/197719905 > > But I can't reproduce it locally on x86 or AArch64. Any guesses? > > Thanks, > > Andrew. From aph at redhat.com Thu Feb 2 18:27:33 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 2 Feb 2017 18:27:33 +0000 Subject: mx unittest failure In-Reply-To: <589377D5.4060007@oracle.com> References: <589377D5.4060007@oracle.com> Message-ID: <30edcacb-5a7a-002d-6c11-cf15b8881391@redhat.com> On 02/02/17 18:17, Tom Rodriguez wrote: > That's definitely weird. It looks like the assignment of hello=world is > also causing the variable a to disappear from the frame. I also see > this in another github PR > https://travis-ci.org/graalvm/graal-core/jobs/197549612, so I don't > think it's you. The travis gate doesn't get run very often so it's > probably something that's only showing up on the travis machines. I'll > see if I can reproduce it. It might be a problem with the way I'm working with git. I've been trying to merge updates into my working branch but something always seems to go wrong. It's quite possible that something ugly happened. Andrew. From aph at redhat.com Thu Feb 2 18:33:29 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 2 Feb 2017 18:33:29 +0000 Subject: mx unittest failure In-Reply-To: <30edcacb-5a7a-002d-6c11-cf15b8881391@redhat.com> References: <589377D5.4060007@oracle.com> <30edcacb-5a7a-002d-6c11-cf15b8881391@redhat.com> Message-ID: On 02/02/17 18:27, Andrew Haley wrote: > It might be a problem with the way I'm working with git. I've been > trying to merge updates into my working branch but something always > seems to go wrong. Scratch that: I just did a new merge from master and the failure is still there. I'm baffled. Andrew. From christian.humer at gmail.com Wed Feb 8 16:13:52 2017 From: christian.humer at gmail.com (Christian Humer) Date: Wed, 08 Feb 2017 16:13:52 +0000 Subject: GraalVM 0.20 Release Message-ID: Hi guys, GraalVM 0.20 with the latest bits of Graal, Truffle, Graal.JS, TruffleRuby, FastR and SVM just landed on OTN. The bits are from early February and based on Truffle 0.23 and LabsJDK 8 with JVMCI 0.23. New and Noteworthy: * This release now includes the Substrate VM image builder (bin/aot-image). It is possible to create SVM executable images of Graal.JS using "bin/aot-image --js" and TruffleRuby using "bin/aot-image --ruby". * Instead of a Development Kit and Runtime distribution we now distinguish between GraalVM with JDK and GraalVM without. The version without JDK requires a JVMCI enabled JDK 8 to be specified using the JAVA_HOME environment variable. Please note that this version of GraalVM is not yet compatible with early access builds of JDK9. Get it here: http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html Next release should arrive mid March. Cheers, Christian Humer From michel.trudeau at oracle.com Thu Feb 9 01:28:56 2017 From: michel.trudeau at oracle.com (Michel Trudeau) Date: Wed, 08 Feb 2017 17:28:56 -0800 Subject: GraalVM 0.20 Release In-Reply-To: References: Message-ID: <589BC5D8.4090501@oracle.com> I've been trying to create an aot-image for my application, it is using JarFile class, and I end up with the following error. Any workaround ? I tried replacing the JarFile class in the rt.jar from the downloaded graal distribution with one that doesn't contain a reference to JarVerifier, but that didn't work. java.util.jar.JarFile.getManifestFromReference(): Type is marked as deleted: HotSpotType at java.util.jar.JarFile.getManifestFromReference(JarFile.java:184) at java.util.jar.JarFile.getManifest(JarFile.java:180) Thanks, -- Michel > Christian Humer > February 8, 2017 at 8:13 AM > Hi guys, > > GraalVM 0.20 with the latest bits of Graal, Truffle, Graal.JS, > TruffleRuby, FastR and SVM just landed on OTN. > > The bits are from early February and based on Truffle 0.23 and LabsJDK > 8 with JVMCI 0.23. > > New and Noteworthy: > * This release now includes the Substrate VM image builder > (bin/aot-image). It is possible to create SVM executable images of > Graal.JS using "bin/aot-image --js" and TruffleRuby using > "bin/aot-image --ruby". > * Instead of a Development Kit and Runtime distribution we now > distinguish between GraalVM with JDK and GraalVM without. The version > without JDK requires a JVMCI enabled JDK 8 to be specified using the > JAVA_HOME environment variable. Please note that this version of > GraalVM is not yet compatible with early access builds of JDK9. > > Get it here: > http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html > > > Next release should arrive mid March. > > Cheers, > Christian Humer > From chris.seaton at oracle.com Thu Feb 9 10:39:13 2017 From: chris.seaton at oracle.com (Chris Seaton) Date: Thu, 9 Feb 2017 10:39:13 +0000 Subject: GraalVM 0.20 Release In-Reply-To: <589BC5D8.4090501@oracle.com> References: <589BC5D8.4090501@oracle.com> Message-ID: The SVM image builder isn?t designed to compile arbitrary applications and you will likely quickly run into unsupported parts of Java and the libraries if you try to use it on code we don?t test it with. ?type is marked as deleted? means that the class deliberately isn?t there in SVM, as it uses features that we know don?t work on the SVM. Chris > On 9 Feb 2017, at 01:28, Michel Trudeau wrote: > > I've been trying to create an aot-image for my application, it is using JarFile class, and I end up with the following error. Any workaround ? I tried replacing the JarFile class in the rt.jar from the downloaded graal distribution with one that doesn't contain a reference to JarVerifier, but that didn't work. > > java.util.jar.JarFile.getManifestFromReference(): Type is marked as deleted: HotSpotType > at java.util.jar.JarFile.getManifestFromReference(JarFile.java:184) > at java.util.jar.JarFile.getManifest(JarFile.java:180) > > Thanks, > -- > Michel > > >> Christian Humer >> February 8, 2017 at 8:13 AM >> Hi guys, >> >> GraalVM 0.20 with the latest bits of Graal, Truffle, Graal.JS, TruffleRuby, FastR and SVM just landed on OTN. >> >> The bits are from early February and based on Truffle 0.23 and LabsJDK 8 with JVMCI 0.23. >> >> New and Noteworthy: >> * This release now includes the Substrate VM image builder (bin/aot-image). It is possible to create SVM executable images of Graal.JS using "bin/aot-image --js" and TruffleRuby using "bin/aot-image --ruby". >> * Instead of a Development Kit and Runtime distribution we now distinguish between GraalVM with JDK and GraalVM without. The version without JDK requires a JVMCI enabled JDK 8 to be specified using the JAVA_HOME environment variable. Please note that this version of GraalVM is not yet compatible with early access builds of JDK9. >> >> Get it here: >> http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html >> >> Next release should arrive mid March. >> >> Cheers, >> Christian Humer >> > From thomas.wuerthinger at oracle.com Thu Feb 9 13:49:26 2017 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Thu, 9 Feb 2017 14:49:26 +0100 Subject: GraalVM 0.20 Release In-Reply-To: <589BC5D8.4090501@oracle.com> References: <589BC5D8.4090501@oracle.com> Message-ID: <69D7BB5F-489E-4621-97EB-BC647C21809A@oracle.com> Michel, Currently we only support the following zip related classes java.util.zip.Adler32; java.util.zip.CRC32; java.util.zip.Checksum; java.util.zip.DataFormatException; java.util.zip.Deflater; java.util.zip.GZIPInputStream; java.util.zip.GZIPOutputStream; java.util.zip.Inflater; but not java.util.zip.ZipFile or java.util.jar.JarFile in AOT images. We might be able to add support for java.util.jar.JarFile in a future release. Is this the only class blocking you or are you running into additional issues? Thanks, thomas > On 09 Feb 2017, at 02:28, Michel Trudeau wrote: > > I've been trying to create an aot-image for my application, it is using JarFile class, and I end up with the following error. Any workaround ? I tried replacing the JarFile class in the rt.jar from the downloaded graal distribution with one that doesn't contain a reference to JarVerifier, but that didn't work. > > java.util.jar.JarFile.getManifestFromReference(): Type is marked as deleted: HotSpotType > at java.util.jar.JarFile.getManifestFromReference(JarFile.java:184) > at java.util.jar.JarFile.getManifest(JarFile.java:180) > > Thanks, > -- > Michel > > >> Christian Humer >> February 8, 2017 at 8:13 AM >> Hi guys, >> >> GraalVM 0.20 with the latest bits of Graal, Truffle, Graal.JS, TruffleRuby, FastR and SVM just landed on OTN. >> >> The bits are from early February and based on Truffle 0.23 and LabsJDK 8 with JVMCI 0.23. >> >> New and Noteworthy: >> * This release now includes the Substrate VM image builder (bin/aot-image). It is possible to create SVM executable images of Graal.JS using "bin/aot-image --js" and TruffleRuby using "bin/aot-image --ruby". >> * Instead of a Development Kit and Runtime distribution we now distinguish between GraalVM with JDK and GraalVM without. The version without JDK requires a JVMCI enabled JDK 8 to be specified using the JAVA_HOME environment variable. Please note that this version of GraalVM is not yet compatible with early access builds of JDK9. >> >> Get it here: >> http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html >> >> Next release should arrive mid March. >> >> Cheers, >> Christian Humer >> > From michel.trudeau at oracle.com Thu Feb 9 14:54:25 2017 From: michel.trudeau at oracle.com (Michel Trudeau) Date: Thu, 09 Feb 2017 06:54:25 -0800 Subject: GraalVM 0.20 Release In-Reply-To: <69D7BB5F-489E-4621-97EB-BC647C21809A@oracle.com> References: <589BC5D8.4090501@oracle.com> <69D7BB5F-489E-4621-97EB-BC647C21809A@oracle.com> Message-ID: <589C82A1.3020205@oracle.com> Yes, I am running into this one as well. UNSUPPORTED FEATURE: Access of resource bundle that was not pre-cached: com.sun.tools.javac.resources.version Which I have yet to find a good workaround. -- Michel > Thomas Wuerthinger > February 9, 2017 at 5:49 AM > Michel, > > Currently we only support the following zip related classes > but not java.util.zip.ZipFile or java.util.jar.JarFile in AOT images. > > We might be able to add support for java.util.jar.JarFile in a future > release. Is this the only class blocking you or are you running into > additional issues? > > Thanks, thomas > > > > Michel Trudeau > February 8, 2017 at 5:28 PM > I've been trying to create an aot-image for my application, it is > using JarFile class, and I end up with the following error. Any > workaround ? I tried replacing the JarFile class in the rt.jar from > the downloaded graal distribution with one that doesn't contain a > reference to JarVerifier, but that didn't work. > > java.util.jar.JarFile.getManifestFromReference(): Type is marked > as deleted: HotSpotType > at > java.util.jar.JarFile.getManifestFromReference(JarFile.java:184) > at java.util.jar.JarFile.getManifest(JarFile.java:180) > > Thanks, > Christian Humer > February 8, 2017 at 8:13 AM > Hi guys, > > GraalVM 0.20 with the latest bits of Graal, Truffle, Graal.JS, > TruffleRuby, FastR and SVM just landed on OTN. > > The bits are from early February and based on Truffle 0.23 and LabsJDK > 8 with JVMCI 0.23. > > New and Noteworthy: > * This release now includes the Substrate VM image builder > (bin/aot-image). It is possible to create SVM executable images of > Graal.JS using "bin/aot-image --js" and TruffleRuby using > "bin/aot-image --ruby". > * Instead of a Development Kit and Runtime distribution we now > distinguish between GraalVM with JDK and GraalVM without. The version > without JDK requires a JVMCI enabled JDK 8 to be specified using the > JAVA_HOME environment variable. Please note that this version of > GraalVM is not yet compatible with early access builds of JDK9. > > Get it here: > http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html > > > Next release should arrive mid March. > > Cheers, > Christian Humer > From vojin.jovanovic at oracle.com Thu Feb 9 15:35:23 2017 From: vojin.jovanovic at oracle.com (Vojin Jovanovic) Date: Thu, 9 Feb 2017 16:35:23 +0100 Subject: GraalVM 0.20 Release In-Reply-To: <589C82A1.3020205@oracle.com> References: <589BC5D8.4090501@oracle.com> <69D7BB5F-489E-4621-97EB-BC647C21809A@oracle.com> <589C82A1.3020205@oracle.com> Message-ID: <45c6fa77-b4ab-131a-34c4-111282b3630b@oracle.com> Currently, we have hard-coded the list of supported resources and that list does not contain `com.sun.tools.javac.resources.version`. In the next release we will support extending this list externally. Cheers, - Vojin On 2/9/17 3:54 PM, Michel Trudeau wrote: > Yes, I am running into this one as well. > > UNSUPPORTED FEATURE: Access of resource bundle that was not > pre-cached: com.sun.tools.javac.resources.version > > Which I have yet to find a good workaround. > From aph at redhat.com Thu Feb 9 18:08:20 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 9 Feb 2017 18:08:20 +0000 Subject: What is AheadOfTimeCompilationTest supposed to do? Message-ID: I'm running this, and the code I generate looks much the same as the x86 code, structurally speaking. But I fail the testStaticFinalObjectAOT() test with an assertion because assertDeepEquals(1, getConstantNodes(result).count()); I have 3 constant nodes. But what is being tested here? Why does the number of constant nodes have to equal 1? The three constant nodes I have are the static final Object and two integers which are field offsets. Andrew. From doug.simon at oracle.com Thu Feb 9 23:28:03 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 10 Feb 2017 00:28:03 +0100 Subject: What is AheadOfTimeCompilationTest supposed to do? In-Reply-To: References: Message-ID: <19EEF8AE-B4DC-4CD5-9286-3924DF573FA8@oracle.com> Now that real AOT is implemented on Graal with a suite of tests, this early attempt at ensuring what might be necessary for AOT should probably be retired. For now, you can just: Assume.assumeFalse(getTarget().arch instanceof AArch64); for the tests that fail. -Doug > On 9 Feb 2017, at 19:08, Andrew Haley wrote: > > I'm running this, and the code I generate looks much the same as the x86 > code, structurally speaking. But I fail the testStaticFinalObjectAOT() > test with an assertion because > > assertDeepEquals(1, getConstantNodes(result).count()); > > I have 3 constant nodes. > > But what is being tested here? Why does the number of constant nodes > have to equal 1? > > The three constant nodes I have are the static final Object and two > integers which are field offsets. > > Andrew. From doug.simon at oracle.com Fri Feb 10 23:33:15 2017 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 11 Feb 2017 00:33:15 +0100 Subject: JVMCI 0.24 released Message-ID: <4490F10D-DAEE-4A05-93AF-4E363ACF3A34@oracle.com> JVMCI 0.24 updates the base JDK to 8u121. It also includes some new JVMCI API that make this a backwards incompatible release: https://bugs.openjdk.java.net/browse/JDK-8172733 https://bugs.openjdk.java.net/browse/JDK-8173912 The second one above also includes implementation changes that reduce the memory overhead of JVMCI. The complete set of changes can be seen at http://hg.openjdk.java.net/graal/graal-jvmci-8/log?revcount=200&rev=ancestors%28%27jvmci-0.24%27%29+-+ancestors%28%27jvmci-0.23%27%29 The OpenJDK8 based binary[1] will be provided as soon as Travis updates the openjdk8 package to be based on 8u121[2]. The OTN binaries[3] should be available in the next 24h. You will need these binaries (or need to build your own[4]) once you pull https://github.com/graalvm/graal-core/commit/5b8cebee8a66240869de0449d200280ac103b642. -Doug [1] https://github.com/dougxc/openjdk8-jvmci-builder/releases/tag/jvmci-0.24 [2] https://github.com/travis-ci/travis-ci/issues/6483#issuecomment-278981775 [3] labsjdk-8u111-jvmci-0.24-*.tar.gz at http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html [4] https://github.com/graalvm/graal-core#building-jvmci-jdk8 From jaroslav.tulach at oracle.com Mon Feb 13 04:16:43 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Mon, 13 Feb 2017 05:16:43 +0100 Subject: Unsupported resource bundle access & running Javac was: GraalVM 0.20 Release In-Reply-To: <589C82A1.3020205@oracle.com> References: <69D7BB5F-489E-4621-97EB-BC647C21809A@oracle.com> <589C82A1.3020205@oracle.com> Message-ID: <1542239.6t8tHpfXVV@pracovni> On ?tvrtek 9. ?nora 2017 6:54:25 CET Michel Trudeau wrote: > Yes, I am running into this one as well. > > UNSUPPORTED FEATURE: Access of resource bundle that was not pre-cached: > com.sun.tools.javac.resources.version > > Which I have yet to find a good workaround. There is an SVM feature that allows one to instruct SVM to include certain resource bundles when generating an image. I have implemented it in Oct 2015 and as far as I can see, it is still ready for use. I am not however sure how to trigger that feature on in the GraalVM @ 0.20 build. It gets triggered by @RequiredFeature({ResourcesFeature.class}) in the tests I have provided... Btw. I have implemented that SVM feature based on my previous work of [getting Javac running on top of Bck2Brwsr](http://dew.apidesign.org/dew/). Michel, looks like you are trying to get Javac running on top of SVM. That is great, but I am afraid it won't work out of the box. Here is [the list of JDK classes that I had to additionally implement] (https://github.com/jtulach/bck2brwsr/compare/release-0.8...release-0.8.1) to get Javac running on my restricted JVM: bck2brwsr$ git diff release-0.8...release-0.8.1 | grep ^diff.*rt/emul/compact | cut -f 3 -d " " | cut -f 2- -d / | grep -v /test/ $ cat /tmp/support-javac rt/emul/compact/pom.xml rt/emul/compact/src/main/java/java/io/BufferedInputStream.java rt/emul/compact/src/main/java/java/io/FileDescriptor.java rt/emul/compact/src/main/java/java/io/FileInputStream.java rt/emul/compact/src/main/java/java/io/FileOutputStream.java rt/emul/compact/src/main/java/java/io/FileReader.java rt/emul/compact/src/main/java/java/io/FileWriter.java rt/emul/compact/src/main/java/java/io/FilterReader.java rt/emul/compact/src/main/java/java/io/FilterWriter.java rt/emul/compact/src/main/java/java/io/LineNumberInputStream.java rt/emul/compact/src/main/java/java/io/LineNumberReader.java rt/emul/compact/src/main/java/java/io/OutputStreamWriter.java rt/emul/compact/src/main/java/java/io/PrintStream.java rt/emul/compact/src/main/java/java/io/PrintWriter.java rt/emul/compact/src/main/java/java/io/StringReader.java rt/emul/compact/src/main/java/java/io/StringWriter.java rt/emul/compact/src/main/java/java/io/SyncFailedException.java rt/emul/compact/src/main/java/java/lang/System.java rt/emul/compact/src/main/java/java/lang/Thread.java rt/emul/compact/src/main/java/java/lang/annotation/Annotation.java rt/emul/compact/src/main/java/java/lang/annotation/AnnotationFormatError.java rt/emul/compact/src/main/java/java/lang/annotation/ AnnotationTypeMismatchException.java rt/emul/compact/src/main/java/java/lang/annotation/Documented.java rt/emul/compact/src/main/java/java/lang/annotation/ElementType.java rt/emul/compact/src/main/java/java/lang/annotation/ IncompleteAnnotationException.java rt/emul/compact/src/main/java/java/lang/annotation/Inherited.java rt/emul/compact/src/main/java/java/lang/annotation/Retention.java rt/emul/compact/src/main/java/java/lang/annotation/RetentionPolicy.java rt/emul/compact/src/main/java/java/lang/annotation/Target.java rt/emul/compact/src/main/java/java/lang/annotation/package-info.java rt/emul/compact/src/main/java/java/net/URLConnection.java rt/emul/compact/src/main/java/java/nio/charset/Charset.java rt/emul/compact/src/main/java/java/nio/charset/CharsetDecoder.java rt/emul/compact/src/main/java/java/nio/charset/CharsetEncoder.java rt/emul/compact/src/main/java/java/nio/charset/ IllegalCharsetNameException.java rt/emul/compact/src/main/java/java/nio/charset/ UnsupportedCharsetException.java rt/emul/compact/src/main/java/java/security/AccessController.java rt/emul/compact/src/main/java/java/security/PrivilegedAction.java rt/emul/compact/src/main/java/java/security/PrivilegedActionException.java rt/emul/compact/src/main/java/java/security/PrivilegedExceptionAction.java rt/emul/compact/src/main/java/java/text/Annotation.java rt/emul/compact/src/main/java/java/text/AttributedCharacterIterator.java rt/emul/compact/src/main/java/java/text/AttributedString.java rt/emul/compact/src/main/java/java/text/CalendarBuilder.java rt/emul/compact/src/main/java/java/text/CharacterIterator.java rt/emul/compact/src/main/java/java/text/CharacterIteratorFieldDelegate.java rt/emul/compact/src/main/java/java/text/ChoiceFormat.java rt/emul/compact/src/main/java/java/text/DateFormat.java rt/emul/compact/src/main/java/java/text/DateFormatSymbols.java rt/emul/compact/src/main/java/java/text/DecimalFormat.java rt/emul/compact/src/main/java/java/text/DecimalFormatSymbols.java rt/emul/compact/src/main/java/java/text/DigitList.java rt/emul/compact/src/main/java/java/text/DontCareFieldPosition.java rt/emul/compact/src/main/java/java/text/FieldPosition.java rt/emul/compact/src/main/java/java/text/Format.java rt/emul/compact/src/main/java/java/text/MessageFormat.java rt/emul/compact/src/main/java/java/text/NumberFormat.java rt/emul/compact/src/main/java/java/text/ParseException.java rt/emul/compact/src/main/java/java/text/ParsePosition.java rt/emul/compact/src/main/java/java/text/SimpleDateFormat.java rt/emul/compact/src/main/java/java/util/BitSet.java rt/emul/compact/src/main/java/java/util/Calendar.java rt/emul/compact/src/main/java/java/util/Currency.java rt/emul/compact/src/main/java/java/util/CurrencyData.properties rt/emul/compact/src/main/java/java/util/Date.java rt/emul/compact/src/main/java/java/util/EnumMap.java rt/emul/compact/src/main/java/java/util/EnumSet.java rt/emul/compact/src/main/java/java/util/JumboEnumSet.java rt/emul/compact/src/main/java/java/util/Locale.java rt/emul/compact/src/main/java/java/util/MissingResourceException.java rt/emul/compact/src/main/java/java/util/Properties.java rt/emul/compact/src/main/java/java/util/PropertyResourceBundle.java rt/emul/compact/src/main/java/java/util/RegularEnumSet.java rt/emul/compact/src/main/java/java/util/ResourceBundle.java rt/emul/compact/src/main/java/java/util/SimpleTimeZone.java rt/emul/compact/src/main/java/java/util/TimeZone.java rt/emul/compact/src/main/java/java/util/Timer.java rt/emul/compact/src/main/java/java/util/TimerTask.java rt/emul/compact/src/main/java/java/util/concurrent/ConcurrentHashMap.java rt/emul/compact/src/main/java/java/util/concurrent/ConcurrentMap.java rt/emul/compact/src/main/java/java/util/concurrent/atomic/AtomicBoolean.java rt/emul/compact/src/main/java/java/util/concurrent/atomic/AtomicInteger.java rt/emul/compact/src/main/java/java/util/concurrent/atomic/ AtomicIntegerArray.java rt/emul/compact/src/main/java/java/util/concurrent/atomic/AtomicLong.java rt/emul/compact/src/main/java/java/util/concurrent/atomic/AtomicLongArray.java rt/emul/compact/src/main/java/java/util/concurrent/atomic/AtomicReference.java rt/emul/compact/src/main/java/java/util/concurrent/atomic/ AtomicReferenceArray.java rt/emul/compact/src/main/java/java/util/concurrent/atomic/package-info.java rt/emul/compact/src/main/java/java/util/logging/Logger.java rt/emul/compact/src/main/java/java/util/regex/ASCII.java rt/emul/compact/src/main/java/java/util/regex/MatchResult.java rt/emul/compact/src/main/java/java/util/regex/Matcher.java rt/emul/compact/src/main/java/java/util/regex/Pattern.java rt/emul/compact/src/main/java/java/util/regex/PatternSyntaxException.java rt/emul/compact/src/main/java/java/util/regex/UnicodeProp.java rt/emul/compact/src/main/java/java/util/regex/package.html rt/emul/compact/src/main/java/org/apidesign/bck2brwsr/emul/reflect/ ProxyImpl.java Apart from some missing implementations, the biggest problem is going to be the annotation processing. Javac is using java.lang.reflect.Proxy to dynamically create implementations of annotation classes before passing them to annotation processors. That is something SVM can't do at the moment. On the other hand annotation processors are supposed to be loaded dynamically and that will not work either... -jt > > Thomas Wuerthinger > > February 9, 2017 at 5:49 AM > > Michel, > > > > Currently we only support the following zip related classes > > but not java.util.zip.ZipFile or java.util.jar.JarFile in AOT images. > > > > We might be able to add support for java.util.jar.JarFile in a future > > release. Is this the only class blocking you or are you running into > > additional issues? > > > > Thanks, thomas > > > > > > > > Michel Trudeau > > February 8, 2017 at 5:28 PM > > I've been trying to create an aot-image for my application, it is > > using JarFile class, and I end up with the following error. Any > > workaround ? I tried replacing the JarFile class in the rt.jar from > > the downloaded graal distribution with one that doesn't contain a > > reference to JarVerifier, but that didn't work. > > > > java.util.jar.JarFile.getManifestFromReference(): Type is marked > > > > as deleted: HotSpotType > > > > at > > > > java.util.jar.JarFile.getManifestFromReference(JarFile.java:184) > > > > at java.util.jar.JarFile.getManifest(JarFile.java:180) > > > > Thanks, > > Christian Humer > > February 8, 2017 at 8:13 AM > > Hi guys, > > > > GraalVM 0.20 with the latest bits of Graal, Truffle, Graal.JS, > > TruffleRuby, FastR and SVM just landed on OTN. > > > > The bits are from early February and based on Truffle 0.23 and LabsJDK > > 8 with JVMCI 0.23. > > > > New and Noteworthy: > > * This release now includes the Substrate VM image builder > > (bin/aot-image). It is possible to create SVM executable images of > > Graal.JS using "bin/aot-image --js" and TruffleRuby using > > "bin/aot-image --ruby". > > * Instead of a Development Kit and Runtime distribution we now > > distinguish between GraalVM with JDK and GraalVM without. The version > > without JDK requires a JVMCI enabled JDK 8 to be specified using the > > JAVA_HOME environment variable. Please note that this version of > > GraalVM is not yet compatible with early access builds of JDK9. > > > > Get it here: > > http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/ > > index.html > > > > > > Next release should arrive mid March. > > > > Cheers, > > Christian Humer From aph at redhat.com Mon Feb 13 11:49:04 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 13 Feb 2017 11:49:04 +0000 Subject: Package resolution when compiling jdk.aot against jdk.vm.ci Message-ID: <1b04b4f9-043b-7da1-3c10-1910f3fb5945@redhat.com> I have this patch: diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/ELFMacroAssembler.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/ELFMacroAssembler.java --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/ELFMacroAssembler.java +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/ELFMacroAssembler.java @@ -24,8 +24,10 @@ package jdk.tools.jaotc; import jdk.tools.jaotc.CompiledMethodInfo.StubInformation; +import jdk.tools.jaotc.aarch64.AArch64ELFMacroAssembler; import jdk.tools.jaotc.amd64.AMD64ELFMacroAssembler; +import jdk.vm.ci.aarch64.AArch64; import jdk.vm.ci.amd64.AMD64; import jdk.vm.ci.code.Architecture; import jdk.vm.ci.code.TargetDescription; @@ -36,6 +38,8 @@ Architecture architecture = target.arch; if (architecture instanceof AMD64) { return new AMD64ELFMacroAssembler(target); + } else if (architecture instanceof AArch64) { + return new AArch64ELFMacroAssembler(target); } else { throw new InternalError("Unsupported architecture " + architecture); } but I get Compiling jdk.aot /home/aph/jdk10/hs/hotspot/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/ELFMacroAssembler.java:30: error: package jdk.vm.ci.aarch64 does not exist import jdk.vm.ci.aarch64.AArch64; ^ I presume that there is something I should be doing to enable javac to see the jdk.vm.ci.aarch64 package. hotspot/make/gensrc/Gensrc-jdk.vm.compiler.gmk already exports jdk.vm.ci.aarch64. Any ideas? Thanks, Andrew. From doug.simon at oracle.com Mon Feb 13 12:13:16 2017 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 13 Feb 2017 13:13:16 +0100 Subject: Package resolution when compiling jdk.aot against jdk.vm.ci In-Reply-To: <1b04b4f9-043b-7da1-3c10-1910f3fb5945@redhat.com> References: <1b04b4f9-043b-7da1-3c10-1910f3fb5945@redhat.com> Message-ID: Adding in hotspot-compiler-dev as they are more knowledge on building the aot code. > On 13 Feb 2017, at 12:49, Andrew Haley wrote: > > I have this patch: > > diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/ELFMacroAssembler.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/ELFMacroAssembler.java > --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/ELFMacroAssembler.java > +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/ELFMacroAssembler.java > @@ -24,8 +24,10 @@ > package jdk.tools.jaotc; > > import jdk.tools.jaotc.CompiledMethodInfo.StubInformation; > +import jdk.tools.jaotc.aarch64.AArch64ELFMacroAssembler; > import jdk.tools.jaotc.amd64.AMD64ELFMacroAssembler; > > +import jdk.vm.ci.aarch64.AArch64; > import jdk.vm.ci.amd64.AMD64; > import jdk.vm.ci.code.Architecture; > import jdk.vm.ci.code.TargetDescription; > @@ -36,6 +38,8 @@ > Architecture architecture = target.arch; > if (architecture instanceof AMD64) { > return new AMD64ELFMacroAssembler(target); > + } else if (architecture instanceof AArch64) { > + return new AArch64ELFMacroAssembler(target); > } else { > throw new InternalError("Unsupported architecture " + architecture); > } > > but I get > > Compiling jdk.aot > /home/aph/jdk10/hs/hotspot/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/ELFMacroAssembler.java:30: error: package jdk.vm.ci.aarch64 does not exist > import jdk.vm.ci.aarch64.AArch64; > ^ > I presume that there is something I should be doing to enable javac to > see the jdk.vm.ci.aarch64 package. hotspot/make/gensrc/Gensrc-jdk.vm.compiler.gmk > already exports jdk.vm.ci.aarch64. > > Any ideas? > > Thanks, > > Andrew. From aph at redhat.com Mon Feb 13 14:44:23 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 13 Feb 2017 14:44:23 +0000 Subject: Package resolution when compiling jdk.aot against jdk.vm.ci In-Reply-To: <1b04b4f9-043b-7da1-3c10-1910f3fb5945@redhat.com> References: <1b04b4f9-043b-7da1-3c10-1910f3fb5945@redhat.com> Message-ID: <37f4d965-ed2f-5511-f75b-d2a6a1a9334d@redhat.com> Sorry, found it: diff --git a/src/jdk.vm.ci/share/classes/module-info.java b/src/jdk.vm.ci/share/classes/module-info.java --- a/src/jdk.vm.ci/share/classes/module-info.java +++ b/src/jdk.vm.ci/share/classes/module-info.java @@ -35,6 +35,7 @@ jdk.vm.ci.hotspot.sparc.SPARCHotSpotJVMCIBackendFactory; exports jdk.vm.ci.aarch64 to + jdk.aot, jdk.vm.compiler; exports jdk.vm.ci.amd64 to jdk.aot, One thought: it would be nice if javac were a bit more helpful: simply saying "not found" is rather baffling. "Not exported" would be super. Andrew. From dawclarke at gmail.com Tue Feb 14 02:01:24 2017 From: dawclarke at gmail.com (David Clarke) Date: Tue, 14 Feb 2017 13:01:24 +1100 Subject: Controlling the phases of the Graal compiler Message-ID: <94E80792-A2E4-4842-871B-D1D5D559FD3E@gmail.com> Good people, I have found Bahram Yarahmadi?s post of 5th Jun 2016 3:34pm regarding his attempt to use the Graal compiler to generate the machine code for his test program. I need the ability to write a new optimisation phase and inject it into the suite of phases in the correct place. I know what I want to do, but I don?t know how to get my code integrated into the compiler. Please can someone point me to the relevant place in the documentation that describes what the various compiler phases do, the order in which they must be invoked and any implicit dependencies. Alternatively, which Java classes would you suggest as models so that I can start ?code-diving?? Thank you for your help. David (Knobby) CLARKE 6 Coptfold Court Glen Waverley VIC 3150 Australia +61 408 793 793 dawclarke at gmail.com From doug.simon at oracle.com Tue Feb 14 09:55:41 2017 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 14 Feb 2017 10:55:41 +0100 Subject: Controlling the phases of the Graal compiler In-Reply-To: <94E80792-A2E4-4842-871B-D1D5D559FD3E@gmail.com> References: <94E80792-A2E4-4842-871B-D1D5D559FD3E@gmail.com> Message-ID: <57A87B80-3150-4935-894C-C26326CC9710@oracle.com> Hi David, > On 14 Feb 2017, at 03:01, David Clarke wrote: > > Good people, > > I have found Bahram Yarahmadi?s post of 5th Jun 2016 3:34pm regarding his attempt to use the Graal compiler to generate the machine code for his test program. > I need the ability to write a new optimisation phase and inject it into the suite of phases in the correct place. I know what I want to do, but I don?t know how to get my code integrated into the compiler. > Please can someone point me to the relevant place in the documentation that describes what the various compiler phases do, the order in which they must be invoked and any implicit dependencies. Alternatively, which Java classes would you suggest as models so that I can start ?code-diving?? It might be easier if you describe what kind of optimization you are planning on adding. We can then better advise you on where in the pipeline your phase should be attached. You can look at the following classes that build the compilation pipeline: org.graalvm.compiler.core.phases.HighTier org.graalvm.compiler.core.phases.MidTier org.graalvm.compiler.core.phases.LowTier Also, the graph progresses through various states which are captured by these fields in StructuredGraph: private GuardsStage guardsStage = GuardsStage.FLOATING_GUARDS; private boolean isAfterFloatingReadPhase = false; private boolean hasValueProxies = true; -Doug From gilles.m.duboscq at oracle.com Tue Feb 14 11:09:11 2017 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Tue, 14 Feb 2017 12:09:11 +0100 Subject: Controlling the phases of the Graal compiler In-Reply-To: <94E80792-A2E4-4842-871B-D1D5D559FD3E@gmail.com> References: <94E80792-A2E4-4842-871B-D1D5D559FD3E@gmail.com> Message-ID: Hi David, You can also look at the CompilerConfigurationFactory mechanism which should allow you to create alternative compiler configuration that can customize the High/Mid/LowTiers to add/remove phases. Gilles On 14/02/17 03:01, David Clarke wrote: > Good people, > > I have found Bahram Yarahmadi?s post of 5th Jun 2016 3:34pm regarding his attempt to use the Graal compiler to generate the machine code for his test program. > I need the ability to write a new optimisation phase and inject it into the suite of phases in the correct place. I know what I want to do, but I don?t know how to get my code integrated into the compiler. > Please can someone point me to the relevant place in the documentation that describes what the various compiler phases do, the order in which they must be invoked and any implicit dependencies. Alternatively, which Java classes would you suggest as models so that I can start ?code-diving?? > > > Thank you for your help. > > > > David (Knobby) CLARKE > 6 Coptfold Court > Glen Waverley > VIC 3150 > Australia > +61 408 793 793 > dawclarke at gmail.com > > > From aph at redhat.com Tue Feb 14 11:26:46 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 14 Feb 2017 11:26:46 +0000 Subject: Running jaotc with an external Graal Message-ID: Is this possible? Seems that no matter what I do, aotc always prefers to use the internal version of org.graalvm.compiler which is in HotSpot. I don't quite get why this is: I can run an external Graal using JVMCI with no problems. I saw "8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails:" which might be related, but perhaps it's not. So, why is it possible to use an external Graal with JVMCI, but apparently not with jaotc? And is there anything I can do to make progress? Thanks, Andrew. From doug.simon at oracle.com Tue Feb 14 13:34:47 2017 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 14 Feb 2017 14:34:47 +0100 Subject: Running jaotc with an external Graal In-Reply-To: References: Message-ID: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> I don?t know how one patches a module in the middle of the module graph. That is, we use --patch-module and --upgrade-module-path to override the jdk.vm.compiler module in the JDK. I don?t know what that means for modules such as jdk.aot that depend on jdk.vm.compiler. Maybe someone from the AOT or jigsaw team can help. -Doug > On 14 Feb 2017, at 12:26, Andrew Haley wrote: > > Is this possible? Seems that no matter what I do, aotc always prefers to > use the internal version of org.graalvm.compiler which is in HotSpot. > > I don't quite get why this is: I can run an external Graal using JVMCI > with no problems. I saw "8145337: [JVMCI] JVMCI initialization with > SecurityManager installed fails:" which might be related, but perhaps > it's not. > > So, why is it possible to use an external Graal with JVMCI, but > apparently not with jaotc? And is there anything I can do to make > progress? > > Thanks, > > Andrew. From aph at redhat.com Tue Feb 14 14:20:54 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 14 Feb 2017 14:20:54 +0000 Subject: Running jaotc with an external Graal In-Reply-To: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> Message-ID: <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> On 14/02/17 13:34, Doug Simon wrote: > I don?t know how one patches a module in the middle of the module > graph. That is, we use --patch-module and --upgrade-module-path to > override the jdk.vm.compiler module in the JDK. I don?t know what > that means for modules such as jdk.aot that depend on > jdk.vm.compiler. Maybe someone from the AOT or jigsaw team can help. OK, thanks. I guess I could try to upgrade the copy of Graal that is contained in HotSpot. I'll have a look. Andrew. From Alan.Bateman at oracle.com Tue Feb 14 14:37:05 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Feb 2017 14:37:05 +0000 Subject: Running jaotc with an external Graal In-Reply-To: <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> Message-ID: <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> On 14/02/2017 14:20, Andrew Haley wrote: > On 14/02/17 13:34, Doug Simon wrote: > >> I don?t know how one patches a module in the middle of the module >> graph. That is, we use --patch-module and --upgrade-module-path to >> override the jdk.vm.compiler module in the JDK. I don?t know what >> that means for modules such as jdk.aot that depend on >> jdk.vm.compiler. Maybe someone from the AOT or jigsaw team can help. > OK, thanks. I guess I could try to upgrade the copy of Graal that is > contained in HotSpot. I'll have a look. > > --patch-module can be used to patch any module in the boot layer. So if you are looking to override or add classes then --patch-module should work. -Alan From aph at redhat.com Tue Feb 14 14:38:35 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 14 Feb 2017 14:38:35 +0000 Subject: Running jaotc with an external Graal In-Reply-To: <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> Message-ID: <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> On 14/02/17 14:37, Alan Bateman wrote: > --patch-module can be used to patch any module in the boot layer. So if > you are looking to override or add classes then --patch-module should work. Aha! Thanks, Andrew. From dawclarke at gmail.com Tue Feb 14 22:18:03 2017 From: dawclarke at gmail.com (David Clarke) Date: Wed, 15 Feb 2017 09:18:03 +1100 Subject: Controlling the phases of the Graal compiler In-Reply-To: <57A87B80-3150-4935-894C-C26326CC9710@oracle.com> References: <94E80792-A2E4-4842-871B-D1D5D559FD3E@gmail.com> <57A87B80-3150-4935-894C-C26326CC9710@oracle.com> Message-ID: <2D8E7681-E069-4659-B459-E753ACCA7669@gmail.com> Doug, Thank you very much for your prompt response. There are three pieces of optimisation that I have in mind: Replacing memory fences by alternative instructions sequences where appropriate, for example, with artificial address dependencies. Integrating an algorithm to optimally select and place memory fences to restore sequential consistency. Integrating an algorithm that detects acquire/release critical sections and searches for data races caused by violation of the implicit access guarantees. I have been able to achieve 1. by modifying some IR graph nodes, adding a number of others, and triggering the required actions by making the nodes participate in existing phases, such as Lowering. It is not certain that this will actually achieve any gains in efficiency but only experimentation can resolve this question. 2. is more difficult. The algorithm has been successfully proven in a static analysis but suffers from scalability because it requires full address and control-flow-graph resolution. My proposed phase would: Read the nodes from Return to Start in predecessor order, extract Load, Store, AtomicReadAndSet and AtomicReadAndInc nodes and present them in program order. Extend the AtomicXXX nodes as Load/Store pairs Extend all Load and Store nodes with the information from their associated Address nodes (which is, of course, fully resolved) With a bit of re-formatting this gives me the Abstract Event Graph that is the starting point for my algorithm Run the algorithm that delivers the selection fence types and their placement Relate the locations in the AEG to the locations in the IR graph and place corresponding Membars Remove any original Membars that are now shown to be redundant This phase would assume that all method invocations have been in-lined and that the IR graph had been transformed into a single ?straight through? sequence with all the IF nodes leading to Deopt nodes. It would need to be run before the Lowering phase that converts Load and Store nodes to floating Read and Write nodes. This process has been shown to work and deliver benefits for C/C++ but has not previously been applied to Java. A phase to implement 3 would look like: Read the nodes as in 2.1 above but include all the Membar nodes Extend the AtomicXXX nodes as Load/Store pairs Extend all Load and Store nodes with the information from their associated Address nodes Run the algorithm which parses for critical sections, groups memory accesses by guard conditions and then finds data races by a series of set intersection operations. Report or log any detected data races using the information in the nodes to relate their location back to the original source code lines. Return leaving the IR Graph untouched. I think this phase fits into the same place as 2. but should follow 2. There are logical difficulties that prevent autocorrection of data race errors (you can?t tell what the coder was trying to do so you can?t tell which of the memory accesses is faulty). Accordingly, I suspect that 2. belongs in an AOT-style invocation of the compiler. But hey!, let?s get something working first and then decide the right way to use it. Any advice that you can give would be most gratefully received. Knobby > On 14 Feb 2017, at 8:55 pm, Doug Simon wrote: > > Hi David, > >> On 14 Feb 2017, at 03:01, David Clarke wrote: >> >> Good people, >> >> I have found Bahram Yarahmadi?s post of 5th Jun 2016 3:34pm regarding his attempt to use the Graal compiler to generate the machine code for his test program. >> I need the ability to write a new optimisation phase and inject it into the suite of phases in the correct place. I know what I want to do, but I don?t know how to get my code integrated into the compiler. >> Please can someone point me to the relevant place in the documentation that describes what the various compiler phases do, the order in which they must be invoked and any implicit dependencies. Alternatively, which Java classes would you suggest as models so that I can start ?code-diving?? > > It might be easier if you describe what kind of optimization you are planning on adding. We can then better advise you on where in the pipeline your phase should be attached. > > You can look at the following classes that build the compilation pipeline: > > org.graalvm.compiler.core.phases.HighTier > org.graalvm.compiler.core.phases.MidTier > org.graalvm.compiler.core.phases.LowTier > > Also, the graph progresses through various states which are captured by these fields in StructuredGraph: > > private GuardsStage guardsStage = GuardsStage.FLOATING_GUARDS; > private boolean isAfterFloatingReadPhase = false; > private boolean hasValueProxies = true; > > > -Doug David (Knobby) CLARKE 6 Coptfold Court Glen Waverley VIC 3150 Australia +61 408 793 793 dawclarke at gmail.com From cthalinger at twitter.com Wed Feb 15 21:56:41 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 15 Feb 2017 11:56:41 -1000 Subject: Running jaotc with an external Graal In-Reply-To: <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> Message-ID: <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> > On Feb 14, 2017, at 4:38 AM, Andrew Haley wrote: > > On 14/02/17 14:37, Alan Bateman wrote: >> --patch-module can be used to patch any module in the boot layer. So if >> you are looking to override or add classes then --patch-module should work. > > Aha! Thanks, Does it? From mandy.chung at oracle.com Wed Feb 15 22:44:19 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 15 Feb 2017 14:44:19 -0800 Subject: Running jaotc with an external Graal In-Reply-To: <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> Message-ID: <9AFEE7EF-BCB8-47E3-B8D7-0BF1E2274805@oracle.com> > On Feb 15, 2017, at 1:56 PM, Christian Thalinger wrote: > > >> On Feb 14, 2017, at 4:38 AM, Andrew Haley wrote: >> >> On 14/02/17 14:37, Alan Bateman wrote: >>> --patch-module can be used to patch any module in the boot layer. So if >>> you are looking to override or add classes then --patch-module should work. >> >> Aha! Thanks, > > Does it? Yes it does except that module-info.class can?t be patched. You will get a warning if the patched path contains module-info.class. Are you seeing the otherwise? Mandy From forax at univ-mlv.fr Wed Feb 15 23:43:40 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 16 Feb 2017 00:43:40 +0100 (CET) Subject: Running jaotc with an external Graal In-Reply-To: <9AFEE7EF-BCB8-47E3-B8D7-0BF1E2274805@oracle.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> <9AFEE7EF-BCB8-47E3-B8D7-0BF1E2274805@oracle.com> Message-ID: <716343417.1404138.1487202220423.JavaMail.zimbra@u-pem.fr> Can i say again that when using --patch-module, module-info.class should be merged instead of having a warning ? R?mi ----- Mail original ----- > De: "Mandy Chung" > ?: "Christian Thalinger" > Cc: jigsaw-dev at openjdk.java.net, "hotspot compiler" , graal-dev at openjdk.java.net > Envoy?: Mercredi 15 F?vrier 2017 23:44:19 > Objet: Re: Running jaotc with an external Graal >> On Feb 15, 2017, at 1:56 PM, Christian Thalinger wrote: >> >> >>> On Feb 14, 2017, at 4:38 AM, Andrew Haley wrote: >>> >>> On 14/02/17 14:37, Alan Bateman wrote: >>>> --patch-module can be used to patch any module in the boot layer. So if >>>> you are looking to override or add classes then --patch-module should work. >>> >>> Aha! Thanks, >> >> Does it? > > Yes it does except that module-info.class can?t be patched. You will get a > warning if the patched path contains module-info.class. Are you seeing the > otherwise? > > Mandy From vladimir.kozlov at oracle.com Thu Feb 16 01:37:15 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Feb 2017 17:37:15 -0800 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci Message-ID: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8174879 jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is only of interest to VM developers (and researchers), not general Java developers. It'd be appropriate for it to be an internal module and not to export any API. Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and jdk.internal.vm.compiler. No packages renaming. Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. Webrevs: top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ Tested with RBT. Thanks, Vladimir From mandy.chung at oracle.com Thu Feb 16 04:35:32 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 15 Feb 2017 20:35:32 -0800 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci In-Reply-To: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> References: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> Message-ID: <1A3EDC42-9BFD-46E1-B8B7-04A6A781F891@oracle.com> > On Feb 15, 2017, at 5:37 PM, Vladimir Kozlov wrote: > > https://bugs.openjdk.java.net/browse/JDK-8174879 > > jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is only of interest to VM developers (and researchers), not general Java developers. It'd be appropriate for it to be an internal module and not to export any API. > > Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and jdk.internal.vm.compiler. No packages renaming. > Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. > > Webrevs: > > top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ > jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ > hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ The change looks fine to me. Mandy From vladimir.kozlov at oracle.com Thu Feb 16 06:09:36 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Feb 2017 22:09:36 -0800 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci In-Reply-To: <1A3EDC42-9BFD-46E1-B8B7-04A6A781F891@oracle.com> References: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> <1A3EDC42-9BFD-46E1-B8B7-04A6A781F891@oracle.com> Message-ID: <61ca272f-419b-902e-50ff-f7536f060cb7@oracle.com> Thank you, Mandy Vladimir On 2/15/17 8:35 PM, Mandy Chung wrote: > >> On Feb 15, 2017, at 5:37 PM, Vladimir Kozlov wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8174879 >> >> jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is only of interest to VM developers (and researchers), not general Java developers. It'd be appropriate for it to be an internal module and not to export any API. >> >> Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and jdk.internal.vm.compiler. No packages renaming. >> Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. >> >> Webrevs: >> >> top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ >> jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ >> hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ > > The change looks fine to me. > > Mandy > From magnus.ihse.bursie at oracle.com Thu Feb 16 07:54:53 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 16 Feb 2017 08:54:53 +0100 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci In-Reply-To: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> References: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> Message-ID: <913fdf9f-7b21-bd40-96ee-20b45afb78a9@oracle.com> On 2017-02-16 02:37, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8174879 > > jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is > only of interest to VM developers (and researchers), not general Java > developers. It'd be appropriate for it to be an internal module and > not to export any API. > > Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and > jdk.internal.vm.compiler. No packages renaming. > Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. > > Webrevs: > > top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ > jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ > hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ Looks good to me. /Magnus > > Tested with RBT. > > Thanks, > Vladimir From aph at redhat.com Thu Feb 16 09:17:12 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 16 Feb 2017 09:17:12 +0000 Subject: Running jaotc with an external Graal In-Reply-To: <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> Message-ID: <3570b9d9-aeb3-bff1-e38b-d473d8b41474@redhat.com> On 15/02/17 21:56, Christian Thalinger wrote: > >> On Feb 14, 2017, at 4:38 AM, Andrew Haley wrote: >> >> On 14/02/17 14:37, Alan Bateman wrote: >>> --patch-module can be used to patch any module in the boot layer. So if >>> you are looking to override or add classes then --patch-module should work. >> >> Aha! Thanks, > > Does it? Not quite. The problem is that the service loader finds classes in the Hotspot copy of Graal which don't exist in the external copy, and chaos ensues. I suppose the only way to make it work is to replace the copy of Graal in HotSpot, but I don't think that's a trivial thing to do. Andrew. From doug.simon at oracle.com Thu Feb 16 09:33:42 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 16 Feb 2017 10:33:42 +0100 Subject: Running jaotc with an external Graal In-Reply-To: <3570b9d9-aeb3-bff1-e38b-d473d8b41474@redhat.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> <3570b9d9-aeb3-bff1-e38b-d473d8b41474@redhat.com> Message-ID: <455F160E-8154-4C93-8555-626289BC2BB3@oracle.com> With the current bits in jdk9/hs and graal-core, the following bootstrapping command works in terms of replacing Graal in the JDK: java -server -XX:+UnlockExperimentalVMOptions --module-path=/Users/dsimon/hs/truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar --upgrade-module-path=/Users/dsimon/hs/graal-core/mxbuild/modules/jdk.vm.compiler.jar --patch-module=jdk.vm.compiler=.jar -XX:+UseJVMCICompiler -XX:+BootstrapJVMCI -version However, the --patch-module + --upgrade-module-path trick[1] we?re using to replace the version of Graal in the JDK apparently only works due to a bug that will be fixed at some point. From Mandy Chung: "-?patch-module is to patch a module to replace or add content of that module and yes it disables the hash checking on the patched module. However, it?s not intended to allow it to combine with ?-upgrade-module-path as you did, to change the module dependences." Given all the continuing flux around jigsaw, we cannot be sure that developing and using GitHub Graal on JDK 9 is stable until jigsaw is stable. -Doug [1] https://bugs.openjdk.java.net/browse/JDK-8171448?focusedCommentId=14046154&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14046154 > On 16 Feb 2017, at 10:17, Andrew Haley wrote: > > On 15/02/17 21:56, Christian Thalinger wrote: >> >>> On Feb 14, 2017, at 4:38 AM, Andrew Haley wrote: >>> >>> On 14/02/17 14:37, Alan Bateman wrote: >>>> --patch-module can be used to patch any module in the boot layer. So if >>>> you are looking to override or add classes then --patch-module should work. >>> >>> Aha! Thanks, >> >> Does it? > > Not quite. The problem is that the service loader finds classes in > the Hotspot copy of Graal which don't exist in the external copy, and > chaos ensues. > > I suppose the only way to make it work is to replace the copy of Graal > in HotSpot, but I don't think that's a trivial thing to do. > > Andrew. > From doug.simon at oracle.com Thu Feb 16 10:01:19 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 16 Feb 2017 11:01:19 +0100 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci In-Reply-To: <913fdf9f-7b21-bd40-96ee-20b45afb78a9@oracle.com> References: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> <913fdf9f-7b21-bd40-96ee-20b45afb78a9@oracle.com> Message-ID: <0C1A8698-0F78-4D10-ABA3-B2BEB3D666A7@oracle.com> Just to note here, this means an external version of Graal will now have to use --add-exports VM options to access JVMCI. Which is ok since additional VM options are required anyway to put an external Graal on the module path. -Doug > On 16 Feb 2017, at 08:54, Magnus Ihse Bursie wrote: > > On 2017-02-16 02:37, Vladimir Kozlov wrote: >> https://bugs.openjdk.java.net/browse/JDK-8174879 >> >> jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is only of interest to VM developers (and researchers), not general Java developers. It'd be appropriate for it to be an internal module and not to export any API. >> >> Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and jdk.internal.vm.compiler. No packages renaming. >> Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. >> >> Webrevs: >> >> top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ >> jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ >> hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ > > Looks good to me. > > /Magnus >> >> Tested with RBT. >> >> Thanks, >> Vladimir > From aph at redhat.com Thu Feb 16 12:25:04 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 16 Feb 2017 12:25:04 +0000 Subject: Running jaotc with an external Graal In-Reply-To: <455F160E-8154-4C93-8555-626289BC2BB3@oracle.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> <3570b9d9-aeb3-bff1-e38b-d473d8b41474@redhat.com> <455F160E-8154-4C93-8555-626289BC2BB3@oracle.com> Message-ID: <8093ab13-e039-c03c-136d-4518e46e1d81@redhat.com> On 16/02/17 09:33, Doug Simon wrote: > With the current bits in jdk9/hs and graal-core, the following bootstrapping command works in terms of replacing Graal in the JDK: > > java -server -XX:+UnlockExperimentalVMOptions --module-path=/Users/dsimon/hs/truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar --upgrade-module-path=/Users/dsimon/hs/graal-core/mxbuild/modules/jdk.vm.compiler.jar --patch-module=jdk.vm.compiler=.jar -XX:+UseJVMCICompiler -XX:+BootstrapJVMCI -version > > However, the --patch-module + --upgrade-module-path trick[1] we?re using to replace the version of Graal in the JDK apparently only works due to a bug that will be fixed at some point. From Mandy Chung: Magic, thank you. This works: ~/jdk10/hs/build/linux-aarch64-normal-server-release/jdk/bin/java \ -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI \ --add-exports=java.base/jdk.internal.module=jdk.vm.compiler \ --upgrade-module-path=/nfs/zebedee/home/graal/aph/graal-core/mxbuild/modules/jdk.vm.compiler.jar \ --patch-module=jdk.vm.compiler=.jar \ --module-path=/nfs/zebedee/home/graal/aph/truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar:/nfs/zebedee/home/graal/aph/graal-core/mxbuild/modules/jdk.vm.compiler.jar \ -XX:+UseAOT -Djvmci.UseProfilingInformation=false \ -Dgraal.UseExceptionProbability=false -Djvmci.Compiler=graal \ --add-modules ALL-DEFAULT -m jdk.aot/jdk.tools.jaotc.Main ~/Hello.jar \ --output libHello.so I'm posting it here for posterity. It would indeed be very bad if we could not do something at least equivalent to this. Andrew. From mandy.chung at oracle.com Thu Feb 16 15:57:08 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 16 Feb 2017 07:57:08 -0800 Subject: Running jaotc with an external Graal In-Reply-To: <455F160E-8154-4C93-8555-626289BC2BB3@oracle.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> <3570b9d9-aeb3-bff1-e38b-d473d8b41474@redhat.com> <455F160E-8154-4C93-8555-626289BC2BB3@oracle.com> Message-ID: <5DEE9908-53E3-4B4D-82A9-EE2A8D7D4DFB@oracle.com> > On Feb 16, 2017, at 1:33 AM, Doug Simon wrote: > > With the current bits in jdk9/hs and graal-core, the following bootstrapping command works in terms of replacing Graal in the JDK: > > java -server -XX:+UnlockExperimentalVMOptions --module-path=/Users/dsimon/hs/truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar --upgrade-module-path=/Users/dsimon/hs/graal-core/mxbuild/modules/jdk.vm.compiler.jar --patch-module=jdk.vm.compiler=.jar -XX:+UseJVMCICompiler -XX:+BootstrapJVMCI -version > > However, the --patch-module + --upgrade-module-path trick[1] we?re using to replace the version of Graal in the JDK apparently only works due to a bug that will be fixed at some point. From Mandy Chung: > > "-?patch-module is to patch a module to replace or add content of that module and yes it disables the hash checking on the patched module. However, it?s not intended to allow it to combine with ?-upgrade-module-path as you did, to change the module dependences.? > It?s a bug that --patch-module + --upgrade-module-path work as described above. I have a patch to fix ?-patch-module that no longer has to disable the hash checking but allow patching the content of the mdoule. I think we will need to look into the alternatives how Graal can be upgraded to a different version of module-info.class. Mandy > Given all the continuing flux around jigsaw, we cannot be sure that developing and using GitHub Graal on JDK 9 is stable until jigsaw is stable. > > -Doug > > [1] https://bugs.openjdk.java.net/browse/JDK-8171448?focusedCommentId=14046154&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14046154 > >> On 16 Feb 2017, at 10:17, Andrew Haley wrote: >> >> On 15/02/17 21:56, Christian Thalinger wrote: >>> >>>> On Feb 14, 2017, at 4:38 AM, Andrew Haley wrote: >>>> >>>> On 14/02/17 14:37, Alan Bateman wrote: >>>>> --patch-module can be used to patch any module in the boot layer. So if >>>>> you are looking to override or add classes then --patch-module should work. >>>> >>>> Aha! Thanks, >>> >>> Does it? >> >> Not quite. The problem is that the service loader finds classes in >> the Hotspot copy of Graal which don't exist in the external copy, and >> chaos ensues. >> >> I suppose the only way to make it work is to replace the copy of Graal >> in HotSpot, but I don't think that's a trivial thing to do. >> >> Andrew. >> > From vladimir.kozlov at oracle.com Thu Feb 16 18:24:52 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Feb 2017 10:24:52 -0800 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci In-Reply-To: <913fdf9f-7b21-bd40-96ee-20b45afb78a9@oracle.com> References: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> <913fdf9f-7b21-bd40-96ee-20b45afb78a9@oracle.com> Message-ID: <678ae64e-aae8-74d3-c382-e47b17005be6@oracle.com> Thank you, Magnus Vladimir On 2/15/17 11:54 PM, Magnus Ihse Bursie wrote: > On 2017-02-16 02:37, Vladimir Kozlov wrote: >> https://bugs.openjdk.java.net/browse/JDK-8174879 >> >> jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is only of interest to VM developers (and >> researchers), not general Java developers. It'd be appropriate for it to be an internal module and not to export any API. >> >> Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and jdk.internal.vm.compiler. No packages renaming. >> Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. >> >> Webrevs: >> >> top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ >> jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ >> hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ > > Looks good to me. > > /Magnus >> >> Tested with RBT. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Thu Feb 16 18:30:59 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Feb 2017 10:30:59 -0800 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci In-Reply-To: <0C1A8698-0F78-4D10-ABA3-B2BEB3D666A7@oracle.com> References: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> <913fdf9f-7b21-bd40-96ee-20b45afb78a9@oracle.com> <0C1A8698-0F78-4D10-ABA3-B2BEB3D666A7@oracle.com> Message-ID: <73ae8fc4-2641-eb1e-e1d7-34738801648f@oracle.com> Hi Doug, Is it because of next change?: module jdk.internal.vm.ci { - exports jdk.vm.ci.services; + exports jdk.vm.ci.services to jdk.internal.vm.compiler; But you said before that your version of graal has the same module name. Why you need --add-exports? Thanks, Vladimir On 2/16/17 2:01 AM, Doug Simon wrote: > Just to note here, this means an external version of Graal will now have to use --add-exports VM options to access JVMCI. Which is ok since additional VM options are required anyway to put an external Graal on the module path. > > -Doug > >> On 16 Feb 2017, at 08:54, Magnus Ihse Bursie wrote: >> >> On 2017-02-16 02:37, Vladimir Kozlov wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8174879 >>> >>> jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is only of interest to VM developers (and researchers), not general Java developers. It'd be appropriate for it to be an internal module and not to export any API. >>> >>> Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and jdk.internal.vm.compiler. No packages renaming. >>> Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. >>> >>> Webrevs: >>> >>> top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ >>> jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ >>> hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ >> >> Looks good to me. >> >> /Magnus >>> >>> Tested with RBT. >>> >>> Thanks, >>> Vladimir >> > From doug.simon at oracle.com Thu Feb 16 18:57:14 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 16 Feb 2017 19:57:14 +0100 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci In-Reply-To: <73ae8fc4-2641-eb1e-e1d7-34738801648f@oracle.com> References: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> <913fdf9f-7b21-bd40-96ee-20b45afb78a9@oracle.com> <0C1A8698-0F78-4D10-ABA3-B2BEB3D666A7@oracle.com> <73ae8fc4-2641-eb1e-e1d7-34738801648f@oracle.com> Message-ID: <9B8A67FE-A748-4599-B9BC-A6D1BBF3F576@oracle.com> > On 16 Feb 2017, at 19:30, Vladimir Kozlov wrote: > > Hi Doug, > > Is it because of next change?: > > module jdk.internal.vm.ci { > - exports jdk.vm.ci.services; > + exports jdk.vm.ci.services to jdk.internal.vm.compiler; > > But you said before that your version of graal has the same module name. Why you need --add-exports? I am projecting ahead to the bug fix Mandy talks about in http://mail.openjdk.java.net/pipermail/graal-dev/2017-February/004889.html which means patching in an external version of Graal will no longer benefit from the qualified exports of JVMCI to jdk.vm.compiler. -Doug > On 2/16/17 2:01 AM, Doug Simon wrote: >> Just to note here, this means an external version of Graal will now have to use --add-exports VM options to access JVMCI. Which is ok since additional VM options are required anyway to put an external Graal on the module path. >> >> -Doug >> >>> On 16 Feb 2017, at 08:54, Magnus Ihse Bursie wrote: >>> >>> On 2017-02-16 02:37, Vladimir Kozlov wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8174879 >>>> >>>> jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is only of interest to VM developers (and researchers), not general Java developers. It'd be appropriate for it to be an internal module and not to export any API. >>>> >>>> Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and jdk.internal.vm.compiler. No packages renaming. >>>> Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. >>>> >>>> Webrevs: >>>> >>>> top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ >>>> jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ >>>> hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ >>> >>> Looks good to me. >>> >>> /Magnus >>>> >>>> Tested with RBT. >>>> >>>> Thanks, >>>> Vladimir >>> >> From deepali_patel at persistent.com Thu Feb 23 09:41:29 2017 From: deepali_patel at persistent.com (Deepali Patel) Date: Thu, 23 Feb 2017 09:41:29 +0000 Subject: Error while building JVMCI enabled JDK8 on Power Message-ID: Hello Team, I am trying to build Graal core on Power. 1. I have updated mx.py to allow build on Power: ----------------- diff --git a/mx.py b/mx.py index 172609d..de932f6 100755 --- a/mx.py +++ b/mx.py @@ -7369,6 +7369,8 @@ def get_arch(): except OSError: # sysctl is not available pass + if machine == 'ppc64le' and get_os() == 'linux': + return 'ppc64le' abort('unknown or unsupported architecture: os=' + get_os() + ', machine=' + machine) mx_subst.results_substitutions.register_no_arg('arch', get_arch) ------------------------------ 2. Next I am trying to build building JVMCI enabled JDK8. However, I see following error: Generating precompiled header precompiled.hpp.gch In file included from /pathto/allocation.hpp:28:0, from /pathto/iterator.hpp:28, from /pathto/genOopClosures.hpp:28, from /pathto/klass.hpp:28, from /pathto/handles.hpp:28, from /pathto/universe.hpp:28, from /pathto/oopRecorder.hpp:28, from /pathto/codeBuffer.hpp:28, from /pathto/assembler.hpp:28, from /pathto/precompiled.hpp:29: /pathto/globals.hpp:143:34: fatal error: jvmci_globals_ppc.hpp: No such file or directory compilation terminated. /pathto/vm.make:322: recipe for target 'precompiled.hpp.gch' failed make[4]: Leaving directory '/pathto/linux_ppc64_compiler2/product' make[4]: *** [precompiled.hpp.gch] Error 1 /pathto/top.make:119: recipe for target 'the_vm' failed make[3]: Leaving directory '/pathto/product' /pathto/make/linux/Makefile:303: recipe for target 'product' failed make[2]: Leaving directory '/pathto/graal-jvmci-8/build/linux' Makefile:231: recipe for target 'generic_build2' failed make[1]: Leaving directory '/pathtoGraal/graal-jvmci-8/make' make[3]: *** [the_vm] Error 2 make[2]: *** [product] Error 2 make[1]: *** [generic_build2] Error 2 Makefile:182: recipe for target 'product' failed make: *** [product] Error 2 make: Leaving directory '/pathto/graal-jvmci-8/make' Building HotSpot[product, server] failed 1 build tasks failed 3. I dont see jvmci_globals_ppc.hpp in the src tree. But there is another file with name jvmciGlobals_ppc.hpp available in the src tree. I tried to use jvmciGlobals_ppc.hpp, but I get following errors: /pathto/graal-jvmci-8/src/cpu/ppc/vm/jvmciGlobals_ppc.hpp:35:2: error: #error Unimplemented #error Unimplemented ^ /pathto/graal-jvmci-8/make/linux/makefiles/vm.make:322: recipe for target 'precompiled.hpp.gch' failed Please advise if I am missing on something here. Regards Deepali DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. From doug.simon at oracle.com Thu Feb 23 10:26:42 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 23 Feb 2017 11:26:42 +0100 Subject: Error while building JVMCI enabled JDK8 on Power In-Reply-To: References: Message-ID: Hi Deepali, This is an interesting but non-trivial project I suspect. You will need to look at all the machine specific JVMCI files and create corresponding *_ppc.[hpp|cpp] files. The existing jvmciGlobals_ppc.hpp needs to be renamed to jvmci_globals_ppc.hpp (as you observed) and completed as part of this. -Doug > On 23 Feb 2017, at 10:41, Deepali Patel wrote: > > Hello Team, > > I am trying to build Graal core on Power. > > > 1. I have updated mx.py to allow build on Power: > ----------------- > diff --git a/mx.py b/mx.py > index 172609d..de932f6 100755 > --- a/mx.py > +++ b/mx.py > @@ -7369,6 +7369,8 @@ def get_arch(): > except OSError: > # sysctl is not available > pass > + if machine == 'ppc64le' and get_os() == 'linux': > + return 'ppc64le' > abort('unknown or unsupported architecture: os=' + get_os() + ', machine=' + machine) > > mx_subst.results_substitutions.register_no_arg('arch', get_arch) > ------------------------------ > > > 2. Next I am trying to build building JVMCI enabled JDK8. However, I see following error: > > Generating precompiled header precompiled.hpp.gch > > In file included from /pathto/allocation.hpp:28:0, > > from /pathto/iterator.hpp:28, > > from /pathto/genOopClosures.hpp:28, > > from /pathto/klass.hpp:28, > > from /pathto/handles.hpp:28, > > from /pathto/universe.hpp:28, > > from /pathto/oopRecorder.hpp:28, > > from /pathto/codeBuffer.hpp:28, > > from /pathto/assembler.hpp:28, > > from /pathto/precompiled.hpp:29: > > /pathto/globals.hpp:143:34: fatal error: jvmci_globals_ppc.hpp: No such file or directory > > compilation terminated. > > /pathto/vm.make:322: recipe for target 'precompiled.hpp.gch' failed > > make[4]: Leaving directory '/pathto/linux_ppc64_compiler2/product' > > make[4]: *** [precompiled.hpp.gch] Error 1 > > /pathto/top.make:119: recipe for target 'the_vm' failed > > make[3]: Leaving directory '/pathto/product' > > /pathto/make/linux/Makefile:303: recipe for target 'product' failed > > make[2]: Leaving directory '/pathto/graal-jvmci-8/build/linux' > > Makefile:231: recipe for target 'generic_build2' failed > > make[1]: Leaving directory '/pathtoGraal/graal-jvmci-8/make' > > make[3]: *** [the_vm] Error 2 > > make[2]: *** [product] Error 2 > > make[1]: *** [generic_build2] Error 2 > > Makefile:182: recipe for target 'product' failed > > make: *** [product] Error 2 > > make: Leaving directory '/pathto/graal-jvmci-8/make' > > Building HotSpot[product, server] failed > > 1 build tasks failed > > > > 3. I dont see jvmci_globals_ppc.hpp in the src tree. But there is another file with name jvmciGlobals_ppc.hpp available in the src tree. I tried to use jvmciGlobals_ppc.hpp, but I get following errors: > > /pathto/graal-jvmci-8/src/cpu/ppc/vm/jvmciGlobals_ppc.hpp:35:2: error: #error Unimplemented > > #error Unimplemented > > ^ > > /pathto/graal-jvmci-8/make/linux/makefiles/vm.make:322: recipe for target 'precompiled.hpp.gch' failed > > Please advise if I am missing on something here. > > Regards > Deepali > > > > DISCLAIMER > ========== > This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. > From gilles.m.duboscq at oracle.com Thu Feb 23 11:32:15 2017 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Thu, 23 Feb 2017 12:32:15 +0100 Subject: Error while building JVMCI enabled JDK8 on Power In-Reply-To: References: Message-ID: You will also need to implement the Java side of things. See for example the sources in jvmci/jdk.vm.ci.amd64 and jvmci/jdk.vm.ci.hotspot.amd64. Gilles On 23/02/17 11:26, Doug Simon wrote: > Hi Deepali, > > This is an interesting but non-trivial project I suspect. You will need to look at all the machine specific JVMCI files and create corresponding *_ppc.[hpp|cpp] files. The existing jvmciGlobals_ppc.hpp needs to be renamed to jvmci_globals_ppc.hpp (as you observed) and completed as part of this. > > -Doug > >> On 23 Feb 2017, at 10:41, Deepali Patel wrote: >> >> Hello Team, >> >> I am trying to build Graal core on Power. >> >> >> 1. I have updated mx.py to allow build on Power: >> ----------------- >> diff --git a/mx.py b/mx.py >> index 172609d..de932f6 100755 >> --- a/mx.py >> +++ b/mx.py >> @@ -7369,6 +7369,8 @@ def get_arch(): >> except OSError: >> # sysctl is not available >> pass >> + if machine == 'ppc64le' and get_os() == 'linux': >> + return 'ppc64le' >> abort('unknown or unsupported architecture: os=' + get_os() + ', machine=' + machine) >> >> mx_subst.results_substitutions.register_no_arg('arch', get_arch) >> ------------------------------ >> >> >> 2. Next I am trying to build building JVMCI enabled JDK8. However, I see following error: >> >> Generating precompiled header precompiled.hpp.gch >> >> In file included from /pathto/allocation.hpp:28:0, >> >> from /pathto/iterator.hpp:28, >> >> from /pathto/genOopClosures.hpp:28, >> >> from /pathto/klass.hpp:28, >> >> from /pathto/handles.hpp:28, >> >> from /pathto/universe.hpp:28, >> >> from /pathto/oopRecorder.hpp:28, >> >> from /pathto/codeBuffer.hpp:28, >> >> from /pathto/assembler.hpp:28, >> >> from /pathto/precompiled.hpp:29: >> >> /pathto/globals.hpp:143:34: fatal error: jvmci_globals_ppc.hpp: No such file or directory >> >> compilation terminated. >> >> /pathto/vm.make:322: recipe for target 'precompiled.hpp.gch' failed >> >> make[4]: Leaving directory '/pathto/linux_ppc64_compiler2/product' >> >> make[4]: *** [precompiled.hpp.gch] Error 1 >> >> /pathto/top.make:119: recipe for target 'the_vm' failed >> >> make[3]: Leaving directory '/pathto/product' >> >> /pathto/make/linux/Makefile:303: recipe for target 'product' failed >> >> make[2]: Leaving directory '/pathto/graal-jvmci-8/build/linux' >> >> Makefile:231: recipe for target 'generic_build2' failed >> >> make[1]: Leaving directory '/pathtoGraal/graal-jvmci-8/make' >> >> make[3]: *** [the_vm] Error 2 >> >> make[2]: *** [product] Error 2 >> >> make[1]: *** [generic_build2] Error 2 >> >> Makefile:182: recipe for target 'product' failed >> >> make: *** [product] Error 2 >> >> make: Leaving directory '/pathto/graal-jvmci-8/make' >> >> Building HotSpot[product, server] failed >> >> 1 build tasks failed >> >> >> >> 3. I dont see jvmci_globals_ppc.hpp in the src tree. But there is another file with name jvmciGlobals_ppc.hpp available in the src tree. I tried to use jvmciGlobals_ppc.hpp, but I get following errors: >> >> /pathto/graal-jvmci-8/src/cpu/ppc/vm/jvmciGlobals_ppc.hpp:35:2: error: #error Unimplemented >> >> #error Unimplemented >> >> ^ >> >> /pathto/graal-jvmci-8/make/linux/makefiles/vm.make:322: recipe for target 'precompiled.hpp.gch' failed >> >> Please advise if I am missing on something here. >> >> Regards >> Deepali >> >> >> >> DISCLAIMER >> ========== >> This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. >> > From deepali_patel at persistent.com Fri Feb 24 08:20:35 2017 From: deepali_patel at persistent.com (Deepali Patel) Date: Fri, 24 Feb 2017 08:20:35 +0000 Subject: Error while building JVMCI enabled JDK8 on Power In-Reply-To: References: Message-ID: Thanks Doug and Gilles for quick response. Could you please throw some more light on the parts of code(folders, files etc) that will need to be updated/modified to get this working on PPC. Would we need assembly code as well? If so, could you please point me to the corresponding x86 files for reference. Regards Deepali -----Original Message----- From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Gilles Duboscq Sent: Thursday, February 23, 2017 5:02 PM To: graal-dev at openjdk.java.net Subject: Re: Error while building JVMCI enabled JDK8 on Power You will also need to implement the Java side of things. See for example the sources in jvmci/jdk.vm.ci.amd64 and jvmci/jdk.vm.ci.hotspot.amd64. Gilles On 23/02/17 11:26, Doug Simon wrote: > Hi Deepali, > > This is an interesting but non-trivial project I suspect. You will need to look at all the machine specific JVMCI files and create corresponding *_ppc.[hpp|cpp] files. The existing jvmciGlobals_ppc.hpp needs to be renamed to jvmci_globals_ppc.hpp (as you observed) and completed as part of this. > > -Doug > >> On 23 Feb 2017, at 10:41, Deepali Patel wrote: >> >> Hello Team, >> >> I am trying to build Graal core on Power. >> >> >> 1. I have updated mx.py to allow build on Power: >> ----------------- >> diff --git a/mx.py b/mx.py >> index 172609d..de932f6 100755 >> --- a/mx.py >> +++ b/mx.py >> @@ -7369,6 +7369,8 @@ def get_arch(): >> except OSError: >> # sysctl is not available >> pass >> + if machine == 'ppc64le' and get_os() == 'linux': >> + return 'ppc64le' >> abort('unknown or unsupported architecture: os=' + get_os() + ', machine=' + machine) >> >> mx_subst.results_substitutions.register_no_arg('arch', get_arch) >> ------------------------------ >> >> >> 2. Next I am trying to build building JVMCI enabled JDK8. However, I see following error: >> >> Generating precompiled header precompiled.hpp.gch >> >> In file included from /pathto/allocation.hpp:28:0, >> >> from /pathto/iterator.hpp:28, >> >> from /pathto/genOopClosures.hpp:28, >> >> from /pathto/klass.hpp:28, >> >> from /pathto/handles.hpp:28, >> >> from /pathto/universe.hpp:28, >> >> from /pathto/oopRecorder.hpp:28, >> >> from /pathto/codeBuffer.hpp:28, >> >> from /pathto/assembler.hpp:28, >> >> from /pathto/precompiled.hpp:29: >> >> /pathto/globals.hpp:143:34: fatal error: jvmci_globals_ppc.hpp: No such file or directory >> >> compilation terminated. >> >> /pathto/vm.make:322: recipe for target 'precompiled.hpp.gch' failed >> >> make[4]: Leaving directory '/pathto/linux_ppc64_compiler2/product' >> >> make[4]: *** [precompiled.hpp.gch] Error 1 >> >> /pathto/top.make:119: recipe for target 'the_vm' failed >> >> make[3]: Leaving directory '/pathto/product' >> >> /pathto/make/linux/Makefile:303: recipe for target 'product' failed >> >> make[2]: Leaving directory '/pathto/graal-jvmci-8/build/linux' >> >> Makefile:231: recipe for target 'generic_build2' failed >> >> make[1]: Leaving directory '/pathtoGraal/graal-jvmci-8/make' >> >> make[3]: *** [the_vm] Error 2 >> >> make[2]: *** [product] Error 2 >> >> make[1]: *** [generic_build2] Error 2 >> >> Makefile:182: recipe for target 'product' failed >> >> make: *** [product] Error 2 >> >> make: Leaving directory '/pathto/graal-jvmci-8/make' >> >> Building HotSpot[product, server] failed >> >> 1 build tasks failed >> >> >> >> 3. I dont see jvmci_globals_ppc.hpp in the src tree. But there is another file with name jvmciGlobals_ppc.hpp available in the src tree. I tried to use jvmciGlobals_ppc.hpp, but I get following errors: >> >> /pathto/graal-jvmci-8/src/cpu/ppc/vm/jvmciGlobals_ppc.hpp:35:2: error: #error Unimplemented >> >> #error Unimplemented >> >> ^ >> >> /pathto/graal-jvmci-8/make/linux/makefiles/vm.make:322: recipe for target 'precompiled.hpp.gch' failed >> >> Please advise if I am missing on something here. >> >> Regards >> Deepali >> >> >> >> DISCLAIMER >> ========== >> This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. >> > DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. From doug.simon at oracle.com Fri Feb 24 09:17:33 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 24 Feb 2017 10:17:33 +0100 Subject: Error while building JVMCI enabled JDK8 on Power In-Reply-To: References: Message-ID: <6B778C59-F1F2-4973-AD86-15C27C9EB335@oracle.com> > On 24 Feb 2017, at 09:20, Deepali Patel wrote: > > Thanks Doug and Gilles for quick response. > > Could you please throw some more light on the parts of code(folders, files etc) that will need to be updated/modified to get this working on PPC. Would we need assembly code as well? If so, could you please point me to the corresponding x86 files for reference. dsimon at kurz-3 ~/g/graal-jvmci-8> find src | grep jvmci | grep x86 src/cpu/x86/vm/jvmci_globals_x86.hpp src/cpu/x86/vm/jvmciCodeInstaller_x86.cpp dsimon at kurz-3 ~/g/graal-jvmci-8> find src | grep jvmci | grep sparc src/cpu/sparc/vm/jvmci_globals_sparc.hpp src/cpu/sparc/vm/jvmciCodeInstaller_sparc.cpp dsimon at kurz-3 ~/g/graal-core> ls -d graal/*sparc* graal/org.graalvm.compiler.asm.sparc graal/org.graalvm.compiler.core.sparc.test graal/org.graalvm.compiler.replacements.sparc graal/org.graalvm.compiler.asm.sparc.test graal/org.graalvm.compiler.hotspot.sparc graal/org.graalvm.compiler.truffle.hotspot.sparc graal/org.graalvm.compiler.core.sparc graal/org.graalvm.compiler.lir.sparc dsimon at kurz-3 ~/g/graal-core> ls -d graal/*amd64* graal/org.graalvm.compiler.asm.amd64 graal/org.graalvm.compiler.core.amd64.test graal/org.graalvm.compiler.lir.amd64 graal/org.graalvm.compiler.asm.amd64.test graal/org.graalvm.compiler.hotspot.amd64 graal/org.graalvm.compiler.replacements.amd64 graal/org.graalvm.compiler.core.amd64 graal/org.graalvm.compiler.hotspot.amd64.test graal/org.graalvm.compiler.truffle.hotspot.amd64 Hope that helps, -Doug > -----Original Message----- > From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Gilles Duboscq > Sent: Thursday, February 23, 2017 5:02 PM > To: graal-dev at openjdk.java.net > Subject: Re: Error while building JVMCI enabled JDK8 on Power > > You will also need to implement the Java side of things. > See for example the sources in jvmci/jdk.vm.ci.amd64 and jvmci/jdk.vm.ci.hotspot.amd64. > > Gilles > > On 23/02/17 11:26, Doug Simon wrote: >> Hi Deepali, >> >> This is an interesting but non-trivial project I suspect. You will need to look at all the machine specific JVMCI files and create corresponding *_ppc.[hpp|cpp] files. The existing jvmciGlobals_ppc.hpp needs to be renamed to jvmci_globals_ppc.hpp (as you observed) and completed as part of this. >> >> -Doug >> >>> On 23 Feb 2017, at 10:41, Deepali Patel wrote: >>> >>> Hello Team, >>> >>> I am trying to build Graal core on Power. >>> >>> >>> 1. I have updated mx.py to allow build on Power: >>> ----------------- >>> diff --git a/mx.py b/mx.py >>> index 172609d..de932f6 100755 >>> --- a/mx.py >>> +++ b/mx.py >>> @@ -7369,6 +7369,8 @@ def get_arch(): >>> except OSError: >>> # sysctl is not available >>> pass >>> + if machine == 'ppc64le' and get_os() == 'linux': >>> + return 'ppc64le' >>> abort('unknown or unsupported architecture: os=' + get_os() + ', machine=' + machine) >>> >>> mx_subst.results_substitutions.register_no_arg('arch', get_arch) >>> ------------------------------ >>> >>> >>> 2. Next I am trying to build building JVMCI enabled JDK8. However, I see following error: >>> >>> Generating precompiled header precompiled.hpp.gch >>> >>> In file included from /pathto/allocation.hpp:28:0, >>> >>> from /pathto/iterator.hpp:28, >>> >>> from /pathto/genOopClosures.hpp:28, >>> >>> from /pathto/klass.hpp:28, >>> >>> from /pathto/handles.hpp:28, >>> >>> from /pathto/universe.hpp:28, >>> >>> from /pathto/oopRecorder.hpp:28, >>> >>> from /pathto/codeBuffer.hpp:28, >>> >>> from /pathto/assembler.hpp:28, >>> >>> from /pathto/precompiled.hpp:29: >>> >>> /pathto/globals.hpp:143:34: fatal error: jvmci_globals_ppc.hpp: No such file or directory >>> >>> compilation terminated. >>> >>> /pathto/vm.make:322: recipe for target 'precompiled.hpp.gch' failed >>> >>> make[4]: Leaving directory '/pathto/linux_ppc64_compiler2/product' >>> >>> make[4]: *** [precompiled.hpp.gch] Error 1 >>> >>> /pathto/top.make:119: recipe for target 'the_vm' failed >>> >>> make[3]: Leaving directory '/pathto/product' >>> >>> /pathto/make/linux/Makefile:303: recipe for target 'product' failed >>> >>> make[2]: Leaving directory '/pathto/graal-jvmci-8/build/linux' >>> >>> Makefile:231: recipe for target 'generic_build2' failed >>> >>> make[1]: Leaving directory '/pathtoGraal/graal-jvmci-8/make' >>> >>> make[3]: *** [the_vm] Error 2 >>> >>> make[2]: *** [product] Error 2 >>> >>> make[1]: *** [generic_build2] Error 2 >>> >>> Makefile:182: recipe for target 'product' failed >>> >>> make: *** [product] Error 2 >>> >>> make: Leaving directory '/pathto/graal-jvmci-8/make' >>> >>> Building HotSpot[product, server] failed >>> >>> 1 build tasks failed >>> >>> >>> >>> 3. I dont see jvmci_globals_ppc.hpp in the src tree. But there is another file with name jvmciGlobals_ppc.hpp available in the src tree. I tried to use jvmciGlobals_ppc.hpp, but I get following errors: >>> >>> /pathto/graal-jvmci-8/src/cpu/ppc/vm/jvmciGlobals_ppc.hpp:35:2: error: #error Unimplemented >>> >>> #error Unimplemented >>> >>> ^ >>> >>> /pathto/graal-jvmci-8/make/linux/makefiles/vm.make:322: recipe for target 'precompiled.hpp.gch' failed >>> >>> Please advise if I am missing on something here. >>> >>> Regards >>> Deepali >>> >>> >>> >>> DISCLAIMER >>> ========== >>> This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. >>> >> > > DISCLAIMER > ========== > This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. > From doug.simon at oracle.com Sun Feb 26 11:20:58 2017 From: doug.simon at oracle.com (Doug Simon) Date: Sun, 26 Feb 2017 12:20:58 +0100 Subject: Problem loading Truffle service providers in Graal Message-ID: While trying to get upstream Graal working again with JDK 9, I'm having problems with service loading. Graal uses a LayoutFactory service defined by Truffle where the latter also includes a provider. The relevant parts of the module-info descriptors are: module com.oracle.truffle.truffle_api { exports com.oracle.truffle.object; exports com.oracle.truffle.object.basic; uses com.oracle.truffle.api.object.LayoutFactory; provides com.oracle.truffle.api.object.LayoutFactory with com.oracle.truffle.object.basic.DefaultLayoutFactory; } module jdk.internal.vm.compiler { requires transitive com.oracle.truffle.truffle_api; uses com.oracle.truffle.api.object.LayoutFactory; } However, looking up a provider in Graal[1] returns no providers. As far as I understand service loading with modules, this is because jdk.internal.vm.compiler is loaded via the platform class loader while truffle is loaded via the app class loader as shown by the output of trace statements I added: GraalTruffleRuntime.class.getClassLoader() -> jdk.internal.loader.ClassLoaders$PlatformClassLoader at 366e2eef LayoutFactory.class.getClassLoader() -> jdk.internal.loader.ClassLoaders$AppClassLoader at 6df97b55 This ability of a platform loaded class to depend on an app loaded class is probably due to the soon-to-be-disabled mechanism[2] we use for overriding the version of Graal bundled with JDK 9. Is there some command line magic I can use to make this case work now or do I have to wait until [2] is addressed? If the latter, how will it work then? -Doug [1] https://github.com/graalvm/graal-core/blob/1efc1c543acd7ed447c59788aeabc223be13e774/graal/org.graalvm.compiler.truffle/src/org/graalvm/compiler/truffle/GraalTruffleRuntime.java#L693 [2] http://mail.openjdk.java.net/pipermail/graal-dev/2017-February/004889.html From Alan.Bateman at oracle.com Sun Feb 26 12:08:09 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 26 Feb 2017 12:08:09 +0000 Subject: Problem loading Truffle service providers in Graal In-Reply-To: References: Message-ID: On 26/02/2017 11:20, Doug Simon wrote: > While trying to get upstream Graal working again with JDK 9, I'm having problems with service loading. Graal uses a LayoutFactory service defined by Truffle where the latter also includes a provider. The relevant parts of the module-info descriptors are: > > module com.oracle.truffle.truffle_api { > > exports com.oracle.truffle.object; > exports com.oracle.truffle.object.basic; > > uses com.oracle.truffle.api.object.LayoutFactory; > provides com.oracle.truffle.api.object.LayoutFactory with com.oracle.truffle.object.basic.DefaultLayoutFactory; > > } > > module jdk.internal.vm.compiler { > > requires transitive com.oracle.truffle.truffle_api; > uses com.oracle.truffle.api.object.LayoutFactory; > > } > > However, looking up a provider in Graal[1] returns no providers. As far as I understand service loading with modules, this is because jdk.internal.vm.compiler is loaded via the platform class loader while truffle is loaded via the app class loader as shown by the output of trace statements I added: > > GraalTruffleRuntime.class.getClassLoader() -> jdk.internal.loader.ClassLoaders$PlatformClassLoader at 366e2eef > LayoutFactory.class.getClassLoader() -> jdk.internal.loader.ClassLoaders$AppClassLoader at 6df97b55 > > This ability of a platform loaded class to depend on an app loaded class is probably due to the soon-to-be-disabled mechanism[2] we use for overriding the version of Graal bundled with JDK 9. > > Is there some command line magic I can use to make this case work now or do I have to wait until [2] is addressed? If the latter, how will it work then? > An upgraded moduledefined to the platform loader can link to types in modules defined to the app loader. So I wouldn't expect issues there. Can you track down the code that uses ServiceLoader.load to load the LayoutFactory providers? It might be using loadInstalled or invoking it with the platform class loader and that would explain what you are seeing. -Alan From doug.simon at oracle.com Sun Feb 26 12:22:08 2017 From: doug.simon at oracle.com (Doug Simon) Date: Sun, 26 Feb 2017 13:22:08 +0100 Subject: Problem loading Truffle service providers in Graal In-Reply-To: References: Message-ID: > On 26 Feb 2017, at 13:08, Alan Bateman wrote: > > On 26/02/2017 11:20, Doug Simon wrote: > >> While trying to get upstream Graal working again with JDK 9, I'm having problems with service loading. Graal uses a LayoutFactory service defined by Truffle where the latter also includes a provider. The relevant parts of the module-info descriptors are: >> >> module com.oracle.truffle.truffle_api { >> >> exports com.oracle.truffle.object; >> exports com.oracle.truffle.object.basic; >> >> uses com.oracle.truffle.api.object.LayoutFactory; >> provides com.oracle.truffle.api.object.LayoutFactory with com.oracle.truffle.object.basic.DefaultLayoutFactory; >> >> } >> >> module jdk.internal.vm.compiler { >> requires transitive com.oracle.truffle.truffle_api; >> uses com.oracle.truffle.api.object.LayoutFactory; >> >> } >> >> However, looking up a provider in Graal[1] returns no providers. As far as I understand service loading with modules, this is because jdk.internal.vm.compiler is loaded via the platform class loader while truffle is loaded via the app class loader as shown by the output of trace statements I added: >> >> GraalTruffleRuntime.class.getClassLoader() -> jdk.internal.loader.ClassLoaders$PlatformClassLoader at 366e2eef >> LayoutFactory.class.getClassLoader() -> jdk.internal.loader.ClassLoaders$AppClassLoader at 6df97b55 >> >> This ability of a platform loaded class to depend on an app loaded class is probably due to the soon-to-be-disabled mechanism[2] we use for overriding the version of Graal bundled with JDK 9. >> >> Is there some command line magic I can use to make this case work now or do I have to wait until [2] is addressed? If the latter, how will it work then? >> > An upgraded moduledefined to the platform loader can link to types in modules defined to the app loader. So I wouldn't expect issues there. > > Can you track down the code that uses ServiceLoader.load to load the LayoutFactory providers? The code is in the first link of my previous message: https://github.com/graalvm/graal-core/blob/1efc1c543acd7ed447c59788aeabc223be13e774/graal/org.graalvm.compiler.truffle/src/org/graalvm/compiler/truffle/GraalTruffleRuntime.java#L693 > It might be using loadInstalled or invoking it with the platform class loader and that would explain what you are seeing. Thanks - using LayoutFactory.class.getClassLoader() works. So the general rule is to use the leaf most class loader the service client knows about? -Doug From doug.simon at oracle.com Sun Feb 26 12:26:35 2017 From: doug.simon at oracle.com (Doug Simon) Date: Sun, 26 Feb 2017 13:26:35 +0100 Subject: Problem loading Truffle service providers in Graal In-Reply-To: References: Message-ID: <7D3F4645-5219-4EE7-97A6-9B6131811735@oracle.com> > On 26 Feb 2017, at 13:22, Doug Simon wrote: > >> >> On 26 Feb 2017, at 13:08, Alan Bateman wrote: >> >> On 26/02/2017 11:20, Doug Simon wrote: >> >>> While trying to get upstream Graal working again with JDK 9, I'm having problems with service loading. Graal uses a LayoutFactory service defined by Truffle where the latter also includes a provider. The relevant parts of the module-info descriptors are: >>> >>> module com.oracle.truffle.truffle_api { >>> >>> exports com.oracle.truffle.object; >>> exports com.oracle.truffle.object.basic; >>> >>> uses com.oracle.truffle.api.object.LayoutFactory; >>> provides com.oracle.truffle.api.object.LayoutFactory with com.oracle.truffle.object.basic.DefaultLayoutFactory; >>> >>> } >>> >>> module jdk.internal.vm.compiler { >>> requires transitive com.oracle.truffle.truffle_api; >>> uses com.oracle.truffle.api.object.LayoutFactory; >>> >>> } >>> >>> However, looking up a provider in Graal[1] returns no providers. As far as I understand service loading with modules, this is because jdk.internal.vm.compiler is loaded via the platform class loader while truffle is loaded via the app class loader as shown by the output of trace statements I added: >>> >>> GraalTruffleRuntime.class.getClassLoader() -> jdk.internal.loader.ClassLoaders$PlatformClassLoader at 366e2eef >>> LayoutFactory.class.getClassLoader() -> jdk.internal.loader.ClassLoaders$AppClassLoader at 6df97b55 >>> >>> This ability of a platform loaded class to depend on an app loaded class is probably due to the soon-to-be-disabled mechanism[2] we use for overriding the version of Graal bundled with JDK 9. >>> >>> Is there some command line magic I can use to make this case work now or do I have to wait until [2] is addressed? If the latter, how will it work then? >>> >> An upgraded moduledefined to the platform loader can link to types in modules defined to the app loader. So I wouldn't expect issues there. >> >> Can you track down the code that uses ServiceLoader.load to load the LayoutFactory providers? > > The code is in the first link of my previous message: > > https://github.com/graalvm/graal-core/blob/1efc1c543acd7ed447c59788aeabc223be13e774/graal/org.graalvm.compiler.truffle/src/org/graalvm/compiler/truffle/GraalTruffleRuntime.java#L693 > >> It might be using loadInstalled or invoking it with the platform class loader and that would explain what you are seeing. > > Thanks - using LayoutFactory.class.getClassLoader() works. So the general rule is to use the leaf most class loader the service client knows about? If that's the case, does that mean I could pick up any provider on the app class path? Seems a little risky. Is there some way to confine it to modules the service user trusts (by virtual of being a module in its dependency graph)? -Doug From doug.simon at oracle.com Sun Feb 26 13:13:32 2017 From: doug.simon at oracle.com (Doug Simon) Date: Sun, 26 Feb 2017 14:13:32 +0100 Subject: Problem loading Truffle service providers in Graal In-Reply-To: <7D3F4645-5219-4EE7-97A6-9B6131811735@oracle.com> References: <7D3F4645-5219-4EE7-97A6-9B6131811735@oracle.com> Message-ID: <78D820BA-F0B0-4F65-82CC-41B9F5A5BE6F@oracle.com> > On 26 Feb 2017, at 13:26, Doug Simon wrote: > >> >> On 26 Feb 2017, at 13:22, Doug Simon wrote: >> >>> >>> On 26 Feb 2017, at 13:08, Alan Bateman wrote: >>> >>> On 26/02/2017 11:20, Doug Simon wrote: >>> >>>> While trying to get upstream Graal working again with JDK 9, I'm having problems with service loading. Graal uses a LayoutFactory service defined by Truffle where the latter also includes a provider. The relevant parts of the module-info descriptors are: >>>> >>>> module com.oracle.truffle.truffle_api { >>>> >>>> exports com.oracle.truffle.object; >>>> exports com.oracle.truffle.object.basic; >>>> >>>> uses com.oracle.truffle.api.object.LayoutFactory; >>>> provides com.oracle.truffle.api.object.LayoutFactory with com.oracle.truffle.object.basic.DefaultLayoutFactory; >>>> >>>> } >>>> >>>> module jdk.internal.vm.compiler { >>>> requires transitive com.oracle.truffle.truffle_api; >>>> uses com.oracle.truffle.api.object.LayoutFactory; >>>> >>>> } >>>> >>>> However, looking up a provider in Graal[1] returns no providers. As far as I understand service loading with modules, this is because jdk.internal.vm.compiler is loaded via the platform class loader while truffle is loaded via the app class loader as shown by the output of trace statements I added: >>>> >>>> GraalTruffleRuntime.class.getClassLoader() -> jdk.internal.loader.ClassLoaders$PlatformClassLoader at 366e2eef >>>> LayoutFactory.class.getClassLoader() -> jdk.internal.loader.ClassLoaders$AppClassLoader at 6df97b55 >>>> >>>> This ability of a platform loaded class to depend on an app loaded class is probably due to the soon-to-be-disabled mechanism[2] we use for overriding the version of Graal bundled with JDK 9. >>>> >>>> Is there some command line magic I can use to make this case work now or do I have to wait until [2] is addressed? If the latter, how will it work then? >>>> >>> An upgraded moduledefined to the platform loader can link to types in modules defined to the app loader. So I wouldn't expect issues there. >>> >>> Can you track down the code that uses ServiceLoader.load to load the LayoutFactory providers? >> >> The code is in the first link of my previous message: >> >> https://github.com/graalvm/graal-core/blob/1efc1c543acd7ed447c59788aeabc223be13e774/graal/org.graalvm.compiler.truffle/src/org/graalvm/compiler/truffle/GraalTruffleRuntime.java#L693 >> >>> It might be using loadInstalled or invoking it with the platform class loader and that would explain what you are seeing. >> >> Thanks - using LayoutFactory.class.getClassLoader() works. So the general rule is to use the leaf most class loader the service client knows about? > > If that's the case, does that mean I could pick up any provider on the app class path? Seems a little risky. Is there some way to confine it to modules the service user trusts (by virtual of being a module in its dependency graph)? Also, what if there's provider in jdk.internal.vm.compiler itself? Will it be loaded along with the providers on my module path? -Doug From Alan.Bateman at oracle.com Sun Feb 26 13:35:27 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 26 Feb 2017 13:35:27 +0000 Subject: Problem loading Truffle service providers in Graal In-Reply-To: <7D3F4645-5219-4EE7-97A6-9B6131811735@oracle.com> References: <7D3F4645-5219-4EE7-97A6-9B6131811735@oracle.com> Message-ID: On 26/02/2017 12:26, Doug Simon wrote: > : > If that's the case, does that mean I could pick up any provider on the app class path? Seems a little risky. Is there some way to confine it to modules the service user trusts (by virtual of being a module in its dependency graph)? > You can restrict the service type using a qualified export. -Alan From Alan.Bateman at oracle.com Sun Feb 26 13:44:42 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 26 Feb 2017 13:44:42 +0000 Subject: Problem loading Truffle service providers in Graal In-Reply-To: <78D820BA-F0B0-4F65-82CC-41B9F5A5BE6F@oracle.com> References: <7D3F4645-5219-4EE7-97A6-9B6131811735@oracle.com> <78D820BA-F0B0-4F65-82CC-41B9F5A5BE6F@oracle.com> Message-ID: On 26/02/2017 13:13, Doug Simon wrote: > : > Also, what if there's provider in jdk.internal.vm.compiler itself? Will it be loaded along with the providers on my module path? > If it has `provides com.oracle.truffle.api.object.LayoutFactory` then it will be located too. If the provider interface is only for overriding then you could use ServiceLoader.load(LayerFactory.class).findFirst().orElse(DefaultLayoutFactory.get()) so that it use a default/fallback implementation in your module when there isn't a provider deployed on the module path. -Alan From doug.simon at oracle.com Sun Feb 26 13:54:38 2017 From: doug.simon at oracle.com (Doug Simon) Date: Sun, 26 Feb 2017 14:54:38 +0100 Subject: Problem loading Truffle service providers in Graal In-Reply-To: References: <7D3F4645-5219-4EE7-97A6-9B6131811735@oracle.com> <78D820BA-F0B0-4F65-82CC-41B9F5A5BE6F@oracle.com> Message-ID: <31EE63B3-7076-4BF6-BE65-F100945B1B22@oracle.com> > On 26 Feb 2017, at 14:44, Alan Bateman wrote: > > > > On 26/02/2017 13:13, Doug Simon wrote: >> : >> Also, what if there's provider in jdk.internal.vm.compiler itself? Will it be loaded along with the providers on my module path? >> > If it has `provides com.oracle.truffle.api.object.LayoutFactory` then it will be located too. I assume that's because the app class loader delegates to the platform class loader? > If the provider interface is only for overriding then you could use ServiceLoader.load(LayerFactory.class).findFirst().orElse(DefaultLayoutFactory.get()) so that it use a default/fallback implementation in your module when there isn't a provider deployed on the module path. Ok, thanks for the tip. -Doug From frodwith at gmail.com Mon Feb 27 17:30:09 2017 From: frodwith at gmail.com (Paul Driver) Date: Mon, 27 Feb 2017 09:30:09 -0800 Subject: Truffle DSL compiler detection Message-ID: I'm trying build some truffle code with leiningen (a clojure build tool). It has a "lein javac" task which invokes the java compiler. Under the covers, this calls the ant "javac" task. The compiler being used is in fact oracle javac (as you can see in attached stacktrace) but isn't being invoked by the javac executable, but rather being called as a library. My truffle code compiles when I invoke the javac tool from the command line and under eclipse. My suspicion is that the Class.forName (in https://github.com/graalvm/truffle/blob/master/truffle/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/java/compiler/JavaCCompiler.java) is not working as a way to detect javac when it is invoked the way leiningen is invoking it. A relevant piece of stacktrace is pasted below. Any help is appreciated. /home/pdriver/code/jaque/src/java/jaque/truffle/NockNode.java:15: error: Uncaught error in AnnotationProcessor while processing jaque.truffle.NockNode : Parsing of Node jaque.truffle.NockNode failed. public abstract class NockNode extends Node { ^ java.lang.RuntimeException: Parsing of Node jaque.truffle.NockNode failed. at com.oracle.truffle.dsl.processor.parser.NodeParser.parseRootType(NodeParser.java:162) at com.oracle.truffle.dsl.processor.parser.NodeParser.parse(NodeParser.java:111) at com.oracle.truffle.dsl.processor.parser.NodeParser.parse(NodeParser.java:101) at com.oracle.truffle.dsl.processor.parser.AbstractParser.parse(AbstractParser.java:72) at com.oracle.truffle.dsl.processor.AnnotationProcessor.process(AnnotationProcessor.java:80) at com.oracle.truffle.dsl.processor.TruffleProcessor.processElement(TruffleProcessor.java:98) at com.oracle.truffle.dsl.processor.TruffleProcessor.processImpl(TruffleProcessor.java:86) at com.oracle.truffle.dsl.processor.TruffleProcessor.process(TruffleProcessor.java:60) at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:794) at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:705) at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1800(JavacProcessingEnvironment.java:91) at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1035) at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1176) at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856) at com.sun.tools.javac.main.Main.compile(Main.java:523) at com.sun.tools.javac.main.Main.compile(Main.java:381) at com.sun.tools.javac.main.Main.compile(Main.java:370) at com.sun.tools.javac.main.Main.compile(Main.java:361) at com.sun.tools.javac.Main.compile(Main.java:74) at com.sun.tools.javac.api.JavacTool.run(JavacTool.java:237) at user$eval3.invokeStatic(form-init7367735244504712043.clj:1) at user$eval3.invoke(form-init7367735244504712043.clj:1) at clojure.lang.Compiler.eval(Compiler.java:6927) at clojure.lang.Compiler.load(Compiler.java:7379) at clojure.lang.Compiler.loadFile(Compiler.java:7317) at clojure.main$load_script.invokeStatic(main.clj:275) at clojure.main$init_opt.invokeStatic(main.clj:277) at clojure.main$init_opt.invoke(main.clj:277) at clojure.main$initialize.invokeStatic(main.clj:308) at clojure.main$null_opt.invokeStatic(main.clj:342) at clojure.main$null_opt.invoke(main.clj:339) at clojure.main$main.invokeStatic(main.clj:421) at clojure.main$main.doInvoke(main.clj:384) at clojure.lang.RestFn.invoke(RestFn.java:421) at clojure.lang.Var.invoke(Var.java:383) at clojure.lang.AFn.applyToHelper(AFn.java:156) at clojure.lang.Var.applyTo(Var.java:700) at clojure.main.main(main.java:37) Suppressed: java.lang.UnsupportedOperationException: Unsupported compiler for element com.sun.tools.javac.code.Symbol$ClassSymbol. at com.oracle.truffle.dsl.processor.java.compiler.CompilerFactory.getCompiler(CompilerFactory.java:44) at com.oracle.truffle.dsl.processor.parser.NodeParser.loadMembers(NodeParser.java:318) at com.oracle.truffle.dsl.processor.parser.NodeParser.parseNode(NodeParser.java:192) at com.oracle.truffle.dsl.processor.parser.NodeParser.parseRootType(NodeParser.java:158) ... 38 more From gilles.m.duboscq at oracle.com Mon Feb 27 17:43:42 2017 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Mon, 27 Feb 2017 18:43:42 +0100 Subject: Truffle DSL compiler detection In-Reply-To: References: Message-ID: Hi Paul, Most compilations with the mx tool are also done in a similar way (using javac as a libarary [1]). So there should not be any fundamental problem with this in the Truffle DSL annotation processor. What are the arguments you pass to JavacTool.run? Gilles [1]: https://github.com/graalvm/mx/blob/master/java/com.oracle.mxtool.compilerserver/src/com/oracle/mxtool/compilerserver/JavacDaemon.java On 27/02/17 18:30, Paul Driver wrote: > I'm trying build some truffle code with leiningen (a clojure build > tool). It has a "lein javac" task which invokes the java compiler. > Under the covers, this calls the ant "javac" task. The compiler being > used is in fact oracle javac (as you can see in attached stacktrace) > but isn't being invoked by the javac executable, but rather being > called as a library. > > My truffle code compiles when I invoke the javac tool from the command > line and under eclipse. My suspicion is that the Class.forName (in > https://github.com/graalvm/truffle/blob/master/truffle/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/java/compiler/JavaCCompiler.java) > is not working as a way to detect javac when it is invoked the way > leiningen is invoking it. > > A relevant piece of stacktrace is pasted below. Any help is appreciated. > > /home/pdriver/code/jaque/src/java/jaque/truffle/NockNode.java:15: > error: Uncaught error in AnnotationProcessor while processing > jaque.truffle.NockNode : Parsing of Node jaque.truffle.NockNode > failed. > public abstract class NockNode extends Node { > ^ > java.lang.RuntimeException: Parsing of Node jaque.truffle.NockNode failed. > at com.oracle.truffle.dsl.processor.parser.NodeParser.parseRootType(NodeParser.java:162) > at com.oracle.truffle.dsl.processor.parser.NodeParser.parse(NodeParser.java:111) > at com.oracle.truffle.dsl.processor.parser.NodeParser.parse(NodeParser.java:101) > at com.oracle.truffle.dsl.processor.parser.AbstractParser.parse(AbstractParser.java:72) > at com.oracle.truffle.dsl.processor.AnnotationProcessor.process(AnnotationProcessor.java:80) > at com.oracle.truffle.dsl.processor.TruffleProcessor.processElement(TruffleProcessor.java:98) > at com.oracle.truffle.dsl.processor.TruffleProcessor.processImpl(TruffleProcessor.java:86) > at com.oracle.truffle.dsl.processor.TruffleProcessor.process(TruffleProcessor.java:60) > at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:794) > at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:705) > at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1800(JavacProcessingEnvironment.java:91) > at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1035) > at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1176) > at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170) > at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856) > at com.sun.tools.javac.main.Main.compile(Main.java:523) > at com.sun.tools.javac.main.Main.compile(Main.java:381) > at com.sun.tools.javac.main.Main.compile(Main.java:370) > at com.sun.tools.javac.main.Main.compile(Main.java:361) > at com.sun.tools.javac.Main.compile(Main.java:74) > at com.sun.tools.javac.api.JavacTool.run(JavacTool.java:237) > at user$eval3.invokeStatic(form-init7367735244504712043.clj:1) > at user$eval3.invoke(form-init7367735244504712043.clj:1) > at clojure.lang.Compiler.eval(Compiler.java:6927) > at clojure.lang.Compiler.load(Compiler.java:7379) > at clojure.lang.Compiler.loadFile(Compiler.java:7317) > at clojure.main$load_script.invokeStatic(main.clj:275) > at clojure.main$init_opt.invokeStatic(main.clj:277) > at clojure.main$init_opt.invoke(main.clj:277) > at clojure.main$initialize.invokeStatic(main.clj:308) > at clojure.main$null_opt.invokeStatic(main.clj:342) > at clojure.main$null_opt.invoke(main.clj:339) > at clojure.main$main.invokeStatic(main.clj:421) > at clojure.main$main.doInvoke(main.clj:384) > at clojure.lang.RestFn.invoke(RestFn.java:421) > at clojure.lang.Var.invoke(Var.java:383) > at clojure.lang.AFn.applyToHelper(AFn.java:156) > at clojure.lang.Var.applyTo(Var.java:700) > at clojure.main.main(main.java:37) > Suppressed: java.lang.UnsupportedOperationException: Unsupported > compiler for element com.sun.tools.javac.code.Symbol$ClassSymbol. > at com.oracle.truffle.dsl.processor.java.compiler.CompilerFactory.getCompiler(CompilerFactory.java:44) > at com.oracle.truffle.dsl.processor.parser.NodeParser.loadMembers(NodeParser.java:318) > at com.oracle.truffle.dsl.processor.parser.NodeParser.parseNode(NodeParser.java:192) > at com.oracle.truffle.dsl.processor.parser.NodeParser.parseRootType(NodeParser.java:158) > ... 38 more > From frodwith at gmail.com Mon Feb 27 18:12:39 2017 From: frodwith at gmail.com (Paul Driver) Date: Mon, 27 Feb 2017 10:12:39 -0800 Subject: Truffle DSL compiler detection In-Reply-To: References: Message-ID: That's unfortunately not trivial to discover (it's being called by leiningen and i'm struggling to find a good way to debug it), but it's good to know that I was barking up the wrong tree. Thanks Gilles. On Mon, Feb 27, 2017 at 9:43 AM, Gilles Duboscq wrote: > Hi Paul, > > Most compilations with the mx tool are also done in a similar way (using javac as a libarary [1]). So there should not be any fundamental problem with this in the Truffle DSL annotation processor. > > What are the arguments you pass to JavacTool.run? > > Gilles > > [1]: https://github.com/graalvm/mx/blob/master/java/com.oracle.mxtool.compilerserver/src/com/oracle/mxtool/compilerserver/JavacDaemon.java > > On 27/02/17 18:30, Paul Driver wrote: >> I'm trying build some truffle code with leiningen (a clojure build >> tool). It has a "lein javac" task which invokes the java compiler. >> Under the covers, this calls the ant "javac" task. The compiler being >> used is in fact oracle javac (as you can see in attached stacktrace) >> but isn't being invoked by the javac executable, but rather being >> called as a library. >> >> My truffle code compiles when I invoke the javac tool from the command >> line and under eclipse. My suspicion is that the Class.forName (in >> https://github.com/graalvm/truffle/blob/master/truffle/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/java/compiler/JavaCCompiler.java) >> is not working as a way to detect javac when it is invoked the way >> leiningen is invoking it. >> >> A relevant piece of stacktrace is pasted below. Any help is appreciated. >> >> /home/pdriver/code/jaque/src/java/jaque/truffle/NockNode.java:15: >> error: Uncaught error in AnnotationProcessor while processing >> jaque.truffle.NockNode : Parsing of Node jaque.truffle.NockNode >> failed. >> public abstract class NockNode extends Node { >> ^ >> java.lang.RuntimeException: Parsing of Node jaque.truffle.NockNode failed. >> at com.oracle.truffle.dsl.processor.parser.NodeParser.parseRootType(NodeParser.java:162) >> at com.oracle.truffle.dsl.processor.parser.NodeParser.parse(NodeParser.java:111) >> at com.oracle.truffle.dsl.processor.parser.NodeParser.parse(NodeParser.java:101) >> at com.oracle.truffle.dsl.processor.parser.AbstractParser.parse(AbstractParser.java:72) >> at com.oracle.truffle.dsl.processor.AnnotationProcessor.process(AnnotationProcessor.java:80) >> at com.oracle.truffle.dsl.processor.TruffleProcessor.processElement(TruffleProcessor.java:98) >> at com.oracle.truffle.dsl.processor.TruffleProcessor.processImpl(TruffleProcessor.java:86) >> at com.oracle.truffle.dsl.processor.TruffleProcessor.process(TruffleProcessor.java:60) >> at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:794) >> at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:705) >> at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1800(JavacProcessingEnvironment.java:91) >> at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1035) >> at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1176) >> at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170) >> at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856) >> at com.sun.tools.javac.main.Main.compile(Main.java:523) >> at com.sun.tools.javac.main.Main.compile(Main.java:381) >> at com.sun.tools.javac.main.Main.compile(Main.java:370) >> at com.sun.tools.javac.main.Main.compile(Main.java:361) >> at com.sun.tools.javac.Main.compile(Main.java:74) >> at com.sun.tools.javac.api.JavacTool.run(JavacTool.java:237) >> at user$eval3.invokeStatic(form-init7367735244504712043.clj:1) >> at user$eval3.invoke(form-init7367735244504712043.clj:1) >> at clojure.lang.Compiler.eval(Compiler.java:6927) >> at clojure.lang.Compiler.load(Compiler.java:7379) >> at clojure.lang.Compiler.loadFile(Compiler.java:7317) >> at clojure.main$load_script.invokeStatic(main.clj:275) >> at clojure.main$init_opt.invokeStatic(main.clj:277) >> at clojure.main$init_opt.invoke(main.clj:277) >> at clojure.main$initialize.invokeStatic(main.clj:308) >> at clojure.main$null_opt.invokeStatic(main.clj:342) >> at clojure.main$null_opt.invoke(main.clj:339) >> at clojure.main$main.invokeStatic(main.clj:421) >> at clojure.main$main.doInvoke(main.clj:384) >> at clojure.lang.RestFn.invoke(RestFn.java:421) >> at clojure.lang.Var.invoke(Var.java:383) >> at clojure.lang.AFn.applyToHelper(AFn.java:156) >> at clojure.lang.Var.applyTo(Var.java:700) >> at clojure.main.main(main.java:37) >> Suppressed: java.lang.UnsupportedOperationException: Unsupported >> compiler for element com.sun.tools.javac.code.Symbol$ClassSymbol. >> at com.oracle.truffle.dsl.processor.java.compiler.CompilerFactory.getCompiler(CompilerFactory.java:44) >> at com.oracle.truffle.dsl.processor.parser.NodeParser.loadMembers(NodeParser.java:318) >> at com.oracle.truffle.dsl.processor.parser.NodeParser.parseNode(NodeParser.java:192) >> at com.oracle.truffle.dsl.processor.parser.NodeParser.parseRootType(NodeParser.java:158) >> ... 38 more >> From frodwith at gmail.com Mon Feb 27 19:31:35 2017 From: frodwith at gmail.com (Paul Driver) Date: Mon, 27 Feb 2017 11:31:35 -0800 Subject: Truffle DSL compiler detection In-Reply-To: References: Message-ID: It took some digging. Leiningen writes a temp file containing the following and then passes .run(null, null, null, "@filename"). Simply pasting the arguments to command line works correctly. Any thoughts? -cp "/home/pdriver/code/jaque/test:/home/pdriver/code/jaque/src/clojure:/home/pdriver/code/jaque/dev-resources:/home/pdriver/code/jaque/resources:/home/pdriver/code/jaque/target/classes:/home/pdriver/.m2/repository/cider/cider-nrepl/0.10.2/cider-nrepl-0.10.2.jar:/home/pdriver/.m2/repository/org/tcrawley/dynapath/0.2.3/dynapath-0.2.3.jar:/home/pdriver/.m2/repository/org/clojure/clojure/1.8.0/clojure-1.8.0.jar:/home/pdriver/.m2/repository/com/oracle/truffle/truffle-api/0.22/truffle-api-0.22.jar:/home/pdriver/.m2/repository/com/oracle/truffle/truffle-dsl-processor/0.22/truffle-dsl-processor-0.22.jar:/home/pdriver/.m2/repository/slingshot/slingshot/0.12.2/slingshot-0.12.2.jar:/home/pdriver/.m2/repository/org/clojure/tools.nrepl/0.2.12/tools.nrepl-0.2.12.jar:/home/pdriver/.m2/repository/clojure-complete/clojure-complete/0.2.4/clojure-complete-0.2.4.jar" -d "/home/pdriver/code/jaque/target/classes" "/home/pdriver/code/jaque/src/java/jaque/interpreter/Interpreter.java" From adinn at redhat.com Tue Feb 28 11:44:26 2017 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 28 Feb 2017 11:44:26 +0000 Subject: RFR: AArch64: Implementing address lowering to make use of immediate address mode Message-ID: <206f2ccf-7e37-1b7b-3f30-7b319ddb6534@redhat.com> I have patched (a slightly out of date version of) Graal to allow AArch64 to make use of scaled and unscaled immediate addressing. This generates much better code but the implementation is 'wrong' in several important respects. A pull request including the change is available here https://github.com/graalvm/graal-core/pull/258 I have no wish for this change to be included as is - I posted it merely to enable discussion of what is really needed. The patch deliberately bypasses the normal AddressLowering phase (I'll explain why in a second). Instead it intercepts translation of addresses during the generate phase. Basically, it attempts to improve addresses initially generated as an OffsetAddress (i.e. supplied with 2 Values, base and index) when the index is an integer constant whcih can be embedded as an immediate displacement (I guess it ought to handle the reverse case where base is a constant and index a general Value but nothing appears to be generating addresses with constants in that order). It does so by 'nulling' the index saving the constant as a displacement and resetting the addressing mode from register offset to scaled or unscaled immediate. So, before applying the patch addresses with constant index were 'improved' by replacing the constant node with a constant load and relying on the use of register_offset addressing mode to do the actual memory operation. The result is code like this: movz x3, #0xc # constant load of offset value movk x3, #0x0, lsl #16 ldr w1 [x2, x3] # (1) load via register_offset addressing The patch tries instead to transform the node to use either scaled or unscaled immediate addressing resulting, respectively, in code like this: ldr w1, [x2,#12] # (2) load via scaled immediate addressing or (let's assume we had a negative offset mandating an unscaled load) ldr w1, [x2, #-12] # (3) load via unscaled immediate addressing There are two related reasons why this has been done in the Generate phase rather than in the AddressLowering phase. I present them both in turn below in order to pose some questions about why AddressLowering is currently done as is and to suggest what might be needed to fix it. I have also include a critique of the way a derived LIRKind is computed for the AddressValue returned by method generate(). I am unclear why it is currently being computed as is and also unclear what would be an appropriate derived value when immediates are encoded. Advice or comments regarding the patch and the following critique would be very welcome. Scaling depends on the transfer size ------------------------------------ The first problem is that for scaled memory addressing the decision as to whether or not a given constant index can be embedded as an immediate constant in the address node depends upon how the address is used by one or more memory ops. In code example (2) which uses scaled addressing above the load instruction is transferring a 32 bit datum (as indicated in the assembly code by the target register being named w1). The load address is the 64 bit value in r1 (as indicated in the assembly code by the base register being named x1) plus constant offset 12. A scaled immediate memory op can embed a 12 bit unsigned displacement. However, the unit size for the embedded value is determined by the size of the accessed datum. So, for a 32 bit load/store the set of offsets which are valid is {4, 8, ... 4 * (2^12 - 1)}. For a byte load the set of valid offsets is {1, 2, ... (2^12-1)}. Obviously, as the name clearly indicates, there is no dependency on transfer size when using unscaled addressing. Memory ops employing this latter addressing may embed any signed 9-bit displacement which is always counted in a unit size of bytes. So, translation to use unscaled addressing in the AddressLowering phase doesn't present any great problem. However, generating the best code requires implementing both modes. The upshot is that in order to determine whether a constant index can be replaced by an immediate node the lowering code needs to investigate usages of the address node and establish that all usages employ a unique transfer size. As you can see in the pull request, the patch includes a method getUsageSize() which does that job. It traverses all usages and returns either a single platform kind which defines a transfer size common to all usages or null if no such unique common kind exists. This leads to the second problem. (n.b. I have finessed Prefetch usages for now because the current AArch64 Graal does not generate code for prefetch. That will need fixing when it is implemented). Identification of the platform kind requires a generator -------------------------------------------------------- The above requirement explains why the lowering code is implemented as part of the Generate phase instead of in the AddressLowering phase. Identifying the PlatformKind associated with a specific usage of the AddressNode requires translating the stamp of each usage to an LIRKind. That mandates availability of a suitable instance of LIRKindTool (actually an AArch64LIRKindTool) which parameterizes the call to getUsageSize(). The KindTool must be obtained from the AArch64LIRGenerator tool which is obtained form the NodeLIRBuilderTool passed to the AArch64AddressNode generate() method. I don't doubt that here is some sneaky way of ensuring that the AArch64AddressLowering instance obtains access to an AArch64LIRGenerator (and, thence, an AArch64LIRKindTool) behind the scenes. However, implementing a solution like that does not really seem to me to be the correct solution. There is an assumption in the current code that address lowering can be done prior to the Generate phase without needing to identify whatever transfer datum and/or transfer size is at stake when the address is being used. That's a broken assumption and I would prefer to fix it. One solution would be to have the generic code precompute the common usage LIRKind and pass it to the implementation class which extends AddressLowering. Alternatively, the abstract parent class could provide a convenience method allowing a suitable PlatformKind to be computed. Either way this means that the parent needs to know about the Arch and know how to obtain an arch-specific KindTool. I'm happy to look into proposing a solution along these lines but I'd like to canvas here for comments before doing so. Another alternative would be to perform address lowering at a later stage, perhaps in the back end even. This would perhaps require doing some of the transforms done in e.g. AMD64AddressLowering as generic transforms and having a generic AddressNode which allowed for a non-constant index and/or constant displacement. I'm also happy to consider how this might work but I'd probably need more advice about how to go about this. The LIRKind of the resulting AddressValue -- is it correct? ----------------------------------------------------------- The patch in the pull request attempts to follow the logic of the preceding code in deriving an LIRKind for whatever AddressNode it constructs, whether using register offset or immediate addressing. However, I am not sure what the original logic is. In the original code for AArch64AddressNode.generate() the case where the either base or index was null is treated by setting, respectively, baseValue or indexValue to Value.ILLEGAL. Later in that original code this implies that indexReference is also set to Value.ILLEGAL. The LIRKind for the final resulting AArch64AddressValue is computed by executing LIRKind kind = LIRKind.combineDerived(tool.getLIRKind(stamp()), baseReference, indexReference); So, when base is, say, a register and index is null this represents a direct reference through a register with no offset. I would have expected that in this circumstance there was some coherent way of deriving the LIRKind of the address from the LIRKind associated with base. However, because index is null, so indexValue is Value.ILLEGAL and hence indexReference is also Value.ILLEGAL. combineDerived handles this case by returning an unknown reference derived from the stamp(). By contrast, if indexReference was null then combineDerived would compute the combined reference by calling makeDerivedReference(base). My patch follows this code by starting off with indexValue = null then resetting it to Value.ILLEGAL either if it is null or if it is possible to intervene and replace a constant index with a displacement. Otherwise, when we have a non-null index, indexValue is computed as before by executing indexValue = tool.asAllocatable(gen.operand(index)); I have also preserved the original special case processing for AddressingMode.IMMEDIATE_UNSCALED where the indexReference is derived by executing indexReference = LIRKind.derivedBaseFromValue(indexValue); although I'll note that in cases where that addressing mode is introduced by replacing a constant index with an unscaled displacement indexValue will be Value.ILLEGAL and hence the indexReference will be returned as Value.ILLEGAL which seems to negate the purpose of that special case handling. I am suspicious that all of this computation seems to be rather redundant anyway. At the point of use of an Address to encode a Load or Store (or possibly a Prefetch) the LIRKind of the address appears to be ignored and instead the LIRKind of the transfer datum is used to generate the load. Is this computation of the derived actually achieving anything important? 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 deepali_patel at persistent.com Tue Feb 28 12:47:59 2017 From: deepali_patel at persistent.com (Deepali Patel) Date: Tue, 28 Feb 2017 12:47:59 +0000 Subject: Error while building JVMCI enabled JDK8 on Power In-Reply-To: <6B778C59-F1F2-4973-AD86-15C27C9EB335@oracle.com> References: <6B778C59-F1F2-4973-AD86-15C27C9EB335@oracle.com> Message-ID: Hi Doug, Thanks for helpful response. I have copied jvmci/jdk.vm.ci.amd64 and jvmci/jdk.vm.ci.hotspot.amd64 to create jvmci/jdk.vm.ci.ppc64 and jvmci/jdk.vm.ci.hotspot.ppc64 (as suggested by Gilles) respectively. I have modified the source code files to reflect ppc64 instead of amd64 in these folders. Then I realized that graal-jvmci-8/mx.jvmci/suite.py also needs to be updated to incorporate these new folders. I have also added ppc64le as the supported arch for the Distributions in graal-jvmci-8/mx.jvmci/suite.py. By default, the ppc64 is set as arch for LE versions as well, however this leads to following error. The jdk source code has jvm.cfg file under ppc64le folder: mx --java-home /usr/lib/jvm/java-8-openjdk-ppc64el build None {'ppc64': {'path': 'build/product/linux/ppc64/server/jvm.tar'}, 'amd64': {'path': 'build/product/linux/amd64/server/jvm.tar'}, 'sparcv9': {'path': 'build/product/linux/sparcv9/server/jvm.tar'}} Creating /home/deepali/Graal/graal-jvmci-8/jdk1.8.0_121/product from /usr/lib/jvm/java-8-openjdk-ppc64el /home/deepali/Graal/graal-jvmci-8/jdk1.8.0_121/product/jre/lib/ppc64/jvm.cfg does not exist Thus I think I need to update the arch to ppc64le in the makefiles. Another thing that I noticed is " WARNING: hsdis with flavor 'None' not supported on this plattform or architecture". So looks like I will need to port hsdis as well because it is not available for ppc at https://lafo.ssw.uni-linz.ac.at/pub/hsdis/. Regards Deepali -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Friday, February 24, 2017 2:48 PM To: Deepali Patel Cc: Gilles Duboscq; graal-dev at openjdk.java.net Subject: Re: Error while building JVMCI enabled JDK8 on Power > On 24 Feb 2017, at 09:20, Deepali Patel wrote: > > Thanks Doug and Gilles for quick response. > > Could you please throw some more light on the parts of code(folders, files etc) that will need to be updated/modified to get this working on PPC. Would we need assembly code as well? If so, could you please point me to the corresponding x86 files for reference. dsimon at kurz-3 ~/g/graal-jvmci-8> find src | grep jvmci | grep x86 src/cpu/x86/vm/jvmci_globals_x86.hpp src/cpu/x86/vm/jvmciCodeInstaller_x86.cpp dsimon at kurz-3 ~/g/graal-jvmci-8> find src | grep jvmci | grep sparc src/cpu/sparc/vm/jvmci_globals_sparc.hpp src/cpu/sparc/vm/jvmciCodeInstaller_sparc.cpp dsimon at kurz-3 ~/g/graal-core> ls -d graal/*sparc* graal/org.graalvm.compiler.asm.sparc graal/org.graalvm.compiler.core.sparc.test graal/org.graalvm.compiler.replacements.sparc graal/org.graalvm.compiler.asm.sparc.test graal/org.graalvm.compiler.hotspot.sparc graal/org.graalvm.compiler.truffle.hotspot.sparc graal/org.graalvm.compiler.core.sparc graal/org.graalvm.compiler.lir.sparc dsimon at kurz-3 ~/g/graal-core> ls -d graal/*amd64* graal/org.graalvm.compiler.asm.amd64 graal/org.graalvm.compiler.core.amd64.test graal/org.graalvm.compiler.lir.amd64 graal/org.graalvm.compiler.asm.amd64.test graal/org.graalvm.compiler.hotspot.amd64 graal/org.graalvm.compiler.replacements.amd64 graal/org.graalvm.compiler.core.amd64 graal/org.graalvm.compiler.hotspot.amd64.test graal/org.graalvm.compiler.truffle.hotspot.amd64 Hope that helps, -Doug > -----Original Message----- > From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf > Of Gilles Duboscq > Sent: Thursday, February 23, 2017 5:02 PM > To: graal-dev at openjdk.java.net > Subject: Re: Error while building JVMCI enabled JDK8 on Power > > You will also need to implement the Java side of things. > See for example the sources in jvmci/jdk.vm.ci.amd64 and jvmci/jdk.vm.ci.hotspot.amd64. > > Gilles > > On 23/02/17 11:26, Doug Simon wrote: >> Hi Deepali, >> >> This is an interesting but non-trivial project I suspect. You will need to look at all the machine specific JVMCI files and create corresponding *_ppc.[hpp|cpp] files. The existing jvmciGlobals_ppc.hpp needs to be renamed to jvmci_globals_ppc.hpp (as you observed) and completed as part of this. >> >> -Doug >> >>> On 23 Feb 2017, at 10:41, Deepali Patel wrote: >>> >>> Hello Team, >>> >>> I am trying to build Graal core on Power. >>> >>> >>> 1. I have updated mx.py to allow build on Power: >>> ----------------- >>> diff --git a/mx.py b/mx.py >>> index 172609d..de932f6 100755 >>> --- a/mx.py >>> +++ b/mx.py >>> @@ -7369,6 +7369,8 @@ def get_arch(): >>> except OSError: >>> # sysctl is not available >>> pass >>> + if machine == 'ppc64le' and get_os() == 'linux': >>> + return 'ppc64le' >>> abort('unknown or unsupported architecture: os=' + get_os() + ', >>> machine=' + machine) >>> >>> mx_subst.results_substitutions.register_no_arg('arch', get_arch) >>> ------------------------------ >>> >>> >>> 2. Next I am trying to build building JVMCI enabled JDK8. However, I see following error: >>> >>> Generating precompiled header precompiled.hpp.gch >>> >>> In file included from /pathto/allocation.hpp:28:0, >>> >>> from /pathto/iterator.hpp:28, >>> >>> from /pathto/genOopClosures.hpp:28, >>> >>> from /pathto/klass.hpp:28, >>> >>> from /pathto/handles.hpp:28, >>> >>> from /pathto/universe.hpp:28, >>> >>> from /pathto/oopRecorder.hpp:28, >>> >>> from /pathto/codeBuffer.hpp:28, >>> >>> from /pathto/assembler.hpp:28, >>> >>> from /pathto/precompiled.hpp:29: >>> >>> /pathto/globals.hpp:143:34: fatal error: jvmci_globals_ppc.hpp: No >>> such file or directory >>> >>> compilation terminated. >>> >>> /pathto/vm.make:322: recipe for target 'precompiled.hpp.gch' failed >>> >>> make[4]: Leaving directory '/pathto/linux_ppc64_compiler2/product' >>> >>> make[4]: *** [precompiled.hpp.gch] Error 1 >>> >>> /pathto/top.make:119: recipe for target 'the_vm' failed >>> >>> make[3]: Leaving directory '/pathto/product' >>> >>> /pathto/make/linux/Makefile:303: recipe for target 'product' failed >>> >>> make[2]: Leaving directory '/pathto/graal-jvmci-8/build/linux' >>> >>> Makefile:231: recipe for target 'generic_build2' failed >>> >>> make[1]: Leaving directory '/pathtoGraal/graal-jvmci-8/make' >>> >>> make[3]: *** [the_vm] Error 2 >>> >>> make[2]: *** [product] Error 2 >>> >>> make[1]: *** [generic_build2] Error 2 >>> >>> Makefile:182: recipe for target 'product' failed >>> >>> make: *** [product] Error 2 >>> >>> make: Leaving directory '/pathto/graal-jvmci-8/make' >>> >>> Building HotSpot[product, server] failed >>> >>> 1 build tasks failed >>> >>> >>> >>> 3. I dont see jvmci_globals_ppc.hpp in the src tree. But there is another file with name jvmciGlobals_ppc.hpp available in the src tree. I tried to use jvmciGlobals_ppc.hpp, but I get following errors: >>> >>> /pathto/graal-jvmci-8/src/cpu/ppc/vm/jvmciGlobals_ppc.hpp:35:2: >>> error: #error Unimplemented >>> >>> #error Unimplemented >>> >>> ^ >>> >>> /pathto/graal-jvmci-8/make/linux/makefiles/vm.make:322: recipe for >>> target 'precompiled.hpp.gch' failed >>> >>> Please advise if I am missing on something here. >>> >>> Regards >>> Deepali >>> >>> >>> >>> DISCLAIMER >>> ========== >>> This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. >>> >> > > DISCLAIMER > ========== > This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. > DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.