From aph at redhat.com Thu Dec 1 09:19:11 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 1 Dec 2016 09:19:11 +0000 Subject: BitScanForwardNode: LongBits test failure In-Reply-To: References: <3c15d3d3-c033-c0d7-8a6b-ad6a920c2300@redhat.com> Message-ID: <6c29b2c9-d06a-2204-7aab-802504344665@redhat.com> On 30/11/16 20:19, Tom Rodriguez wrote: > It would probably make sense to make BitScanForwardNode have straightforward semantics and just require the back to deal with the undefined nature 0 for the actual instruction. Yes, indeed it would. The current code is baffling. I'll have a look. Andrew. From aph at redhat.com Thu Dec 1 13:55:26 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 1 Dec 2016 13:55:26 +0000 Subject: Lowering multiplyExact Message-ID: Graal assumes that multiplies set the overflow flag, and relies on this for multiplyExact. AArch64 doesn't set the overlfow flag for multiply, and as far as I can see neither does SPARC, so we have to do some backward somersaults to get it to work. Right now we do this: 0x0000007fa8baec54: smull x8, w1, w2 0x0000007fa8baec58: add w0, w8, #0x0 0x0000007fa8baec5c: cmp x8, w8, sxtw 0x0000007fa8baec60: orr x8, xzr, #0x80000000 0x0000007fa8baec64: csel w8, w8, wzr, ne 0x0000007fa8baec68: cmp w8, #0x1 0x0000007fa8baec6c: b.vs 0x0000007fa8baec8c which is x8 = i2l(w1) * i2l(w2) result = l2i(x8) flags = compare(x8, result) x8 = 0x80000000 w8 = flags.ne ? w8 : 0 flags = compare(w8, 1) ... if (flags.vs) goto overflow But it could be simply x8 = i2l(w1) * i2l(w2) result = l2i(x8) flags = compare(x8, result) ... if (flags.ne) goto overflow if we had a lowering for multiplyExact that didn't assume that multiplies set the overflow flag. It's really not an important thing, but it's kinda irksome. :-) Andrew. From aph at redhat.com Thu Dec 1 14:53:43 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 1 Dec 2016 14:53:43 +0000 Subject: Parallel jtreg? Message-ID: <78459e38-e7b1-2a3c-cf5e-733ed0d42ff5@redhat.com> Is there any way to run the tests in parallel? It's improve my life no end. Thanks, Andrew. From shade at redhat.com Thu Dec 1 14:58:00 2016 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 1 Dec 2016 15:58:00 +0100 Subject: Parallel jtreg? In-Reply-To: <78459e38-e7b1-2a3c-cf5e-733ed0d42ff5@redhat.com> References: <78459e38-e7b1-2a3c-cf5e-733ed0d42ff5@redhat.com> Message-ID: On 12/01/2016 03:53 PM, Andrew Haley wrote: > Is there any way to run the tests in parallel? It's improve my life > no end. Yes, e.g.: $ jtreg -conc:8 ... -Aleksey From aph at redhat.com Thu Dec 1 15:05:06 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 1 Dec 2016 15:05:06 +0000 Subject: Parallel jtreg? In-Reply-To: References: <78459e38-e7b1-2a3c-cf5e-733ed0d42ff5@redhat.com> Message-ID: On 01/12/16 14:58, Aleksey Shipilev wrote: > On 12/01/2016 03:53 PM, Andrew Haley wrote: >> Is there any way to run the tests in parallel? It's improve my life >> no end. > > Yes, e.g.: > $ jtreg -conc:8 ... Sorry, I meant JUnit used from inside mx testing. Sure, I know about jtreg. Andrew. From doug.simon at oracle.com Thu Dec 1 15:39:09 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 1 Dec 2016 16:39:09 +0100 Subject: Parallel jtreg? In-Reply-To: References: <78459e38-e7b1-2a3c-cf5e-733ed0d42ff5@redhat.com> Message-ID: <5E3FF94C-4ADF-4A9D-A60B-059A300B37FE@oracle.com> Hi Andrew, Sorry, mx does not support running junit tests in parallel. Junit itself does not have explicit support for this and relies on extensions (e.g., http://tempusfugitlibrary.org/documentation/junit/parallel/) which require modifying tests to parallelize them. -Doug > On 1 Dec 2016, at 16:05, Andrew Haley wrote: > > On 01/12/16 14:58, Aleksey Shipilev wrote: >> On 12/01/2016 03:53 PM, Andrew Haley wrote: >>> Is there any way to run the tests in parallel? It's improve my life >>> no end. >> >> Yes, e.g.: >> $ jtreg -conc:8 ... > Sorry, I meant JUnit used from inside mx testing. Sure, I know about jtreg. > > Andrew. > > From aph at redhat.com Thu Dec 1 17:02:06 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 1 Dec 2016 17:02:06 +0000 Subject: StandardMethodSubstitutionsTest Message-ID: <15a7682c-091c-5a2d-eebb-4219a5708cbb@redhat.com> I'm getting a failure here because e.g. Math.sin isn't inlined. Is this compulsory? Andrew. From aph at redhat.com Thu Dec 1 17:08:58 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 1 Dec 2016 17:08:58 +0000 Subject: Parallel jtreg? In-Reply-To: <5E3FF94C-4ADF-4A9D-A60B-059A300B37FE@oracle.com> References: <78459e38-e7b1-2a3c-cf5e-733ed0d42ff5@redhat.com> <5E3FF94C-4ADF-4A9D-A60B-059A300B37FE@oracle.com> Message-ID: <3883b725-a8aa-c6a5-d796-0f8d88473f66@redhat.com> On 01/12/16 15:39, Doug Simon wrote: > Sorry, mx does not support running junit tests in parallel. Junit itself does not have explicit support for this and relies on extensions (e.g., http://tempusfugitlibrary.org/documentation/junit/parallel/) which require modifying tests to parallelize them. Yeah. I see that all of the tests are run from a list in a tmpfile, so I can just hack that manually and do a divide and conquer. Thanks, Andrew. From tom.rodriguez at oracle.com Thu Dec 1 17:51:52 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 1 Dec 2016 09:51:52 -0800 Subject: Lowering multiplyExact In-Reply-To: References: Message-ID: <3D008913-5444-4AB4-B911-CFF6E8D5296A@oracle.com> > On Dec 1, 2016, at 5:55 AM, Andrew Haley wrote: > > Graal assumes that multiplies set the overflow flag, and relies on > this for multiplyExact. AArch64 doesn't set the overlfow flag for > multiply, and as far as I can see neither does SPARC, so we have to do > some backward somersaults to get it to work. Couldn?t you just customize NodeLIRBuilderTool.emitOverflowCheckBranch to emit the proper test? I think the overflow in the name is really about whether the operation overflowed not which particular flags are set, even though the happen to correspond on intel. If it varies depending on the operation then the actual IntegerExactArithmeticSplitNode can be passed in. tom > > Right now we do this: > > 0x0000007fa8baec54: smull x8, w1, w2 > 0x0000007fa8baec58: add w0, w8, #0x0 > 0x0000007fa8baec5c: cmp x8, w8, sxtw > 0x0000007fa8baec60: orr x8, xzr, #0x80000000 > 0x0000007fa8baec64: csel w8, w8, wzr, ne > 0x0000007fa8baec68: cmp w8, #0x1 > 0x0000007fa8baec6c: b.vs 0x0000007fa8baec8c > > which is > > x8 = i2l(w1) * i2l(w2) > result = l2i(x8) > flags = compare(x8, result) > x8 = 0x80000000 > w8 = flags.ne ? w8 : 0 > flags = compare(w8, 1) > ... > if (flags.vs) goto overflow > > But it could be simply > > x8 = i2l(w1) * i2l(w2) > result = l2i(x8) > flags = compare(x8, result) > ... > if (flags.ne) goto overflow > > if we had a lowering for multiplyExact that didn't assume that > multiplies set the overflow flag. > > It's really not an important thing, but it's kinda irksome. :-) > > Andrew. From aph at redhat.com Thu Dec 1 17:53:07 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 1 Dec 2016 17:53:07 +0000 Subject: Lowering multiplyExact In-Reply-To: <3D008913-5444-4AB4-B911-CFF6E8D5296A@oracle.com> References: <3D008913-5444-4AB4-B911-CFF6E8D5296A@oracle.com> Message-ID: On 01/12/16 17:51, Tom Rodriguez wrote: > Couldn?t you just customize NodeLIRBuilderTool.emitOverflowCheckBranch to emit the proper test? I think the overflow in the name is really about whether the operation overflowed not which particular flags are set, even though the happen to correspond on intel. If it varies depending on the operation then the actual IntegerExactArithmeticSplitNode can be passed in. OK, thanks for the hint! I'll have a look. Andrew. From raffaello.giulietti at supsi.ch Thu Dec 1 18:02:33 2016 From: raffaello.giulietti at supsi.ch (raffaello.giulietti at supsi.ch) Date: Thu, 1 Dec 2016 18:02:33 +0000 Subject: Building on JDK9 EA build 146/Windows, try #1 In-Reply-To: References: Message-ID: Hi, I tried again to build graal-core & truffle on Windows, this time against JDK9 EA build 146: unsuccessfully, similar errors. (The same on Linux works without troubles.) Without reading the 14613 lines of the mx Python script, what could the failure on Windows depend on? Which are the assumptions of mx about the OS? Greetings Raffaello On 2016-11-18 21:05, Raffaello Giulietti wrote: > Hi guys, > > I guess few of you usually work on Windows. > > Nevertheless, since starting with build 143 the JDK 9 EA release now > supports JVMCI, I decided to give some tries building a Truffle/Graal > environment on Windows 10 (64 bit). > > *** > If you feel this makes no sense at this stage of maturity of both JDK 9 > and Graal, please let me know. > *** > > The reasoning is that by using JDK 9 with JVMCI, I can avoid the complex > and weakly documented procedure to build a JDK with JVMCI from scratch > on Windows. The hope is that building only Graal and Truffle, which > afaik are pure Java projects, is easier when targeting this platform. > > So, along with JDK 9b144, I also installed Git > (https://git-scm.com/download/win) and Python 2.7 > (https://www.python.org/downloads/release/python-2712/). Git for Windows > comes with a bash and some basic Unix commands. > > Then, following the instruction for building Graal > (https://github.com/graalvm/graal-core), when it comes to the first > $mx.cmd build > I stumble across a first error about the impossibility of creating a > file that already exists (see the 1st trace below) > > If I insist and immediately issue another > $mx.cmd build > I now stumble across Java related errors (2nd trace below). > > I repeated this a couple of times taking care of removing the graal root > folder and starting from scratch with the building instructions. > > If anybody could direct me on what I should look at in more details, > that would be a great help. I have no clues and, I confess, not much > willingness to delve into the scripts. > > FYI, here's the java -version > java version "9-ea" > Java(TM) SE Runtime Environment (build 9-ea+144) > Java HotSpot(TM) 64-Bit Server VM (build 9-ea+144, mixed mode) > > Sorry for the long and boring traces, but I can't decide what's > important to you and what's not. > > Greetings > Raffaello > > > > 1st trace > --------- > Compiling com.oracle.mxtool.compilerserver with javac... > [C:\Users\Raffaello\graal\mx\mxbuild\java\com.oracle.mxtoo > l.compilerserver\bin\com\oracle\mxtool\compilerserver\CompilerDaemon.class > does not exist] > warning: [options] bootstrap class path not set in conjunction with > -source 1.7 > C:\Users\Raffaello\graal\mx\java\com.oracle.mxtool.compilerserver\src\com\oracle\mxtool\compilerserver\JavacDaemon. > java:31: warning: [deprecation] newInstance() in Class has been > deprecated > final Object receiver = javacMainClass.newInstance(); > ^ > where T is a type-variable: > T extends Object declared in class Class > 2 warnings > Compiling com.oracle.truffle.api with javac-daemon... > [C:\Users\Raffaello\graal\truffle\mxbuild\truffle\com.oracle. > truffle.api\bin\com\oracle\truffle\api\Assumption.class does not exist] > warning: [options] bootstrap class path not set in conjunction with > -source 1.7 > C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api\src\com\oracle\truffle\api\Truffle.java:68: > warning : [deprecation] newInstance() in Class has been deprecated > return (TruffleRuntime) runtimeClass.newInstance(); > ^ > where T is a type-variable: > T extends Object declared in class Class > C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api\src\com\oracle\truffle\api\nodes\GraphPrintVisitor. > java:565: warning: [deprecation] newInstance() in Class has been > deprecated > return customHandlerClass.newInstance(); > ^ > where T is a type-variable: > T extends Object declared in class Class > 3 warnings > Compiling com.oracle.truffle.api.dsl with javac-daemon... [dependency > com.oracle.truffle.api updated] > warning: [options] bootstrap class path not set in conjunction with > -source 1.7 > 1 warning > Compiling com.oracle.truffle.api.interop with javac-daemon... > [dependency com.oracle.truffle.api updated] > warning: [options] bootstrap class path not set in conjunction with > -source 1.7 > C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop\src\com\oracle\truffle\api\interop\Message. > java:526: warning: [deprecation] newInstance() in Class has been > deprecated > return (Message) Class.forName(message, false, > l).newInstance(); > ^ > where T is a type-variable: > T extends Object declared in class Class > 2 warnings > Compiling com.oracle.truffle.api.instrumentation with javac-daemon... > [dependency com.oracle.truffle.api updated] > warning: [options] bootstrap class path not set in conjunction with > -source 1.7 > C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.instrumentation\src\com\oracle\truffle\api\instrume > ntation\InstrumentationHandler.java:384: warning: [deprecation] > newInstance() in Class has been deprecated > wrapper = ((InstrumentableFactory) > factory.newInstance()).createWrapper(instrumentableNode, probe ); > ^ > where T is a type-variable: > T extends Object declared in class Class > C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.instrumentation\src\com\oracle\truffle\api\instrume > ntation\InstrumentationHandler.java:759: warning: [deprecation] > newInstance() in Class has been deprecated > this.instrument = (TruffleInstrument) > instrumentClass.newInstance(); > ^ > where T is a type-variable: > T extends Object declared in class Class > 3 warnings > Compiling com.oracle.truffle.dsl.processor with javac-daemon... > [dependency com.oracle.truffle.api.dsl updated] > warning: [options] bootstrap class path not set in conjunction with > -source 1.7 > 1 warning > Compiling com.oracle.truffle.api.object with javac-daemon... [dependency > com.oracle.truffle.api.interop updated] > warning: [options] bootstrap class path not set in conjunction with > -source 1.7 > C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.object\src\com\oracle\truffle\api\object\Layout.jav > a:142: warning: [deprecation] newInstance() in Class has been > deprecated > bestLayoutFactory = (LayoutFactory) clazz.newInstance(); > ^ > where T is a type-variable: > T extends Object declared in class Class > 2 warnings > Compiling com.oracle.truffle.api.object.dsl with javac-daemon... > [dependency com.oracle.truffle.api.object updated] > warning: [options] bootstrap class path not set in conjunction with > -source 1.7 > 1 warning > Compiling com.oracle.truffle.object.dsl.processor with javac-daemon... > [dependency com.oracle.truffle.api.object.ds l updated] > warning: [options] bootstrap class path not set in conjunction with > -source 1.7 > 1 warning > Archiving TRUFFLE_DSL_PROCESSOR_INTERNAL... [dependency > com.oracle.truffle.dsl.processor updated] > C:/Users/Raffaello/graal/mx/mx.py:1058: UserWarning: Duplicate name: > 'META-INF/services/javax.annotation.processing .Processor' > arc.zf.writestr(arcname, contents) > C:/Users/Raffaello/graal/mx/mx.py:6654: UserWarning: Duplicate name: > 'META-INF/services/javax.annotation.processing .Processor' > arc.zf.writestr(arcname, '\n'.join(dist.definedAnnotationProcessors) + > '\n') > Traceback (most recent call last): > File "C:/Users/Raffaello/graal/mx/mx.py", line 14468, in > main() > File "C:/Users/Raffaello/graal/mx/mx.py", line 14452, in main > retcode = c(command_args) > File "C:/Users/Raffaello/graal/mx/mx.py", line 9577, in build > t.execute() > File "C:/Users/Raffaello/graal/mx/mx.py", line 669, in execute > self.build() > File "C:/Users/Raffaello/graal/mx/mx.py", line 1212, in build > self.subject.make_archive() > File "C:/Users/Raffaello/graal/mx/mx.py", line 1161, in make_archive > self.notify_updated() > File "C:/Users/Raffaello/graal/mx/mx.py", line 783, in notify_updated > l(self) > File "C:/Users/Raffaello/graal/mx/mx.py", line 6656, in > _refineAnnotationProcessorServiceConfig > arc.zf.writestr(arcname, lp.read(arcname)) > File "C:/Users/Raffaello/graal/mx/mx.py", line 9976, in __exit__ > SafeFileCreation.__exit__(self, exc_type, exc_value, traceback) > File "C:/Users/Raffaello/graal/mx/mx.py", line 9949, in __exit__ > os.rename(self.tmpPath, self.path) > WindowsError: [Error 183] Cannot create a file when that file already exists > java.net.SocketException: Connection reset > at > java.base/java.net.SocketInputStream.read(SocketInputStream.java:209) > at > java.base/java.net.SocketInputStream.read(SocketInputStream.java:141) > at > java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284) > at > java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) > at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) > at > java.base/java.io.InputStreamReader.read(InputStreamReader.java:185) > at java.base/java.io.BufferedReader.fill(BufferedReader.java:161) > at > java.base/java.io.BufferedReader.readLine(BufferedReader.java:325) > at > java.base/java.io.BufferedReader.readLine(BufferedReader.java:390) > at > com.oracle.mxtool.compilerserver.CompilerDaemon$Connection.run(CompilerDaemon.java:133) > at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514) > at > java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1161) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) > at java.base/java.lang.Thread.run(Thread.java:844) > > > > > > > > 2nd trace > --------- > Compiling com.oracle.truffle.api.interop.java with javac-daemon... > [C:\Users\Raffaello\graal\truffle\mxbuild\truffle\com.oracle.truffle.api.interop.java\bin\com\oracle\truffle\api\interop\java\ArrayWriteNode.class > does not exist] > warning: [options] bootstrap class path not set in conjunction with > -source 1.7 > C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaObject.java:44: > error: cannot find symbol > return JavaObjectMessageResolutionForeign.createAccess(); > ^ > symbol: variable JavaObjectMessageResolutionForeign > location: class JavaObject > C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaFunctionMessageResolution.java:62: > error: cannot find symbol > this.toJava[i] = ToJavaNodeGen.create(); > ^ > symbol: variable ToJavaNodeGen > location: class DoExecuteNode > C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaFunctionObject.java:47: > error: cannot find symbol > return JavaFunctionMessageResolutionForeign.createAccess(); > ^ > symbol: variable JavaFunctionMessageResolutionForeign > location: class JavaFunctionObject > C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaInterop.java:151: > error: cannot find symbol > RootNode root = new TemporaryConvertRoot(TruffleLanguage.class, > ToJavaNodeGen.create(), foreignObject, type); > ^ > symbol: variable ToJavaNodeGen > location: class JavaInterop > C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaInterop.java:257: > error: cannot find symbol > RootNode root = new TemporaryConvertRoot(TruffleLanguage.class, > ToJavaNodeGen.create(), function, functionalType); > ^ > symbol: variable ToJavaNodeGen > location: class JavaInterop > C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaObjectMessageResolution.java:177: > error: cannot find symbol > @Child private ArrayReadNode read = ArrayReadNodeGen.create(); > ^ > symbol: variable ArrayReadNodeGen > location: class ReadFieldNode > C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaObjectMessageResolution.java:222: > error: cannot find symbol > @Child private ToJavaNode toJava = ToJavaNodeGen.create(); > ^ > symbol: variable ToJavaNodeGen > location: class WriteFieldNode > C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaObjectMessageResolution.java:250: > error: cannot find symbol > @Child private ArrayWriteNode write = ArrayWriteNodeGen.create(); > ^ > symbol: variable ArrayWriteNodeGen > location: class WriteFieldNode > 8 errors > 1 warning > From doug.simon at oracle.com Thu Dec 1 21:16:58 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 1 Dec 2016 22:16:58 +0100 Subject: Building on JDK9 EA build 146/Windows, try #1 In-Reply-To: References: Message-ID: <676DDD8F-4AEB-4CEC-94AD-E28030B90460@oracle.com> Hi Raffaello, I don?t what the cause of the Windows failure could be. Maybe you could consider trying Bash on Windows (https://msdn.microsoft.com/en-us/commandline/wsl/install_guide) as a workaround/alternative. -Doug > On 1 Dec 2016, at 19:02, raffaello.giulietti at supsi.ch wrote: > > Hi, > > I tried again to build graal-core & truffle on Windows, this time > against JDK9 EA build 146: unsuccessfully, similar errors. > > (The same on Linux works without troubles.) > > Without reading the 14613 lines of the mx Python script, what could the > failure on Windows depend on? > Which are the assumptions of mx about the OS? > > > Greetings > Raffaello > > > > > On 2016-11-18 21:05, Raffaello Giulietti wrote: >> Hi guys, >> >> I guess few of you usually work on Windows. >> >> Nevertheless, since starting with build 143 the JDK 9 EA release now >> supports JVMCI, I decided to give some tries building a Truffle/Graal >> environment on Windows 10 (64 bit). >> >> *** >> If you feel this makes no sense at this stage of maturity of both JDK 9 >> and Graal, please let me know. >> *** >> >> The reasoning is that by using JDK 9 with JVMCI, I can avoid the complex >> and weakly documented procedure to build a JDK with JVMCI from scratch >> on Windows. The hope is that building only Graal and Truffle, which >> afaik are pure Java projects, is easier when targeting this platform. >> >> So, along with JDK 9b144, I also installed Git >> (https://git-scm.com/download/win) and Python 2.7 >> (https://www.python.org/downloads/release/python-2712/). Git for Windows >> comes with a bash and some basic Unix commands. >> >> Then, following the instruction for building Graal >> (https://github.com/graalvm/graal-core), when it comes to the first >> $mx.cmd build >> I stumble across a first error about the impossibility of creating a >> file that already exists (see the 1st trace below) >> >> If I insist and immediately issue another >> $mx.cmd build >> I now stumble across Java related errors (2nd trace below). >> >> I repeated this a couple of times taking care of removing the graal root >> folder and starting from scratch with the building instructions. >> >> If anybody could direct me on what I should look at in more details, >> that would be a great help. I have no clues and, I confess, not much >> willingness to delve into the scripts. >> >> FYI, here's the java -version >> java version "9-ea" >> Java(TM) SE Runtime Environment (build 9-ea+144) >> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+144, mixed mode) >> >> Sorry for the long and boring traces, but I can't decide what's >> important to you and what's not. >> >> Greetings >> Raffaello >> >> >> >> 1st trace >> --------- >> Compiling com.oracle.mxtool.compilerserver with javac... >> [C:\Users\Raffaello\graal\mx\mxbuild\java\com.oracle.mxtoo >> l.compilerserver\bin\com\oracle\mxtool\compilerserver\CompilerDaemon.class >> does not exist] >> warning: [options] bootstrap class path not set in conjunction with >> -source 1.7 >> C:\Users\Raffaello\graal\mx\java\com.oracle.mxtool.compilerserver\src\com\oracle\mxtool\compilerserver\JavacDaemon. >> java:31: warning: [deprecation] newInstance() in Class has been >> deprecated >> final Object receiver = javacMainClass.newInstance(); >> ^ >> where T is a type-variable: >> T extends Object declared in class Class >> 2 warnings >> Compiling com.oracle.truffle.api with javac-daemon... >> [C:\Users\Raffaello\graal\truffle\mxbuild\truffle\com.oracle. >> truffle.api\bin\com\oracle\truffle\api\Assumption.class does not exist] >> warning: [options] bootstrap class path not set in conjunction with >> -source 1.7 >> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api\src\com\oracle\truffle\api\Truffle.java:68: >> warning : [deprecation] newInstance() in Class has been deprecated >> return (TruffleRuntime) runtimeClass.newInstance(); >> ^ >> where T is a type-variable: >> T extends Object declared in class Class >> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api\src\com\oracle\truffle\api\nodes\GraphPrintVisitor. >> java:565: warning: [deprecation] newInstance() in Class has been >> deprecated >> return customHandlerClass.newInstance(); >> ^ >> where T is a type-variable: >> T extends Object declared in class Class >> 3 warnings >> Compiling com.oracle.truffle.api.dsl with javac-daemon... [dependency >> com.oracle.truffle.api updated] >> warning: [options] bootstrap class path not set in conjunction with >> -source 1.7 >> 1 warning >> Compiling com.oracle.truffle.api.interop with javac-daemon... >> [dependency com.oracle.truffle.api updated] >> warning: [options] bootstrap class path not set in conjunction with >> -source 1.7 >> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop\src\com\oracle\truffle\api\interop\Message. >> java:526: warning: [deprecation] newInstance() in Class has been >> deprecated >> return (Message) Class.forName(message, false, >> l).newInstance(); >> ^ >> where T is a type-variable: >> T extends Object declared in class Class >> 2 warnings >> Compiling com.oracle.truffle.api.instrumentation with javac-daemon... >> [dependency com.oracle.truffle.api updated] >> warning: [options] bootstrap class path not set in conjunction with >> -source 1.7 >> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.instrumentation\src\com\oracle\truffle\api\instrume >> ntation\InstrumentationHandler.java:384: warning: [deprecation] >> newInstance() in Class has been deprecated >> wrapper = ((InstrumentableFactory) >> factory.newInstance()).createWrapper(instrumentableNode, probe ); >> ^ >> where T is a type-variable: >> T extends Object declared in class Class >> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.instrumentation\src\com\oracle\truffle\api\instrume >> ntation\InstrumentationHandler.java:759: warning: [deprecation] >> newInstance() in Class has been deprecated >> this.instrument = (TruffleInstrument) >> instrumentClass.newInstance(); >> ^ >> where T is a type-variable: >> T extends Object declared in class Class >> 3 warnings >> Compiling com.oracle.truffle.dsl.processor with javac-daemon... >> [dependency com.oracle.truffle.api.dsl updated] >> warning: [options] bootstrap class path not set in conjunction with >> -source 1.7 >> 1 warning >> Compiling com.oracle.truffle.api.object with javac-daemon... [dependency >> com.oracle.truffle.api.interop updated] >> warning: [options] bootstrap class path not set in conjunction with >> -source 1.7 >> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.object\src\com\oracle\truffle\api\object\Layout.jav >> a:142: warning: [deprecation] newInstance() in Class has been >> deprecated >> bestLayoutFactory = (LayoutFactory) clazz.newInstance(); >> ^ >> where T is a type-variable: >> T extends Object declared in class Class >> 2 warnings >> Compiling com.oracle.truffle.api.object.dsl with javac-daemon... >> [dependency com.oracle.truffle.api.object updated] >> warning: [options] bootstrap class path not set in conjunction with >> -source 1.7 >> 1 warning >> Compiling com.oracle.truffle.object.dsl.processor with javac-daemon... >> [dependency com.oracle.truffle.api.object.ds l updated] >> warning: [options] bootstrap class path not set in conjunction with >> -source 1.7 >> 1 warning >> Archiving TRUFFLE_DSL_PROCESSOR_INTERNAL... [dependency >> com.oracle.truffle.dsl.processor updated] >> C:/Users/Raffaello/graal/mx/mx.py:1058: UserWarning: Duplicate name: >> 'META-INF/services/javax.annotation.processing .Processor' >> arc.zf.writestr(arcname, contents) >> C:/Users/Raffaello/graal/mx/mx.py:6654: UserWarning: Duplicate name: >> 'META-INF/services/javax.annotation.processing .Processor' >> arc.zf.writestr(arcname, '\n'.join(dist.definedAnnotationProcessors) + >> '\n') >> Traceback (most recent call last): >> File "C:/Users/Raffaello/graal/mx/mx.py", line 14468, in >> main() >> File "C:/Users/Raffaello/graal/mx/mx.py", line 14452, in main >> retcode = c(command_args) >> File "C:/Users/Raffaello/graal/mx/mx.py", line 9577, in build >> t.execute() >> File "C:/Users/Raffaello/graal/mx/mx.py", line 669, in execute >> self.build() >> File "C:/Users/Raffaello/graal/mx/mx.py", line 1212, in build >> self.subject.make_archive() >> File "C:/Users/Raffaello/graal/mx/mx.py", line 1161, in make_archive >> self.notify_updated() >> File "C:/Users/Raffaello/graal/mx/mx.py", line 783, in notify_updated >> l(self) >> File "C:/Users/Raffaello/graal/mx/mx.py", line 6656, in >> _refineAnnotationProcessorServiceConfig >> arc.zf.writestr(arcname, lp.read(arcname)) >> File "C:/Users/Raffaello/graal/mx/mx.py", line 9976, in __exit__ >> SafeFileCreation.__exit__(self, exc_type, exc_value, traceback) >> File "C:/Users/Raffaello/graal/mx/mx.py", line 9949, in __exit__ >> os.rename(self.tmpPath, self.path) >> WindowsError: [Error 183] Cannot create a file when that file already exists >> java.net.SocketException: Connection reset >> at >> java.base/java.net.SocketInputStream.read(SocketInputStream.java:209) >> at >> java.base/java.net.SocketInputStream.read(SocketInputStream.java:141) >> at >> java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284) >> at >> java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) >> at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) >> at >> java.base/java.io.InputStreamReader.read(InputStreamReader.java:185) >> at java.base/java.io.BufferedReader.fill(BufferedReader.java:161) >> at >> java.base/java.io.BufferedReader.readLine(BufferedReader.java:325) >> at >> java.base/java.io.BufferedReader.readLine(BufferedReader.java:390) >> at >> com.oracle.mxtool.compilerserver.CompilerDaemon$Connection.run(CompilerDaemon.java:133) >> at >> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514) >> at >> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) >> at >> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1161) >> at >> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) >> at java.base/java.lang.Thread.run(Thread.java:844) >> >> >> >> >> >> >> >> 2nd trace >> --------- >> Compiling com.oracle.truffle.api.interop.java with javac-daemon... >> [C:\Users\Raffaello\graal\truffle\mxbuild\truffle\com.oracle.truffle.api.interop.java\bin\com\oracle\truffle\api\interop\java\ArrayWriteNode.class >> does not exist] >> warning: [options] bootstrap class path not set in conjunction with >> -source 1.7 >> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaObject.java:44: >> error: cannot find symbol >> return JavaObjectMessageResolutionForeign.createAccess(); >> ^ >> symbol: variable JavaObjectMessageResolutionForeign >> location: class JavaObject >> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaFunctionMessageResolution.java:62: >> error: cannot find symbol >> this.toJava[i] = ToJavaNodeGen.create(); >> ^ >> symbol: variable ToJavaNodeGen >> location: class DoExecuteNode >> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaFunctionObject.java:47: >> error: cannot find symbol >> return JavaFunctionMessageResolutionForeign.createAccess(); >> ^ >> symbol: variable JavaFunctionMessageResolutionForeign >> location: class JavaFunctionObject >> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaInterop.java:151: >> error: cannot find symbol >> RootNode root = new TemporaryConvertRoot(TruffleLanguage.class, >> ToJavaNodeGen.create(), foreignObject, type); >> ^ >> symbol: variable ToJavaNodeGen >> location: class JavaInterop >> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaInterop.java:257: >> error: cannot find symbol >> RootNode root = new TemporaryConvertRoot(TruffleLanguage.class, >> ToJavaNodeGen.create(), function, functionalType); >> ^ >> symbol: variable ToJavaNodeGen >> location: class JavaInterop >> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaObjectMessageResolution.java:177: >> error: cannot find symbol >> @Child private ArrayReadNode read = ArrayReadNodeGen.create(); >> ^ >> symbol: variable ArrayReadNodeGen >> location: class ReadFieldNode >> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaObjectMessageResolution.java:222: >> error: cannot find symbol >> @Child private ToJavaNode toJava = ToJavaNodeGen.create(); >> ^ >> symbol: variable ToJavaNodeGen >> location: class WriteFieldNode >> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaObjectMessageResolution.java:250: >> error: cannot find symbol >> @Child private ArrayWriteNode write = ArrayWriteNodeGen.create(); >> ^ >> symbol: variable ArrayWriteNodeGen >> location: class WriteFieldNode >> 8 errors >> 1 warning >> > From josef.eisl at jku.at Fri Dec 2 08:43:56 2016 From: josef.eisl at jku.at (Josef Eisl) Date: Fri, 2 Dec 2016 09:43:56 +0100 Subject: Parallel jtreg? In-Reply-To: <3883b725-a8aa-c6a5-d796-0f8d88473f66@redhat.com> References: <78459e38-e7b1-2a3c-cf5e-733ed0d42ff5@redhat.com> <5E3FF94C-4ADF-4A9D-A60B-059A300B37FE@oracle.com> <3883b725-a8aa-c6a5-d796-0f8d88473f66@redhat.com> Message-ID: <4169b19c-48e0-db0e-5df8-6044c4ad7861@jku.at> On 01/12/16 18:08, Andrew Haley wrote: > On 01/12/16 15:39, Doug Simon wrote: >> Sorry, mx does not support running junit tests in parallel. Junit itself does not have explicit support for this and relies on extensions (e.g., http://tempusfugitlibrary.org/documentation/junit/parallel/) which require modifying tests to parallelize them. > > Yeah. I see that all of the tests are run from a list in a tmpfile, > so I can just hack that manually and do a divide and conquer. There are also the --whitelist=file --blacklist=file options for mx unittest. They can come handy too. Josef > > Thanks, > > Andrew. > From aph at redhat.com Fri Dec 2 10:05:55 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 2 Dec 2016 10:05:55 +0000 Subject: AheadOfTimeCompilationTest Message-ID: <6bb1184c-887d-af19-8960-1a5864e7a16f@redhat.com> What does AheadOfTimeCompilationTest do? I'm seeing test failures in that my methods sometimes have the wrong number of nodes, but the code look fine. Thanks, Andrew. From raffaello.giulietti at supsi.ch Fri Dec 2 10:17:17 2016 From: raffaello.giulietti at supsi.ch (raffaello.giulietti at supsi.ch) Date: Fri, 2 Dec 2016 10:17:17 +0000 Subject: Building on JDK9 EA build 146/Windows, try #1 In-Reply-To: <676DDD8F-4AEB-4CEC-94AD-E28030B90460@oracle.com> References: <676DDD8F-4AEB-4CEC-94AD-E28030B90460@oracle.com> Message-ID: Hi Doug, as an alternative, I could *build* on Linux every now and then but then *use* the built product on Windows. Would that work or are there other dependencies of the build from the OS or other parts of the platform? After all, afaik, the build should be pure JVM bytecode, independent of the platform, right? Or is there a Graal binary build for JDK9 already available on some repo? On 2016-12-01 21:16, Doug Simon wrote: > Hi Raffaello, > > I don?t what the cause of the Windows failure could be. > > Maybe you could consider trying Bash on Windows (https://msdn.microsoft.com/en-us/commandline/wsl/install_guide) as a workaround/alternative. > > -Doug > >> On 1 Dec 2016, at 19:02, raffaello.giulietti at supsi.ch wrote: >> >> Hi, >> >> I tried again to build graal-core & truffle on Windows, this time >> against JDK9 EA build 146: unsuccessfully, similar errors. >> >> (The same on Linux works without troubles.) >> >> Without reading the 14613 lines of the mx Python script, what could the >> failure on Windows depend on? >> Which are the assumptions of mx about the OS? >> >> >> Greetings >> Raffaello >> >> >> >> >> On 2016-11-18 21:05, Raffaello Giulietti wrote: >>> Hi guys, >>> >>> I guess few of you usually work on Windows. >>> >>> Nevertheless, since starting with build 143 the JDK 9 EA release now >>> supports JVMCI, I decided to give some tries building a Truffle/Graal >>> environment on Windows 10 (64 bit). >>> >>> *** >>> If you feel this makes no sense at this stage of maturity of both JDK 9 >>> and Graal, please let me know. >>> *** >>> >>> The reasoning is that by using JDK 9 with JVMCI, I can avoid the complex >>> and weakly documented procedure to build a JDK with JVMCI from scratch >>> on Windows. The hope is that building only Graal and Truffle, which >>> afaik are pure Java projects, is easier when targeting this platform. >>> >>> So, along with JDK 9b144, I also installed Git >>> (https://git-scm.com/download/win) and Python 2.7 >>> (https://www.python.org/downloads/release/python-2712/). Git for Windows >>> comes with a bash and some basic Unix commands. >>> >>> Then, following the instruction for building Graal >>> (https://github.com/graalvm/graal-core), when it comes to the first >>> $mx.cmd build >>> I stumble across a first error about the impossibility of creating a >>> file that already exists (see the 1st trace below) >>> >>> If I insist and immediately issue another >>> $mx.cmd build >>> I now stumble across Java related errors (2nd trace below). >>> >>> I repeated this a couple of times taking care of removing the graal root >>> folder and starting from scratch with the building instructions. >>> >>> If anybody could direct me on what I should look at in more details, >>> that would be a great help. I have no clues and, I confess, not much >>> willingness to delve into the scripts. >>> >>> FYI, here's the java -version >>> java version "9-ea" >>> Java(TM) SE Runtime Environment (build 9-ea+144) >>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+144, mixed mode) >>> >>> Sorry for the long and boring traces, but I can't decide what's >>> important to you and what's not. >>> >>> Greetings >>> Raffaello >>> >>> >>> >>> 1st trace >>> --------- >>> Compiling com.oracle.mxtool.compilerserver with javac... >>> [C:\Users\Raffaello\graal\mx\mxbuild\java\com.oracle.mxtoo >>> l.compilerserver\bin\com\oracle\mxtool\compilerserver\CompilerDaemon.class >>> does not exist] >>> warning: [options] bootstrap class path not set in conjunction with >>> -source 1.7 >>> C:\Users\Raffaello\graal\mx\java\com.oracle.mxtool.compilerserver\src\com\oracle\mxtool\compilerserver\JavacDaemon. >>> java:31: warning: [deprecation] newInstance() in Class has been >>> deprecated >>> final Object receiver = javacMainClass.newInstance(); >>> ^ >>> where T is a type-variable: >>> T extends Object declared in class Class >>> 2 warnings >>> Compiling com.oracle.truffle.api with javac-daemon... >>> [C:\Users\Raffaello\graal\truffle\mxbuild\truffle\com.oracle. >>> truffle.api\bin\com\oracle\truffle\api\Assumption.class does not exist] >>> warning: [options] bootstrap class path not set in conjunction with >>> -source 1.7 >>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api\src\com\oracle\truffle\api\Truffle.java:68: >>> warning : [deprecation] newInstance() in Class has been deprecated >>> return (TruffleRuntime) runtimeClass.newInstance(); >>> ^ >>> where T is a type-variable: >>> T extends Object declared in class Class >>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api\src\com\oracle\truffle\api\nodes\GraphPrintVisitor. >>> java:565: warning: [deprecation] newInstance() in Class has been >>> deprecated >>> return customHandlerClass.newInstance(); >>> ^ >>> where T is a type-variable: >>> T extends Object declared in class Class >>> 3 warnings >>> Compiling com.oracle.truffle.api.dsl with javac-daemon... [dependency >>> com.oracle.truffle.api updated] >>> warning: [options] bootstrap class path not set in conjunction with >>> -source 1.7 >>> 1 warning >>> Compiling com.oracle.truffle.api.interop with javac-daemon... >>> [dependency com.oracle.truffle.api updated] >>> warning: [options] bootstrap class path not set in conjunction with >>> -source 1.7 >>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop\src\com\oracle\truffle\api\interop\Message. >>> java:526: warning: [deprecation] newInstance() in Class has been >>> deprecated >>> return (Message) Class.forName(message, false, >>> l).newInstance(); >>> ^ >>> where T is a type-variable: >>> T extends Object declared in class Class >>> 2 warnings >>> Compiling com.oracle.truffle.api.instrumentation with javac-daemon... >>> [dependency com.oracle.truffle.api updated] >>> warning: [options] bootstrap class path not set in conjunction with >>> -source 1.7 >>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.instrumentation\src\com\oracle\truffle\api\instrume >>> ntation\InstrumentationHandler.java:384: warning: [deprecation] >>> newInstance() in Class has been deprecated >>> wrapper = ((InstrumentableFactory) >>> factory.newInstance()).createWrapper(instrumentableNode, probe ); >>> ^ >>> where T is a type-variable: >>> T extends Object declared in class Class >>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.instrumentation\src\com\oracle\truffle\api\instrume >>> ntation\InstrumentationHandler.java:759: warning: [deprecation] >>> newInstance() in Class has been deprecated >>> this.instrument = (TruffleInstrument) >>> instrumentClass.newInstance(); >>> ^ >>> where T is a type-variable: >>> T extends Object declared in class Class >>> 3 warnings >>> Compiling com.oracle.truffle.dsl.processor with javac-daemon... >>> [dependency com.oracle.truffle.api.dsl updated] >>> warning: [options] bootstrap class path not set in conjunction with >>> -source 1.7 >>> 1 warning >>> Compiling com.oracle.truffle.api.object with javac-daemon... [dependency >>> com.oracle.truffle.api.interop updated] >>> warning: [options] bootstrap class path not set in conjunction with >>> -source 1.7 >>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.object\src\com\oracle\truffle\api\object\Layout.jav >>> a:142: warning: [deprecation] newInstance() in Class has been >>> deprecated >>> bestLayoutFactory = (LayoutFactory) clazz.newInstance(); >>> ^ >>> where T is a type-variable: >>> T extends Object declared in class Class >>> 2 warnings >>> Compiling com.oracle.truffle.api.object.dsl with javac-daemon... >>> [dependency com.oracle.truffle.api.object updated] >>> warning: [options] bootstrap class path not set in conjunction with >>> -source 1.7 >>> 1 warning >>> Compiling com.oracle.truffle.object.dsl.processor with javac-daemon... >>> [dependency com.oracle.truffle.api.object.ds l updated] >>> warning: [options] bootstrap class path not set in conjunction with >>> -source 1.7 >>> 1 warning >>> Archiving TRUFFLE_DSL_PROCESSOR_INTERNAL... [dependency >>> com.oracle.truffle.dsl.processor updated] >>> C:/Users/Raffaello/graal/mx/mx.py:1058: UserWarning: Duplicate name: >>> 'META-INF/services/javax.annotation.processing .Processor' >>> arc.zf.writestr(arcname, contents) >>> C:/Users/Raffaello/graal/mx/mx.py:6654: UserWarning: Duplicate name: >>> 'META-INF/services/javax.annotation.processing .Processor' >>> arc.zf.writestr(arcname, '\n'.join(dist.definedAnnotationProcessors) + >>> '\n') >>> Traceback (most recent call last): >>> File "C:/Users/Raffaello/graal/mx/mx.py", line 14468, in >>> main() >>> File "C:/Users/Raffaello/graal/mx/mx.py", line 14452, in main >>> retcode = c(command_args) >>> File "C:/Users/Raffaello/graal/mx/mx.py", line 9577, in build >>> t.execute() >>> File "C:/Users/Raffaello/graal/mx/mx.py", line 669, in execute >>> self.build() >>> File "C:/Users/Raffaello/graal/mx/mx.py", line 1212, in build >>> self.subject.make_archive() >>> File "C:/Users/Raffaello/graal/mx/mx.py", line 1161, in make_archive >>> self.notify_updated() >>> File "C:/Users/Raffaello/graal/mx/mx.py", line 783, in notify_updated >>> l(self) >>> File "C:/Users/Raffaello/graal/mx/mx.py", line 6656, in >>> _refineAnnotationProcessorServiceConfig >>> arc.zf.writestr(arcname, lp.read(arcname)) >>> File "C:/Users/Raffaello/graal/mx/mx.py", line 9976, in __exit__ >>> SafeFileCreation.__exit__(self, exc_type, exc_value, traceback) >>> File "C:/Users/Raffaello/graal/mx/mx.py", line 9949, in __exit__ >>> os.rename(self.tmpPath, self.path) >>> WindowsError: [Error 183] Cannot create a file when that file already exists >>> java.net.SocketException: Connection reset >>> at >>> java.base/java.net.SocketInputStream.read(SocketInputStream.java:209) >>> at >>> java.base/java.net.SocketInputStream.read(SocketInputStream.java:141) >>> at >>> java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284) >>> at >>> java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) >>> at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) >>> at >>> java.base/java.io.InputStreamReader.read(InputStreamReader.java:185) >>> at java.base/java.io.BufferedReader.fill(BufferedReader.java:161) >>> at >>> java.base/java.io.BufferedReader.readLine(BufferedReader.java:325) >>> at >>> java.base/java.io.BufferedReader.readLine(BufferedReader.java:390) >>> at >>> com.oracle.mxtool.compilerserver.CompilerDaemon$Connection.run(CompilerDaemon.java:133) >>> at >>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514) >>> at >>> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) >>> at >>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1161) >>> at >>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) >>> at java.base/java.lang.Thread.run(Thread.java:844) >>> >>> >>> >>> >>> >>> >>> >>> 2nd trace >>> --------- >>> Compiling com.oracle.truffle.api.interop.java with javac-daemon... >>> [C:\Users\Raffaello\graal\truffle\mxbuild\truffle\com.oracle.truffle.api.interop.java\bin\com\oracle\truffle\api\interop\java\ArrayWriteNode.class >>> does not exist] >>> warning: [options] bootstrap class path not set in conjunction with >>> -source 1.7 >>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaObject.java:44: >>> error: cannot find symbol >>> return JavaObjectMessageResolutionForeign.createAccess(); >>> ^ >>> symbol: variable JavaObjectMessageResolutionForeign >>> location: class JavaObject >>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaFunctionMessageResolution.java:62: >>> error: cannot find symbol >>> this.toJava[i] = ToJavaNodeGen.create(); >>> ^ >>> symbol: variable ToJavaNodeGen >>> location: class DoExecuteNode >>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaFunctionObject.java:47: >>> error: cannot find symbol >>> return JavaFunctionMessageResolutionForeign.createAccess(); >>> ^ >>> symbol: variable JavaFunctionMessageResolutionForeign >>> location: class JavaFunctionObject >>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaInterop.java:151: >>> error: cannot find symbol >>> RootNode root = new TemporaryConvertRoot(TruffleLanguage.class, >>> ToJavaNodeGen.create(), foreignObject, type); >>> ^ >>> symbol: variable ToJavaNodeGen >>> location: class JavaInterop >>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaInterop.java:257: >>> error: cannot find symbol >>> RootNode root = new TemporaryConvertRoot(TruffleLanguage.class, >>> ToJavaNodeGen.create(), function, functionalType); >>> ^ >>> symbol: variable ToJavaNodeGen >>> location: class JavaInterop >>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaObjectMessageResolution.java:177: >>> error: cannot find symbol >>> @Child private ArrayReadNode read = ArrayReadNodeGen.create(); >>> ^ >>> symbol: variable ArrayReadNodeGen >>> location: class ReadFieldNode >>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaObjectMessageResolution.java:222: >>> error: cannot find symbol >>> @Child private ToJavaNode toJava = ToJavaNodeGen.create(); >>> ^ >>> symbol: variable ToJavaNodeGen >>> location: class WriteFieldNode >>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaObjectMessageResolution.java:250: >>> error: cannot find symbol >>> @Child private ArrayWriteNode write = ArrayWriteNodeGen.create(); >>> ^ >>> symbol: variable ArrayWriteNodeGen >>> location: class WriteFieldNode >>> 8 errors >>> 1 warning >>> >> > From doug.simon at oracle.com Fri Dec 2 10:27:00 2016 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 2 Dec 2016 11:27:00 +0100 Subject: AheadOfTimeCompilationTest In-Reply-To: <6bb1184c-887d-af19-8960-1a5864e7a16f@redhat.com> References: <6bb1184c-887d-af19-8960-1a5864e7a16f@redhat.com> Message-ID: <5D37AFF3-5B18-48D1-9A71-7B9FE86B395D@oracle.com> They test the expected behavior of the com.oracle.graal.compiler.common.GraalOptions.ImmutableCode option. If you?re having problems making these tests pass on AArch64, you could insert `org.junit.Assume.assumeFalse(getTarget().arch.getName().equals("aarch64"));` in the relevant tests. -Doug > On 2 Dec 2016, at 11:05, Andrew Haley wrote: > > What does AheadOfTimeCompilationTest do? I'm seeing test failures > in that my methods sometimes have the wrong number of nodes, but the > code look fine. > > Thanks, > > Andrew. From doug.simon at oracle.com Fri Dec 2 10:30:25 2016 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 2 Dec 2016 11:30:25 +0100 Subject: Building on JDK9 EA build 146/Windows, try #1 In-Reply-To: References: <676DDD8F-4AEB-4CEC-94AD-E28030B90460@oracle.com> Message-ID: <47867BEB-1D3D-4F75-8728-2E42BA8C5BD5@oracle.com> > On 2 Dec 2016, at 11:17, raffaello.giulietti at supsi.ch wrote: > > Hi Doug, > > as an alternative, I could *build* on Linux every now and then but then > *use* the built product on Windows. Maybe. I am only suggesting something that may work without having tested it. > Would that work or are there other dependencies of the build from the OS > or other parts of the platform? After all, afaik, the build should be > pure JVM bytecode, independent of the platform, right? I assume you?re talking about building graal-core and truffle in which case, yes, it should be pure Java source code. > Or is there a Graal binary build for JDK9 already available on some repo? No, we don?t deploy binary builds apart from the GraalVM binaries available at http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html -Doug > On 2016-12-01 21:16, Doug Simon wrote: >> Hi Raffaello, >> >> I don?t what the cause of the Windows failure could be. >> >> Maybe you could consider trying Bash on Windows (https://msdn.microsoft.com/en-us/commandline/wsl/install_guide) as a workaround/alternative. >> >> -Doug >> >>> On 1 Dec 2016, at 19:02, raffaello.giulietti at supsi.ch wrote: >>> >>> Hi, >>> >>> I tried again to build graal-core & truffle on Windows, this time >>> against JDK9 EA build 146: unsuccessfully, similar errors. >>> >>> (The same on Linux works without troubles.) >>> >>> Without reading the 14613 lines of the mx Python script, what could the >>> failure on Windows depend on? >>> Which are the assumptions of mx about the OS? >>> >>> >>> Greetings >>> Raffaello >>> >>> >>> >>> >>> On 2016-11-18 21:05, Raffaello Giulietti wrote: >>>> Hi guys, >>>> >>>> I guess few of you usually work on Windows. >>>> >>>> Nevertheless, since starting with build 143 the JDK 9 EA release now >>>> supports JVMCI, I decided to give some tries building a Truffle/Graal >>>> environment on Windows 10 (64 bit). >>>> >>>> *** >>>> If you feel this makes no sense at this stage of maturity of both JDK 9 >>>> and Graal, please let me know. >>>> *** >>>> >>>> The reasoning is that by using JDK 9 with JVMCI, I can avoid the complex >>>> and weakly documented procedure to build a JDK with JVMCI from scratch >>>> on Windows. The hope is that building only Graal and Truffle, which >>>> afaik are pure Java projects, is easier when targeting this platform. >>>> >>>> So, along with JDK 9b144, I also installed Git >>>> (https://git-scm.com/download/win) and Python 2.7 >>>> (https://www.python.org/downloads/release/python-2712/). Git for Windows >>>> comes with a bash and some basic Unix commands. >>>> >>>> Then, following the instruction for building Graal >>>> (https://github.com/graalvm/graal-core), when it comes to the first >>>> $mx.cmd build >>>> I stumble across a first error about the impossibility of creating a >>>> file that already exists (see the 1st trace below) >>>> >>>> If I insist and immediately issue another >>>> $mx.cmd build >>>> I now stumble across Java related errors (2nd trace below). >>>> >>>> I repeated this a couple of times taking care of removing the graal root >>>> folder and starting from scratch with the building instructions. >>>> >>>> If anybody could direct me on what I should look at in more details, >>>> that would be a great help. I have no clues and, I confess, not much >>>> willingness to delve into the scripts. >>>> >>>> FYI, here's the java -version >>>> java version "9-ea" >>>> Java(TM) SE Runtime Environment (build 9-ea+144) >>>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+144, mixed mode) >>>> >>>> Sorry for the long and boring traces, but I can't decide what's >>>> important to you and what's not. >>>> >>>> Greetings >>>> Raffaello >>>> >>>> >>>> >>>> 1st trace >>>> --------- >>>> Compiling com.oracle.mxtool.compilerserver with javac... >>>> [C:\Users\Raffaello\graal\mx\mxbuild\java\com.oracle.mxtoo >>>> l.compilerserver\bin\com\oracle\mxtool\compilerserver\CompilerDaemon.class >>>> does not exist] >>>> warning: [options] bootstrap class path not set in conjunction with >>>> -source 1.7 >>>> C:\Users\Raffaello\graal\mx\java\com.oracle.mxtool.compilerserver\src\com\oracle\mxtool\compilerserver\JavacDaemon. >>>> java:31: warning: [deprecation] newInstance() in Class has been >>>> deprecated >>>> final Object receiver = javacMainClass.newInstance(); >>>> ^ >>>> where T is a type-variable: >>>> T extends Object declared in class Class >>>> 2 warnings >>>> Compiling com.oracle.truffle.api with javac-daemon... >>>> [C:\Users\Raffaello\graal\truffle\mxbuild\truffle\com.oracle. >>>> truffle.api\bin\com\oracle\truffle\api\Assumption.class does not exist] >>>> warning: [options] bootstrap class path not set in conjunction with >>>> -source 1.7 >>>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api\src\com\oracle\truffle\api\Truffle.java:68: >>>> warning : [deprecation] newInstance() in Class has been deprecated >>>> return (TruffleRuntime) runtimeClass.newInstance(); >>>> ^ >>>> where T is a type-variable: >>>> T extends Object declared in class Class >>>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api\src\com\oracle\truffle\api\nodes\GraphPrintVisitor. >>>> java:565: warning: [deprecation] newInstance() in Class has been >>>> deprecated >>>> return customHandlerClass.newInstance(); >>>> ^ >>>> where T is a type-variable: >>>> T extends Object declared in class Class >>>> 3 warnings >>>> Compiling com.oracle.truffle.api.dsl with javac-daemon... [dependency >>>> com.oracle.truffle.api updated] >>>> warning: [options] bootstrap class path not set in conjunction with >>>> -source 1.7 >>>> 1 warning >>>> Compiling com.oracle.truffle.api.interop with javac-daemon... >>>> [dependency com.oracle.truffle.api updated] >>>> warning: [options] bootstrap class path not set in conjunction with >>>> -source 1.7 >>>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop\src\com\oracle\truffle\api\interop\Message. >>>> java:526: warning: [deprecation] newInstance() in Class has been >>>> deprecated >>>> return (Message) Class.forName(message, false, >>>> l).newInstance(); >>>> ^ >>>> where T is a type-variable: >>>> T extends Object declared in class Class >>>> 2 warnings >>>> Compiling com.oracle.truffle.api.instrumentation with javac-daemon... >>>> [dependency com.oracle.truffle.api updated] >>>> warning: [options] bootstrap class path not set in conjunction with >>>> -source 1.7 >>>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.instrumentation\src\com\oracle\truffle\api\instrume >>>> ntation\InstrumentationHandler.java:384: warning: [deprecation] >>>> newInstance() in Class has been deprecated >>>> wrapper = ((InstrumentableFactory) >>>> factory.newInstance()).createWrapper(instrumentableNode, probe ); >>>> ^ >>>> where T is a type-variable: >>>> T extends Object declared in class Class >>>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.instrumentation\src\com\oracle\truffle\api\instrume >>>> ntation\InstrumentationHandler.java:759: warning: [deprecation] >>>> newInstance() in Class has been deprecated >>>> this.instrument = (TruffleInstrument) >>>> instrumentClass.newInstance(); >>>> ^ >>>> where T is a type-variable: >>>> T extends Object declared in class Class >>>> 3 warnings >>>> Compiling com.oracle.truffle.dsl.processor with javac-daemon... >>>> [dependency com.oracle.truffle.api.dsl updated] >>>> warning: [options] bootstrap class path not set in conjunction with >>>> -source 1.7 >>>> 1 warning >>>> Compiling com.oracle.truffle.api.object with javac-daemon... [dependency >>>> com.oracle.truffle.api.interop updated] >>>> warning: [options] bootstrap class path not set in conjunction with >>>> -source 1.7 >>>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.object\src\com\oracle\truffle\api\object\Layout.jav >>>> a:142: warning: [deprecation] newInstance() in Class has been >>>> deprecated >>>> bestLayoutFactory = (LayoutFactory) clazz.newInstance(); >>>> ^ >>>> where T is a type-variable: >>>> T extends Object declared in class Class >>>> 2 warnings >>>> Compiling com.oracle.truffle.api.object.dsl with javac-daemon... >>>> [dependency com.oracle.truffle.api.object updated] >>>> warning: [options] bootstrap class path not set in conjunction with >>>> -source 1.7 >>>> 1 warning >>>> Compiling com.oracle.truffle.object.dsl.processor with javac-daemon... >>>> [dependency com.oracle.truffle.api.object.ds l updated] >>>> warning: [options] bootstrap class path not set in conjunction with >>>> -source 1.7 >>>> 1 warning >>>> Archiving TRUFFLE_DSL_PROCESSOR_INTERNAL... [dependency >>>> com.oracle.truffle.dsl.processor updated] >>>> C:/Users/Raffaello/graal/mx/mx.py:1058: UserWarning: Duplicate name: >>>> 'META-INF/services/javax.annotation.processing .Processor' >>>> arc.zf.writestr(arcname, contents) >>>> C:/Users/Raffaello/graal/mx/mx.py:6654: UserWarning: Duplicate name: >>>> 'META-INF/services/javax.annotation.processing .Processor' >>>> arc.zf.writestr(arcname, '\n'.join(dist.definedAnnotationProcessors) + >>>> '\n') >>>> Traceback (most recent call last): >>>> File "C:/Users/Raffaello/graal/mx/mx.py", line 14468, in >>>> main() >>>> File "C:/Users/Raffaello/graal/mx/mx.py", line 14452, in main >>>> retcode = c(command_args) >>>> File "C:/Users/Raffaello/graal/mx/mx.py", line 9577, in build >>>> t.execute() >>>> File "C:/Users/Raffaello/graal/mx/mx.py", line 669, in execute >>>> self.build() >>>> File "C:/Users/Raffaello/graal/mx/mx.py", line 1212, in build >>>> self.subject.make_archive() >>>> File "C:/Users/Raffaello/graal/mx/mx.py", line 1161, in make_archive >>>> self.notify_updated() >>>> File "C:/Users/Raffaello/graal/mx/mx.py", line 783, in notify_updated >>>> l(self) >>>> File "C:/Users/Raffaello/graal/mx/mx.py", line 6656, in >>>> _refineAnnotationProcessorServiceConfig >>>> arc.zf.writestr(arcname, lp.read(arcname)) >>>> File "C:/Users/Raffaello/graal/mx/mx.py", line 9976, in __exit__ >>>> SafeFileCreation.__exit__(self, exc_type, exc_value, traceback) >>>> File "C:/Users/Raffaello/graal/mx/mx.py", line 9949, in __exit__ >>>> os.rename(self.tmpPath, self.path) >>>> WindowsError: [Error 183] Cannot create a file when that file already exists >>>> java.net.SocketException: Connection reset >>>> at >>>> java.base/java.net.SocketInputStream.read(SocketInputStream.java:209) >>>> at >>>> java.base/java.net.SocketInputStream.read(SocketInputStream.java:141) >>>> at >>>> java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284) >>>> at >>>> java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) >>>> at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) >>>> at >>>> java.base/java.io.InputStreamReader.read(InputStreamReader.java:185) >>>> at java.base/java.io.BufferedReader.fill(BufferedReader.java:161) >>>> at >>>> java.base/java.io.BufferedReader.readLine(BufferedReader.java:325) >>>> at >>>> java.base/java.io.BufferedReader.readLine(BufferedReader.java:390) >>>> at >>>> com.oracle.mxtool.compilerserver.CompilerDaemon$Connection.run(CompilerDaemon.java:133) >>>> at >>>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514) >>>> at >>>> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) >>>> at >>>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1161) >>>> at >>>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) >>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 2nd trace >>>> --------- >>>> Compiling com.oracle.truffle.api.interop.java with javac-daemon... >>>> [C:\Users\Raffaello\graal\truffle\mxbuild\truffle\com.oracle.truffle.api.interop.java\bin\com\oracle\truffle\api\interop\java\ArrayWriteNode.class >>>> does not exist] >>>> warning: [options] bootstrap class path not set in conjunction with >>>> -source 1.7 >>>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaObject.java:44: >>>> error: cannot find symbol >>>> return JavaObjectMessageResolutionForeign.createAccess(); >>>> ^ >>>> symbol: variable JavaObjectMessageResolutionForeign >>>> location: class JavaObject >>>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaFunctionMessageResolution.java:62: >>>> error: cannot find symbol >>>> this.toJava[i] = ToJavaNodeGen.create(); >>>> ^ >>>> symbol: variable ToJavaNodeGen >>>> location: class DoExecuteNode >>>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaFunctionObject.java:47: >>>> error: cannot find symbol >>>> return JavaFunctionMessageResolutionForeign.createAccess(); >>>> ^ >>>> symbol: variable JavaFunctionMessageResolutionForeign >>>> location: class JavaFunctionObject >>>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaInterop.java:151: >>>> error: cannot find symbol >>>> RootNode root = new TemporaryConvertRoot(TruffleLanguage.class, >>>> ToJavaNodeGen.create(), foreignObject, type); >>>> ^ >>>> symbol: variable ToJavaNodeGen >>>> location: class JavaInterop >>>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaInterop.java:257: >>>> error: cannot find symbol >>>> RootNode root = new TemporaryConvertRoot(TruffleLanguage.class, >>>> ToJavaNodeGen.create(), function, functionalType); >>>> ^ >>>> symbol: variable ToJavaNodeGen >>>> location: class JavaInterop >>>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaObjectMessageResolution.java:177: >>>> error: cannot find symbol >>>> @Child private ArrayReadNode read = ArrayReadNodeGen.create(); >>>> ^ >>>> symbol: variable ArrayReadNodeGen >>>> location: class ReadFieldNode >>>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaObjectMessageResolution.java:222: >>>> error: cannot find symbol >>>> @Child private ToJavaNode toJava = ToJavaNodeGen.create(); >>>> ^ >>>> symbol: variable ToJavaNodeGen >>>> location: class WriteFieldNode >>>> C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaObjectMessageResolution.java:250: >>>> error: cannot find symbol >>>> @Child private ArrayWriteNode write = ArrayWriteNodeGen.create(); >>>> ^ >>>> symbol: variable ArrayWriteNodeGen >>>> location: class WriteFieldNode >>>> 8 errors >>>> 1 warning >>>> >>> >> > From josef.eisl at jku.at Fri Dec 2 10:37:02 2016 From: josef.eisl at jku.at (Josef Eisl) Date: Fri, 2 Dec 2016 11:37:02 +0100 Subject: AheadOfTimeCompilationTest In-Reply-To: <5D37AFF3-5B18-48D1-9A71-7B9FE86B395D@oracle.com> References: <6bb1184c-887d-af19-8960-1a5864e7a16f@redhat.com> <5D37AFF3-5B18-48D1-9A71-7B9FE86B395D@oracle.com> Message-ID: <0f92c146-d5cb-f07a-66f8-dbd3e578e76a@jku.at> On 02/12/16 11:27, Doug Simon wrote: > They test the expected behavior of the com.oracle.graal.compiler.common.GraalOptions.ImmutableCode option. > > If you?re having problems making these tests pass on AArch64, you could insert `org.junit.Assume.assumeFalse(getTarget().arch.getName().equals("aarch64"));` in the relevant tests. Or even better, check for the instance instead of the name: assumeFalse("skipping on AArch64", getTarget().arch instanceof AArch64); > > -Doug > >> On 2 Dec 2016, at 11:05, Andrew Haley wrote: >> >> What does AheadOfTimeCompilationTest do? I'm seeing test failures >> in that my methods sometimes have the wrong number of nodes, but the >> code look fine. >> >> Thanks, >> >> Andrew. > From aph at redhat.com Fri Dec 2 10:47:46 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 2 Dec 2016 10:47:46 +0000 Subject: AheadOfTimeCompilationTest In-Reply-To: <5D37AFF3-5B18-48D1-9A71-7B9FE86B395D@oracle.com> References: <6bb1184c-887d-af19-8960-1a5864e7a16f@redhat.com> <5D37AFF3-5B18-48D1-9A71-7B9FE86B395D@oracle.com> Message-ID: <9f3c2022-df41-57c7-2ef0-64e5e4aa1112@redhat.com> On 02/12/16 10:27, Doug Simon wrote: > They test the expected behavior of the com.oracle.graal.compiler.common.GraalOptions.ImmutableCode option. > > If you?re having problems making these tests pass on AArch64, you could insert `org.junit.Assume.assumeFalse(getTarget().arch.getName().equals("aarch64"));` in the relevant tests. Okay, so ImmutableCode is TBD on AArch64. I'll add it to the list. Thanks, Andrew. From rahman.usta.88 at gmail.com Sat Dec 3 13:30:35 2016 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Sat, 3 Dec 2016 16:30:35 +0300 Subject: GraalVM running ruby-tool error Message-ID: Hello, When I try to run https://github.com/lucasocon/openweather.git on GraalVM, ruby-tool gives me the following errors; $ ruby-tool setup Error opening script file: /opt/graalvm-0.18-dk/jre/language/ruby/lib/ruby/truffle/jruby+truffle/bin/jruby+truffle (No such file or directory) First, name of script file is not jruby+truffle it is jruby-truffle-tool, after fixing it, I get the following error; OptionParser::InvalidOption: invalid option: --interpreter-path block in complete at /opt/graalvm-0.18-dk/jre/language/ruby/lib/ruby/stdlib/optparse.rb:1726 catch at org/jruby/RubyKernel.java:1118 complete at /opt/graalvm-0.18-dk/jre/language/ruby/lib/ruby/stdlib/optparse.rb:1724 block in parse_in_order at /opt/graalvm-0.18-dk/jre/language/ruby/lib/ruby/stdlib/optparse.rb:1534 catch at org/jruby/RubyKernel.java:1118 parse_in_order at /opt/graalvm-0.18-dk/jre/language/ruby/lib/ruby/stdlib/optparse.rb:1527 order! at /opt/graalvm-0.18-dk/jre/language/ruby/lib/ruby/stdlib/optparse.rb:1521 order at /opt/graalvm-0.18-dk/jre/language/ruby/lib/ruby/stdlib/optparse.rb:1513 initialize at /opt/graalvm-0.18-dk/jre/language/ruby/lib/ruby/truffle/jruby-truffle-tool/lib/truffle/tool.rb:362
at /opt/graalvm-0.18-dk/jre/language/ruby/lib/ruby/truffle/jruby-truffle-tool/bin/jruby-truffle-tool:5 How can I solve this issue ? Thanks -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From chris.seaton at oracle.com Sun Dec 4 17:47:57 2016 From: chris.seaton at oracle.com (Chris Seaton) Date: Sun, 4 Dec 2016 17:47:57 +0000 Subject: GraalVM running ruby-tool error In-Reply-To: References: Message-ID: <7D44465E-B751-4125-96BA-179C117D042A@oracle.com> Hello Rahman, Sorry, this is my fault. I haven?t been maintaining this tool properly and have actually now removed it from future GraalVM releases because it will be possible to use bundle almost as normal from the next release. For openweather specifically, you should just be able to clone the source and run it directly - run the executable with the library on the load path. $ git clone https://github.com/lucasocon/openweather.git $ graalvm-0.18-re/bin/ruby -I openweather/lib openweather/examples/temperature.rb london london: 3.69 ? Chris > On 3 Dec 2016, at 13:30, Rahman USTA wrote: > > Hello, > > When I try to run https://github.com/lucasocon/openweather.git on GraalVM, > ruby-tool gives me the following errors; > > $ ruby-tool setup > > Error opening script file: > /opt/graalvm-0.18-dk/jre/language/ruby/lib/ruby/truffle/jruby+truffle/bin/jruby+truffle > (No such file or directory) > > First, name of script file is not jruby+truffle it is jruby-truffle-tool, > after fixing it, I get the following error; > > OptionParser::InvalidOption: invalid option: --interpreter-path > block in complete at > /opt/graalvm-0.18-dk/jre/language/ruby/lib/ruby/stdlib/optparse.rb:1726 > catch at org/jruby/RubyKernel.java:1118 > complete at > /opt/graalvm-0.18-dk/jre/language/ruby/lib/ruby/stdlib/optparse.rb:1724 > block in parse_in_order at > /opt/graalvm-0.18-dk/jre/language/ruby/lib/ruby/stdlib/optparse.rb:1534 > catch at org/jruby/RubyKernel.java:1118 > parse_in_order at > /opt/graalvm-0.18-dk/jre/language/ruby/lib/ruby/stdlib/optparse.rb:1527 > order! at > /opt/graalvm-0.18-dk/jre/language/ruby/lib/ruby/stdlib/optparse.rb:1521 > order at > /opt/graalvm-0.18-dk/jre/language/ruby/lib/ruby/stdlib/optparse.rb:1513 > initialize at > /opt/graalvm-0.18-dk/jre/language/ruby/lib/ruby/truffle/jruby-truffle-tool/lib/truffle/tool.rb:362 >
at > /opt/graalvm-0.18-dk/jre/language/ruby/lib/ruby/truffle/jruby-truffle-tool/bin/jruby-truffle-tool:5 > > How can I solve this issue ? > > Thanks > > -- > Rahman USTA > Istanbul JUG > https://github.com/rahmanusta From aph at redhat.com Tue Dec 6 10:55:29 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 6 Dec 2016 10:55:29 +0000 Subject: InstrumentBranchesPhaseTest Message-ID: <984b70e5-534a-e390-6968-b8097f136625@redhat.com> I'm baffled by InstrumentBranchesPhaseTest. I'm getting a failure here: Assert.assertTrue(stackOutput.contains("[bci: 4]\n[0] state = ELSE(if=0#, else=1#)")); but the output is: {com.oracle.graal.truffle.test.InstrumentBranchesPhaseTest$SimpleIfTestNode.execute(InstrumentBranchesPhaseTest.java:48) [bci: 4]=[0] state = NONE(if=0#, else=0#)} I don't know what this test does, and I don't understand how any of this might be AArch64-specific. Thanks, Andrew. From doug.simon at oracle.com Tue Dec 6 11:01:27 2016 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 6 Dec 2016 12:01:27 +0100 Subject: InstrumentBranchesPhaseTest In-Reply-To: <984b70e5-534a-e390-6968-b8097f136625@redhat.com> References: <984b70e5-534a-e390-6968-b8097f136625@redhat.com> Message-ID: <74C425FC-CA9A-4016-9732-EC3C6757D667@oracle.com> Alex, Do you know why Andrew may be getting this failure? Also, maybe you could add some javadoc to InstrumentBranchesPhase at some point ;-) -Doug > On 6 Dec 2016, at 11:55, Andrew Haley wrote: > > I'm baffled by InstrumentBranchesPhaseTest. I'm getting a failure here: > > Assert.assertTrue(stackOutput.contains("[bci: 4]\n[0] state = ELSE(if=0#, else=1#)")); > > but the output is: > > {com.oracle.graal.truffle.test.InstrumentBranchesPhaseTest$SimpleIfTestNode.execute(InstrumentBranchesPhaseTest.java:48) [bci: 4]=[0] state = NONE(if=0#, else=0#)} > > I don't know what this test does, and I don't understand how any of > this might be AArch64-specific. > > Thanks, > > Andrew. From aleksandar.prokopec at oracle.com Tue Dec 6 13:27:09 2016 From: aleksandar.prokopec at oracle.com (Aleksandar Prokopec) Date: Tue, 6 Dec 2016 14:27:09 +0100 Subject: InstrumentBranchesPhaseTest In-Reply-To: <74C425FC-CA9A-4016-9732-EC3C6757D667@oracle.com> References: <984b70e5-534a-e390-6968-b8097f136625@redhat.com> <74C425FC-CA9A-4016-9732-EC3C6757D667@oracle.com> Message-ID: <5846BCAD.6090109@oracle.com> Hi Andrew, The InstrumentBranchesPhase is used to instrument the code paths at different branches in the program. For each "if" statement in the compiled program, the phase effectively tracks whether the "true" branch or the "else" branch was taken. It does so by adding a counter at the beginning of each branch. When the JVM terminates, information about all the branches is printed to the standard output. This functionality proved useful for Truffle language developers, as it allows them to quickly figure out which optimization paths were correctly taken in their language implementations. I'll add a bit of JavaDoc to the phase. The test in question checks that the branch instrumentation output is correct, i.e., that it reports that the "else" branch of the "execute" method of the Truffle "SimpleIfTestNode" is taken exactly once. I am unsure why this fails on AArch64, but two things that come to mind: 1) It is possible that there is an optimization somewhere that somehow folds away the entire if-else statement, and that this happens only on AArch64. 2) It is possible that NodeSourcePositions are somehow not created on AArch64. Cheers, Alex On 06.12.2016 12:01, Doug Simon wrote: > Alex, > > Do you know why Andrew may be getting this failure? Also, maybe you could add some javadoc to InstrumentBranchesPhase at some point ;-) > > -Doug > >> On 6 Dec 2016, at 11:55, Andrew Haley wrote: >> >> I'm baffled by InstrumentBranchesPhaseTest. I'm getting a failure here: >> >> Assert.assertTrue(stackOutput.contains("[bci: 4]\n[0] state = ELSE(if=0#, else=1#)")); >> >> but the output is: >> >> {com.oracle.graal.truffle.test.InstrumentBranchesPhaseTest$SimpleIfTestNode.execute(InstrumentBranchesPhaseTest.java:48) [bci: 4]=[0] state = NONE(if=0#, else=0#)} >> >> I don't know what this test does, and I don't understand how any of >> this might be AArch64-specific. >> >> Thanks, >> >> Andrew. From aph at redhat.com Wed Dec 7 15:44:09 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 7 Dec 2016 15:44:09 +0000 Subject: CompilationFinalWeakReferencePartialEvaluationTest Message-ID: <3495c230-7ad1-75af-f860-6ac7a060169d@redhat.com> I'm baffled by this test. If I run it on AArch64 it fails with java.lang.AssertionError: expected:<42> but was:<57005> at org.junit.Assert.fail(JUNIT.4e031bb61df09069aeb2bffb4019e7a5034a4ee0/Assert.java:88) ... at com.oracle.graal.truffle.test.CompilationFinalWeakReferencePartialEvaluationTest.compilationFinalWeakReferenceTest(CompilationFinalWeakReferencePartialEvaluationTest.java:147) So I tried it on x86. If I run it on x86 with debugging single-step in eclipse, it does the same as on AArch64. If I run it on x86 without debugging enabled then it passes. So, I cannot debug to find the problem because debugging always breaks the test. Please help me to understand what this test is supposed to do, and how it is supposed to work. Thanks, Andrew. From andreas.woess at oracle.com Wed Dec 7 16:03:00 2016 From: andreas.woess at oracle.com (Andreas Woess) Date: Wed, 7 Dec 2016 17:03:00 +0100 Subject: CompilationFinalWeakReferencePartialEvaluationTest In-Reply-To: <3495c230-7ad1-75af-f860-6ac7a060169d@redhat.com> References: <3495c230-7ad1-75af-f860-6ac7a060169d@redhat.com> Message-ID: Hi Andrew, I guess this test is fails on AArch64 because Truffle is currently missing AArch64 support [1], so it's not executing Truffle-compiled code as the test expects. Feel free to @Ignore the test for now, and we will take care of it later. [1] namely an implementation of OptimizedCallTargetInstrumentationFactory (for interested parties) - Andreas On 07/12/2016 16:44, Andrew Haley wrote: > I'm baffled by this test. If I run it on AArch64 it fails with > > java.lang.AssertionError: expected:<42> but was:<57005> > at org.junit.Assert.fail(JUNIT.4e031bb61df09069aeb2bffb4019e7a5034a4ee0/Assert.java:88) > ... > at com.oracle.graal.truffle.test.CompilationFinalWeakReferencePartialEvaluationTest.compilationFinalWeakReferenceTest(CompilationFinalWeakReferencePartialEvaluationTest.java:147) > > So I tried it on x86. If I run it on x86 with debugging single-step > in eclipse, it does the same as on AArch64. If I run it on x86 > without debugging enabled then it passes. > > So, I cannot debug to find the problem because debugging always > breaks the test. Please help me to understand what this test is > supposed to do, and how it is supposed to work. > > Thanks, > > Andrew. From aph at redhat.com Wed Dec 7 16:05:52 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 7 Dec 2016 16:05:52 +0000 Subject: CompilationFinalWeakReferencePartialEvaluationTest In-Reply-To: References: <3495c230-7ad1-75af-f860-6ac7a060169d@redhat.com> Message-ID: <9369f134-05ec-3f78-2595-39f3ffa03c4a@redhat.com> On 07/12/16 16:03, Andreas Woess wrote: > I guess this test is fails on AArch64 because Truffle is currently > missing AArch64 support [1], so it's not executing Truffle-compiled code > as the test expects. Feel free to @Ignore the test for now, and we will > take care of it later. OK. Are there more Truffle-dependent tests I should @Ignore? Thanks, Andrew. From andreas.woess at oracle.com Wed Dec 7 16:21:56 2016 From: andreas.woess at oracle.com (Andreas Woess) Date: Wed, 7 Dec 2016 17:21:56 +0100 Subject: CompilationFinalWeakReferencePartialEvaluationTest In-Reply-To: <9369f134-05ec-3f78-2595-39f3ffa03c4a@redhat.com> References: <3495c230-7ad1-75af-f860-6ac7a060169d@redhat.com> <9369f134-05ec-3f78-2595-39f3ffa03c4a@redhat.com> Message-ID: <8951ffc8-a771-329a-b750-5482ec96c763@oracle.com> More PartialEvaluationTests (in the com.oracle.graal.truffle.test package) might fail because of that. If it's not just 1 test, maybe we need to skip these tests on AArch64 only. This could be done with junit's Assume.assumeTrue/False with an arch check. It's probably enough to put it somewhere in PartialEvaluationTest. (Obviously, the other option would be to implement the missing pieces. But we can do that in a follow-up.) - andreas On 07/12/2016 17:05, Andrew Haley wrote: > On 07/12/16 16:03, Andreas Woess wrote: >> I guess this test is fails on AArch64 because Truffle is currently >> missing AArch64 support [1], so it's not executing Truffle-compiled code >> as the test expects. Feel free to @Ignore the test for now, and we will >> take care of it later. > OK. Are there more Truffle-dependent tests I should @Ignore? > > Thanks, > > Andrew. > From aph at redhat.com Wed Dec 7 16:26:06 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 7 Dec 2016 16:26:06 +0000 Subject: CompilationFinalWeakReferencePartialEvaluationTest In-Reply-To: <8951ffc8-a771-329a-b750-5482ec96c763@oracle.com> References: <3495c230-7ad1-75af-f860-6ac7a060169d@redhat.com> <9369f134-05ec-3f78-2595-39f3ffa03c4a@redhat.com> <8951ffc8-a771-329a-b750-5482ec96c763@oracle.com> Message-ID: <8473f608-8b97-8d3a-758c-ebdf652098fb@redhat.com> On 07/12/16 16:21, Andreas Woess wrote: > More PartialEvaluationTests (in the com.oracle.graal.truffle.test > package) might fail because of that. If it's not just 1 test, maybe we > need to skip these tests on AArch64 only. This could be done with > junit's Assume.assumeTrue/False with an arch check. It's probably enough > to put it somewhere in PartialEvaluationTest. (Obviously, the other > option would be to implement the missing pieces. But we can do that in a > follow-up.) OK. I'll try that and see what happens. Of course, I don't know what is missing in the way of AArch64 support, so responses like "Truffle is currently missing AArch64 support" are extremely helpful, especially when this test is failing in a very obscure way and I've been staring it it for hours! Thanks again, Andrew. From andreas.woess at oracle.com Wed Dec 7 17:08:50 2016 From: andreas.woess at oracle.com (Andreas Woess) Date: Wed, 7 Dec 2016 18:08:50 +0100 Subject: CompilationFinalWeakReferencePartialEvaluationTest In-Reply-To: <8473f608-8b97-8d3a-758c-ebdf652098fb@redhat.com> References: <3495c230-7ad1-75af-f860-6ac7a060169d@redhat.com> <9369f134-05ec-3f78-2595-39f3ffa03c4a@redhat.com> <8951ffc8-a771-329a-b750-5482ec96c763@oracle.com> <8473f608-8b97-8d3a-758c-ebdf652098fb@redhat.com> Message-ID: <94f023aa-2324-75df-123f-55091c03a8ef@oracle.com> Something like this may work (untested): https://github.com/graalvm/graal-core/pull/237 - andreas On 07/12/2016 17:26, Andrew Haley wrote: > On 07/12/16 16:21, Andreas Woess wrote: >> More PartialEvaluationTests (in the com.oracle.graal.truffle.test >> package) might fail because of that. If it's not just 1 test, maybe we >> need to skip these tests on AArch64 only. This could be done with >> junit's Assume.assumeTrue/False with an arch check. It's probably enough >> to put it somewhere in PartialEvaluationTest. (Obviously, the other >> option would be to implement the missing pieces. But we can do that in a >> follow-up.) > OK. I'll try that and see what happens. > > Of course, I don't know what is missing in the way of AArch64 support, > so responses like "Truffle is currently missing AArch64 support" are > extremely helpful, especially when this test is failing in a very > obscure way and I've been staring it it for hours! > > Thanks again, > > Andrew. > From aph at redhat.com Wed Dec 7 17:52:54 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 7 Dec 2016 17:52:54 +0000 Subject: All Graal tests pass on AArch64 Message-ID: ... except the truffle ones, which I've excluded. So I'm going to do a cleanup pass on the aarch64_graal_misc_fixes branch, hopefully get that pulled into master, and then fix the Truffle bugs. Once that's done I'll look at code quality. There are quite a few examples of poor code generation. It would be nice to get Graal somewhere near C2, but that will require some serious work on vectorization. Andrew. From vladimir.kozlov at oracle.com Wed Dec 7 17:59:46 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 7 Dec 2016 09:59:46 -0800 Subject: All Graal tests pass on AArch64 In-Reply-To: References: Message-ID: <1d6465e6-a248-7d1a-6c39-ddb3f0977931@oracle.com> Hurray! Congratulation! Looking forward to run AOT on aarch64 in jdk 10 ;) Regards, Vladimir On 12/7/16 9:52 AM, Andrew Haley wrote: > ... except the truffle ones, which I've excluded. > > > So I'm going to do a cleanup pass on the aarch64_graal_misc_fixes > branch, hopefully get that pulled into master, and then fix the > Truffle bugs. > > Once that's done I'll look at code quality. There are quite a few > examples of poor code generation. It would be nice to get Graal > somewhere near C2, but that will require some serious work on > vectorization. > > Andrew. > From doug.simon at oracle.com Wed Dec 7 18:16:18 2016 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 7 Dec 2016 19:16:18 +0100 Subject: All Graal tests pass on AArch64 In-Reply-To: <1d6465e6-a248-7d1a-6c39-ddb3f0977931@oracle.com> References: <1d6465e6-a248-7d1a-6c39-ddb3f0977931@oracle.com> Message-ID: <137FDEE7-AAE8-429B-B11E-75117C9E7D63@oracle.com> Congrats Andrew! It would be great to add come AArch64 CI testing. However, I?m not sure there?s anything available for this. All I?ve found so far is https://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html which may be a start. -Doug > On 7 Dec 2016, at 18:59, Vladimir Kozlov wrote: > > Hurray! Congratulation! > > Looking forward to run AOT on aarch64 in jdk 10 ;) > > Regards, > Vladimir > > > On 12/7/16 9:52 AM, Andrew Haley wrote: >> ... except the truffle ones, which I've excluded. >> >> >> So I'm going to do a cleanup pass on the aarch64_graal_misc_fixes >> branch, hopefully get that pulled into master, and then fix the >> Truffle bugs. >> >> Once that's done I'll look at code quality. There are quite a few >> examples of poor code generation. It would be nice to get Graal >> somewhere near C2, but that will require some serious work on >> vectorization. >> >> Andrew. >> From doug.simon at oracle.com Wed Dec 7 20:39:02 2016 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 7 Dec 2016 21:39:02 +0100 Subject: Renaming com.oracle.graal to org.graalvm.compiler Message-ID: A requirement for integrating graal-core into OpenJDK as part of AOT[1] is to remove Oracle from package names. As such, we are renaming all com.oracle.graal packages to org.graalvm.compiler (to avoid redundancy, com.oracle.graal.compiler.** will be renamed to org.graalvm.compiler.core.**). A preview of this change can be seen here: https://github.com/graalvm/graal-core/pull/238 Once you pull these changes, you should `mx clean; mx ideinit` and re-import all projects in your IDE. Be extra diligent when merging (or rebasing these changes) into any branches you have. I?ve taken care to split the directory renaming into it?s own commit without any other files changes. This apparently is a good strategy[2] to ensure git sees the renames. Even so, if you have new files in your branch, you may have to do some manual cleanup after merging. This change should arrive in the github repo this Friday at the latest. -Doug [1] https://bugs.openjdk.java.net/browse/JDK-8166417 [2] http://stackoverflow.com/questions/433111/how-to-make-git-mark-a-deleted-and-a-new-file-as-a-file-move From vladimir.kozlov at oracle.com Wed Dec 7 22:10:15 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 7 Dec 2016 14:10:15 -0800 Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler Message-ID: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8166417 It is part of JEP 295: Ahead-of-Time Compilation https://bugs.openjdk.java.net/browse/JDK-8166089 http://cr.openjdk.java.net/~kvn/8166417/top.webrev/ http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/ http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/ This is formal review request for integration Graal-core sources into OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to integrated Graal-core sources into JDK and add build changes to build Graal module. Note, changes are based on latest jdk9/hs sources which do not have latest jigsaw update yet. With jigsaw update small changes will be done to module-info.java.extra in java.base: exports jdk.internal.misc to jdk.vm.compiler; + opens jdk.internal.misc to jdk.vm.compiler; - exports com.sun.crypto.provider to jdk.vm.compiler; + opens com.sun.crypto.provider to jdk.vm.compiler; And changes in top make/GensrcModuleInfo.gmk will not be needed. Graal is a dynamic compiler written in Java that integrates with the HotSpot JVM. It has a focus on high performance and extensibility. In addition, it provides optimized performance for Truffle based languages running on the JVM. https://github.com/graalvm/graal-core Oracle Labs is developing and maintaining it. Here are people who contributed into Graal development (sorry if someone is missing or misspelled, please speak): ~70k LOC: Douglas Simon ~60k LOC: Lukas Stadler ~30k LOC: Thomas Wuerthinger ~30k LOC: Tom Rodriguez ~30k LOC: Roland Schatz ~30k LOC: Josef Eisl ~30k LOC: Christian Wimmer ~16k LOC: Chris Thalinger ~13k LOC: Gilles Duboscq ~11k LOC: David Leopoldseder ~ 8k LOC: Stefan Anzinger ~ 8k LOC: Christian Humer Other contributors >100 LOC in approximate order of contribution size: Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec, Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, Jaroslav Tulach, Chris Seaton, Peter B. Kessler, Christian Wirth, Benoit Daloze. Thanks, Vladimir From igor.veresov at oracle.com Wed Dec 7 22:21:47 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 7 Dec 2016 14:21:47 -0800 Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler In-Reply-To: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com> References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com> Message-ID: <502C698D-88CC-4874-A8F3-799E823ABE5E@oracle.com> Perfect. :) Reviewed. igor > On Dec 7, 2016, at 2:10 PM, Vladimir Kozlov wrote: > > https://bugs.openjdk.java.net/browse/JDK-8166417 > > It is part of JEP 295: Ahead-of-Time Compilation > https://bugs.openjdk.java.net/browse/JDK-8166089 > > http://cr.openjdk.java.net/~kvn/8166417/top.webrev/ > http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/ > http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/ > > This is formal review request for integration Graal-core sources into OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to integrated Graal-core sources into JDK and add build changes to build Graal module. > > Note, changes are based on latest jdk9/hs sources which do not have latest jigsaw update yet. With jigsaw update small changes will be done to module-info.java.extra in java.base: > > exports jdk.internal.misc to jdk.vm.compiler; > + opens jdk.internal.misc to jdk.vm.compiler; > > - exports com.sun.crypto.provider to jdk.vm.compiler; > + opens com.sun.crypto.provider to jdk.vm.compiler; > > And changes in top make/GensrcModuleInfo.gmk will not be needed. > > > > Graal is a dynamic compiler written in Java that integrates with the HotSpot JVM. It has a focus on high performance and extensibility. In addition, it provides optimized performance for Truffle based languages running on the JVM. > > https://github.com/graalvm/graal-core > > Oracle Labs is developing and maintaining it. > > Here are people who contributed into Graal development (sorry if someone is missing or misspelled, please speak): > > ~70k LOC: Douglas Simon > ~60k LOC: Lukas Stadler > ~30k LOC: Thomas Wuerthinger > ~30k LOC: Tom Rodriguez > ~30k LOC: Roland Schatz > ~30k LOC: Josef Eisl > ~30k LOC: Christian Wimmer > ~16k LOC: Chris Thalinger > ~13k LOC: Gilles Duboscq > ~11k LOC: David Leopoldseder > ~ 8k LOC: Stefan Anzinger > ~ 8k LOC: Christian Humer > > Other contributors >100 LOC in approximate order of contribution size: > Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec, Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, Jaroslav Tulach, Chris Seaton, Peter B. Kessler, Christian Wirth, Benoit Daloze. > > > Thanks, > Vladimir From doug.simon at oracle.com Thu Dec 8 13:08:01 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 8 Dec 2016 14:08:01 +0100 Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler In-Reply-To: <957e584a-a283-bfda-2b75-1474bbcac7ae@oracle.com> References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com> <957e584a-a283-bfda-2b75-1474bbcac7ae@oracle.com> Message-ID: <637554AA-0A53-4002-A1EA-78F10FCF88CB@oracle.com> > On 8 Dec 2016, at 13:50, Magnus Ihse Bursie wrote: > > On 2016-12-07 23:10, Vladimir Kozlov wrote: >> https://bugs.openjdk.java.net/browse/JDK-8166417 >> >> It is part of JEP 295: Ahead-of-Time Compilation >> https://bugs.openjdk.java.net/browse/JDK-8166089 >> >> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/ >> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/ >> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/ > > * In CompileJavaModules.gmk, there is an *extreme* list of excludes. I note that most of them end in ".test". The proper solution to this is to move the test code to the test/ directory instead of the src/ directory. Also, four of them are the javac processor build tools. These should move to make/src, as other build tools. Keeping like it is simplifies pulling changes from https://github.com/graalvm/graal-core. It's possible to write a more sophisticated tool for pulling changes in from the github and places the sources into more openjdk compatible locations. It's up to the HotSpot compiler team whether investing in such a tool makes sense. > * In hotspot.m4: AC_MSG_CHECKING must always be matched by a AC_MSG_RESULT, even before AC_MSG_ERROR, otherwise the output will be garbled. > > * In hotspot.m4: The test to determine if we should set INCLUDE_GRAAL is incorrect. It only tests for the default value, not for the explicitely set (i.e., HOTSPOT_CHECK_JVM_FEATURE(graal)). > > * The file hotspot/make/Tools.gmk is broken ("ifeq ($(ENABLE_AOT), true)" will never evaluate to true). But on the other hand, it is not needed, and should just be removed. :-) > > * The file hotspot/src/jdk.vm.compiler/share/classes/overview.html seems a bit dangling. Is this supposed to be included in some Javadoc generation? The html file refers to a projects.jpg and projects.html that does not exist. Maybe it should just be removed? I would recommend omitting all graal-core overview.html files in OpenJDK. > * Finally, just for the record, I too think the source should be structured according to the OpenJDK praxis. (But I won't fight about this.) -Doug >> >> This is formal review request for integration Graal-core sources into OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to integrated Graal-core sources into JDK and add build changes to build Graal module. >> >> Note, changes are based on latest jdk9/hs sources which do not have latest jigsaw update yet. With jigsaw update small changes will be done to module-info.java.extra in java.base: >> >> exports jdk.internal.misc to jdk.vm.compiler; >> + opens jdk.internal.misc to jdk.vm.compiler; >> >> - exports com.sun.crypto.provider to jdk.vm.compiler; >> + opens com.sun.crypto.provider to jdk.vm.compiler; >> >> And changes in top make/GensrcModuleInfo.gmk will not be needed. >> >> >> >> Graal is a dynamic compiler written in Java that integrates with the HotSpot JVM. It has a focus on high performance and extensibility. In addition, it provides optimized performance for Truffle based languages running on the JVM. >> >> https://github.com/graalvm/graal-core >> >> Oracle Labs is developing and maintaining it. >> >> Here are people who contributed into Graal development (sorry if someone is missing or misspelled, please speak): >> >> ~70k LOC: Douglas Simon >> ~60k LOC: Lukas Stadler >> ~30k LOC: Thomas Wuerthinger >> ~30k LOC: Tom Rodriguez >> ~30k LOC: Roland Schatz >> ~30k LOC: Josef Eisl >> ~30k LOC: Christian Wimmer >> ~16k LOC: Chris Thalinger >> ~13k LOC: Gilles Duboscq >> ~11k LOC: David Leopoldseder >> ~ 8k LOC: Stefan Anzinger >> ~ 8k LOC: Christian Humer >> >> Other contributors >100 LOC in approximate order of contribution size: >> Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec, Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, Jaroslav Tulach, Chris Seaton, Peter B. Kessler, Christian Wirth, Benoit Daloze. >> >> >> Thanks, >> Vladimir > From aph at redhat.com Thu Dec 8 14:54:13 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 8 Dec 2016 14:54:13 +0000 Subject: Checkstyle AvoidNestedBlocksCheck Message-ID: I'm having this rejected: { Label loop = new Label(); // Align the main loop masm.align(crb.target.wordSize * 2); masm.bind(loop); masm.ldr(64, temp, AArch64Address.createRegisterOffsetAddress(array1, length, false)); masm.ldr(64, rscratch1, AArch64Address.createRegisterOffsetAddress(array2, length, false)); masm.eor(64, rscratch1, temp, rscratch1); masm.cbnz(64, rscratch1, breakLabel); masm.add(64, length, length, VECTOR_SIZE); masm.cbnz(64, length, loop); } This seems to me like good coding style. Declaring locally-used variables in a block has always been good coding style. Is it forbidden in Graal? Andrew. From erik.joelsson at oracle.com Thu Dec 8 10:12:41 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 8 Dec 2016 11:12:41 +0100 Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler In-Reply-To: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com> References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com> Message-ID: Hello, The file hotspot/make/Tools.gmk is dead code at this point and should be removed. Also stop including it from Gensrc-jdk.vm.compiler.gmk. Otherwise it looks ok to me. /Erik On 2016-12-07 23:10, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8166417 > > It is part of JEP 295: Ahead-of-Time Compilation > https://bugs.openjdk.java.net/browse/JDK-8166089 > > http://cr.openjdk.java.net/~kvn/8166417/top.webrev/ > http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/ > http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/ > > This is formal review request for integration Graal-core sources into > OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to > integrated Graal-core sources into JDK and add build changes to build > Graal module. > > Note, changes are based on latest jdk9/hs sources which do not have > latest jigsaw update yet. With jigsaw update small changes will be > done to module-info.java.extra in java.base: > > exports jdk.internal.misc to jdk.vm.compiler; > + opens jdk.internal.misc to jdk.vm.compiler; > > - exports com.sun.crypto.provider to jdk.vm.compiler; > + opens com.sun.crypto.provider to jdk.vm.compiler; > > And changes in top make/GensrcModuleInfo.gmk will not be needed. > > > > Graal is a dynamic compiler written in Java that integrates with the > HotSpot JVM. It has a focus on high performance and extensibility. In > addition, it provides optimized performance for Truffle based > languages running on the JVM. > > https://github.com/graalvm/graal-core > > Oracle Labs is developing and maintaining it. > > Here are people who contributed into Graal development (sorry if > someone is missing or misspelled, please speak): > > ~70k LOC: Douglas Simon > ~60k LOC: Lukas Stadler > ~30k LOC: Thomas Wuerthinger > ~30k LOC: Tom Rodriguez > ~30k LOC: Roland Schatz > ~30k LOC: Josef Eisl > ~30k LOC: Christian Wimmer > ~16k LOC: Chris Thalinger > ~13k LOC: Gilles Duboscq > ~11k LOC: David Leopoldseder > ~ 8k LOC: Stefan Anzinger > ~ 8k LOC: Christian Humer > > Other contributors >100 LOC in approximate order of contribution size: > Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos > Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec, > Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef > Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, Jaroslav Tulach, > Chris Seaton, Peter B. Kessler, Christian Wirth, Benoit Daloze. > > > Thanks, > Vladimir From magnus.ihse.bursie at oracle.com Thu Dec 8 12:50:38 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 8 Dec 2016 13:50:38 +0100 Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler In-Reply-To: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com> References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com> Message-ID: <957e584a-a283-bfda-2b75-1474bbcac7ae@oracle.com> On 2016-12-07 23:10, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8166417 > > It is part of JEP 295: Ahead-of-Time Compilation > https://bugs.openjdk.java.net/browse/JDK-8166089 > > http://cr.openjdk.java.net/~kvn/8166417/top.webrev/ > http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/ > http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/ * In CompileJavaModules.gmk, there is an *extreme* list of excludes. I note that most of them end in ".test". The proper solution to this is to move the test code to the test/ directory instead of the src/ directory. Also, four of them are the javac processor build tools. These should move to make/src, as other build tools. * In hotspot.m4: AC_MSG_CHECKING must always be matched by a AC_MSG_RESULT, even before AC_MSG_ERROR, otherwise the output will be garbled. * In hotspot.m4: The test to determine if we should set INCLUDE_GRAAL is incorrect. It only tests for the default value, not for the explicitely set (i.e., HOTSPOT_CHECK_JVM_FEATURE(graal)). * The file hotspot/make/Tools.gmk is broken ("ifeq ($(ENABLE_AOT), true)" will never evaluate to true). But on the other hand, it is not needed, and should just be removed. :-) * The file hotspot/src/jdk.vm.compiler/share/classes/overview.html seems a bit dangling. Is this supposed to be included in some Javadoc generation? The html file refers to a projects.jpg and projects.html that does not exist. Maybe it should just be removed? * Finally, just for the record, I too think the source should be structured according to the OpenJDK praxis. (But I won't fight about this.) /Magnus > > This is formal review request for integration Graal-core sources into > OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to > integrated Graal-core sources into JDK and add build changes to build > Graal module. > > Note, changes are based on latest jdk9/hs sources which do not have > latest jigsaw update yet. With jigsaw update small changes will be > done to module-info.java.extra in java.base: > > exports jdk.internal.misc to jdk.vm.compiler; > + opens jdk.internal.misc to jdk.vm.compiler; > > - exports com.sun.crypto.provider to jdk.vm.compiler; > + opens com.sun.crypto.provider to jdk.vm.compiler; > > And changes in top make/GensrcModuleInfo.gmk will not be needed. > > > > Graal is a dynamic compiler written in Java that integrates with the > HotSpot JVM. It has a focus on high performance and extensibility. In > addition, it provides optimized performance for Truffle based > languages running on the JVM. > > https://github.com/graalvm/graal-core > > Oracle Labs is developing and maintaining it. > > Here are people who contributed into Graal development (sorry if > someone is missing or misspelled, please speak): > > ~70k LOC: Douglas Simon > ~60k LOC: Lukas Stadler > ~30k LOC: Thomas Wuerthinger > ~30k LOC: Tom Rodriguez > ~30k LOC: Roland Schatz > ~30k LOC: Josef Eisl > ~30k LOC: Christian Wimmer > ~16k LOC: Chris Thalinger > ~13k LOC: Gilles Duboscq > ~11k LOC: David Leopoldseder > ~ 8k LOC: Stefan Anzinger > ~ 8k LOC: Christian Humer > > Other contributors >100 LOC in approximate order of contribution size: > Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos > Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec, > Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef > Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, Jaroslav Tulach, > Chris Seaton, Peter B. Kessler, Christian Wirth, Benoit Daloze. > > > Thanks, > Vladimir From thomas.wuerthinger at oracle.com Thu Dec 8 14:59:06 2016 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Thu, 8 Dec 2016 15:59:06 +0100 Subject: Checkstyle AvoidNestedBlocksCheck In-Reply-To: References: Message-ID: <58AAAA3A-0BF8-4539-B603-BF74A8E002A8@oracle.com> You can propose a change that changes the check style rule file. - thomas > On 08 Dec 2016, at 15:54, Andrew Haley wrote: > > I'm having this rejected: > > { > Label loop = new Label(); > // Align the main loop > masm.align(crb.target.wordSize * 2); > masm.bind(loop); > masm.ldr(64, temp, AArch64Address.createRegisterOffsetAddress(array1, length, false)); > masm.ldr(64, rscratch1, AArch64Address.createRegisterOffsetAddress(array2, length, false)); > masm.eor(64, rscratch1, temp, rscratch1); > masm.cbnz(64, rscratch1, breakLabel); > masm.add(64, length, length, VECTOR_SIZE); > masm.cbnz(64, length, loop); > } > > This seems to me like good coding style. Declaring locally-used variables > in a block has always been good coding style. Is it forbidden in Graal? > > Andrew. From aph at redhat.com Thu Dec 8 15:22:54 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 8 Dec 2016 15:22:54 +0000 Subject: Checkstyle AvoidNestedBlocksCheck In-Reply-To: <58AAAA3A-0BF8-4539-B603-BF74A8E002A8@oracle.com> References: <58AAAA3A-0BF8-4539-B603-BF74A8E002A8@oracle.com> Message-ID: On 08/12/16 14:59, Thomas Wuerthinger wrote: > You can propose a change that changes the check style rule file. Sure, I can do that, but I'm wondering whether any contributors believe the rule should be enforced. It seems to me to be a perverse rule that enforces bad coding practices, but I guess someone somewhere must like it. Andrew. From java at stefan-marr.de Thu Dec 8 15:40:01 2016 From: java at stefan-marr.de (Stefan Marr) Date: Thu, 8 Dec 2016 16:40:01 +0100 Subject: Checkstyle AvoidNestedBlocksCheck In-Reply-To: References: <58AAAA3A-0BF8-4539-B603-BF74A8E002A8@oracle.com> Message-ID: <21E2C4BC-EA74-44FE-87E8-F388F2E0C2E7@stefan-marr.de> Hi: > On 8 Dec 2016, at 16:22, Andrew Haley wrote: > > Sure, I can do that, but I'm wondering whether any contributors > believe the rule should be enforced. It seems to me to be a perverse > rule that enforces bad coding practices, but I guess someone somewhere > must like it. Can you give a name to the block? If so, it might improve readability to break out such blocks into methods consistently. Looking from that angle, I?d think there is value in the style rule. Best regards Stefan -- Stefan Marr Johannes Kepler Universit?t Linz http://stefan-marr.de/research/ From aph at redhat.com Thu Dec 8 15:43:57 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 8 Dec 2016 15:43:57 +0000 Subject: Checkstyle AvoidNestedBlocksCheck In-Reply-To: <21E2C4BC-EA74-44FE-87E8-F388F2E0C2E7@stefan-marr.de> References: <58AAAA3A-0BF8-4539-B603-BF74A8E002A8@oracle.com> <21E2C4BC-EA74-44FE-87E8-F388F2E0C2E7@stefan-marr.de> Message-ID: <5c3d39cf-5374-620d-edcf-05a3a25f4a2e@redhat.com> On 08/12/16 15:40, Stefan Marr wrote: > Can you give a name to the block? > > If so, it might improve readability to break out such blocks into methods consistently. This is hand-written assembly code. It's just a loop. All I'm doing is looping over two strings, comparing them. If I make the label global and remove the braces Checkstyle stops complaining, which is what I've done. The code is now compliant and worse: it's much like the equivalent x86 code. Andrew. From doug.simon at oracle.com Thu Dec 8 15:49:22 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 8 Dec 2016 16:49:22 +0100 Subject: Checkstyle AvoidNestedBlocksCheck In-Reply-To: <5c3d39cf-5374-620d-edcf-05a3a25f4a2e@redhat.com> References: <58AAAA3A-0BF8-4539-B603-BF74A8E002A8@oracle.com> <21E2C4BC-EA74-44FE-87E8-F388F2E0C2E7@stefan-marr.de> <5c3d39cf-5374-620d-edcf-05a3a25f4a2e@redhat.com> Message-ID: > On 8 Dec 2016, at 16:43, Andrew Haley wrote: > > On 08/12/16 15:40, Stefan Marr wrote: >> Can you give a name to the block? >> >> If so, it might improve readability to break out such blocks into methods consistently. > > This is hand-written assembly code. It's just a loop. All I'm doing > is looping over two strings, comparing them. Sounds like it could be refactored into an emitCompareStrings() method. > If I make the label > global and remove the braces Checkstyle stops complaining, which is > what I've done. The code is now compliant and worse: it's much like > the equivalent x86 code. If you prefer the nested block, you can bracket it with: // Checkstyle: stop ... // Checkstyle: resume I?ve mostly found nested blocks useful in C++ in use with destructors. -Doug From aph at redhat.com Thu Dec 8 16:04:41 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 8 Dec 2016 16:04:41 +0000 Subject: Checkstyle AvoidNestedBlocksCheck In-Reply-To: References: <58AAAA3A-0BF8-4539-B603-BF74A8E002A8@oracle.com> <21E2C4BC-EA74-44FE-87E8-F388F2E0C2E7@stefan-marr.de> <5c3d39cf-5374-620d-edcf-05a3a25f4a2e@redhat.com> Message-ID: <32b9347d-414c-1d6b-b759-be96fd68601d@redhat.com> On 08/12/16 15:49, Doug Simon wrote: > >> On 8 Dec 2016, at 16:43, Andrew Haley wrote: >> >> On 08/12/16 15:40, Stefan Marr wrote: >>> Can you give a name to the block? >>> >>> If so, it might improve readability to break out such blocks into methods consistently. >> >> This is hand-written assembly code. It's just a loop. All I'm doing >> is looping over two strings, comparing them. > > Sounds like it could be refactored into an emitCompareStrings() method. It *is* the emitCompareStrings() method. It requires some setup before the loop body, and the loop body has one variable, its label. I can make that label global. >> If I make the label >> global and remove the braces Checkstyle stops complaining, which is >> what I've done. The code is now compliant and worse: it's much like >> the equivalent x86 code. > > If you prefer the nested block, you can bracket it with: > > // Checkstyle: stop > ... > // Checkstyle: resume OK, thanks. > I?ve mostly found nested blocks useful in C++ in use with destructors. I'm used to a highly-structured way of writing assembly language, with labels only visible inside the blocks where they are used. I also use braces to indicate nesting. It seems to me that structured programming is just as valid in assembly language as any other language. Andrew. From stuart.monteith at linaro.org Thu Dec 8 16:48:00 2016 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Thu, 8 Dec 2016 16:48:00 +0000 Subject: All Graal tests pass on AArch64 In-Reply-To: <137FDEE7-AAE8-429B-B11E-75117C9E7D63@oracle.com> References: <1d6465e6-a248-7d1a-6c39-ddb3f0977931@oracle.com> <137FDEE7-AAE8-429B-B11E-75117C9E7D63@oracle.com> Message-ID: That is great Andrew - I'd like to add this to Linaro's automation for Aarch64, once I have more machine capacity for running tests. I am new to the OpenJDK processes, but it is disappointing that this feature was added so late, such that there was no-to-little time for the other architectures to catch up. There is an assumption this would only be in JDK10 for AArch64 (and, indeed, s390, ppc). Is JDK 9u not a more suitable target? BR, Stuart On 7 December 2016 at 18:16, Doug Simon wrote: > Congrats Andrew! > > It would be great to add come AArch64 CI testing. However, I?m not sure there?s anything available for this. All I?ve found so far is https://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html which may be a start. > > -Doug > >> On 7 Dec 2016, at 18:59, Vladimir Kozlov wrote: >> >> Hurray! Congratulation! >> >> Looking forward to run AOT on aarch64 in jdk 10 ;) >> >> Regards, >> Vladimir >> >> >> On 12/7/16 9:52 AM, Andrew Haley wrote: >>> ... except the truffle ones, which I've excluded. >>> >>> >>> So I'm going to do a cleanup pass on the aarch64_graal_misc_fixes >>> branch, hopefully get that pulled into master, and then fix the >>> Truffle bugs. >>> >>> Once that's done I'll look at code quality. There are quite a few >>> examples of poor code generation. It would be nice to get Graal >>> somewhere near C2, but that will require some serious work on >>> vectorization. >>> >>> Andrew. >>> > From aph at redhat.com Thu Dec 8 16:53:25 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 8 Dec 2016 16:53:25 +0000 Subject: All Graal tests pass on AArch64 In-Reply-To: References: <1d6465e6-a248-7d1a-6c39-ddb3f0977931@oracle.com> <137FDEE7-AAE8-429B-B11E-75117C9E7D63@oracle.com> Message-ID: On 08/12/16 16:48, Stuart Monteith wrote: > Is JDK 9u not a more suitable target? I don't know. It's all extremely raw at the moment, so that might be premature. If we can get it up to high-enough quality I'll ask. Andrew. From aph at redhat.com Thu Dec 8 18:11:23 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 8 Dec 2016 18:11:23 +0000 Subject: Complex rebasing Message-ID: <0e4fdbcb-2880-d546-d81d-739e7108b2ae@redhat.com> My first rebase has run into the weeds. I've been hit by the reorganization, which causes quite a lot of merge errors in my imports. But the biggest problem I've come across is that my newly-added files seem to disappear when I do a git rebase! Is this usual, is this something to do with the reorganization, or is it that I must have made a mistake somewhere? I've followed the instructions about rebasing as carefully as I can. Thanks, Andrew. From aph at redhat.com Thu Dec 8 18:12:13 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 8 Dec 2016 18:12:13 +0000 Subject: Complex rebasing In-Reply-To: <0e4fdbcb-2880-d546-d81d-739e7108b2ae@redhat.com> References: <0e4fdbcb-2880-d546-d81d-739e7108b2ae@redhat.com> Message-ID: <7eb4036e-11d5-461a-e116-bfce21f7cb37@redhat.com> So, I forgot to ask: What is the right way to rebase my working branch from the Graal master? Thanks, Andrew. From gilles.m.duboscq at oracle.com Thu Dec 8 18:14:38 2016 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Thu, 8 Dec 2016 19:14:38 +0100 Subject: Complex rebasing In-Reply-To: <0e4fdbcb-2880-d546-d81d-739e7108b2ae@redhat.com> References: <0e4fdbcb-2880-d546-d81d-739e7108b2ae@redhat.com> Message-ID: There was a lot of renaming and after a certain threshold, git gives up on trying to detect renames. For me it helped to set [merge] renamelimit = 3000 in ~/.gitconfig. That way git still tries to detect renames and thus gives better merge results. Gilles On 08/12/16 19:11, Andrew Haley wrote: > My first rebase has run into the weeds. > > I've been hit by the reorganization, which causes quite a lot of merge > errors in my imports. But the biggest problem I've come across is > that my newly-added files seem to disappear when I do a git rebase! > Is this usual, is this something to do with the reorganization, or is > it that I must have made a mistake somewhere? I've followed the > instructions about rebasing as carefully as I can. > > Thanks, > > Andrew. > From tom.rodriguez at oracle.com Thu Dec 8 18:29:05 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 8 Dec 2016 10:29:05 -0800 Subject: Complex rebasing In-Reply-To: <7eb4036e-11d5-461a-e116-bfce21f7cb37@redhat.com> References: <0e4fdbcb-2880-d546-d81d-739e7108b2ae@redhat.com> <7eb4036e-11d5-461a-e116-bfce21f7cb37@redhat.com> Message-ID: <8F14543C-C5C6-4AB4-8386-B727BF76EE71@oracle.com> > On Dec 8, 2016, at 10:12 AM, Andrew Haley wrote: > > So, I forgot to ask: > > What is the right way to rebase my working branch from the Graal master? > > Thanks, git pull ?rebase origin master is the usual command I use followed by git mergetool to resolve the conflict, but pulling renames and adding files definitely adds to the difficulty factor. Your files definitely shouldn?t disappear but they will be in the wrong place since you will have to rename them to the new layout. You may be able to use something like find graal -name \*.java | xargs perl -p -i - e ?s/com.oracle.graal/org.graalvm.compiler/g? though that will leave the imports improperly sorted. You can ask eclipse to organize those imports for you. Does that help any? tom From aph at redhat.com Thu Dec 8 18:39:06 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 8 Dec 2016 18:39:06 +0000 Subject: Complex rebasing In-Reply-To: <8F14543C-C5C6-4AB4-8386-B727BF76EE71@oracle.com> References: <0e4fdbcb-2880-d546-d81d-739e7108b2ae@redhat.com> <7eb4036e-11d5-461a-e116-bfce21f7cb37@redhat.com> <8F14543C-C5C6-4AB4-8386-B727BF76EE71@oracle.com> Message-ID: <4479e46a-f910-f8d3-eae2-d6f9bc1d1464@redhat.com> On 08/12/16 18:29, Tom Rodriguez wrote: > git pull ?rebase origin master is the usual command I use Ah, OK. That is very different from what I did. I tried "git rebase" but it rebased my checked-out code from my personal master, not graalvm's real master. My remote origin is https://github.com/theRealAph/graal-core (branch aarch64_graal_misc_fixes) and I want to rebase from https://github.com/graalvm/graal-core (branch master) Andrew. From tom.rodriguez at oracle.com Thu Dec 8 18:47:46 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 8 Dec 2016 10:47:46 -0800 Subject: Complex rebasing In-Reply-To: <4479e46a-f910-f8d3-eae2-d6f9bc1d1464@redhat.com> References: <0e4fdbcb-2880-d546-d81d-739e7108b2ae@redhat.com> <7eb4036e-11d5-461a-e116-bfce21f7cb37@redhat.com> <8F14543C-C5C6-4AB4-8386-B727BF76EE71@oracle.com> <4479e46a-f910-f8d3-eae2-d6f9bc1d1464@redhat.com> Message-ID: <2B5B5798-B4E5-4E5A-89F5-C3533459913F@oracle.com> > On Dec 8, 2016, at 10:39 AM, Andrew Haley wrote: > > On 08/12/16 18:29, Tom Rodriguez wrote: >> git pull ?rebase origin master is the usual command I use > > Ah, OK. That is very different from what I did. > > I tried "git rebase" but it rebased my checked-out code from my > personal master, not graalvm's real master. > > My remote origin is > > https://github.com/theRealAph/graal-core (branch aarch64_graal_misc_fixes) > > and I want to rebase from > > https://github.com/graalvm/graal-core (branch master) Right, so in my example origin would be replaced with whatever you named the remote for graalvm/graal-core. One problem with git is that there are usually 12 ways to do the same thing which complicates giving instructions to someone on how to solve a problem. Having multiple remotes makes it more complicated as well. If you have your own repo you might never use master which can get out of date with upstream. My personal practice is that origin always refers to the repo I will end up pushing to and my personal repo is named after my GitHub user name. tom From aph at redhat.com Thu Dec 8 18:56:29 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 8 Dec 2016 18:56:29 +0000 Subject: Complex rebasing In-Reply-To: <2B5B5798-B4E5-4E5A-89F5-C3533459913F@oracle.com> References: <0e4fdbcb-2880-d546-d81d-739e7108b2ae@redhat.com> <7eb4036e-11d5-461a-e116-bfce21f7cb37@redhat.com> <8F14543C-C5C6-4AB4-8386-B727BF76EE71@oracle.com> <4479e46a-f910-f8d3-eae2-d6f9bc1d1464@redhat.com> <2B5B5798-B4E5-4E5A-89F5-C3533459913F@oracle.com> Message-ID: <175ebea9-8bb9-0f1f-0225-e6e3dd43140a@redhat.com> On 08/12/16 18:47, Tom Rodriguez wrote: > >> On Dec 8, 2016, at 10:39 AM, Andrew Haley wrote: >> >> On 08/12/16 18:29, Tom Rodriguez wrote: >>> git pull ?rebase origin master is the usual command I use >> >> Ah, OK. That is very different from what I did. >> >> I tried "git rebase" but it rebased my checked-out code from my >> personal master, not graalvm's real master. >> >> My remote origin is >> >> https://github.com/theRealAph/graal-core (branch aarch64_graal_misc_fixes) >> >> and I want to rebase from >> >> https://github.com/graalvm/graal-core (branch master) > > Right, so in my example origin would be replaced with whatever you > named the remote for graalvm/graal-core. I'm sorry, I don't even know what that sentence means. I don't remember naming a remote for graalvm/graal-core. How would you do that? > One problem with git is that there are usually 12 ways to do the > same thing which complicates giving instructions to someone on how > to solve a problem. Having multiple remotes makes it more > complicated as well. If you have your own repo you might never use > master which can get out of date with upstream. That's right, and it has. > My personal practice is that origin always refers to the repo I will > end up pushing to and my personal repo is named after my GitHub user > name. Sure, and that sounds very sensible and much like what I'd like to do, but I have no idea how to do it. That's the problem: too many choices and no single standardized set of instructions. I'm just about managing to cope, but I'm new to Graal and Eclipse. Having to deal with git (and github) as well feels like cruel and unusual punishment. The big reorg of the files feels like I really must have done something wicked in a previous life. Andrew. From doug.simon at oracle.com Thu Dec 8 19:15:40 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 8 Dec 2016 20:15:40 +0100 Subject: Complex rebasing In-Reply-To: <175ebea9-8bb9-0f1f-0225-e6e3dd43140a@redhat.com> References: <0e4fdbcb-2880-d546-d81d-739e7108b2ae@redhat.com> <7eb4036e-11d5-461a-e116-bfce21f7cb37@redhat.com> <8F14543C-C5C6-4AB4-8386-B727BF76EE71@oracle.com> <4479e46a-f910-f8d3-eae2-d6f9bc1d1464@redhat.com> <2B5B5798-B4E5-4E5A-89F5-C3533459913F@oracle.com> <175ebea9-8bb9-0f1f-0225-e6e3dd43140a@redhat.com> Message-ID: <875B6886-669B-4F45-B46A-C0C26E57C532@oracle.com> I also have a rather large pending change on a branch where the rename is causing me headaches. Here is what I did after much googling: dsimon at kurz-3 ~/g/graal-core> git branch master * topic/non-static-options dsimon at kurz-3 ~/g/graal-core> git fetch -p ssh://git at github.com/graalvm/graal-core.git dsimon at kurz-3 ~/g/graal-core> git -c diff.renameLimit=3000 merge -s recursive -X rename-threshold=10% -X patience master That leaves me in a state where I have about 282 files with conflicts (which I expected). > On 8 Dec 2016, at 19:56, Andrew Haley wrote: > > On 08/12/16 18:47, Tom Rodriguez wrote: >> >>> On Dec 8, 2016, at 10:39 AM, Andrew Haley wrote: >>> >>> On 08/12/16 18:29, Tom Rodriguez wrote: >>>> git pull ?rebase origin master is the usual command I use >>> >>> Ah, OK. That is very different from what I did. >>> >>> I tried "git rebase" but it rebased my checked-out code from my >>> personal master, not graalvm's real master. >>> >>> My remote origin is >>> >>> https://github.com/theRealAph/graal-core (branch aarch64_graal_misc_fixes) >>> >>> and I want to rebase from >>> >>> https://github.com/graalvm/graal-core (branch master) >> >> Right, so in my example origin would be replaced with whatever you >> named the remote for graalvm/graal-core. > > I'm sorry, I don't even know what that sentence means. I don't > remember naming a remote for graalvm/graal-core. How would you do > that? > git remote add origin ssh://git at github.com/graalvm/graal-core.git would create an alias named ?origin? for the remote ssh://git at github.com/graalvm/graal-core.git > >> One problem with git is that there are usually 12 ways to do the >> same thing which complicates giving instructions to someone on how >> to solve a problem. Having multiple remotes makes it more >> complicated as well. If you have your own repo you might never use >> master which can get out of date with upstream. > > That's right, and it has. > >> My personal practice is that origin always refers to the repo I will >> end up pushing to and my personal repo is named after my GitHub user >> name. > > Sure, and that sounds very sensible and much like what I'd like to do, > but I have no idea how to do it. That's the problem: too many choices > and no single standardized set of instructions. > > I'm just about managing to cope, but I'm new to Graal and Eclipse. > Having to deal with git (and github) as well feels like cruel and > unusual punishment. The big reorg of the files feels like I really > must have done something wicked in a previous life. I feel your pain. The rename is unfortunate. However, it?s something out of our control. -Doug From vladimir.kozlov at oracle.com Thu Dec 8 22:49:46 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 8 Dec 2016 14:49:46 -0800 Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler In-Reply-To: References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com> Message-ID: Thank you, Erik It was accident - I forgot to replace ENABLE_AOT with INCLUDE_GRAAL. But it is very good accident :) It showed that Tools.gmk is not needed - nice. Removed and verified that combined AOT+Graal code is still built as before. Thanks, Vladimir On 12/8/16 2:12 AM, Erik Joelsson wrote: > Hello, > > The file hotspot/make/Tools.gmk is dead code at this point and should be > removed. Also stop including it from Gensrc-jdk.vm.compiler.gmk. > > Otherwise it looks ok to me. > > /Erik > > On 2016-12-07 23:10, Vladimir Kozlov wrote: >> https://bugs.openjdk.java.net/browse/JDK-8166417 >> >> It is part of JEP 295: Ahead-of-Time Compilation >> https://bugs.openjdk.java.net/browse/JDK-8166089 >> >> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/ >> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/ >> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/ >> >> This is formal review request for integration Graal-core sources into >> OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to >> integrated Graal-core sources into JDK and add build changes to build >> Graal module. >> >> Note, changes are based on latest jdk9/hs sources which do not have >> latest jigsaw update yet. With jigsaw update small changes will be >> done to module-info.java.extra in java.base: >> >> exports jdk.internal.misc to jdk.vm.compiler; >> + opens jdk.internal.misc to jdk.vm.compiler; >> >> - exports com.sun.crypto.provider to jdk.vm.compiler; >> + opens com.sun.crypto.provider to jdk.vm.compiler; >> >> And changes in top make/GensrcModuleInfo.gmk will not be needed. >> >> >> >> Graal is a dynamic compiler written in Java that integrates with the >> HotSpot JVM. It has a focus on high performance and extensibility. In >> addition, it provides optimized performance for Truffle based >> languages running on the JVM. >> >> https://github.com/graalvm/graal-core >> >> Oracle Labs is developing and maintaining it. >> >> Here are people who contributed into Graal development (sorry if >> someone is missing or misspelled, please speak): >> >> ~70k LOC: Douglas Simon >> ~60k LOC: Lukas Stadler >> ~30k LOC: Thomas Wuerthinger >> ~30k LOC: Tom Rodriguez >> ~30k LOC: Roland Schatz >> ~30k LOC: Josef Eisl >> ~30k LOC: Christian Wimmer >> ~16k LOC: Chris Thalinger >> ~13k LOC: Gilles Duboscq >> ~11k LOC: David Leopoldseder >> ~ 8k LOC: Stefan Anzinger >> ~ 8k LOC: Christian Humer >> >> Other contributors >100 LOC in approximate order of contribution size: >> Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos >> Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec, >> Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef >> Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, Jaroslav Tulach, >> Chris Seaton, Peter B. Kessler, Christian Wirth, Benoit Daloze. >> >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Fri Dec 9 07:07:05 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 8 Dec 2016 23:07:05 -0800 Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler In-Reply-To: <51713578-102F-40C8-9F8A-79988D7674B0@oracle.com> References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com> <51713578-102F-40C8-9F8A-79988D7674B0@oracle.com> Message-ID: Thank you, Mandy On 12/8/16 7:46 PM, Mandy Chung wrote: > >> On Dec 7, 2016, at 2:10 PM, Vladimir Kozlov wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8166417 >> >> It is part of JEP 295: Ahead-of-Time Compilation >> https://bugs.openjdk.java.net/browse/JDK-8166089 >> >> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/ >> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/ > > I reviewed module-info.java.*. > > src/java.base/share/classes/module-info.java.extra > > Now I realized jdk.vm.compiler may be excluded from JDK time at > build/configure time. That explains why you can?t add these > qualified exports to module-info.java. > > As we discussed offline, you can move this file to unix/classes > and if jdk.vm.compiler is not included in the JDK build, the build > tool that generates gensrc/java.base/module-info.java would filter > out these qualified exports. Done. And it works. > > Related to the use of jdk.internal.misc.VM, you mentioned separately > that Graal uses jdk.internal.misc.VM.savedProps to find properties with > GRAAL_OPTION_PROPERTY_PREFIX. Why can?t you use System.getProperties? > savedProps stores the properties that are removed from system properties. > Are Graal?s properties not in system properties? I asked Graal guys. May be Doug can answer. > > >> >> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/ > > src/jdk.vm.compiler/share/classes/module-info.java > > jdk.management requires transitive java.management and so line 28 is > not strictly necessary but no harm to have it: > 28 requires java.management; Then I will keep it. > > make/gensrc/Gensrc-jdk.vm.compiler.gmk > > 131 for i in $$($(FIND) $(GENSRC_DIR) -name '*_OptionDescriptors.java'); do \ > 132 c=$$($(ECHO) $$i | $(SED) 's:.*/jdk\.vm\.compiler/\(.*\)\.java:\1:' | $(TR) '/' '.'); \ > 133 $(ECHO) "provides org.graalvm.compiler.options.OptionDescriptors with $$c;" >> $@; \ > 134 done > > The new syntax for provides is to have one `provides` clause of the same SPI > with comma-separated implementation classes (see [1] for reference) Previous loop in this makefile also produces multiple `provides` of the same SPI. I fixed it too. The output is next for example: provides org.graalvm.compiler.hotspot.CompilerConfigurationFactory with org.graalvm.compiler.hotspot.CoreCompilerConfigurationFactory, org.graalvm.compiler.hotspot.EconomyCompilerConfigurationFactory, ; Looks like build tools excepts ; after , If you are fine with it I will make this change. Thanks, Vladimir > > The build tool temporarily allows multiple `provides` of the same SPI just > for transition. Is it easy to change the above to generate one single `provides` > clauses? I?m okay if you want to file a JBS issue to follow up this separately > after the integration. > > Mandy > [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/java.desktop/share/classes/module-info.java > From doug.simon at oracle.com Fri Dec 9 08:25:40 2016 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 9 Dec 2016 09:25:40 +0100 Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler In-Reply-To: References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com> <51713578-102F-40C8-9F8A-79988D7674B0@oracle.com> Message-ID: <14EDCB93-1A23-4232-96C8-FD2C5A8ADDA5@oracle.com> > On 9 Dec 2016, at 08:07, Vladimir Kozlov wrote: > > Thank you, Mandy > > On 12/8/16 7:46 PM, Mandy Chung wrote: >> >>> On Dec 7, 2016, at 2:10 PM, Vladimir Kozlov wrote: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8166417 >>> >>> It is part of JEP 295: Ahead-of-Time Compilation >>> https://bugs.openjdk.java.net/browse/JDK-8166089 >>> >>> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/ >>> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/ >> >> I reviewed module-info.java.*. >> >> src/java.base/share/classes/module-info.java.extra >> >> Now I realized jdk.vm.compiler may be excluded from JDK time at >> build/configure time. That explains why you can?t add these >> qualified exports to module-info.java. >> >> As we discussed offline, you can move this file to unix/classes >> and if jdk.vm.compiler is not included in the JDK build, the build >> tool that generates gensrc/java.base/module-info.java would filter >> out these qualified exports. > > Done. And it works. > >> >> Related to the use of jdk.internal.misc.VM, you mentioned separately >> that Graal uses jdk.internal.misc.VM.savedProps to find properties with >> GRAAL_OPTION_PROPERTY_PREFIX. Why can?t you use System.getProperties? >> savedProps stores the properties that are removed from system properties. >> Are Graal?s properties not in system properties? > > I asked Graal guys. May be Doug can answer. The reason we use VM.savedProps is that initialization of JVMCI and Graal is lazy (to avoid impacting VM startup) and can take place after application code has been executed. As such, we want to avoid the possibility of tampering with the system properties that configure JVMCI and Graal (i.e., all ?jvmci.*? and ?graal.*? properties). -Doug From vladimir.kozlov at oracle.com Fri Dec 9 09:13:24 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 9 Dec 2016 01:13:24 -0800 Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler In-Reply-To: <637554AA-0A53-4002-A1EA-78F10FCF88CB@oracle.com> References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com> <957e584a-a283-bfda-2b75-1474bbcac7ae@oracle.com> <637554AA-0A53-4002-A1EA-78F10FCF88CB@oracle.com> Message-ID: Thank you, Magnus, for review. I updated webrevs with merge from latest jdk9/hs which now has Jigsaw update. http://cr.openjdk.java.net/~kvn/8166417.v2/top.webrev/ http://cr.openjdk.java.net/~kvn/8166417.v2/jdk.webrev/ http://cr.openjdk.java.net/~kvn/8166417.v2/hotspot.webrev/ Removed hotspot/make/Tools.gmk Removed all overview.html files in graal sources. Fixed hotspot.m4 and changed condition in hotspot.m4 to build graal only on linux-x64. The condition will be changed to check ENABLE_AOT when merged with AOT changes later. Moved module-info.java.extra from share/classes to unix/classes per Mandy suggestion since we will build graal only for AOT. I have to modify make/Javadoc.gmk to avoid next JPRT failure: javadoc: error - No source files for package org.graalvm.compiler.api.collections.src.org.graalvm.compiler.api.collections make[3]: *** [/scratch/opt/jprt/T/P1/232453.vkozlov/s/build/linux-x64/images/docs/api/index.html] Error 1 We did not generate docs for Graal before because its package was com.oracle.graal. I think it is fine to not generate it now too. Please, help if you think make/Javadoc.gmk should be fixed other way. By Mandy request changed code in hotspot/make/gensrc/Gensrc-jdk.vm.compiler.gmk to produce module-info.java.extra with one `provides` clause of the same SPI like next: provides org.graalvm.compiler.hotspot.CompilerConfigurationFactory with org.graalvm.compiler.hotspot.CoreCompilerConfigurationFactory, org.graalvm.compiler.hotspot.EconomyCompilerConfigurationFactory, ; About moving preprocessors .java files into make/src and .test files into hotspot/test. First, they are unit tests and not jtreg. Second, we did experiment during AOT development with tests move but found that it is merge (from graal-core) nightmare and tests execution problems. For now we want sources in JDK exactly match sources in https://github.com/graalvm/graal-core Oracle Labs continue Graal development very actively and we want to be in sync with them without big merge overhead. Thanks, Vladimir On 12/8/16 5:08 AM, Doug Simon wrote: > >> On 8 Dec 2016, at 13:50, Magnus Ihse Bursie wrote: >> >> On 2016-12-07 23:10, Vladimir Kozlov wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8166417 >>> >>> It is part of JEP 295: Ahead-of-Time Compilation >>> https://bugs.openjdk.java.net/browse/JDK-8166089 >>> >>> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/ >>> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/ >>> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/ >> >> * In CompileJavaModules.gmk, there is an *extreme* list of excludes. I note that most of them end in ".test". The proper solution to this is to move the test code to the test/ directory instead of the src/ directory. Also, four of them are the javac processor build tools. These should move to make/src, as other build tools. > > Keeping like it is simplifies pulling changes from https://github.com/graalvm/graal-core. It's possible to write a more sophisticated tool for pulling changes in from the github and places the sources into more openjdk compatible locations. It's up to the HotSpot compiler team whether investing in such a tool makes sense. > >> * In hotspot.m4: AC_MSG_CHECKING must always be matched by a AC_MSG_RESULT, even before AC_MSG_ERROR, otherwise the output will be garbled. >> >> * In hotspot.m4: The test to determine if we should set INCLUDE_GRAAL is incorrect. It only tests for the default value, not for the explicitely set (i.e., HOTSPOT_CHECK_JVM_FEATURE(graal)). >> >> * The file hotspot/make/Tools.gmk is broken ("ifeq ($(ENABLE_AOT), true)" will never evaluate to true). But on the other hand, it is not needed, and should just be removed. :-) >> >> * The file hotspot/src/jdk.vm.compiler/share/classes/overview.html seems a bit dangling. Is this supposed to be included in some Javadoc generation? The html file refers to a projects.jpg and projects.html that does not exist. Maybe it should just be removed? > > I would recommend omitting all graal-core overview.html files in OpenJDK. > >> * Finally, just for the record, I too think the source should be structured according to the OpenJDK praxis. (But I won't fight about this.) > > -Doug > >>> >>> This is formal review request for integration Graal-core sources into OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to integrated Graal-core sources into JDK and add build changes to build Graal module. >>> >>> Note, changes are based on latest jdk9/hs sources which do not have latest jigsaw update yet. With jigsaw update small changes will be done to module-info.java.extra in java.base: >>> >>> exports jdk.internal.misc to jdk.vm.compiler; >>> + opens jdk.internal.misc to jdk.vm.compiler; >>> >>> - exports com.sun.crypto.provider to jdk.vm.compiler; >>> + opens com.sun.crypto.provider to jdk.vm.compiler; >>> >>> And changes in top make/GensrcModuleInfo.gmk will not be needed. >>> >>> >>> >>> Graal is a dynamic compiler written in Java that integrates with the HotSpot JVM. It has a focus on high performance and extensibility. In addition, it provides optimized performance for Truffle based languages running on the JVM. >>> >>> https://github.com/graalvm/graal-core >>> >>> Oracle Labs is developing and maintaining it. >>> >>> Here are people who contributed into Graal development (sorry if someone is missing or misspelled, please speak): >>> >>> ~70k LOC: Douglas Simon >>> ~60k LOC: Lukas Stadler >>> ~30k LOC: Thomas Wuerthinger >>> ~30k LOC: Tom Rodriguez >>> ~30k LOC: Roland Schatz >>> ~30k LOC: Josef Eisl >>> ~30k LOC: Christian Wimmer >>> ~16k LOC: Chris Thalinger >>> ~13k LOC: Gilles Duboscq >>> ~11k LOC: David Leopoldseder >>> ~ 8k LOC: Stefan Anzinger >>> ~ 8k LOC: Christian Humer >>> >>> Other contributors >100 LOC in approximate order of contribution size: >>> Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec, Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, Jaroslav Tulach, Chris Seaton, Peter B. Kessler, Christian Wirth, Benoit Daloze. >>> >>> >>> Thanks, >>> Vladimir >> > From mandy.chung at oracle.com Fri Dec 9 03:46:00 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 8 Dec 2016 19:46:00 -0800 Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler In-Reply-To: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com> References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com> Message-ID: <51713578-102F-40C8-9F8A-79988D7674B0@oracle.com> > On Dec 7, 2016, at 2:10 PM, Vladimir Kozlov wrote: > > https://bugs.openjdk.java.net/browse/JDK-8166417 > > It is part of JEP 295: Ahead-of-Time Compilation > https://bugs.openjdk.java.net/browse/JDK-8166089 > > http://cr.openjdk.java.net/~kvn/8166417/top.webrev/ > http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/ I reviewed module-info.java.*. src/java.base/share/classes/module-info.java.extra Now I realized jdk.vm.compiler may be excluded from JDK time at build/configure time. That explains why you can?t add these qualified exports to module-info.java. As we discussed offline, you can move this file to unix/classes and if jdk.vm.compiler is not included in the JDK build, the build tool that generates gensrc/java.base/module-info.java would filter out these qualified exports. Related to the use of jdk.internal.misc.VM, you mentioned separately that Graal uses jdk.internal.misc.VM.savedProps to find properties with GRAAL_OPTION_PROPERTY_PREFIX. Why can?t you use System.getProperties? savedProps stores the properties that are removed from system properties. Are Graal?s properties not in system properties? > > http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/ src/jdk.vm.compiler/share/classes/module-info.java jdk.management requires transitive java.management and so line 28 is not strictly necessary but no harm to have it: 28 requires java.management; make/gensrc/Gensrc-jdk.vm.compiler.gmk 131 for i in $$($(FIND) $(GENSRC_DIR) -name '*_OptionDescriptors.java'); do \ 132 c=$$($(ECHO) $$i | $(SED) 's:.*/jdk\.vm\.compiler/\(.*\)\.java:\1:' | $(TR) '/' '.'); \ 133 $(ECHO) "provides org.graalvm.compiler.options.OptionDescriptors with $$c;" >> $@; \ 134 done The new syntax for provides is to have one `provides` clause of the same SPI with comma-separated implementation classes (see [1] for reference) The build tool temporarily allows multiple `provides` of the same SPI just for transition. Is it easy to change the above to generate one single `provides` clauses? I?m okay if you want to file a JBS issue to follow up this separately after the integration. Mandy [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/java.desktop/share/classes/module-info.java From aph at redhat.com Fri Dec 9 15:31:02 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 9 Dec 2016 15:31:02 +0000 Subject: Complex rebasing In-Reply-To: <2B5B5798-B4E5-4E5A-89F5-C3533459913F@oracle.com> References: <0e4fdbcb-2880-d546-d81d-739e7108b2ae@redhat.com> <7eb4036e-11d5-461a-e116-bfce21f7cb37@redhat.com> <8F14543C-C5C6-4AB4-8386-B727BF76EE71@oracle.com> <4479e46a-f910-f8d3-eae2-d6f9bc1d1464@redhat.com> <2B5B5798-B4E5-4E5A-89F5-C3533459913F@oracle.com> Message-ID: On 08/12/16 18:47, Tom Rodriguez wrote: > >> On Dec 8, 2016, at 10:39 AM, Andrew Haley wrote: >> >> On 08/12/16 18:29, Tom Rodriguez wrote: >>> git pull ?rebase origin master is the usual command I use >> >> Ah, OK. That is very different from what I did. >> >> I tried "git rebase" but it rebased my checked-out code from my >> personal master, not graalvm's real master. >> >> My remote origin is >> >> https://github.com/theRealAph/graal-core (branch aarch64_graal_misc_fixes) >> >> and I want to rebase from >> >> https://github.com/graalvm/graal-core (branch master) > > Right, so in my example origin would be replaced with whatever you named the remote for graalvm/graal-core. > > One problem with git is that there are usually 12 ways to do the same thing which complicates giving instructions to someone on how to solve a problem. Having multiple remotes makes it more complicated as well. If you have your own repo you might never use master which can get out of date with upstream. My personal practice is that origin always refers to the repo I will end up pushing to and my personal repo is named after my GitHub user name. It's still not working for me. mercury:graal-core $ git remote add graal-master ssh://git at github.com/graalvm/graal-core mercury:graal-core $ git remote -v graal-master ssh://git at github.com/graalvm/graal-core (fetch) graal-master ssh://git at github.com/graalvm/graal-core (push) graal-origin ssh://git at github.com/graalvm/graal-core.git (fetch) graal-origin ssh://git at github.com/graalvm/graal-core.git (push) origin https://github.com/theRealAph/graal-core (fetch) origin https://github.com/theRealAph/graal-core (push) mercury:graal-core $ git pull --rebase origin graal-master fatal: Couldn't find remote ref graal-master Any ideas? Andrew. From aph at redhat.com Fri Dec 9 15:36:14 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 9 Dec 2016 15:36:14 +0000 Subject: Complex rebasing In-Reply-To: <875B6886-669B-4F45-B46A-C0C26E57C532@oracle.com> References: <0e4fdbcb-2880-d546-d81d-739e7108b2ae@redhat.com> <7eb4036e-11d5-461a-e116-bfce21f7cb37@redhat.com> <8F14543C-C5C6-4AB4-8386-B727BF76EE71@oracle.com> <4479e46a-f910-f8d3-eae2-d6f9bc1d1464@redhat.com> <2B5B5798-B4E5-4E5A-89F5-C3533459913F@oracle.com> <175ebea9-8bb9-0f1f-0225-e6e3dd43140a@redhat.com> <875B6886-669B-4F45-B46A-C0C26E57C532@oracle.com> Message-ID: <59b6cf37-75b2-c318-1c24-e6ade7a99891@redhat.com> On 08/12/16 19:15, Doug Simon wrote: > I also have a rather large pending change on a branch where the rename is causing me headaches. Here is what I did after much googling: > > dsimon at kurz-3 ~/g/graal-core> git branch > master > * topic/non-static-options > dsimon at kurz-3 ~/g/graal-core> git fetch -p ssh://git at github.com/graalvm/graal-core.git > dsimon at kurz-3 ~/g/graal-core> git -c diff.renameLimit=3000 merge -s recursive -X rename-threshold=10% -X patience master > > That leaves me in a state where I have about 282 files with conflicts (which I expected). Doesn't seem to do anything: mercury:graal-core $ git fetch -p ssh://git at github.com/graalvm/graal-core.git Enter passphrase for key '/home/aph/.ssh/id_rsa': mercury:graal-core $ git -c diff.renameLimit=3000 merge -s recursive -X rename-threshold=10% -X patience master Unknown option: -c usage: git [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path] [-p|--paginate|--no-pager] [--no-replace-objects] [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS] mercury:graal-core $ git merge -s recursive -X rename-threshold=10% -X patience master Already up-to-date. Andrew. From doug.simon at oracle.com Fri Dec 9 15:50:05 2016 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 9 Dec 2016 16:50:05 +0100 Subject: Complex rebasing In-Reply-To: <59b6cf37-75b2-c318-1c24-e6ade7a99891@redhat.com> References: <0e4fdbcb-2880-d546-d81d-739e7108b2ae@redhat.com> <7eb4036e-11d5-461a-e116-bfce21f7cb37@redhat.com> <8F14543C-C5C6-4AB4-8386-B727BF76EE71@oracle.com> <4479e46a-f910-f8d3-eae2-d6f9bc1d1464@redhat.com> <2B5B5798-B4E5-4E5A-89F5-C3533459913F@oracle.com> <175ebea9-8bb9-0f1f-0225-e6e3dd43140a@redhat.com> <875B6886-669B-4F45-B46A-C0C26E57C532@oracle.com> <59b6cf37-75b2-c318-1c24-e6ade7a99891@redhat.com> Message-ID: I will do the merge for you and push to my github fork which you can then pull from. -Doug > On 9 Dec 2016, at 16:36, Andrew Haley wrote: > > On 08/12/16 19:15, Doug Simon wrote: >> I also have a rather large pending change on a branch where the rename is causing me headaches. Here is what I did after much googling: >> >> dsimon at kurz-3 ~/g/graal-core> git branch >> master >> * topic/non-static-options >> dsimon at kurz-3 ~/g/graal-core> git fetch -p ssh://git at github.com/graalvm/graal-core.git >> dsimon at kurz-3 ~/g/graal-core> git -c diff.renameLimit=3000 merge -s recursive -X rename-threshold=10% -X patience master >> >> That leaves me in a state where I have about 282 files with conflicts (which I expected). > > Doesn't seem to do anything: > > mercury:graal-core $ git fetch -p ssh://git at github.com/graalvm/graal-core.git > Enter passphrase for key '/home/aph/.ssh/id_rsa': > mercury:graal-core $ git -c diff.renameLimit=3000 merge -s recursive -X rename-threshold=10% -X patience master > Unknown option: -c > usage: git [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path] > [-p|--paginate|--no-pager] [--no-replace-objects] > [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] > [--help] COMMAND [ARGS] > mercury:graal-core $ git merge -s recursive -X rename-threshold=10% -X patience master > Already up-to-date. > > Andrew. > From aph at redhat.com Fri Dec 9 15:51:21 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 9 Dec 2016 15:51:21 +0000 Subject: Complex rebasing In-Reply-To: References: <0e4fdbcb-2880-d546-d81d-739e7108b2ae@redhat.com> <7eb4036e-11d5-461a-e116-bfce21f7cb37@redhat.com> <8F14543C-C5C6-4AB4-8386-B727BF76EE71@oracle.com> <4479e46a-f910-f8d3-eae2-d6f9bc1d1464@redhat.com> <2B5B5798-B4E5-4E5A-89F5-C3533459913F@oracle.com> <175ebea9-8bb9-0f1f-0225-e6e3dd43140a@redhat.com> <875B6886-669B-4F45-B46A-C0C26E57C532@oracle.com> <59b6cf37-75b2-c318-1c24-e6ade7a99891@redhat.com> Message-ID: On 09/12/16 15:50, Doug Simon wrote: > I will do the merge for you and push to my github fork which you can then pull from. Umm, alright. Please let me know exactly what you did: I need to learn. Thanks, Andrew. From java at stefan-marr.de Fri Dec 9 16:06:02 2016 From: java at stefan-marr.de (Stefan Marr) Date: Fri, 9 Dec 2016 17:06:02 +0100 Subject: Complex rebasing In-Reply-To: <59b6cf37-75b2-c318-1c24-e6ade7a99891@redhat.com> References: <0e4fdbcb-2880-d546-d81d-739e7108b2ae@redhat.com> <7eb4036e-11d5-461a-e116-bfce21f7cb37@redhat.com> <8F14543C-C5C6-4AB4-8386-B727BF76EE71@oracle.com> <4479e46a-f910-f8d3-eae2-d6f9bc1d1464@redhat.com> <2B5B5798-B4E5-4E5A-89F5-C3533459913F@oracle.com> <175ebea9-8bb9-0f1f-0225-e6e3dd43140a@redhat.com> <875B6886-669B-4F45-B46A-C0C26E57C532@oracle.com> <59b6cf37-75b2-c318-1c24-e6ade7a99891@redhat.com> Message-ID: <31253E15-15C9-494E-A9A0-57E242673C04@stefan-marr.de> Hi Andrew: > On 9 Dec 2016, at 16:36, Andrew Haley wrote: > > mercury:graal-core $ git -c diff.renameLimit=3000 merge -s recursive -X rename-threshold=10% -X patience master > Unknown option: -c > usage: git [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path] > [-p|--paginate|--no-pager] [--no-replace-objects] > [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] > [?help] COMMAND [ARGS] Could it be that your git version is too old? The -c option was available already in git 1.8, which is the earliest version documented on https://git-scm.com/docs/git/1.8.0.2 Best regards Stefan -- Stefan Marr Johannes Kepler Universit?t Linz http://stefan-marr.de/research/ From stepan.sindelar at oracle.com Fri Dec 9 16:08:17 2016 From: stepan.sindelar at oracle.com (Stepan) Date: Fri, 9 Dec 2016 17:08:17 +0100 Subject: Complex rebasing In-Reply-To: References: <0e4fdbcb-2880-d546-d81d-739e7108b2ae@redhat.com> <7eb4036e-11d5-461a-e116-bfce21f7cb37@redhat.com> <8F14543C-C5C6-4AB4-8386-B727BF76EE71@oracle.com> <4479e46a-f910-f8d3-eae2-d6f9bc1d1464@redhat.com> <2B5B5798-B4E5-4E5A-89F5-C3533459913F@oracle.com> Message-ID: On 09/12/16 16:31, Andrew Haley wrote: > On 08/12/16 18:47, Tom Rodriguez wrote: >>> On Dec 8, 2016, at 10:39 AM, Andrew Haley wrote: >>> >>> On 08/12/16 18:29, Tom Rodriguez wrote: >>>> git pull ?rebase origin master is the usual command I use >>> Ah, OK. That is very different from what I did. >>> >>> I tried "git rebase" but it rebased my checked-out code from my >>> personal master, not graalvm's real master. >>> >>> My remote origin is >>> >>> https://github.com/theRealAph/graal-core (branch aarch64_graal_misc_fixes) >>> >>> and I want to rebase from >>> >>> https://github.com/graalvm/graal-core (branch master) >> Right, so in my example origin would be replaced with whatever you named the remote for graalvm/graal-core. >> >> One problem with git is that there are usually 12 ways to do the same thing which complicates giving instructions to someone on how to solve a problem. Having multiple remotes makes it more complicated as well. If you have your own repo you might never use master which can get out of date with upstream. My personal practice is that origin always refers to the repo I will end up pushing to and my personal repo is named after my GitHub user name. > It's still not working for me. > > > mercury:graal-core $ git remote add graal-master ssh://git at github.com/graalvm/graal-core > mercury:graal-core $ git remote -v > graal-master ssh://git at github.com/graalvm/graal-core (fetch) > graal-master ssh://git at github.com/graalvm/graal-core (push) > graal-origin ssh://git at github.com/graalvm/graal-core.git (fetch) > graal-origin ssh://git at github.com/graalvm/graal-core.git (push) > origin https://github.com/theRealAph/graal-core (fetch) > origin https://github.com/theRealAph/graal-core (push) > mercury:graal-core $ git pull --rebase origin graal-master > fatal: Couldn't find remote ref graal-master I believe it should be 'git pull --rebase graal-origin master' -- first the remote name and then the name of the branch you want to pull from that remote. Stepan From doug.simon at oracle.com Fri Dec 9 16:19:10 2016 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 9 Dec 2016 17:19:10 +0100 Subject: Complex rebasing In-Reply-To: References: <0e4fdbcb-2880-d546-d81d-739e7108b2ae@redhat.com> <7eb4036e-11d5-461a-e116-bfce21f7cb37@redhat.com> <8F14543C-C5C6-4AB4-8386-B727BF76EE71@oracle.com> <4479e46a-f910-f8d3-eae2-d6f9bc1d1464@redhat.com> <2B5B5798-B4E5-4E5A-89F5-C3533459913F@oracle.com> <175ebea9-8bb9-0f1f-0225-e6e3dd43140a@redhat.com> <875B6886-669B-4F45-B46A-C0C26E57C532@oracle.com> <59b6cf37-75b2-c318-1c24-e6ade7a99891@redhat.com> Message-ID: <80010596-B26A-446A-81AE-CDB6850C0F77@oracle.com> I?ve done the merge and created a (temporary) PR for it: https://github.com/graalvm/graal-core/pull/240 You can follow the linked command line instructions in that PR to pull it into your aarch64_graal_misc_fixes branch. I think this should do it: git pull https://github.com/dougxc/graal-core.git theRealAph-aarch64_graal_misc_fixes To get to this state, here?s what I did. First was so set renameLimit in my ~/.gitconfig: [merge] renameLimit = 3000 Then: dsimon at kurz-3 ~/h/graal-core> git checkout -b theRealAph-aarch64_graal_misc_fixes master Switched to a new branch 'theRealAph-aarch64_graal_misc_fixes' dsimon at kurz-3 ~/h/graal-core> git pull https://github.com/theRealAph/graal-core.git aarch64_graal_misc_fixes remote: Counting objects: 411, done. remote: Compressing objects: 100% (106/106), done. remote: Total 411 (delta 106), reused 41 (delta 41), pack-reused 101 Receiving objects: 100% (411/411), 104.30 KiB | 0 bytes/s, done. Resolving deltas: 100% (118/118), completed with 25 local objects. From https://github.com/theRealAph/graal-core * branch aarch64_graal_misc_fixes -> FETCH_HEAD Performing inexact rename detection: 100% (6884935/6884935), done. Auto-merging graal/org.graalvm.compiler.truffle.hotspot.test/src/org/graalvm/compiler/truffle/hotspot/test/NativeFunctionInterfaceUnsatisfiedLinkTest.java Auto-merging graal/org.graalvm.compiler.replacements.aarch64/src/org/graalvm/compiler/replacements/aarch64/AArch64GraphBuilderPlugins.java CONFLICT (content): Merge conflict in graal/org.graalvm.compiler.replacements.aarch64/src/org/graalvm/compiler/replacements/aarch64/AArch64GraphBuilderPlugins.java Auto-merging graal/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64SignExtendOp.java ... Auto-merging graal/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/TestProtectedAssembler.java Automatic merge failed; fix conflicts and then commit the result. I then had to move some files: dsimon at kurz-3 ~/h/graal-core> git mv graal/com.oracle.graal.lir.aarch64//src/com/oracle/graal/lir/aarch64/AArch64ArrayEqualsOp.java graal/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/ dsimon at kurz-3 ~/h/graal-core> git mv graal/com.oracle.graal.lir.aarch64//src/com/oracle/graal/lir/aarch64/AArch64ByteSwapOp.java graal/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/ dsimon at kurz-3 ~/h/graal-core> git mv graal/com.oracle.graal.lir.aarch64//src/com/oracle/graal/lir/aarch64/AArch64Unary.java graal/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/ dsimon at kurz-3 ~/h/graal-core> git mv graal/com.oracle.graal.replacements.aarch64/src/com/oracle/graal/replacements/aarch64/AArch64CountTrailingZerosNode.java graal/org.graalvm.compiler.replacements.aarch64/src/org/graalvm/compiler/replacements/aarch64/ After that, I used Eclipse to find and resolve all the conflicts, using the "Organize Imports? mechanism a bit to fix up imports. I then marked all conflicts as resolved using SourceTree[1] - not sure how to do that on the command line but it shouldn?t be hard. Then I committed the merge and pushed to my fork: dsimon at kurz-3 ~/h/graal-core> git push github HEAD I can say the code builds but can?t guarantee nothing broke. -Doug [1] https://www.sourcetreeapp.com > On 9 Dec 2016, at 16:51, Andrew Haley wrote: > > On 09/12/16 15:50, Doug Simon wrote: >> I will do the merge for you and push to my github fork which you can then pull from. > > Umm, alright. Please let me know exactly what you did: I need to learn. > > Thanks, > > Andrew. > From gilles.m.duboscq at oracle.com Fri Dec 9 16:35:47 2016 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Fri, 9 Dec 2016 17:35:47 +0100 Subject: Complex rebasing In-Reply-To: <80010596-B26A-446A-81AE-CDB6850C0F77@oracle.com> References: <0e4fdbcb-2880-d546-d81d-739e7108b2ae@redhat.com> <7eb4036e-11d5-461a-e116-bfce21f7cb37@redhat.com> <8F14543C-C5C6-4AB4-8386-B727BF76EE71@oracle.com> <4479e46a-f910-f8d3-eae2-d6f9bc1d1464@redhat.com> <2B5B5798-B4E5-4E5A-89F5-C3533459913F@oracle.com> <175ebea9-8bb9-0f1f-0225-e6e3dd43140a@redhat.com> <875B6886-669B-4F45-B46A-C0C26E57C532@oracle.com> <59b6cf37-75b2-c318-1c24-e6ade7a99891@redhat.com> <80010596-B26A-446A-81AE-CDB6850C0F77@oracle.com> Message-ID: <0302ce46-312b-5141-ed98-73a9d32762df@oracle.com> On 09/12/16 17:19, Doug Simon wrote: > I?ve done the merge and created a (temporary) PR for it: > > https://github.com/graalvm/graal-core/pull/240 > > You can follow the linked command line instructions in that PR to pull it into your aarch64_graal_misc_fixes branch. I think this should do it: > > git pull https://github.com/dougxc/graal-core.git theRealAph-aarch64_graal_misc_fixes > > To get to this state, here?s what I did. First was so set renameLimit in my ~/.gitconfig: > > [merge] > renameLimit = 3000 > > Then: > > dsimon at kurz-3 ~/h/graal-core> git checkout -b theRealAph-aarch64_graal_misc_fixes master > Switched to a new branch 'theRealAph-aarch64_graal_misc_fixes' > dsimon at kurz-3 ~/h/graal-core> git pull https://github.com/theRealAph/graal-core.git aarch64_graal_misc_fixes > remote: Counting objects: 411, done. > remote: Compressing objects: 100% (106/106), done. > remote: Total 411 (delta 106), reused 41 (delta 41), pack-reused 101 > Receiving objects: 100% (411/411), 104.30 KiB | 0 bytes/s, done. > Resolving deltas: 100% (118/118), completed with 25 local objects. > From https://github.com/theRealAph/graal-core > * branch aarch64_graal_misc_fixes -> FETCH_HEAD > Performing inexact rename detection: 100% (6884935/6884935), done. > Auto-merging graal/org.graalvm.compiler.truffle.hotspot.test/src/org/graalvm/compiler/truffle/hotspot/test/NativeFunctionInterfaceUnsatisfiedLinkTest.java > Auto-merging graal/org.graalvm.compiler.replacements.aarch64/src/org/graalvm/compiler/replacements/aarch64/AArch64GraphBuilderPlugins.java > CONFLICT (content): Merge conflict in graal/org.graalvm.compiler.replacements.aarch64/src/org/graalvm/compiler/replacements/aarch64/AArch64GraphBuilderPlugins.java > Auto-merging graal/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64SignExtendOp.java > ... > Auto-merging graal/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/TestProtectedAssembler.java > Automatic merge failed; fix conflicts and then commit the result. > > I then had to move some files: > > dsimon at kurz-3 ~/h/graal-core> git mv graal/com.oracle.graal.lir.aarch64//src/com/oracle/graal/lir/aarch64/AArch64ArrayEqualsOp.java graal/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/ > dsimon at kurz-3 ~/h/graal-core> git mv graal/com.oracle.graal.lir.aarch64//src/com/oracle/graal/lir/aarch64/AArch64ByteSwapOp.java graal/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/ > dsimon at kurz-3 ~/h/graal-core> > git mv graal/com.oracle.graal.lir.aarch64//src/com/oracle/graal/lir/aarch64/AArch64Unary.java graal/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/ > dsimon at kurz-3 ~/h/graal-core> git mv graal/com.oracle.graal.replacements.aarch64/src/com/oracle/graal/replacements/aarch64/AArch64CountTrailingZerosNode.java graal/org.graalvm.compiler.replacements.aarch64/src/org/graalvm/compiler/replacements/aarch64/ > > After that, I used Eclipse to find and resolve all the conflicts, using the "Organize Imports? mechanism a bit to fix up imports. I then marked all conflicts as resolved using SourceTree[1] - not sure how to do that on the command line but it shouldn?t be hard. Then I committed the merge and pushed to my fork: You can mark files as merged with $ git add > > dsimon at kurz-3 ~/h/graal-core> git push github HEAD > > I can say the code builds but can?t guarantee nothing broke. > > -Doug > > [1] https://www.sourcetreeapp.com > >> On 9 Dec 2016, at 16:51, Andrew Haley wrote: >> >> On 09/12/16 15:50, Doug Simon wrote: >>> I will do the merge for you and push to my github fork which you can then pull from. >> >> Umm, alright. Please let me know exactly what you did: I need to learn. >> >> Thanks, >> >> Andrew. >> > From mandy.chung at oracle.com Fri Dec 9 16:36:46 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 9 Dec 2016 08:36:46 -0800 Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler In-Reply-To: <14EDCB93-1A23-4232-96C8-FD2C5A8ADDA5@oracle.com> References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com> <51713578-102F-40C8-9F8A-79988D7674B0@oracle.com> <14EDCB93-1A23-4232-96C8-FD2C5A8ADDA5@oracle.com> Message-ID: > On Dec 9, 2016, at 12:25 AM, Doug Simon wrote: > > The reason we use VM.savedProps is that initialization of JVMCI and Graal is lazy (to avoid impacting VM startup) and can take place after application code has been executed. As such, we want to avoid the possibility of tampering with the system properties that configure JVMCI and Graal (i.e., all ?jvmci.*? and ?graal.*? properties). You may want to re-examine this as a future follow-up issue that may remove this qualified `opens`. There is no magic with savedProps but it does not have security permission check. Mandy From mandy.chung at oracle.com Fri Dec 9 16:40:04 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 9 Dec 2016 08:40:04 -0800 Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler In-Reply-To: References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com> <51713578-102F-40C8-9F8A-79988D7674B0@oracle.com> Message-ID: > On Dec 8, 2016, at 11:07 PM, Vladimir Kozlov wrote: > >> >> The new syntax for provides is to have one `provides` clause of the same SPI >> with comma-separated implementation classes (see [1] for reference) > > Previous loop in this makefile also produces multiple `provides` of the same SPI. I fixed it too. The output is next for example: > > provides org.graalvm.compiler.hotspot.CompilerConfigurationFactory with > org.graalvm.compiler.hotspot.CoreCompilerConfigurationFactory, > org.graalvm.compiler.hotspot.EconomyCompilerConfigurationFactory, > ; > > Looks like build tools excepts ; after , > If you are fine with it I will make this change. It?s a bug in the build tool and I will file a bug. Is it easy to drop last comma? If not, we could fix this makefile when the build tool is fixed. Mandy From vladimir.kozlov at oracle.com Fri Dec 9 18:40:56 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 9 Dec 2016 10:40:56 -0800 Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler In-Reply-To: References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com> <51713578-102F-40C8-9F8A-79988D7674B0@oracle.com> Message-ID: <9f4e7c10-e9c5-3039-688c-877487d71724@oracle.com> On 12/9/16 8:40 AM, Mandy Chung wrote: > >> On Dec 8, 2016, at 11:07 PM, Vladimir Kozlov wrote: >> >>> >>> The new syntax for provides is to have one `provides` clause of the same SPI >>> with comma-separated implementation classes (see [1] for reference) >> >> Previous loop in this makefile also produces multiple `provides` of the same SPI. I fixed it too. The output is next for example: >> >> provides org.graalvm.compiler.hotspot.CompilerConfigurationFactory with >> org.graalvm.compiler.hotspot.CoreCompilerConfigurationFactory, >> org.graalvm.compiler.hotspot.EconomyCompilerConfigurationFactory, >> ; >> >> Looks like build tools excepts ; after , >> If you are fine with it I will make this change. > > It?s a bug in the build tool and I will file a bug. > > Is it easy to drop last comma? If not, we could fix this makefile when the build tool is fixed. It is very hard to drop the last comma from makefile code. I don't know how to do that. Please, don't fix this in tool and allow such output. Otherwise I will have to return back to produces multiple `provides` of the same SPI. Vladimir > > Mandy > From mandy.chung at oracle.com Fri Dec 9 19:00:00 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 9 Dec 2016 11:00:00 -0800 Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler In-Reply-To: <9f4e7c10-e9c5-3039-688c-877487d71724@oracle.com> References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com> <51713578-102F-40C8-9F8A-79988D7674B0@oracle.com> <9f4e7c10-e9c5-3039-688c-877487d71724@oracle.com> Message-ID: <522D0DEF-CB64-4B47-84B1-3756C90C8876@oracle.com> > On Dec 9, 2016, at 10:40 AM, Vladimir Kozlov wrote: > > > It is very hard to drop the last comma from makefile code. I don't know how to do that. Please, don't fix this in tool and allow such output. > > Otherwise I will have to return back to produces multiple `provides` of the same SPI. OK. What I meant is that the alternative is to clean this up in the future together when the build tool enforces this check. I?m okay with your patch. Mandy From vladimir.kozlov at oracle.com Fri Dec 9 19:15:34 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 9 Dec 2016 11:15:34 -0800 Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler In-Reply-To: <522D0DEF-CB64-4B47-84B1-3756C90C8876@oracle.com> References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com> <51713578-102F-40C8-9F8A-79988D7674B0@oracle.com> <9f4e7c10-e9c5-3039-688c-877487d71724@oracle.com> <522D0DEF-CB64-4B47-84B1-3756C90C8876@oracle.com> Message-ID: <48cbd8cd-66f5-3e09-7a99-793916f6bde6@oracle.com> Thank you, Mandy Vladimir On 12/9/16 11:00 AM, Mandy Chung wrote: > >> On Dec 9, 2016, at 10:40 AM, Vladimir Kozlov wrote: >> >> >> It is very hard to drop the last comma from makefile code. I don't know how to do that. Please, don't fix this in tool and allow such output. >> >> Otherwise I will have to return back to produces multiple `provides` of the same SPI. > > OK. What I meant is that the alternative is to clean this up in the future together when the build tool enforces this check. > > I?m okay with your patch. > > Mandy > From erik.joelsson at oracle.com Sat Dec 10 07:42:35 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Sat, 10 Dec 2016 08:42:35 +0100 Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler In-Reply-To: References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com> <957e584a-a283-bfda-2b75-1474bbcac7ae@oracle.com> <637554AA-0A53-4002-A1EA-78F10FCF88CB@oracle.com> Message-ID: <201e1454-22e4-22fd-0b43-36ffbc83e4d9@oracle.com> This looks ok to me. /Erik On 2016-12-09 10:13, Vladimir Kozlov wrote: > Thank you, Magnus, for review. > > I updated webrevs with merge from latest jdk9/hs which now has Jigsaw > update. > > http://cr.openjdk.java.net/~kvn/8166417.v2/top.webrev/ > http://cr.openjdk.java.net/~kvn/8166417.v2/jdk.webrev/ > http://cr.openjdk.java.net/~kvn/8166417.v2/hotspot.webrev/ > > Removed hotspot/make/Tools.gmk > > Removed all overview.html files in graal sources. > > Fixed hotspot.m4 and changed condition in hotspot.m4 to build graal > only on linux-x64. The condition will be changed to check ENABLE_AOT > when merged with AOT changes later. > > Moved module-info.java.extra from share/classes to unix/classes per > Mandy suggestion since we will build graal only for AOT. > > I have to modify make/Javadoc.gmk to avoid next JPRT failure: > > javadoc: error - No source files for package > org.graalvm.compiler.api.collections.src.org.graalvm.compiler.api.collections > make[3]: *** > [/scratch/opt/jprt/T/P1/232453.vkozlov/s/build/linux-x64/images/docs/api/index.html] > Error 1 > > We did not generate docs for Graal before because its package was > com.oracle.graal. I think it is fine to not generate it now too. > Please, help if you think make/Javadoc.gmk should be fixed other way. > > By Mandy request changed code in > hotspot/make/gensrc/Gensrc-jdk.vm.compiler.gmk to produce > module-info.java.extra with one `provides` clause of the same SPI like > next: > > provides org.graalvm.compiler.hotspot.CompilerConfigurationFactory with > org.graalvm.compiler.hotspot.CoreCompilerConfigurationFactory, > org.graalvm.compiler.hotspot.EconomyCompilerConfigurationFactory, > ; > > > About moving preprocessors .java files into make/src and .test files > into hotspot/test. > > First, they are unit tests and not jtreg. Second, we did experiment > during AOT development with tests move but found that it is merge > (from graal-core) nightmare and tests execution problems. > > For now we want sources in JDK exactly match sources in > https://github.com/graalvm/graal-core > > Oracle Labs continue Graal development very actively and we want to be > in sync with them without big merge overhead. > > Thanks, > Vladimir > > On 12/8/16 5:08 AM, Doug Simon wrote: >> >>> On 8 Dec 2016, at 13:50, Magnus Ihse Bursie >>> wrote: >>> >>> On 2016-12-07 23:10, Vladimir Kozlov wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8166417 >>>> >>>> It is part of JEP 295: Ahead-of-Time Compilation >>>> https://bugs.openjdk.java.net/browse/JDK-8166089 >>>> >>>> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/ >>>> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/ >>>> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/ >>> >>> * In CompileJavaModules.gmk, there is an *extreme* list of excludes. >>> I note that most of them end in ".test". The proper solution to this >>> is to move the test code to the test/ directory instead of the src/ >>> directory. Also, four of them are the javac processor build tools. >>> These should move to make/src, as other build tools. >> >> Keeping like it is simplifies pulling changes from >> https://github.com/graalvm/graal-core. It's possible to write a more >> sophisticated tool for pulling changes in from the github and places >> the sources into more openjdk compatible locations. It's up to the >> HotSpot compiler team whether investing in such a tool makes sense. >> >>> * In hotspot.m4: AC_MSG_CHECKING must always be matched by a >>> AC_MSG_RESULT, even before AC_MSG_ERROR, otherwise the output will >>> be garbled. >>> >>> * In hotspot.m4: The test to determine if we should set >>> INCLUDE_GRAAL is incorrect. It only tests for the default value, not >>> for the explicitely set (i.e., HOTSPOT_CHECK_JVM_FEATURE(graal)). >>> >>> * The file hotspot/make/Tools.gmk is broken ("ifeq ($(ENABLE_AOT), >>> true)" will never evaluate to true). But on the other hand, it is >>> not needed, and should just be removed. :-) >>> >>> * The file hotspot/src/jdk.vm.compiler/share/classes/overview.html >>> seems a bit dangling. Is this supposed to be included in some >>> Javadoc generation? The html file refers to a projects.jpg and >>> projects.html that does not exist. Maybe it should just be removed? >> >> I would recommend omitting all graal-core overview.html files in >> OpenJDK. >> >>> * Finally, just for the record, I too think the source should be >>> structured according to the OpenJDK praxis. (But I won't fight about >>> this.) >> >> -Doug >> >>>> >>>> This is formal review request for integration Graal-core sources >>>> into OpenJDK. AOT compiler uses Graal-core as backend compiler. We >>>> need to integrated Graal-core sources into JDK and add build >>>> changes to build Graal module. >>>> >>>> Note, changes are based on latest jdk9/hs sources which do not have >>>> latest jigsaw update yet. With jigsaw update small changes will be >>>> done to module-info.java.extra in java.base: >>>> >>>> exports jdk.internal.misc to jdk.vm.compiler; >>>> + opens jdk.internal.misc to jdk.vm.compiler; >>>> >>>> - exports com.sun.crypto.provider to jdk.vm.compiler; >>>> + opens com.sun.crypto.provider to jdk.vm.compiler; >>>> >>>> And changes in top make/GensrcModuleInfo.gmk will not be needed. >>>> >>>> >>>> >>>> Graal is a dynamic compiler written in Java that integrates with >>>> the HotSpot JVM. It has a focus on high performance and >>>> extensibility. In addition, it provides optimized performance for >>>> Truffle based languages running on the JVM. >>>> >>>> https://github.com/graalvm/graal-core >>>> >>>> Oracle Labs is developing and maintaining it. >>>> >>>> Here are people who contributed into Graal development (sorry if >>>> someone is missing or misspelled, please speak): >>>> >>>> ~70k LOC: Douglas Simon >>>> ~60k LOC: Lukas Stadler >>>> ~30k LOC: Thomas Wuerthinger >>>> ~30k LOC: Tom Rodriguez >>>> ~30k LOC: Roland Schatz >>>> ~30k LOC: Josef Eisl >>>> ~30k LOC: Christian Wimmer >>>> ~16k LOC: Chris Thalinger >>>> ~13k LOC: Gilles Duboscq >>>> ~11k LOC: David Leopoldseder >>>> ~ 8k LOC: Stefan Anzinger >>>> ~ 8k LOC: Christian Humer >>>> >>>> Other contributors >100 LOC in approximate order of contribution size: >>>> Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos >>>> Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec, >>>> Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, >>>> Josef Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, >>>> Jaroslav Tulach, Chris Seaton, Peter B. Kessler, Christian Wirth, >>>> Benoit Daloze. >>>> >>>> >>>> Thanks, >>>> Vladimir >>> >> From vladimir.kozlov at oracle.com Sat Dec 10 18:07:32 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 10 Dec 2016 10:07:32 -0800 Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler In-Reply-To: <201e1454-22e4-22fd-0b43-36ffbc83e4d9@oracle.com> References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com> <957e584a-a283-bfda-2b75-1474bbcac7ae@oracle.com> <637554AA-0A53-4002-A1EA-78F10FCF88CB@oracle.com> <201e1454-22e4-22fd-0b43-36ffbc83e4d9@oracle.com> Message-ID: Thank you, Erik Vladimir On 12/9/16 11:42 PM, Erik Joelsson wrote: > This looks ok to me. > > /Erik > > > On 2016-12-09 10:13, Vladimir Kozlov wrote: >> Thank you, Magnus, for review. >> >> I updated webrevs with merge from latest jdk9/hs which now has Jigsaw >> update. >> >> http://cr.openjdk.java.net/~kvn/8166417.v2/top.webrev/ >> http://cr.openjdk.java.net/~kvn/8166417.v2/jdk.webrev/ >> http://cr.openjdk.java.net/~kvn/8166417.v2/hotspot.webrev/ >> >> Removed hotspot/make/Tools.gmk >> >> Removed all overview.html files in graal sources. >> >> Fixed hotspot.m4 and changed condition in hotspot.m4 to build graal >> only on linux-x64. The condition will be changed to check ENABLE_AOT >> when merged with AOT changes later. >> >> Moved module-info.java.extra from share/classes to unix/classes per >> Mandy suggestion since we will build graal only for AOT. >> >> I have to modify make/Javadoc.gmk to avoid next JPRT failure: >> >> javadoc: error - No source files for package >> org.graalvm.compiler.api.collections.src.org.graalvm.compiler.api.collections >> >> make[3]: *** >> [/scratch/opt/jprt/T/P1/232453.vkozlov/s/build/linux-x64/images/docs/api/index.html] >> Error 1 >> >> We did not generate docs for Graal before because its package was >> com.oracle.graal. I think it is fine to not generate it now too. >> Please, help if you think make/Javadoc.gmk should be fixed other way. >> >> By Mandy request changed code in >> hotspot/make/gensrc/Gensrc-jdk.vm.compiler.gmk to produce >> module-info.java.extra with one `provides` clause of the same SPI like >> next: >> >> provides org.graalvm.compiler.hotspot.CompilerConfigurationFactory with >> org.graalvm.compiler.hotspot.CoreCompilerConfigurationFactory, >> org.graalvm.compiler.hotspot.EconomyCompilerConfigurationFactory, >> ; >> >> >> About moving preprocessors .java files into make/src and .test files >> into hotspot/test. >> >> First, they are unit tests and not jtreg. Second, we did experiment >> during AOT development with tests move but found that it is merge >> (from graal-core) nightmare and tests execution problems. >> >> For now we want sources in JDK exactly match sources in >> https://github.com/graalvm/graal-core >> >> Oracle Labs continue Graal development very actively and we want to be >> in sync with them without big merge overhead. >> >> Thanks, >> Vladimir >> >> On 12/8/16 5:08 AM, Doug Simon wrote: >>> >>>> On 8 Dec 2016, at 13:50, Magnus Ihse Bursie >>>> wrote: >>>> >>>> On 2016-12-07 23:10, Vladimir Kozlov wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8166417 >>>>> >>>>> It is part of JEP 295: Ahead-of-Time Compilation >>>>> https://bugs.openjdk.java.net/browse/JDK-8166089 >>>>> >>>>> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/ >>>>> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/ >>>>> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/ >>>> >>>> * In CompileJavaModules.gmk, there is an *extreme* list of excludes. >>>> I note that most of them end in ".test". The proper solution to this >>>> is to move the test code to the test/ directory instead of the src/ >>>> directory. Also, four of them are the javac processor build tools. >>>> These should move to make/src, as other build tools. >>> >>> Keeping like it is simplifies pulling changes from >>> https://github.com/graalvm/graal-core. It's possible to write a more >>> sophisticated tool for pulling changes in from the github and places >>> the sources into more openjdk compatible locations. It's up to the >>> HotSpot compiler team whether investing in such a tool makes sense. >>> >>>> * In hotspot.m4: AC_MSG_CHECKING must always be matched by a >>>> AC_MSG_RESULT, even before AC_MSG_ERROR, otherwise the output will >>>> be garbled. >>>> >>>> * In hotspot.m4: The test to determine if we should set >>>> INCLUDE_GRAAL is incorrect. It only tests for the default value, not >>>> for the explicitely set (i.e., HOTSPOT_CHECK_JVM_FEATURE(graal)). >>>> >>>> * The file hotspot/make/Tools.gmk is broken ("ifeq ($(ENABLE_AOT), >>>> true)" will never evaluate to true). But on the other hand, it is >>>> not needed, and should just be removed. :-) >>>> >>>> * The file hotspot/src/jdk.vm.compiler/share/classes/overview.html >>>> seems a bit dangling. Is this supposed to be included in some >>>> Javadoc generation? The html file refers to a projects.jpg and >>>> projects.html that does not exist. Maybe it should just be removed? >>> >>> I would recommend omitting all graal-core overview.html files in >>> OpenJDK. >>> >>>> * Finally, just for the record, I too think the source should be >>>> structured according to the OpenJDK praxis. (But I won't fight about >>>> this.) >>> >>> -Doug >>> >>>>> >>>>> This is formal review request for integration Graal-core sources >>>>> into OpenJDK. AOT compiler uses Graal-core as backend compiler. We >>>>> need to integrated Graal-core sources into JDK and add build >>>>> changes to build Graal module. >>>>> >>>>> Note, changes are based on latest jdk9/hs sources which do not have >>>>> latest jigsaw update yet. With jigsaw update small changes will be >>>>> done to module-info.java.extra in java.base: >>>>> >>>>> exports jdk.internal.misc to jdk.vm.compiler; >>>>> + opens jdk.internal.misc to jdk.vm.compiler; >>>>> >>>>> - exports com.sun.crypto.provider to jdk.vm.compiler; >>>>> + opens com.sun.crypto.provider to jdk.vm.compiler; >>>>> >>>>> And changes in top make/GensrcModuleInfo.gmk will not be needed. >>>>> >>>>> >>>>> >>>>> Graal is a dynamic compiler written in Java that integrates with >>>>> the HotSpot JVM. It has a focus on high performance and >>>>> extensibility. In addition, it provides optimized performance for >>>>> Truffle based languages running on the JVM. >>>>> >>>>> https://github.com/graalvm/graal-core >>>>> >>>>> Oracle Labs is developing and maintaining it. >>>>> >>>>> Here are people who contributed into Graal development (sorry if >>>>> someone is missing or misspelled, please speak): >>>>> >>>>> ~70k LOC: Douglas Simon >>>>> ~60k LOC: Lukas Stadler >>>>> ~30k LOC: Thomas Wuerthinger >>>>> ~30k LOC: Tom Rodriguez >>>>> ~30k LOC: Roland Schatz >>>>> ~30k LOC: Josef Eisl >>>>> ~30k LOC: Christian Wimmer >>>>> ~16k LOC: Chris Thalinger >>>>> ~13k LOC: Gilles Duboscq >>>>> ~11k LOC: David Leopoldseder >>>>> ~ 8k LOC: Stefan Anzinger >>>>> ~ 8k LOC: Christian Humer >>>>> >>>>> Other contributors >100 LOC in approximate order of contribution size: >>>>> Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos >>>>> Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec, >>>>> Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, >>>>> Josef Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, >>>>> Jaroslav Tulach, Chris Seaton, Peter B. Kessler, Christian Wirth, >>>>> Benoit Daloze. >>>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>> >>> > From java at stefan-marr.de Mon Dec 12 10:33:50 2016 From: java at stefan-marr.de (Stefan Marr) Date: Mon, 12 Dec 2016 11:33:50 +0100 Subject: [MoreVMs'17] Call for Contributions: 1st Workshop on Modern Language Runtimes, Ecosystems, and VMs at 2017 Message-ID: ============================================================================ Call for Papers: MoreVMs?17 1st Workshop on Modern Language Runtimes, Ecosystems, and VMs Co-located with 2017 April, 2017, Brussels, Belgium http://2017.programming-conference.org/track/MoreVMs-2017-papers ============================================================================ The MoreVMs'17 workshop aims bring together programmers from industry and academy to discuss the design, implementation, and usage of modern languages and runtimes. This includes aspects such as reuse of language runtimes, modular implementation, or design and compilation strategies to target existing runtimes. The main goals of the workshop is to bring together both researchers and practitioners and facilitate effective sharing of their respective experiences and ideas on how languages and runtimes are utilized and where they need to improve further. We welcome presentation proposals in the form of extended abstracts discussing experiences, work-in-progress, as well as future visions from the academic as well as industrial perspective. Relevant topics include, but are definitely not limited to, the following: - extensible VM design (compiler- or interpreter-based VMs) - reusable runtime components (e.g. interpreters, garbage collectors, intermediate representations) - static and dynamic compiler techniques - techniques for compilation to high-level languages such as JavaScript - runtimes and mechanisms for interoperability between languages - tooling support (e.g. debugging, profiling, etc.) - programming language development environments and virtual machines - case studies of existing language implementations, virtual machines, and runtime components (e.g. design choices, tradeoffs, etc.) - language implementation challenges and trade-offs (e.g. performance, completeness, etc.) - surveys and applications usage reports to understand runtime usage in the wild - surveys on frameworks and their impact on runtime usage - new research ideas on how we want to build languages in the future ### Workshop Format and Submissions This workshop welcomes the presentation and discussion of new ideas and emerging problems to facilitate interaction among workshop participants and exchange of ideas. We accept presentation proposals in the form of extended abstracts (1-2 pages). Accepted abstracts will be published on the workshop's website before the workshop date. For preparing your abstract, please use the provided author kit: https://github.com/smarr/morevms17-author-kit. It is based on the ACM SIGPLAN Conference Format with 10 point font, and includes a Creative Commons License, which will allow us to publish the abstract on the workshop web site. Please submit abstracts through http://ssw.jku.at/morevms17/ ### Important Dates Abstract submission: 15 February 2017 Author notification: 01 March 2017 Workshop: 3 April 2017 All deadlines are Anywhere on Earth (AoE), i.e. GMT/UTC?12:00 hour ### Program Committee Matthias Grimmer, Oracle Labs Christine H. Flood, Red Hat Tony Hosking, Australian National University Hannes Payer, Google Tiark Rompf, Purdue University Jeremy Singer, University of Glasgow Mark Stoodley, IBM Canada Sam Tobin-Hochstadt, Indiana University ### Workshop Organizers Laurence Tratt, King's College London, United Kingdom Adam Welc, Oracle Labs, United States Stefan Marr, Johannes Kepler University Linz, Austria From aph at redhat.com Mon Dec 12 18:33:59 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 12 Dec 2016 18:33:59 +0000 Subject: Pull request: Many small AArch64 fixes #224 Message-ID: <51332ec1-57b1-9394-9bd1-8cda7e966127@redhat.com> All done: passes Graal and jcstress tests on Aarch64. Thanks to Doug for sorting out the merge. Andrew. From aph at redhat.com Thu Dec 15 12:34:44 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 15 Dec 2016 12:34:44 +0000 Subject: Graal day-to-day process Message-ID: I now have my grand AArch64 pull request out for review. So, on to the next thing. Whatever I do will depend on the big AArch64 patch because Graal crashes without it. But I don't want to add anything to that branch, and I'm waiting for the big patch to be pulled then I'll base my new work on that. So what do people do in this situation? Work in a local repo based on a branch, create a new branch based on the big patch, or what? Thanks, Andrew. From roland.schatz at oracle.com Thu Dec 15 13:03:07 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Thu, 15 Dec 2016 14:03:07 +0100 Subject: Graal day-to-day process In-Reply-To: References: Message-ID: On 12/15/2016 01:34 PM, Andrew Haley wrote: > I now have my grand AArch64 pull request out for review. > > So, on to the next thing. Whatever I do will depend on the big > AArch64 patch because Graal crashes without it. But I don't want > to add anything to that branch, and I'm waiting for the big patch > to be pulled then I'll base my new work on that. > > So what do people do in this situation? Work in a local repo > based on a branch, create a new branch based on the big patch, > or what? I usually just create a new branch based on the not-yet-merged branch, and when the merge happens, I rebase to master. That usually works without conflicts. - Roland > > Thanks, > > Andrew. From dawclarke at gmail.com Fri Dec 16 20:08:04 2016 From: dawclarke at gmail.com (David Clarke) Date: Sat, 17 Dec 2016 07:08:04 +1100 Subject: Query from PhD student Message-ID: Good People, I am trying to understand the class MembarNode (com.oracle.graal.nodes) in the ?extended" folder. The integer field barriers is clearly related to the type of memory barrier to be inserted. However, I can?t find any documentation that tells me whether the value is intended to uniquely identify the type of memory barrier or is bit significant. Please can you point me to the class in which this is defined. Thank you. David (Knobby) CLARKE 6 Coptfold Court Glen Waverley VIC 3150 Australia +61 408 793 793 dawclarke at gmail.com From aph at redhat.com Fri Dec 16 23:27:46 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 16 Dec 2016 23:27:46 +0000 Subject: Query from PhD student In-Reply-To: References: Message-ID: On 16/12/16 20:08, David Clarke wrote: > Good People, > > I am trying to understand the class MembarNode (com.oracle.graal.nodes) in the ?extended" folder. > > The integer field barriers is clearly related to the type of memory barrier to be inserted. However, I can?t find any documentation that tells me whether the value is intended to uniquely identify the type of memory barrier or is bit significant. Please can you point me to the class in which this is defined. The base definitions are here: http://hg.openjdk.java.net/jdk9/hs/hotspot/file/66e2100be052/src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/MemoryBarriers.java Andrew. From vladimir.kozlov at oracle.com Mon Dec 19 21:50:01 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 19 Dec 2016 13:50:01 -0800 Subject: RFR(S) 8169938: [AOT] SIGSEGV at ~BufferBlob::vtable chunks In-Reply-To: References: Message-ID: <7bfd84b2-9a26-8a17-3646-906e73f86fee@oracle.com> Thank you, Dean, for finding the cause. Looks good to me. CCing to Graal since it affects it. I am curious why Labs did not hit it before. Thanks, Vladimir On 12/19/16 1:22 PM, dean.long at oracle.com wrote: > AOT code, like C2 code, can reallocate objects during deoptimization, > because of escape analysis. To support this, we need to set the > "return_oop" flag on the scope correctly. > > https://bugs.openjdk.java.net/browse/JDK-8169938 > http://cr.openjdk.java.net/~dlong/8169938/webrev/ > > dl > From tom.rodriguez at oracle.com Tue Dec 20 21:44:07 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 20 Dec 2016 13:44:07 -0800 Subject: RFR(S) 8169938: [AOT] SIGSEGV at ~BufferBlob::vtable chunks In-Reply-To: <7bfd84b2-9a26-8a17-3646-906e73f86fee@oracle.com> References: <7bfd84b2-9a26-8a17-3646-906e73f86fee@oracle.com> Message-ID: <5936E0A9-A6CB-4436-BCEC-CA0D3E2B8D71@oracle.com> > On Dec 19, 2016, at 1:50 PM, Vladimir Kozlov wrote: > > Thank you, Dean, for finding the cause. > > Looks good to me. > > CCing to Graal since it affects it. I am curious why Labs did not hit it before. Not sure either, though AOT?s been running for a while without seeing it either. I?m a unsure that this is the right logic though. If you look at how C2 is setting this flag it?s driven by lower level code generation details. Basically it?s looking at the underlying call object at the debug info site to determine if that call is returning an oop. Will that produce the same answer as checking the return type of the call? For any site which is a normal method invoke I think it will but what about other calls like a vm entry point? tom > > Thanks, > Vladimir > > On 12/19/16 1:22 PM, dean.long at oracle.com wrote: >> AOT code, like C2 code, can reallocate objects during deoptimization, >> because of escape analysis. To support this, we need to set the >> "return_oop" flag on the scope correctly. >> >> https://bugs.openjdk.java.net/browse/JDK-8169938 >> http://cr.openjdk.java.net/~dlong/8169938/webrev/ >> >> dl >> From vladimir.kozlov at oracle.com Tue Dec 20 23:34:34 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 20 Dec 2016 15:34:34 -0800 Subject: RFR(S) 8169938: [AOT] SIGSEGV at ~BufferBlob::vtable chunks In-Reply-To: <5936E0A9-A6CB-4436-BCEC-CA0D3E2B8D71@oracle.com> References: <7bfd84b2-9a26-8a17-3646-906e73f86fee@oracle.com> <5936E0A9-A6CB-4436-BCEC-CA0D3E2B8D71@oracle.com> Message-ID: <171869bf-ae4a-b133-97f6-0c36918115b2@oracle.com> On 12/20/16 1:44 PM, Tom Rodriguez wrote: > >> On Dec 19, 2016, at 1:50 PM, Vladimir Kozlov wrote: >> >> Thank you, Dean, for finding the cause. >> >> Looks good to me. >> >> CCing to Graal since it affects it. I am curious why Labs did not hit it before. > > Not sure either, though AOT?s been running for a while without seeing it either. > > I?m a unsure that this is the right logic though. If you look at how C2 is setting this flag it?s driven by lower level code generation details. Basically it?s looking at the underlying call object at the debug info site to determine if that call is returning an oop. Will that produce the same answer as checking the return type of the call? For any site which is a normal method invoke I think it will but what about other calls like a vm entry point? I agree, C2 is checking is_ptr() which include metadata pointers. In such case we need help from you. I think pointer return information can be recorded in DebugInfo or Call class. Thanks, Vladimir > > tom > >> >> Thanks, >> Vladimir >> >> On 12/19/16 1:22 PM, dean.long at oracle.com wrote: >>> AOT code, like C2 code, can reallocate objects during deoptimization, >>> because of escape analysis. To support this, we need to set the >>> "return_oop" flag on the scope correctly. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8169938 >>> http://cr.openjdk.java.net/~dlong/8169938/webrev/ >>> >>> dl >>> > From tom.rodriguez at oracle.com Wed Dec 21 04:30:53 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 20 Dec 2016 20:30:53 -0800 Subject: RFR(S) 8169938: [AOT] SIGSEGV at ~BufferBlob::vtable chunks In-Reply-To: <215fa525-0aeb-f20a-b9d4-7449a28565a0@oracle.com> References: <7bfd84b2-9a26-8a17-3646-906e73f86fee@oracle.com> <5936E0A9-A6CB-4436-BCEC-CA0D3E2B8D71@oracle.com> <171869bf-ae4a-b133-97f6-0c36918115b2@oracle.com> <215fa525-0aeb-f20a-b9d4-7449a28565a0@oracle.com> Message-ID: <1182298D-0703-4F6C-A0B6-D23865233792@oracle.com> > On Dec 20, 2016, at 7:01 PM, dean.long at oracle.com wrote: > > On 12/20/16 3:34 PM, Vladimir Kozlov wrote: > >> On 12/20/16 1:44 PM, Tom Rodriguez wrote: >>> >>>> On Dec 19, 2016, at 1:50 PM, Vladimir Kozlov wrote: >>>> >>>> Thank you, Dean, for finding the cause. >>>> >>>> Looks good to me. >>>> >>>> CCing to Graal since it affects it. I am curious why Labs did not hit it before. >>> >>> Not sure either, though AOT?s been running for a while without seeing it either. >>> >>> I?m a unsure that this is the right logic though. If you look at how C2 is setting this flag it?s driven by lower level code generation details. Basically it?s looking at the underlying call object at the debug info site to determine if that call is returning an oop. Will that produce the same answer as checking the return type of the call? For any site which is a normal method invoke I think it will but what about other calls like a vm entry point? >> > > Is there a VM entry point that returns an oop in a register? From the perspective of code generation the allocation paths do this. But to answer my own question, I think c2 may be setting it to true under conditions where it will never be consulted. Any VM entry point that actually returns an oop uses a stub to handle it and passes the value through vm_result so it?s handled across the safe point. You can't actually stop at the call site pc when you deoptimize. I think a correct value is only required for real Java invoke sites. > >> I agree, C2 is checking is_ptr() which include metadata pointers. >> > > It must be an oop, not metadata: > > oop result = deoptee.saved_oop_result(&map); > assert(result == NULL || result->is_oop(), "must be oop?); The code is using isa_ptr() so any pointer return value will set it to true which is clearly wrong. I suspect any path which might set this incorrectly simply will never consult the value. So I think your fix for JVMCI looks right. And the existing C2 code is benignly wrong. tom > > dl > >> In such case we need help from you. I think pointer return information can be recorded in DebugInfo or Call class. >> >> Thanks, >> Vladimir >> >>> >>> tom >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 12/19/16 1:22 PM, dean.long at oracle.com wrote: >>>>> AOT code, like C2 code, can reallocate objects during deoptimization, >>>>> because of escape analysis. To support this, we need to set the >>>>> "return_oop" flag on the scope correctly. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8169938 >>>>> http://cr.openjdk.java.net/~dlong/8169938/webrev/ >>>>> >>>>> dl From dean.long at oracle.com Tue Dec 20 19:36:04 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 20 Dec 2016 11:36:04 -0800 Subject: RFR(S) 8169938: [AOT] SIGSEGV at ~BufferBlob::vtable chunks In-Reply-To: <7bfd84b2-9a26-8a17-3646-906e73f86fee@oracle.com> References: <7bfd84b2-9a26-8a17-3646-906e73f86fee@oracle.com> Message-ID: Thanks Vladimir. dl On 12/19/16 1:50 PM, Vladimir Kozlov wrote: > Thank you, Dean, for finding the cause. > > Looks good to me. > > CCing to Graal since it affects it. I am curious why Labs did not hit > it before. > > Thanks, > Vladimir > > On 12/19/16 1:22 PM, dean.long at oracle.com wrote: >> AOT code, like C2 code, can reallocate objects during deoptimization, >> because of escape analysis. To support this, we need to set the >> "return_oop" flag on the scope correctly. >> >> https://bugs.openjdk.java.net/browse/JDK-8169938 >> http://cr.openjdk.java.net/~dlong/8169938/webrev/ >> >> dl >> From dean.long at oracle.com Wed Dec 21 03:01:52 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 20 Dec 2016 19:01:52 -0800 Subject: RFR(S) 8169938: [AOT] SIGSEGV at ~BufferBlob::vtable chunks In-Reply-To: <171869bf-ae4a-b133-97f6-0c36918115b2@oracle.com> References: <7bfd84b2-9a26-8a17-3646-906e73f86fee@oracle.com> <5936E0A9-A6CB-4436-BCEC-CA0D3E2B8D71@oracle.com> <171869bf-ae4a-b133-97f6-0c36918115b2@oracle.com> Message-ID: <215fa525-0aeb-f20a-b9d4-7449a28565a0@oracle.com> On 12/20/16 3:34 PM, Vladimir Kozlov wrote: > On 12/20/16 1:44 PM, Tom Rodriguez wrote: >> >>> On Dec 19, 2016, at 1:50 PM, Vladimir Kozlov >>> wrote: >>> >>> Thank you, Dean, for finding the cause. >>> >>> Looks good to me. >>> >>> CCing to Graal since it affects it. I am curious why Labs did not >>> hit it before. >> >> Not sure either, though AOT?s been running for a while without seeing >> it either. >> >> I?m a unsure that this is the right logic though. If you look at how >> C2 is setting this flag it?s driven by lower level code generation >> details. Basically it?s looking at the underlying call object at the >> debug info site to determine if that call is returning an oop. Will >> that produce the same answer as checking the return type of the >> call? For any site which is a normal method invoke I think it will >> but what about other calls like a vm entry point? > Is there a VM entry point that returns an oop in a register? > I agree, C2 is checking is_ptr() which include metadata pointers. > It must be an oop, not metadata: oop result = deoptee.saved_oop_result(&map); assert(result == NULL || result->is_oop(), "must be oop"); dl > In such case we need help from you. I think pointer return information > can be recorded in DebugInfo or Call class. > > Thanks, > Vladimir > >> >> tom >> >>> >>> Thanks, >>> Vladimir >>> >>> On 12/19/16 1:22 PM, dean.long at oracle.com wrote: >>>> AOT code, like C2 code, can reallocate objects during deoptimization, >>>> because of escape analysis. To support this, we need to set the >>>> "return_oop" flag on the scope correctly. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8169938 >>>> http://cr.openjdk.java.net/~dlong/8169938/webrev/ >>>> >>>> dl >>>> >> From dean.long at oracle.com Wed Dec 21 04:35:29 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 20 Dec 2016 20:35:29 -0800 Subject: RFR(S) 8169938: [AOT] SIGSEGV at ~BufferBlob::vtable chunks In-Reply-To: <1182298D-0703-4F6C-A0B6-D23865233792@oracle.com> References: <7bfd84b2-9a26-8a17-3646-906e73f86fee@oracle.com> <5936E0A9-A6CB-4436-BCEC-CA0D3E2B8D71@oracle.com> <171869bf-ae4a-b133-97f6-0c36918115b2@oracle.com> <215fa525-0aeb-f20a-b9d4-7449a28565a0@oracle.com> <1182298D-0703-4F6C-A0B6-D23865233792@oracle.com> Message-ID: Thanks Tom. dl On 12/20/16 8:30 PM, Tom Rodriguez wrote: > >> On Dec 20, 2016, at 7:01 PM, dean.long at oracle.com >> wrote: >> >> On 12/20/16 3:34 PM, Vladimir Kozlov wrote: >> >>> On 12/20/16 1:44 PM, Tom Rodriguez wrote: >>>> >>>>> On Dec 19, 2016, at 1:50 PM, Vladimir Kozlov >>>>> > >>>>> wrote: >>>>> >>>>> Thank you, Dean, for finding the cause. >>>>> >>>>> Looks good to me. >>>>> >>>>> CCing to Graal since it affects it. I am curious why Labs did not >>>>> hit it before. >>>> >>>> Not sure either, though AOT?s been running for a while without >>>> seeing it either. >>>> >>>> I?m a unsure that this is the right logic though. If you look at >>>> how C2 is setting this flag it?s driven by lower level code >>>> generation details. Basically it?s looking at the underlying call >>>> object at the debug info site to determine if that call is >>>> returning an oop. Will that produce the same answer as checking >>>> the return type of the call? For any site which is a normal method >>>> invoke I think it will but what about other calls like a vm entry >>>> point? >>> >> >> Is there a VM entry point that returns an oop in a register? > > From the perspective of code generation the allocation paths do this. > But to answer my own question, I think c2 may be setting it to true > under conditions where it will never be consulted. Any VM entry point > that actually returns an oop uses a stub to handle it and passes the > value through vm_result so it?s handled across the safe point. You > can't actually stop at the call site pc when you deoptimize. I think > a correct value is only required for real Java invoke sites. > >> >>> I agree, C2 is checking is_ptr() which include metadata pointers. >>> >> >> It must be an oop, not metadata: >> >> oop result = deoptee.saved_oop_result(&map); >> assert(result == NULL || result->is_oop(), "must be oop?); > > The code is using isa_ptr() so any pointer return value will set it to > true which is clearly wrong. I suspect any path which might set this > incorrectly simply will never consult the value. > > So I think your fix for JVMCI looks right. And the existing C2 code > is benignly wrong. > > tom > >> >> dl >> >>> In such case we need help from you. I think pointer return >>> information can be recorded in DebugInfo or Call class. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> tom >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 12/19/16 1:22 PM, dean.long at oracle.com >>>>> wrote: >>>>>> AOT code, like C2 code, can reallocate objects during deoptimization, >>>>>> because of escape analysis. To support this, we need to set the >>>>>> "return_oop" flag on the scope correctly. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8169938 >>>>>> http://cr.openjdk.java.net/~dlong/8169938/webrev/ >>>>>> >>>>>> dl >