From doug.simon at oracle.com Tue Jul 3 08:22:50 2018 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 3 Jul 2018 10:22:50 +0200 Subject: JVMCI 0.46 released Message-ID: <3F0211EA-48C3-43F5-B74D-2FAE947F0931@oracle.com> For about the last half year, we've been working on changes to JVMCI, Graal and SVM to allow for Graal to be compiled into an SVM image and then used in HotSpot as a shared library[1]. We call this effort "libgraal". This improves a number of aspects when deploying Graal as a JIT in HotSpot: * Faster startup. * Fast compilation speed from startup (Graal is already compiled). * Graal memory usage is disjoint from the HotSpot heap (SVM has its own heap and GC). * Avoids Graal polluting profiles of JDK code. To implement this, changes[2] were needed to JVMCI, mainly to avoid exposing raw Object values that now cross the HotSpot-SVM boundary. Making these changes backwards compatible would have resulted in very ugly API in parts. Combined with the fact that JVMCI is still an internal and experimental API, we opted to forego backwards compatibility. This means that as of Graal commit 9423a9eccc4[3], upstream/GitHub Graal will work with JVMCI JDK 8[4][5] and JDK 11-ea+20[6]; for JDK 9 and JDK 10 only the Graal version included in those JDKs will work. The compiler/README.md document has also been updated to note these new requirements. -Doug [1] https://bugs.openjdk.java.net/browse/JDK-8204853 [2] https://bugs.openjdk.java.net/browse/JDK-8204855 [3] https://github.com/oracle/graal/commit/9423a9eccc46a2e6cc4cfd76da81bec9837054e6 [4] https://github.com/graalvm/openjdk8-jvmci-builder/releases/tag/jvmci-0.46 [5] http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html [6] http://jdk.java.net/11/ From aph at redhat.com Tue Jul 10 08:31:33 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 10 Jul 2018 09:31:33 +0100 Subject: Will there be any "Graal Sync" for JDK 11 repo In-Reply-To: References: Message-ID: <74d8e82e-b9e0-f086-ad42-2188ed19450f@redhat.com> On 07/10/2018 04:24 AM, Zhongwei Yao wrote: > If not, shall I manually fix it in JDK11? Yes. Propose it and I'll review it. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Zhongwei.Yao at arm.com Tue Jul 10 10:49:34 2018 From: Zhongwei.Yao at arm.com (Zhongwei Yao) Date: Tue, 10 Jul 2018 10:49:34 +0000 Subject: Will there be any "Graal Sync" for JDK 11 repo In-Reply-To: <74d8e82e-b9e0-f086-ad42-2188ed19450f@redhat.com> References: , <74d8e82e-b9e0-f086-ad42-2188ed19450f@redhat.com> Message-ID: Sure, I will. -- Best regards, Zhongwei ________________________________________ From: Andrew Haley Sent: Tuesday, July 10, 2018 4:31 PM To: Zhongwei Yao; graal-dev at openjdk.java.net; hotspot-dev Cc: nd Subject: Re: Will there be any "Graal Sync" for JDK 11 repo On 07/10/2018 04:24 AM, Zhongwei Yao wrote: > If not, shall I manually fix it in JDK11? Yes. Propose it and I'll review it. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dean.long at oracle.com Wed Jul 11 22:33:13 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 11 Jul 2018 15:33:13 -0700 Subject: [11] 8181855: [Graal] runtime/ReservedStack/ReservedStackTest.java triggers: assert(thread->deopt_mark() == __null) failed: no stack overflow from deopt blob/uncommon trap Message-ID: <9ac1922e-bb48-ac6c-9f1c-62d7712b2945@oracle.com> http://cr.openjdk.java.net/~dlong/8181855/webrev/ https://bugs.openjdk.java.net/browse/JDK-8181855 This change adds "reserved stack" support to Graal for SPARC, x64, and AArch64. This change has already gone upstream into Graal, except for the AOT change in aotCodeHeap.cpp. dl* * From vladimir.kozlov at oracle.com Wed Jul 11 23:20:35 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 11 Jul 2018 16:20:35 -0700 Subject: [11] 8181855: [Graal] runtime/ReservedStack/ReservedStackTest.java triggers: assert(thread->deopt_mark() == __null) failed: no stack overflow from deopt blob/uncommon trap In-Reply-To: <9ac1922e-bb48-ac6c-9f1c-62d7712b2945@oracle.com> References: <9ac1922e-bb48-ac6c-9f1c-62d7712b2945@oracle.com> Message-ID: Looks good. Vladimir On 7/11/18 3:33 PM, dean.long at oracle.com wrote: > http://cr.openjdk.java.net/~dlong/8181855/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8181855 > > This change adds "reserved stack" support to Graal for SPARC, x64, and AArch64. > This change has already gone upstream into Graal, except for the AOT change in aotCodeHeap.cpp. > > dl* > * From dean.long at oracle.com Thu Jul 12 17:07:18 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 12 Jul 2018 10:07:18 -0700 Subject: [11] 8181855: [Graal] runtime/ReservedStack/ReservedStackTest.java triggers: assert(thread->deopt_mark() == __null) failed: no stack overflow from deopt blob/uncommon trap In-Reply-To: References: <9ac1922e-bb48-ac6c-9f1c-62d7712b2945@oracle.com> Message-ID: <24cf7e66-b6c3-2a70-7733-fe92df5d3b12@oracle.com> Unfortunately, when compiler/graalunit/HotspotTest.java runs my test in JDK, org.graalvm.compiler.test.SubprocessUtil thinks the command-line is empty, causing a failure.? Vladimir or Katya, is there anything special I need to do to run Graal unit tests in JDK? dl On 7/11/18 4:20 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > On 7/11/18 3:33 PM, dean.long at oracle.com wrote: >> http://cr.openjdk.java.net/~dlong/8181855/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8181855 >> >> This change adds "reserved stack" support to Graal for SPARC, x64, >> and AArch64. >> This change has already gone upstream into Graal, except for the AOT >> change in aotCodeHeap.cpp. >> >> dl* >> * From tom.rodriguez at oracle.com Thu Jul 12 17:28:11 2018 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 12 Jul 2018 10:28:11 -0700 Subject: [11] 8181855: [Graal] runtime/ReservedStack/ReservedStackTest.java triggers: assert(thread->deopt_mark() == __null) failed: no stack overflow from deopt blob/uncommon trap In-Reply-To: <24cf7e66-b6c3-2a70-7733-fe92df5d3b12@oracle.com> References: <9ac1922e-bb48-ac6c-9f1c-62d7712b2945@oracle.com> <24cf7e66-b6c3-2a70-7733-fe92df5d3b12@oracle.com> Message-ID: <85e1ae25-e565-d044-6242-107ec33fb2ba@oracle.com> dean.long at oracle.com wrote on 7/12/18 10:07 AM: > Unfortunately, when compiler/graalunit/HotspotTest.java runs my test in > JDK, org.graalvm.compiler.test.SubprocessUtil thinks the command-line is > empty, causing a failure. Vladimir or Katya, is there anything special > I need to do to run Graal unit tests in JDK? The tests that use SubprocessUtil in the JDK don't work so they are disabled in ProblemList-graal.txt. Here's my edit to that file from the Graal update I was preparing. It's also restores the regular ReservedStackTestCompiler test. diff -r e0028bb6dd3d test/hotspot/jtreg/ProblemList-graal.txt --- a/test/hotspot/jtreg/ProblemList-graal.txt +++ b/test/hotspot/jtreg/ProblemList-graal.txt @@ -67,8 +67,6 @@ gc/TestNUMAPageSize.java 8194949 generic-all -runtime/ReservedStack/ReservedStackTestCompiler.java 8181855 generic-all - serviceability/jvmti/GetModulesInfo/JvmtiGetAllModulesTest.java 8195156 generic-all compiler/compilercontrol/directives/LogTest.java 8181753 generic-all @@ -174,6 +172,7 @@ org.graalvm.compiler.hotspot.test.CompilationWrapperTest 8205081 org.graalvm.compiler.hotspot.test.HsErrLogTest 8205081 org.graalvm.compiler.hotspot.test.OptionsInFileTest 8205081 +org.graalvm.compiler.hotspot.test.ReservedStackAccessTest 8205081 org.graalvm.compiler.replacements.test.classfile.ClassfileBytecodeProviderTest 8205081 org.graalvm.compiler.replacements.test.classfile.RedefineIntrinsicTest 8205081 > > dl > > On 7/11/18 4:20 PM, Vladimir Kozlov wrote: >> Looks good. >> >> Vladimir >> >> On 7/11/18 3:33 PM, dean.long at oracle.com wrote: >>> http://cr.openjdk.java.net/~dlong/8181855/webrev/ >>> https://bugs.openjdk.java.net/browse/JDK-8181855 >>> >>> This change adds "reserved stack" support to Graal for SPARC, x64, >>> and AArch64. >>> This change has already gone upstream into Graal, except for the AOT >>> change in aotCodeHeap.cpp. >>> >>> dl* >>> * > From dean.long at oracle.com Thu Jul 12 17:46:02 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 12 Jul 2018 10:46:02 -0700 Subject: [11] 8181855: [Graal] runtime/ReservedStack/ReservedStackTest.java triggers: assert(thread->deopt_mark() == __null) failed: no stack overflow from deopt blob/uncommon trap In-Reply-To: <85e1ae25-e565-d044-6242-107ec33fb2ba@oracle.com> References: <9ac1922e-bb48-ac6c-9f1c-62d7712b2945@oracle.com> <24cf7e66-b6c3-2a70-7733-fe92df5d3b12@oracle.com> <85e1ae25-e565-d044-6242-107ec33fb2ba@oracle.com> Message-ID: <34fcad5d-deb7-9f95-e334-404ddd558d0a@oracle.com> Thanks Tom.? I'll retest with that patch. dl On 7/12/18 10:28 AM, Tom Rodriguez wrote: > > > dean.long at oracle.com wrote on 7/12/18 10:07 AM: >> Unfortunately, when compiler/graalunit/HotspotTest.java runs my test >> in JDK, org.graalvm.compiler.test.SubprocessUtil thinks the >> command-line is empty, causing a failure.? Vladimir or Katya, is >> there anything special I need to do to run Graal unit tests in JDK? > > The tests that use SubprocessUtil in the JDK don't work so they are > disabled in ProblemList-graal.txt.? Here's my edit to that file from > the Graal update I was preparing.? It's also restores the regular > ReservedStackTestCompiler test. > > diff -r e0028bb6dd3d test/hotspot/jtreg/ProblemList-graal.txt > --- a/test/hotspot/jtreg/ProblemList-graal.txt > +++ b/test/hotspot/jtreg/ProblemList-graal.txt > @@ -67,8 +67,6 @@ > > ?gc/TestNUMAPageSize.java 8194949?? generic-all > > -runtime/ReservedStack/ReservedStackTestCompiler.java 8181855 ? > generic-all > - > ?serviceability/jvmti/GetModulesInfo/JvmtiGetAllModulesTest.java > 8195156?? generic-all > > ?compiler/compilercontrol/directives/LogTest.java 8181753 generic-all > @@ -174,6 +172,7 @@ > ?org.graalvm.compiler.hotspot.test.CompilationWrapperTest ????????? > 8205081 > ?org.graalvm.compiler.hotspot.test.HsErrLogTest ????????? 8205081 > ?org.graalvm.compiler.hotspot.test.OptionsInFileTest 8205081 > +org.graalvm.compiler.hotspot.test.ReservedStackAccessTest ???????? > 8205081 > > org.graalvm.compiler.replacements.test.classfile.ClassfileBytecodeProviderTest > ? 8205081 > ?org.graalvm.compiler.replacements.test.classfile.RedefineIntrinsicTest > ????????? 8205081 > > >> >> dl >> >> On 7/11/18 4:20 PM, Vladimir Kozlov wrote: >>> Looks good. >>> >>> Vladimir >>> >>> On 7/11/18 3:33 PM, dean.long at oracle.com wrote: >>>> http://cr.openjdk.java.net/~dlong/8181855/webrev/ >>>> https://bugs.openjdk.java.net/browse/JDK-8181855 >>>> >>>> This change adds "reserved stack" support to Graal for SPARC, x64, >>>> and AArch64. >>>> This change has already gone upstream into Graal, except for the >>>> AOT change in aotCodeHeap.cpp. >>>> >>>> dl* >>>> * >> From dean.long at oracle.com Thu Jul 12 21:15:22 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 12 Jul 2018 14:15:22 -0700 Subject: [11] 8181855: [Graal] runtime/ReservedStack/ReservedStackTest.java triggers: assert(thread->deopt_mark() == __null) failed: no stack overflow from deopt blob/uncommon trap In-Reply-To: <34fcad5d-deb7-9f95-e334-404ddd558d0a@oracle.com> References: <9ac1922e-bb48-ac6c-9f1c-62d7712b2945@oracle.com> <24cf7e66-b6c3-2a70-7733-fe92df5d3b12@oracle.com> <85e1ae25-e565-d044-6242-107ec33fb2ba@oracle.com> <34fcad5d-deb7-9f95-e334-404ddd558d0a@oracle.com> Message-ID: New webrev: http://cr.openjdk.java.net/~dlong/8181855/webrev.2/ The only change is to test/hotspot/jtreg/ProblemList-graal.txt The only test failure was an existing bug (JDK-8206241). dl On 7/12/18 10:46 AM, dean.long at oracle.com wrote: > Thanks Tom.? I'll retest with that patch. > > dl > > On 7/12/18 10:28 AM, Tom Rodriguez wrote: >> >> >> dean.long at oracle.com wrote on 7/12/18 10:07 AM: >>> Unfortunately, when compiler/graalunit/HotspotTest.java runs my test >>> in JDK, org.graalvm.compiler.test.SubprocessUtil thinks the >>> command-line is empty, causing a failure.? Vladimir or Katya, is >>> there anything special I need to do to run Graal unit tests in JDK? >> >> The tests that use SubprocessUtil in the JDK don't work so they are >> disabled in ProblemList-graal.txt.? Here's my edit to that file from >> the Graal update I was preparing.? It's also restores the regular >> ReservedStackTestCompiler test. >> >> diff -r e0028bb6dd3d test/hotspot/jtreg/ProblemList-graal.txt >> --- a/test/hotspot/jtreg/ProblemList-graal.txt >> +++ b/test/hotspot/jtreg/ProblemList-graal.txt >> @@ -67,8 +67,6 @@ >> >> ?gc/TestNUMAPageSize.java 8194949?? generic-all >> >> -runtime/ReservedStack/ReservedStackTestCompiler.java 8181855 >> generic-all >> - >> ?serviceability/jvmti/GetModulesInfo/JvmtiGetAllModulesTest.java >> 8195156?? generic-all >> >> ?compiler/compilercontrol/directives/LogTest.java 8181753 generic-all >> @@ -174,6 +172,7 @@ >> ?org.graalvm.compiler.hotspot.test.CompilationWrapperTest ????????? >> 8205081 >> ?org.graalvm.compiler.hotspot.test.HsErrLogTest 8205081 >> ?org.graalvm.compiler.hotspot.test.OptionsInFileTest 8205081 >> +org.graalvm.compiler.hotspot.test.ReservedStackAccessTest ???????? >> 8205081 >> >> org.graalvm.compiler.replacements.test.classfile.ClassfileBytecodeProviderTest >> ? 8205081 >> ?org.graalvm.compiler.replacements.test.classfile.RedefineIntrinsicTest >> ????????? 8205081 >> >> >>> >>> dl >>> >>> On 7/11/18 4:20 PM, Vladimir Kozlov wrote: >>>> Looks good. >>>> >>>> Vladimir >>>> >>>> On 7/11/18 3:33 PM, dean.long at oracle.com wrote: >>>>> http://cr.openjdk.java.net/~dlong/8181855/webrev/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8181855 >>>>> >>>>> This change adds "reserved stack" support to Graal for SPARC, x64, >>>>> and AArch64. >>>>> This change has already gone upstream into Graal, except for the >>>>> AOT change in aotCodeHeap.cpp. >>>>> >>>>> dl* >>>>> * >>> > From vladimir.kozlov at oracle.com Thu Jul 12 21:30:24 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 Jul 2018 14:30:24 -0700 Subject: [11] 8181855: [Graal] runtime/ReservedStack/ReservedStackTest.java triggers: assert(thread->deopt_mark() == __null) failed: no stack overflow from deopt blob/uncommon trap In-Reply-To: References: <9ac1922e-bb48-ac6c-9f1c-62d7712b2945@oracle.com> <24cf7e66-b6c3-2a70-7733-fe92df5d3b12@oracle.com> <85e1ae25-e565-d044-6242-107ec33fb2ba@oracle.com> <34fcad5d-deb7-9f95-e334-404ddd558d0a@oracle.com> Message-ID: <22738238-2197-9613-0fef-9a4c14fbaaa5@oracle.com> Good. Thanks, Vladimir On 7/12/18 2:15 PM, dean.long at oracle.com wrote: > New webrev: > > http://cr.openjdk.java.net/~dlong/8181855/webrev.2/ > > The only change is to test/hotspot/jtreg/ProblemList-graal.txt > > The only test failure was an existing bug (JDK-8206241). > > dl > > On 7/12/18 10:46 AM, dean.long at oracle.com wrote: >> Thanks Tom.? I'll retest with that patch. >> >> dl >> >> On 7/12/18 10:28 AM, Tom Rodriguez wrote: >>> >>> >>> dean.long at oracle.com wrote on 7/12/18 10:07 AM: >>>> Unfortunately, when compiler/graalunit/HotspotTest.java runs my test in JDK, >>>> org.graalvm.compiler.test.SubprocessUtil thinks the command-line is empty, causing a failure. >>>> Vladimir or Katya, is there anything special I need to do to run Graal unit tests in JDK? >>> >>> The tests that use SubprocessUtil in the JDK don't work so they are disabled in >>> ProblemList-graal.txt.? Here's my edit to that file from the Graal update I was preparing.? It's >>> also restores the regular ReservedStackTestCompiler test. >>> >>> diff -r e0028bb6dd3d test/hotspot/jtreg/ProblemList-graal.txt >>> --- a/test/hotspot/jtreg/ProblemList-graal.txt >>> +++ b/test/hotspot/jtreg/ProblemList-graal.txt >>> @@ -67,8 +67,6 @@ >>> >>> ?gc/TestNUMAPageSize.java 8194949?? generic-all >>> >>> -runtime/ReservedStack/ReservedStackTestCompiler.java 8181855 generic-all >>> - >>> ?serviceability/jvmti/GetModulesInfo/JvmtiGetAllModulesTest.java 8195156?? generic-all >>> >>> ?compiler/compilercontrol/directives/LogTest.java 8181753 generic-all >>> @@ -174,6 +172,7 @@ >>> ?org.graalvm.compiler.hotspot.test.CompilationWrapperTest 8205081 >>> ?org.graalvm.compiler.hotspot.test.HsErrLogTest 8205081 >>> ?org.graalvm.compiler.hotspot.test.OptionsInFileTest 8205081 >>> +org.graalvm.compiler.hotspot.test.ReservedStackAccessTest 8205081 >>> >>> org.graalvm.compiler.replacements.test.classfile.ClassfileBytecodeProviderTest ? 8205081 >>> ?org.graalvm.compiler.replacements.test.classfile.RedefineIntrinsicTest ????????? 8205081 >>> >>> >>>> >>>> dl >>>> >>>> On 7/11/18 4:20 PM, Vladimir Kozlov wrote: >>>>> Looks good. >>>>> >>>>> Vladimir >>>>> >>>>> On 7/11/18 3:33 PM, dean.long at oracle.com wrote: >>>>>> http://cr.openjdk.java.net/~dlong/8181855/webrev/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8181855 >>>>>> >>>>>> This change adds "reserved stack" support to Graal for SPARC, x64, and AArch64. >>>>>> This change has already gone upstream into Graal, except for the AOT change in aotCodeHeap.cpp. >>>>>> >>>>>> dl* >>>>>> * >>>> >> > From dean.long at oracle.com Thu Jul 12 21:51:49 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 12 Jul 2018 14:51:49 -0700 Subject: [11] 8181855: [Graal] runtime/ReservedStack/ReservedStackTest.java triggers: assert(thread->deopt_mark() == __null) failed: no stack overflow from deopt blob/uncommon trap In-Reply-To: <22738238-2197-9613-0fef-9a4c14fbaaa5@oracle.com> References: <9ac1922e-bb48-ac6c-9f1c-62d7712b2945@oracle.com> <24cf7e66-b6c3-2a70-7733-fe92df5d3b12@oracle.com> <85e1ae25-e565-d044-6242-107ec33fb2ba@oracle.com> <34fcad5d-deb7-9f95-e334-404ddd558d0a@oracle.com> <22738238-2197-9613-0fef-9a4c14fbaaa5@oracle.com> Message-ID: Thanks Vladimir. dl On 7/12/18 2:30 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 7/12/18 2:15 PM, dean.long at oracle.com wrote: >> New webrev: >> >> http://cr.openjdk.java.net/~dlong/8181855/webrev.2/ >> >> The only change is to test/hotspot/jtreg/ProblemList-graal.txt >> >> The only test failure was an existing bug (JDK-8206241). >> >> dl >> >> On 7/12/18 10:46 AM, dean.long at oracle.com wrote: >>> Thanks Tom.? I'll retest with that patch. >>> >>> dl >>> >>> On 7/12/18 10:28 AM, Tom Rodriguez wrote: >>>> >>>> >>>> dean.long at oracle.com wrote on 7/12/18 10:07 AM: >>>>> Unfortunately, when compiler/graalunit/HotspotTest.java runs my >>>>> test in JDK, org.graalvm.compiler.test.SubprocessUtil thinks the >>>>> command-line is empty, causing a failure.? Vladimir or Katya, is >>>>> there anything special I need to do to run Graal unit tests in JDK? >>>> >>>> The tests that use SubprocessUtil in the JDK don't work so they are >>>> disabled in ProblemList-graal.txt.? Here's my edit to that file >>>> from the Graal update I was preparing.? It's also restores the >>>> regular ReservedStackTestCompiler test. >>>> >>>> diff -r e0028bb6dd3d test/hotspot/jtreg/ProblemList-graal.txt >>>> --- a/test/hotspot/jtreg/ProblemList-graal.txt >>>> +++ b/test/hotspot/jtreg/ProblemList-graal.txt >>>> @@ -67,8 +67,6 @@ >>>> >>>> ?gc/TestNUMAPageSize.java 8194949?? generic-all >>>> >>>> -runtime/ReservedStack/ReservedStackTestCompiler.java 8181855 >>>> generic-all >>>> - >>>> ?serviceability/jvmti/GetModulesInfo/JvmtiGetAllModulesTest.java >>>> 8195156?? generic-all >>>> >>>> ?compiler/compilercontrol/directives/LogTest.java 8181753 generic-all >>>> @@ -174,6 +172,7 @@ >>>> ?org.graalvm.compiler.hotspot.test.CompilationWrapperTest 8205081 >>>> ?org.graalvm.compiler.hotspot.test.HsErrLogTest 8205081 >>>> ?org.graalvm.compiler.hotspot.test.OptionsInFileTest 8205081 >>>> +org.graalvm.compiler.hotspot.test.ReservedStackAccessTest 8205081 >>>> >>>> org.graalvm.compiler.replacements.test.classfile.ClassfileBytecodeProviderTest >>>> ? 8205081 >>>> ?org.graalvm.compiler.replacements.test.classfile.RedefineIntrinsicTest >>>> ????????? 8205081 >>>> >>>> >>>>> >>>>> dl >>>>> >>>>> On 7/11/18 4:20 PM, Vladimir Kozlov wrote: >>>>>> Looks good. >>>>>> >>>>>> Vladimir >>>>>> >>>>>> On 7/11/18 3:33 PM, dean.long at oracle.com wrote: >>>>>>> http://cr.openjdk.java.net/~dlong/8181855/webrev/ >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8181855 >>>>>>> >>>>>>> This change adds "reserved stack" support to Graal for SPARC, >>>>>>> x64, and AArch64. >>>>>>> This change has already gone upstream into Graal, except for the >>>>>>> AOT change in aotCodeHeap.cpp. >>>>>>> >>>>>>> dl* >>>>>>> * >>>>> >>> >> From dms at samersoff.net Mon Jul 16 13:28:46 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Mon, 16 Jul 2018 16:28:46 +0300 Subject: Travis build fails by timeout in testErrnoCallback for all pull requests Message-ID: Hello Everybody, Travis build "JDK=\"jdk11\" GATE=\"build,test\"", fails by timeout: Test testErrnoCallback(com.oracle.truffle.nfi.test.ErrnoNFITest) not finished after 249 ms for all pull requests. Is there any workaround/solution for this problem? -Dmitry -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ... From doug.simon at oracle.com Mon Jul 16 13:48:10 2018 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 16 Jul 2018 15:48:10 +0200 Subject: Travis build fails by timeout in testErrnoCallback for all pull requests In-Reply-To: References: Message-ID: <0A775199-957F-4B98-912F-C549C280DFB7@oracle.com> > On 16 Jul 2018, at 15:28, Dmitry Samersoff wrote: > > Hello Everybody, > > Travis build "JDK=\"jdk11\" GATE=\"build,test\"", fails by timeout: > > Test testErrnoCallback(com.oracle.truffle.nfi.test.ErrnoNFITest) not > finished after 249 ms > > for all pull requests. > > Is there any workaround/solution for this problem? I think the issue is actually a compilation error caused by the preceding test com.oracle.truffle.sl.test.SLDebugDirectTest. I've opened an internal ticket for this and hope it will be investigated soon. Can you please let me know if this fails for you when JAVA_HOME points to JDK11: mx unittest -Dgraal.TruffleBackgroundCompilation=false -Dgraal.TruffleCompileImmediately=true -Dgraal.TraceTruffleCompilation=false com.oracle.truffle.sl.test.SLDebugDirectTest -Doug From forax at univ-mlv.fr Mon Jul 16 14:00:41 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 16 Jul 2018 16:00:41 +0200 (CEST) Subject: Travis build fails by timeout in testErrnoCallback for all pull requests In-Reply-To: <0A775199-957F-4B98-912F-C549C280DFB7@oracle.com> References: <0A775199-957F-4B98-912F-C549C280DFB7@oracle.com> Message-ID: <1530204823.321164.1531749641288.JavaMail.zimbra@u-pem.fr> Hi Doug, ----- Mail original ----- > De: "Doug Simon" > ?: "Dmitry Samersoff" > Cc: "graal-dev" > Envoy?: Lundi 16 Juillet 2018 15:48:10 > Objet: Re: Travis build fails by timeout in testErrnoCallback for all pull requests >> On 16 Jul 2018, at 15:28, Dmitry Samersoff wrote: >> >> Hello Everybody, >> >> Travis build "JDK=\"jdk11\" GATE=\"build,test\"", fails by timeout: >> >> Test testErrnoCallback(com.oracle.truffle.nfi.test.ErrnoNFITest) not >> finished after 249 ms >> >> for all pull requests. >> >> Is there any workaround/solution for this problem? > > I think the issue is actually a compilation error caused by the preceding test > com.oracle.truffle.sl.test.SLDebugDirectTest. I've opened an internal ticket > for this and hope it will be investigated soon. Can you please let me know if > this fails for you when JAVA_HOME points to JDK11: > > mx unittest -Dgraal.TruffleBackgroundCompilation=false > -Dgraal.TruffleCompileImmediately=true -Dgraal.TraceTruffleCompilation=false > com.oracle.truffle.sl.test.SLDebugDirectTest > this is maybe a different bug but i also had the same kind of issue with latest jdk 11 (b22), https://travis-ci.org/forax/exotic/jobs/404348683 (note that while these are perf tests, the perf tests are using c2, only the VM that runs the tester is using Graal) the VM has finished to run but something is holding it to exit. > -Doug R?mi From doug.simon at oracle.com Mon Jul 16 14:59:24 2018 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 16 Jul 2018 16:59:24 +0200 Subject: Travis build fails by timeout in testErrnoCallback for all pull requests In-Reply-To: <1530204823.321164.1531749641288.JavaMail.zimbra@u-pem.fr> References: <0A775199-957F-4B98-912F-C549C280DFB7@oracle.com> <1530204823.321164.1531749641288.JavaMail.zimbra@u-pem.fr> Message-ID: <6E5AF0B2-0377-4191-ADB1-84BC2073C08F@oracle.com> > On 16 Jul 2018, at 16:00, Remi Forax wrote: > > Hi Doug, > > ----- Mail original ----- >> De: "Doug Simon" >> ?: "Dmitry Samersoff" >> Cc: "graal-dev" >> Envoy?: Lundi 16 Juillet 2018 15:48:10 >> Objet: Re: Travis build fails by timeout in testErrnoCallback for all pull requests > >>> On 16 Jul 2018, at 15:28, Dmitry Samersoff wrote: >>> >>> Hello Everybody, >>> >>> Travis build "JDK=\"jdk11\" GATE=\"build,test\"", fails by timeout: >>> >>> Test testErrnoCallback(com.oracle.truffle.nfi.test.ErrnoNFITest) not >>> finished after 249 ms >>> >>> for all pull requests. >>> >>> Is there any workaround/solution for this problem? >> >> I think the issue is actually a compilation error caused by the preceding test >> com.oracle.truffle.sl.test.SLDebugDirectTest. I've opened an internal ticket >> for this and hope it will be investigated soon. Can you please let me know if >> this fails for you when JAVA_HOME points to JDK11: >> >> mx unittest -Dgraal.TruffleBackgroundCompilation=false >> -Dgraal.TruffleCompileImmediately=true -Dgraal.TraceTruffleCompilation=false >> com.oracle.truffle.sl.test.SLDebugDirectTest >> > > this is maybe a different bug but i also had the same kind of issue with latest jdk 11 (b22), > https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_forax_exotic_jobs_404348683&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=fbdeH0MKVtcRhPTiuJVQpQhRJkri9lOVsGDzXQE4aA8&s=UGeDId7vPADJKV0Wuo4VqJJFFrJqaUoQSz3T19HevCc&e= > (note that while these are perf tests, the perf tests are using c2, only the VM that runs the tester is using Graal) > > the VM has finished to run but something is holding it to exit. Thanks for the suggestion but I think it's a different issue. In the failing Travis test, we have a combination of Truffle compilation being done on background threads and the option TrufflePerformanceWarningsAreFatal=true. So a compilation triggered by an earlier unittest can fail and interrupt monitoring of a later test while the VM is exiting. -Doug From forax at univ-mlv.fr Mon Jul 16 20:20:22 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 16 Jul 2018 22:20:22 +0200 (CEST) Subject: Travis build fails by timeout in testErrnoCallback for all pull requests In-Reply-To: <6E5AF0B2-0377-4191-ADB1-84BC2073C08F@oracle.com> References: <0A775199-957F-4B98-912F-C549C280DFB7@oracle.com> <1530204823.321164.1531749641288.JavaMail.zimbra@u-pem.fr> <6E5AF0B2-0377-4191-ADB1-84BC2073C08F@oracle.com> Message-ID: <1775414348.397867.1531772422800.JavaMail.zimbra@u-pem.fr> Hi Doug, i think you're right not the same bug, mine is spurious and doesn't seem to be related to graal after all, sorry for the noise. R?mi ----- Mail original ----- > De: "Doug Simon" > ?: "Remi Forax" > Cc: "Dmitry Samersoff" , "graal-dev" > Envoy?: Lundi 16 Juillet 2018 16:59:24 > Objet: Re: Travis build fails by timeout in testErrnoCallback for all pull requests >> On 16 Jul 2018, at 16:00, Remi Forax wrote: >> >> Hi Doug, >> >> ----- Mail original ----- >>> De: "Doug Simon" >>> ?: "Dmitry Samersoff" >>> Cc: "graal-dev" >>> Envoy?: Lundi 16 Juillet 2018 15:48:10 >>> Objet: Re: Travis build fails by timeout in testErrnoCallback for all pull >>> requests >> >>>> On 16 Jul 2018, at 15:28, Dmitry Samersoff wrote: >>>> >>>> Hello Everybody, >>>> >>>> Travis build "JDK=\"jdk11\" GATE=\"build,test\"", fails by timeout: >>>> >>>> Test testErrnoCallback(com.oracle.truffle.nfi.test.ErrnoNFITest) not >>>> finished after 249 ms >>>> >>>> for all pull requests. >>>> >>>> Is there any workaround/solution for this problem? >>> >>> I think the issue is actually a compilation error caused by the preceding test >>> com.oracle.truffle.sl.test.SLDebugDirectTest. I've opened an internal ticket >>> for this and hope it will be investigated soon. Can you please let me know if >>> this fails for you when JAVA_HOME points to JDK11: >>> >>> mx unittest -Dgraal.TruffleBackgroundCompilation=false >>> -Dgraal.TruffleCompileImmediately=true -Dgraal.TraceTruffleCompilation=false >>> com.oracle.truffle.sl.test.SLDebugDirectTest >>> >> >> this is maybe a different bug but i also had the same kind of issue with latest >> jdk 11 (b22), >> https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_forax_exotic_jobs_404348683&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=fbdeH0MKVtcRhPTiuJVQpQhRJkri9lOVsGDzXQE4aA8&s=UGeDId7vPADJKV0Wuo4VqJJFFrJqaUoQSz3T19HevCc&e= >> (note that while these are perf tests, the perf tests are using c2, only the VM >> that runs the tester is using Graal) >> >> the VM has finished to run but something is holding it to exit. > > Thanks for the suggestion but I think it's a different issue. In the failing > Travis test, we have a combination of Truffle compilation being done on > background threads and the option TrufflePerformanceWarningsAreFatal=true. So a > compilation triggered by an earlier unittest can fail and interrupt monitoring > of a later test while the VM is exiting. > > -Doug From Gary.Morrison at arm.com Thu Jul 19 22:58:58 2018 From: Gary.Morrison at arm.com (Gary Morrison) Date: Thu, 19 Jul 2018 22:58:58 +0000 Subject: -XX:+PrintAOT Output: First Two Columns Are...? Message-ID: Apologies in advance if this is too elementary a question. First time posting here. (Also, admittedly not strictly a Graal question, but obviously related.) Googled around a bit but couldn't really find anything. With -XX:+PrintAOT, what are the first two columns of info. They're numerical, so I'm guessing they're some sort of time-stamp? Referring to the 43-44 and the 1-10 below, for example: 43 1 aot[ 2] java.lang.Object.finalize()V 43 2 aot[ 2] java.lang.Object.equals(Ljava/lang/Object;)Z 43 3 aot[ 2] java.lang.Object.()V 43 4 aot[ 2] java.lang.Object.wait()V 43 5 aot[ 2] java.lang.Object.()V 43 6 aot[ 2] java.lang.Object.wait(JI)V 43 7 aot[ 2] java.lang.Object.toString()Ljava/lang/String; 43 8 aot[ 2] java.lang.CharSequence.chars()Ljava/util/stream/IntStream; 44 9 aot[ 2] java.lang.CharSequence.codePoints()Ljava/util/stream/IntStream; 44 10 aot[ 2] java.lang.CharSequence.lambda$codePoints$1()Ljava/util/Spliterator$OfInt; IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From vladimir.kozlov at oracle.com Thu Jul 19 23:29:05 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 19 Jul 2018 16:29:05 -0700 Subject: -XX:+PrintAOT Output: First Two Columns Are...? In-Reply-To: References: Message-ID: <75ab5886-0230-4b09-437b-4ea26ab1c6c1@oracle.com> Hi Gary, I assume you are asking about AOT feature in JDK. $ java -XX:+PrintAOT -XX:AOTLibrary=./aot.so HelloWorld 87 1 loaded ./aot.so aot library 277 1 aot[ 1] HelloWorld.()V 277 2 aot[ 1] HelloWorld.main([Ljava/lang/String;)V First column is milisec from JVM start. Second - ID assigned to AOTed method. Third in [] is AOT library Id (in order they are loaded) http://hg.openjdk.java.net/jdk/jdk/file/e443c637b238/src/hotspot/share/aot/aotCompiledMethod.cpp#l327 Regards, Vladimir On 7/19/18 3:58 PM, Gary Morrison wrote: > Apologies in advance if this is too elementary a question. First time posting here. (Also, admittedly not strictly a Graal question, but obviously related.) > > Googled around a bit but couldn't really find anything. > > With -XX:+PrintAOT, what are the first two columns of info. They're numerical, so I'm guessing they're some sort of time-stamp? Referring to the 43-44 and the 1-10 below, for example: > > 43 1 aot[ 2] java.lang.Object.finalize()V > 43 2 aot[ 2] java.lang.Object.equals(Ljava/lang/Object;)Z > 43 3 aot[ 2] java.lang.Object.()V > 43 4 aot[ 2] java.lang.Object.wait()V > 43 5 aot[ 2] java.lang.Object.()V > 43 6 aot[ 2] java.lang.Object.wait(JI)V > 43 7 aot[ 2] java.lang.Object.toString()Ljava/lang/String; > 43 8 aot[ 2] java.lang.CharSequence.chars()Ljava/util/stream/IntStream; > 44 9 aot[ 2] java.lang.CharSequence.codePoints()Ljava/util/stream/IntStream; > 44 10 aot[ 2] java.lang.CharSequence.lambda$codePoints$1()Ljava/util/Spliterator$OfInt; > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > From dean.long at oracle.com Sat Jul 21 18:52:12 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Sat, 21 Jul 2018 11:52:12 -0700 Subject: [11] 8207383: [Graal] SelfChangedCDS.java fails with "guarantee(disp == (intptr_t)(jint)disp) failed: must be 32-bit offset" Message-ID: https://bugs.openjdk.java.net/browse/JDK-8207383 http://cr.openjdk.java.net/~dlong/8207383/webrev/ This fixes a regression caused by JDK-8181855.? The fix is to use a scratch register to make far calls, but force a near call for AOT. Changeset based on contribution by Tom Rodriguez. dl From vladimir.kozlov at oracle.com Sun Jul 22 00:37:56 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 21 Jul 2018 17:37:56 -0700 Subject: [11] 8207383: [Graal] SelfChangedCDS.java fails with "guarantee(disp == (intptr_t)(jint)disp) failed: must be 32-bit offset" In-Reply-To: References: Message-ID: <32ee879d-70e1-aec5-cf20-e4be16aef120@oracle.com> To be clear. We don't use far call for AOT because in AOT code we call through trampoline anyway. Right? My question is do we do that for all calls? Or only runtime calls? Thanks, Vladimir On 7/21/18 11:52 AM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8207383 > http://cr.openjdk.java.net/~dlong/8207383/webrev/ > > This fixes a regression caused by JDK-8181855.? The fix is to use a > scratch register to make far calls, but force a near call for AOT. > > Changeset based on contribution by Tom Rodriguez. > > dl From dean.long at oracle.com Sun Jul 22 04:57:28 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Sat, 21 Jul 2018 21:57:28 -0700 Subject: [11] 8207383: [Graal] SelfChangedCDS.java fails with "guarantee(disp == (intptr_t)(jint)disp) failed: must be 32-bit offset" In-Reply-To: <32ee879d-70e1-aec5-cf20-e4be16aef120@oracle.com> References: <32ee879d-70e1-aec5-cf20-e4be16aef120@oracle.com> Message-ID: <63b8fa3a-c5ba-617d-a5d6-a750b3146155@oracle.com> On 7/21/18 5:37 PM, Vladimir Kozlov wrote: > To be clear. We don't use far call for AOT because in AOT code we call > through trampoline anyway. Right? Yes, we call through a "PLT". > > My question is do we do that for all calls? Or only runtime calls? > I believe we call through the PLT for everything except calls to code that we know is in the AOT library, like Graal-generated stubs. This is a direct call: ??? 2883:?????? e8 98 1a 00 00????????? callq? 4320 > This calls through a PLT: ??? 2c17:?????? e8 b4 15 00 00????????? callq? 41d0 Finally, we use trampolines when an nmethod needs to make a far call to AOT code. dl > Thanks, > Vladimir > > On 7/21/18 11:52 AM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8207383 >> http://cr.openjdk.java.net/~dlong/8207383/webrev/ >> >> This fixes a regression caused by JDK-8181855.? The fix is to use a >> scratch register to make far calls, but force a near call for AOT. >> >> Changeset based on contribution by Tom Rodriguez. >> >> dl From vladimir.kozlov at oracle.com Sun Jul 22 17:28:54 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sun, 22 Jul 2018 10:28:54 -0700 Subject: [11] 8207383: [Graal] SelfChangedCDS.java fails with "guarantee(disp == (intptr_t)(jint)disp) failed: must be 32-bit offset" In-Reply-To: <63b8fa3a-c5ba-617d-a5d6-a750b3146155@oracle.com> References: <32ee879d-70e1-aec5-cf20-e4be16aef120@oracle.com> <63b8fa3a-c5ba-617d-a5d6-a750b3146155@oracle.com> Message-ID: Dean, On 7/21/18 9:57 PM, dean.long at oracle.com wrote: > On 7/21/18 5:37 PM, Vladimir Kozlov wrote: >> To be clear. We don't use far call for AOT because in AOT code we call >> through trampoline anyway. Right? > > Yes, we call through a "PLT". > >> >> My question is do we do that for all calls? Or only runtime calls? >> > > I believe we call through the PLT for everything except calls to code > that we know is in the AOT library, like Graal-generated stubs. > This is a direct call: Sorry, I was not clear. I asked about code generated by Graal JIT not for AOT. Your changes seem generate indirect call in all cases when scratch register is specified: if (scratch != null && !GeneratePIC.getValue(crb.getOptions())) { What about calls from nmethod to nmethod? They should not be far calls. I am not familiar with Graal and that is why I am asking. Thanks, Vladimir > > ??? 2883:?????? e8 98 1a 00 00????????? callq? 4320 > > > > This calls through a PLT: > > ??? 2c17:?????? e8 b4 15 00 00????????? callq? 41d0 > > > > Finally, we use trampolines when an nmethod needs to make a far call to > AOT code. > > dl > >> Thanks, >> Vladimir >> >> On 7/21/18 11:52 AM, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8207383 >>> http://cr.openjdk.java.net/~dlong/8207383/webrev/ >>> >>> This fixes a regression caused by JDK-8181855.? The fix is to use a >>> scratch register to make far calls, but force a near call for AOT. >>> >>> Changeset based on contribution by Tom Rodriguez. >>> >>> dl > From dean.long at oracle.com Sun Jul 22 18:22:04 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Sun, 22 Jul 2018 11:22:04 -0700 Subject: [11] 8207383: [Graal] SelfChangedCDS.java fails with "guarantee(disp == (intptr_t)(jint)disp) failed: must be 32-bit offset" In-Reply-To: References: <32ee879d-70e1-aec5-cf20-e4be16aef120@oracle.com> <63b8fa3a-c5ba-617d-a5d6-a750b3146155@oracle.com> Message-ID: On 7/22/18 10:28 AM, Vladimir Kozlov wrote: > Dean, > > On 7/21/18 9:57 PM, dean.long at oracle.com wrote: >> On 7/21/18 5:37 PM, Vladimir Kozlov wrote: >>> To be clear. We don't use far call for AOT because in AOT code we >>> call through trampoline anyway. Right? >> >> Yes, we call through a "PLT". >> >>> >>> My question is do we do that for all calls? Or only runtime calls? >>> >> >> I believe we call through the PLT for everything except calls to code >> that we know is in the AOT library, like Graal-generated stubs. >> This is a direct call: > > Sorry, I was not clear. I asked about code generated by Graal JIT not > for AOT. Your changes seem generate indirect call in all cases when > scratch register is specified: > > if (scratch != null && !GeneratePIC.getValue(crb.getOptions())) { > Yes, and that was also the old behavior.? The new changes are: 1) to disallow using the scratch register for AOT calls 2) allowing directJmp to make a far jump 3) using a scratch register for far calls to foreign functions ENABLE_STACK_RESERVED_ZONE and THROW_DELAYED_STACKOVERFLOW_ERROR. Other calls are left unchanged. > What about calls from nmethod to nmethod? They should not be far > calls. I am not familiar with Graal and that is why I am asking. > For Java invokes, they can be direct or indirect.? For direct invokes on x64, Graal is using near calls with a null scratch register. http://hg.openjdk.java.net/jdk/jdk11/file/d5138f8da1ba/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64Call.java#l104 dl > Thanks, > Vladimir > >> >> ???? 2883:?????? e8 98 1a 00 00????????? callq? 4320 >> > >> >> This calls through a PLT: >> >> ???? 2c17:?????? e8 b4 15 00 00????????? callq? 41d0 >> >> >> >> Finally, we use trampolines when an nmethod needs to make a far call >> to AOT code. >> >> dl >> >>> Thanks, >>> Vladimir >>> >>> On 7/21/18 11:52 AM, dean.long at oracle.com wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8207383 >>>> http://cr.openjdk.java.net/~dlong/8207383/webrev/ >>>> >>>> This fixes a regression caused by JDK-8181855.? The fix is to use a >>>> scratch register to make far calls, but force a near call for AOT. >>>> >>>> Changeset based on contribution by Tom Rodriguez. >>>> >>>> dl >> From vladimir.kozlov at oracle.com Sun Jul 22 18:30:37 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sun, 22 Jul 2018 11:30:37 -0700 Subject: [11] 8207383: [Graal] SelfChangedCDS.java fails with "guarantee(disp == (intptr_t)(jint)disp) failed: must be 32-bit offset" In-Reply-To: References: <32ee879d-70e1-aec5-cf20-e4be16aef120@oracle.com> <63b8fa3a-c5ba-617d-a5d6-a750b3146155@oracle.com>

Message-ID: <4a6fd9e6-ce20-0058-b62b-782f3350ddb8@oracle.com> Thank you for explanation, Dean. Reviewed. Good. Vladimir On 7/22/18 11:22 AM, dean.long at oracle.com wrote: > On 7/22/18 10:28 AM, Vladimir Kozlov wrote: >> Dean, >> >> On 7/21/18 9:57 PM, dean.long at oracle.com wrote: >>> On 7/21/18 5:37 PM, Vladimir Kozlov wrote: >>>> To be clear. We don't use far call for AOT because in AOT code we >>>> call through trampoline anyway. Right? >>> >>> Yes, we call through a "PLT". >>> >>>> >>>> My question is do we do that for all calls? Or only runtime calls? >>>> >>> >>> I believe we call through the PLT for everything except calls to code >>> that we know is in the AOT library, like Graal-generated stubs. >>> This is a direct call: >> >> Sorry, I was not clear. I asked about code generated by Graal JIT not >> for AOT. Your changes seem generate indirect call in all cases when >> scratch register is specified: >> >> if (scratch != null && !GeneratePIC.getValue(crb.getOptions())) { >> > > Yes, and that was also the old behavior.? The new changes are: > 1) to disallow using the scratch register for AOT calls > 2) allowing directJmp to make a far jump > 3) using a scratch register for far calls to foreign functions > ENABLE_STACK_RESERVED_ZONE and THROW_DELAYED_STACKOVERFLOW_ERROR. Other > calls are left unchanged. >> What about calls from nmethod to nmethod? They should not be far >> calls. I am not familiar with Graal and that is why I am asking. >> > > For Java invokes, they can be direct or indirect.? For direct invokes on > x64, Graal is using near calls with a null scratch register. > > http://hg.openjdk.java.net/jdk/jdk11/file/d5138f8da1ba/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64Call.java#l104 > > > dl > >> Thanks, >> Vladimir >> >>> >>> ???? 2883:?????? e8 98 1a 00 00????????? callq? 4320 >>> > >>> >>> This calls through a PLT: >>> >>> ???? 2c17:?????? e8 b4 15 00 00????????? callq? 41d0 >>> >>> >>> >>> Finally, we use trampolines when an nmethod needs to make a far call >>> to AOT code. >>> >>> dl >>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 7/21/18 11:52 AM, dean.long at oracle.com wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8207383 >>>>> http://cr.openjdk.java.net/~dlong/8207383/webrev/ >>>>> >>>>> This fixes a regression caused by JDK-8181855.? The fix is to use a >>>>> scratch register to make far calls, but force a near call for AOT. >>>>> >>>>> Changeset based on contribution by Tom Rodriguez. >>>>> >>>>> dl >>> > From dean.long at oracle.com Mon Jul 23 18:59:14 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 23 Jul 2018 11:59:14 -0700 Subject: [11] 8207383: [Graal] SelfChangedCDS.java fails with "guarantee(disp == (intptr_t)(jint)disp) failed: must be 32-bit offset" In-Reply-To: <4a6fd9e6-ce20-0058-b62b-782f3350ddb8@oracle.com> References: <32ee879d-70e1-aec5-cf20-e4be16aef120@oracle.com> <63b8fa3a-c5ba-617d-a5d6-a750b3146155@oracle.com>

<4a6fd9e6-ce20-0058-b62b-782f3350ddb8@oracle.com> Message-ID: Thanks Vladimir. dl On 7/22/18 11:30 AM, Vladimir Kozlov wrote: > Thank you for explanation, Dean. > > Reviewed. Good. > > Vladimir > > On 7/22/18 11:22 AM, dean.long at oracle.com wrote: >> On 7/22/18 10:28 AM, Vladimir Kozlov wrote: >>> Dean, >>> >>> On 7/21/18 9:57 PM, dean.long at oracle.com wrote: >>>> On 7/21/18 5:37 PM, Vladimir Kozlov wrote: >>>>> To be clear. We don't use far call for AOT because in AOT code we >>>>> call through trampoline anyway. Right? >>>> >>>> Yes, we call through a "PLT". >>>> >>>>> >>>>> My question is do we do that for all calls? Or only runtime calls? >>>>> >>>> >>>> I believe we call through the PLT for everything except calls to >>>> code that we know is in the AOT library, like Graal-generated stubs. >>>> This is a direct call: >>> >>> Sorry, I was not clear. I asked about code generated by Graal JIT >>> not for AOT. Your changes seem generate indirect call in all cases >>> when scratch register is specified: >>> >>> if (scratch != null && !GeneratePIC.getValue(crb.getOptions())) { >>> >> >> Yes, and that was also the old behavior.? The new changes are: >> 1) to disallow using the scratch register for AOT calls >> 2) allowing directJmp to make a far jump >> 3) using a scratch register for far calls to foreign functions >> ENABLE_STACK_RESERVED_ZONE and THROW_DELAYED_STACKOVERFLOW_ERROR. >> Other calls are left unchanged. >>> What about calls from nmethod to nmethod? They should not be far >>> calls. I am not familiar with Graal and that is why I am asking. >>> >> >> For Java invokes, they can be direct or indirect.? For direct invokes >> on x64, Graal is using near calls with a null scratch register. >> >> http://hg.openjdk.java.net/jdk/jdk11/file/d5138f8da1ba/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64Call.java#l104 >> >> >> dl >> >>> Thanks, >>> Vladimir >>> >>>> >>>> ???? 2883:?????? e8 98 1a 00 00????????? callq? 4320 >>>> > >>>> >>>> This calls through a PLT: >>>> >>>> ???? 2c17:?????? e8 b4 15 00 00????????? callq? 41d0 >>>> >>>> >>>> >>>> Finally, we use trampolines when an nmethod needs to make a far >>>> call to AOT code. >>>> >>>> dl >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 7/21/18 11:52 AM, dean.long at oracle.com wrote: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8207383 >>>>>> http://cr.openjdk.java.net/~dlong/8207383/webrev/ >>>>>> >>>>>> This fixes a regression caused by JDK-8181855.? The fix is to use >>>>>> a scratch register to make far calls, but force a near call for AOT. >>>>>> >>>>>> Changeset based on contribution by Tom Rodriguez. >>>>>> >>>>>> dl >>>> >> From kovariadam at gmail.com Tue Jul 24 11:05:54 2018 From: kovariadam at gmail.com (=?utf-8?Q?Adam_K=C3=B6v=C3=A1ri?=) Date: Tue, 24 Jul 2018 13:05:54 +0200 Subject: NPE in PolyglotLanguageContext.toHostValue Message-ID: <5b570811.1c69fb81.4f3dc.4b24@mx.google.com> Hello, I am very interested in learning the Truffle API, I find it really amazing so far. I am trying to implement a simple expression language [1], based on SimpleLanguage project, but I got stuck and I am not really sure where the problem might be. Perhaps someone understands what this means? org.graalvm.polyglot.PolyglotException: java.lang.NullPointerException ??????? at com.oracle.truffle.api.vm.PolyglotLanguageContext.toHostValue(PolyglotLanguageContext.java:585) ??????? at com.oracle.truffle.api.vm.PolyglotContextImpl.eval(PolyglotContextImpl.java:789) ??????? at org.graalvm.polyglot.Context.eval(Context.java:313) ??????? at org.graalvm.polyglot.Context.eval(Context.java:338) ??????? at smol.SmolSimpleExpressionTest.unitValueTest(SmolSimpleExpressionTest.java:74) ? This can be easily reproduced by running: $ mvn tests My java version: $ java -version java version "1.8.0_172" Java(TM) SE Runtime Environment (build 1.8.0_172-b11) GraalVM 1.0.0-rc3 (build 25.71-b01-internal-jvmci-0.45, mixed mode) Would someone be able to advice, any ideas or pointers are most welcome. Thanks, Adam [1] https://github.com/akovari/smol From christian.humer at gmail.com Tue Jul 24 13:01:15 2018 From: christian.humer at gmail.com (Christian Humer) Date: Tue, 24 Jul 2018 14:01:15 +0100 Subject: NPE in PolyglotLanguageContext.toHostValue In-Reply-To: <5b570811.1c69fb81.4f3dc.4b24@mx.google.com> References: <5b570811.1c69fb81.4f3dc.4b24@mx.google.com> Message-ID: Hi Adam, First, welcome! Thanks for giving Truffle a go. The NPE you are seeing comes from the fact that the CallTarget that you are returning in SmolLanguage#parse returns itself a Java null value when called. A CallTarget is never expected to return null. Instead we typically use singleton values that represent null. We have some documentation here[1] why we do this. So to fix this make sure your RootNodes always return a value. That being said, the NPE is not a good error for this. We will fix that in RC5. Hope this helps. Feel free to also checkout our Gitter channel for further questions: https://gitter.im/graalvm/graal-core Good luck! - Christian Humer [1] https://github.com/graalvm/simplelanguage/blob/master/language/src/main/java/com/oracle/truffle/sl/runtime/SLNull.java#L54 On Tue, Jul 24, 2018 at 1:06 PM Adam K?v?ri wrote: > Hello, > > I am very interested in learning the Truffle API, I find it really amazing > so far. > > I am trying to implement a simple expression language [1], based on > SimpleLanguage project, but I got stuck and I am not really sure where the > problem might be. > > Perhaps someone understands what this means? > > org.graalvm.polyglot.PolyglotException: java.lang.NullPointerException > at > com.oracle.truffle.api.vm.PolyglotLanguageContext.toHostValue(PolyglotLanguageContext.java:585) > at > com.oracle.truffle.api.vm.PolyglotContextImpl.eval(PolyglotContextImpl.java:789) > at org.graalvm.polyglot.Context.eval(Context.java:313) > at org.graalvm.polyglot.Context.eval(Context.java:338) > at > smol.SmolSimpleExpressionTest.unitValueTest(SmolSimpleExpressionTest.java:74) > ? > > > This can be easily reproduced by running: > > $ mvn tests > > My java version: > > $ java -version > java version "1.8.0_172" > Java(TM) SE Runtime Environment (build 1.8.0_172-b11) > GraalVM 1.0.0-rc3 (build 25.71-b01-internal-jvmci-0.45, mixed mode) > > > Would someone be able to advice, any ideas or pointers are most welcome. > > > Thanks, > Adam > > [1] https://github.com/akovari/smol > From kovariadam at gmail.com Tue Jul 24 14:42:28 2018 From: kovariadam at gmail.com (=?utf-8?Q?Adam_K=C3=B6v=C3=A1ri?=) Date: Tue, 24 Jul 2018 16:42:28 +0200 Subject: NPE in PolyglotLanguageContext.toHostValue In-Reply-To: References: <5b570811.1c69fb81.4f3dc.4b24@mx.google.com> Message-ID: <5b573ad3.1c69fb81.3d161.c794@mx.google.com> Hi Christian, Thank you for such a prompt response. That was exactly the problem! I?didn?t know about gitter, thanks, I?ll join it. Thanks again, Adam Od: Christian Humer Odoslan?: utorok 24. j?la 2018 15:01 Komu: Adam K?v?ri K?pia: graal-dev at openjdk.java.net Predmet: Re: NPE in PolyglotLanguageContext.toHostValue Hi Adam, First, welcome! Thanks for giving Truffle a go. The NPE you are seeing comes from the fact that the CallTarget that you are returning in SmolLanguage#parse returns itself a Java null value when called. A CallTarget is never expected to return null. Instead we typically use singleton values that represent null. We have some documentation here[1] why we do this. So to fix this make sure your RootNodes always return a value. That being said, the NPE is not a good error for this. We will fix that in RC5. Hope this helps. Feel free to also checkout our Gitter channel for further questions:?https://gitter.im/graalvm/graal-core Good luck! - Christian Humer [1]?https://github.com/graalvm/simplelanguage/blob/master/language/src/main/java/com/oracle/truffle/sl/runtime/SLNull.java#L54 On Tue, Jul 24, 2018 at 1:06 PM Adam K?v?ri wrote: Hello, I am very interested in learning the Truffle API, I find it really amazing so far. I am trying to implement a simple expression language [1], based on SimpleLanguage project, but I got stuck and I am not really sure where the problem might be. Perhaps someone understands what this means? org.graalvm.polyglot.PolyglotException: java.lang.NullPointerException ??????? at com.oracle.truffle.api.vm.PolyglotLanguageContext.toHostValue(PolyglotLanguageContext.java:585) ??????? at com.oracle.truffle.api.vm.PolyglotContextImpl.eval(PolyglotContextImpl.java:789) ??????? at org.graalvm.polyglot.Context.eval(Context.java:313) ??????? at org.graalvm.polyglot.Context.eval(Context.java:338) ??????? at smol.SmolSimpleExpressionTest.unitValueTest(SmolSimpleExpressionTest.java:74) ? This can be easily reproduced by running: $ mvn tests My java version: $ java -version java version "1.8.0_172" Java(TM) SE Runtime Environment (build 1.8.0_172-b11) GraalVM 1.0.0-rc3 (build 25.71-b01-internal-jvmci-0.45, mixed mode) Would someone be able to advice, any ideas or pointers are most welcome. Thanks, Adam [1] https://github.com/akovari/smol From adinn at redhat.com Thu Jul 26 10:29:03 2018 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 26 Jul 2018 11:29:03 +0100 Subject: Latest Graal and AArch64 WTF? Message-ID: <090e9326-fa65-d924-bb6c-4a3367a0169c@redhat.com> The latest graalvm repos on github include a helpful source tree for building a JVMCI-enabled jdk8u: https://github.com/graalvm/graal-jvmci-8 and Oracle even offer a helpful, pre-built x86_64 download. This specific repo exists because -- for somewhat unaccountable (or at least unaccounted) reasons -- the mx scripts demand that you have a jdk8 available to execute some part of the build process /even if/ you are trying to build the Graal compiler using jdk11 (or the jdk dev tree) for use with jdk11 (or, respectively, the jdk dev tree). So, some version of the JVCMI code, lots of tooling patches (e.g. to the IdealGraphVisualizer) and a bunch of hotspot shared and CPU changes have been munged into a variant of the jdk8u hotspot src tree embedded in the above repo. Unfortunately, a big problem with this change to the build process is that this hotspot source tree is based on the upstream jdk8u repo and not on Red Hat's downstream jdk8u-aarch64 or jdk8u-shenandoah repos (the ones that include the AArch64 port of OpenJDK used by all Linux+AArch64 releases). As a consequence, it is now /impossible/ to build the Graal compiler on AArch64 without first porting all that hotspot gubbins into our downstream repo. Let me just restate that for emphasis: it is now /impossible/ to build, maintain, fix or in any way extend or improve the functionality of the Graal compiler on AArch64. The AArch64 bits are rotting as regards use on jdk8 or any other, later jdk. That makes the decision to make this change to the build system a rather bad one, in my opinion. I say that because having looked at the differences introduced into the above repo by diffing it with the corresponding jdk8u tree I am pretty sure that porting the changes it includes to our jdk8u-aarch64 tree is a non-starter. If the jdk8 back-porting effort had initially been done using our AArch64 tree this decision might not have been so awful, however distasteful I find the idea that you have to use two different JDKs to build Graal for a given target JDK. Given the current impasse as regards progress with AArch64 I think it is imperative that some way is found of building the Graal compiler using jdk11+ for target jdk11+ that does not also require a tweaked jdk8 compiler. I would like to fix whatever is needed in the Graal or JVMCI code or the mx scripts to make that possible. So, could someone provide the background rationale for this change and why it was seen as better than fixing the Graal, JVMCI and/or mx code? Does anyone have any other information that might help scope what would need to be changed in Graal, JVMCI or mx in order to allow JDK11 to generate a JDK11 compatible Graal compiler? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From doug.simon at oracle.com Thu Jul 26 10:54:05 2018 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 26 Jul 2018 12:54:05 +0200 Subject: Latest Graal and AArch64 WTF? In-Reply-To: <090e9326-fa65-d924-bb6c-4a3367a0169c@redhat.com> References: <090e9326-fa65-d924-bb6c-4a3367a0169c@redhat.com> Message-ID: <68DFF843-41D2-48F5-BE47-8C793A415513@oracle.com> Hi Andrew, Does the "JVMCI-jars-only" work-around described at http://mail.openjdk.java.net/pipermail/graal-dev/2018-June/005413.html not work for you? The original mail in that thread provides some background as to why the build change was made. In terms of making Graal not require a JVMCI JDK8 to build, one would need to factor out all code using API specific to a JDK version. For each body of such code, you'd have a "placeholder" source file specifying its API and overlays for each JDK version. Currently, we collapse the JDK8 overlay into the placeholder. As a concrete example of what I mean, today we have: src/org.graalvm.compiler.serviceprovider/src/org/graalvm/compiler/serviceprovider/GraalServices.java src/org.graalvm.compiler.serviceprovider.jdk9/src/org/graalvm/compiler/serviceprovider/GraalServices.java Where the first file specifies the API for GraalServices as well as its JDK8 implementation. We need to move to this instead: src/org.graalvm.compiler.serviceprovider/src/org/graalvm/compiler/serviceprovider/GraalServices.java src/org.graalvm.compiler.serviceprovider.jdk8/src/org/graalvm/compiler/serviceprovider/GraalServices.java src/org.graalvm.compiler.serviceprovider.jdk9/src/org/graalvm/compiler/serviceprovider/GraalServices.java Where the first file specifies only the API and all its methods simply throw some exception. In addition to the Java code changes, you'd also need to modify mx to consider JDK8 overlays (until now, overlay support is mostly in the JDK9+ parts of mx). -Doug > On 26 Jul 2018, at 12:29, Andrew Dinn wrote: > > The latest graalvm repos on github include a helpful source tree for > building a JVMCI-enabled jdk8u: > > https://github.com/graalvm/graal-jvmci-8 > > and Oracle even offer a helpful, pre-built x86_64 download. > > This specific repo exists because -- for somewhat unaccountable (or at > least unaccounted) reasons -- the mx scripts demand that you have a jdk8 > available to execute some part of the build process /even if/ you are > trying to build the Graal compiler using jdk11 (or the jdk dev tree) for > use with jdk11 (or, respectively, the jdk dev tree). > > So, some version of the JVCMI code, lots of tooling patches (e.g. to the > IdealGraphVisualizer) and a bunch of hotspot shared and CPU changes have > been munged into a variant of the jdk8u hotspot src tree embedded in the > above repo. > > Unfortunately, a big problem with this change to the build process is > that this hotspot source tree is based on the upstream jdk8u repo and > not on Red Hat's downstream jdk8u-aarch64 or jdk8u-shenandoah repos (the > ones that include the AArch64 port of OpenJDK used by all Linux+AArch64 > releases). > > As a consequence, it is now /impossible/ to build the Graal compiler on > AArch64 without first porting all that hotspot gubbins into our > downstream repo. > > Let me just restate that for emphasis: it is now /impossible/ to build, > maintain, fix or in any way extend or improve the functionality of the > Graal compiler on AArch64. The AArch64 bits are rotting as regards use > on jdk8 or any other, later jdk. > > That makes the decision to make this change to the build system a rather > bad one, in my opinion. I say that because having looked at the > differences introduced into the above repo by diffing it with the > corresponding jdk8u tree I am pretty sure that porting the changes it > includes to our jdk8u-aarch64 tree is a non-starter. > > If the jdk8 back-porting effort had initially been done using our > AArch64 tree this decision might not have been so awful, however > distasteful I find the idea that you have to use two different JDKs to > build Graal for a given target JDK. > > Given the current impasse as regards progress with AArch64 I think it is > imperative that some way is found of building the Graal compiler using > jdk11+ for target jdk11+ that does not also require a tweaked jdk8 > compiler. I would like to fix whatever is needed in the Graal or JVMCI > code or the mx scripts to make that possible. > > So, could someone provide the background rationale for this change and > why it was seen as better than fixing the Graal, JVMCI and/or mx code? > Does anyone have any other information that might help scope what would > need to be changed in Graal, JVMCI or mx in order to allow JDK11 to > generate a JDK11 compatible Graal compiler? > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Thu Jul 26 12:43:22 2018 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 26 Jul 2018 13:43:22 +0100 Subject: Latest Graal and AArch64 WTF? In-Reply-To: <68DFF843-41D2-48F5-BE47-8C793A415513@oracle.com> References: <090e9326-fa65-d924-bb6c-4a3367a0169c@redhat.com> <68DFF843-41D2-48F5-BE47-8C793A415513@oracle.com> Message-ID: <07fb1007-fb19-084d-40c2-08732e8d69fd@redhat.com> On 26/07/18 11:54, Doug Simon wrote: > Does the "JVMCI-jars-only" work-around described at > http://mail.openjdk.java.net/pipermail/graal-dev/2018-June/005413.html > not work for you? The original mail in that thread provides some > background as to why the build change was made. The workaround is news to me. I saw the first note about mx --strict-compliance being the only option available now but did not notice the comment in the follow-up about building for AArch64. Is this process advertised anywhere on the graal github sites? I couldn't find anything on either of these two sites: https://github.com/oracle/graal https://github.com/graalvm/graal-jvmci-8 If not perhaps it could be added to the instructions in https://github.com/oracle/graal/blob/master/compiler/README.md I'm still a little confused as to one specific though. Given that the workaround is happy to use a pre-supplied JDK8 to perform the build (modulo inclusion of the JVMCI jars overlay) why was there a need to modify the hotspot sources that sit in the graal-jvmci-8 repo? Are these hotspot changes needed to be able to run the JDK8 version of Graal on JDK8? i.e. does this mean it is not possible to use Graal on a standard jdk8 release? > In terms of making Graal not require a JVMCI JDK8 to build, one would > need to factor out all code using API specific to a JDK version. For > each body of such code, you'd have a "placeholder" source file > specifying its API and overlays for each JDK version. Currently, we > collapse the JDK8 overlay into the placeholder. As a concrete example > of what I mean, today we have: > > src/org.graalvm.compiler.serviceprovider/src/org/graalvm/compiler/serviceprovider/GraalServices.java > > src/org.graalvm.compiler.serviceprovider.jdk9/src/org/graalvm/compiler/serviceprovider/GraalServices.java> > Where the first file specifies the API for GraalServices as well as > its JDK8 implementation. > > We need to move to this instead: > > src/org.graalvm.compiler.serviceprovider/src/org/graalvm/compiler/serviceprovider/GraalServices.java > > src/org.graalvm.compiler.serviceprovider.jdk8/src/org/graalvm/compiler/serviceprovider/GraalServices.java> src/org.graalvm.compiler.serviceprovider.jdk9/src/org/graalvm/compiler/serviceprovider/GraalServices.java > > Where the first file specifies only the API and all its methods > simply throw some exception. > > In addition to the Java code changes, you'd also need to modify mx to > consider JDK8 overlays (until now, overlay support is mostly in the > JDK9+ parts of mx). Ok, thanks. I will try to use the recommended workaround and also look at what is involved in fixing the problem in the Graal tree. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From doug.simon at oracle.com Thu Jul 26 14:45:14 2018 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 26 Jul 2018 16:45:14 +0200 Subject: Latest Graal and AArch64 WTF? In-Reply-To: <07fb1007-fb19-084d-40c2-08732e8d69fd@redhat.com> References: <090e9326-fa65-d924-bb6c-4a3367a0169c@redhat.com> <68DFF843-41D2-48F5-BE47-8C793A415513@oracle.com> <07fb1007-fb19-084d-40c2-08732e8d69fd@redhat.com> Message-ID: Sent from my iPhone > On 26 Jul 2018, at 2:43 pm, Andrew Dinn wrote: > >> On 26/07/18 11:54, Doug Simon wrote: >> Does the "JVMCI-jars-only" work-around described at >> http://mail.openjdk.java.net/pipermail/graal-dev/2018-June/005413.html >> not work for you? The original mail in that thread provides some >> background as to why the build change was made. > > The workaround is news to me. I saw the first note about mx > --strict-compliance being the only option available now but did not > notice the comment in the follow-up about building for AArch64. > > Is this process advertised anywhere on the graal github sites? I > couldn't find anything on either of these two sites: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_oracle_graal&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=UrAmso6HA8BKFUisCMWn5d1wIPWq-LXoRtmMZjf0xxw&s=bJCsIW5H62r8M-ALQ2CTJG9dOjv7w_e0nU6U6RcA8hE&e= > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_graalvm_graal-2Djvmci-2D8&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=UrAmso6HA8BKFUisCMWn5d1wIPWq-LXoRtmMZjf0xxw&s=YO5VjUri8kyaU4kumOThuIiK1jWLQ1dLHVa6MQIjNBM&e= > > If not perhaps it could be added to the instructions in > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_oracle_graal_blob_master_compiler_README.md&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=UrAmso6HA8BKFUisCMWn5d1wIPWq-LXoRtmMZjf0xxw&s=TPTqRwkHUDf8LMw7GSd0JZ8HXbLlReRwcl4wx-o7pAg&e= > I?ll update the README as you suggest. > I'm still a little confused as to one specific though. Given that the > workaround is happy to use a pre-supplied JDK8 to perform the build > (modulo inclusion of the JVMCI jars overlay) why was there a need to > modify the hotspot sources that sit in the graal-jvmci-8 repo? Are these > hotspot changes needed to be able to run the JDK8 version of Graal on > JDK8? i.e. does this mean it is not possible to use Graal on a standard > jdk8 release? Correct. JVMCI is composed of both C++ code and Java code. You need both to execute JVMCI but only the latter to compile against JVMCI. > >> In terms of making Graal not require a JVMCI JDK8 to build, one would >> need to factor out all code using API specific to a JDK version. For >> each body of such code, you'd have a "placeholder" source file >> specifying its API and overlays for each JDK version. Currently, we >> collapse the JDK8 overlay into the placeholder. As a concrete example >> of what I mean, today we have: >> >> src/org.graalvm.compiler.serviceprovider/src/org/graalvm/compiler/serviceprovider/GraalServices.java >> >> src/org.graalvm.compiler.serviceprovider.jdk9/src/org/graalvm/compiler/serviceprovider/GraalServices.java> >> Where the first file specifies the API for GraalServices as well as >> its JDK8 implementation. >> >> We need to move to this instead: >> >> src/org.graalvm.compiler.serviceprovider/src/org/graalvm/compiler/serviceprovider/GraalServices.java >> >> src/org.graalvm.compiler.serviceprovider.jdk8/src/org/graalvm/compiler/serviceprovider/GraalServices.java> > src/org.graalvm.compiler.serviceprovider.jdk9/src/org/graalvm/compiler/serviceprovider/GraalServices.java >> >> Where the first file specifies only the API and all its methods >> simply throw some exception. >> >> In addition to the Java code changes, you'd also need to modify mx to >> consider JDK8 overlays (until now, overlay support is mostly in the >> JDK9+ parts of mx). > > Ok, thanks. I will try to use the recommended workaround and also look > at what is involved in fixing the problem in the Graal tree. Great! Please keep me in the loop as I would also like to remove this requirement for a JVMCI JDK8 to be able to develop Graal that will be deployed on JDK11. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From dms at samersoff.net Sun Jul 29 14:58:27 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Sun, 29 Jul 2018 17:58:27 +0300 Subject: Latest Graal and AArch64 WTF? In-Reply-To: <07fb1007-fb19-084d-40c2-08732e8d69fd@redhat.com> References: <090e9326-fa65-d924-bb6c-4a3367a0169c@redhat.com> <68DFF843-41D2-48F5-BE47-8C793A415513@oracle.com> <07fb1007-fb19-084d-40c2-08732e8d69fd@redhat.com> Message-ID: <24c4470b-6dab-f38f-b7ae-6bed6f33274d@samersoff.net> Andrew, Finally, I end up with script below building graal on AArch64 ===================================================== #!/bin/sh JDK8_STOCK=/export/dsamersoff/jdk1.8.0_172 JDK11_HOME=/export/dsamersoff/esc/graal/jdk/build/linux-aarch64-normal-server-fastdebug/jdk JDK8_HOME=/export/dsamersoff/esc/graal/graal-jvmci-8/jdk1.8.0_172/linux-aarch64/product JAVA_HOME=${JDK11_HOME} export JAVA_HOME ( cd graal-jvmci-8 ../mx/mx --java-home=${JDK8_STOCK} --vmbuild=product build --no-native ) cd graal/compiler ../../mx/mx --java-home=${JDK11_HOME} --extra-java-homes=${JDK8_HOME} -v build ============================================================================= On 07/26/2018 03:43 PM, Andrew Dinn wrote: > On 26/07/18 11:54, Doug Simon wrote: >> Does the "JVMCI-jars-only" work-around described at >> http://mail.openjdk.java.net/pipermail/graal-dev/2018-June/005413.html >> not work for you? The original mail in that thread provides some >> background as to why the build change was made. > > The workaround is news to me. I saw the first note about mx > --strict-compliance being the only option available now but did not > notice the comment in the follow-up about building for AArch64. > > Is this process advertised anywhere on the graal github sites? I > couldn't find anything on either of these two sites: > > https://github.com/oracle/graal > https://github.com/graalvm/graal-jvmci-8 > > If not perhaps it could be added to the instructions in > > https://github.com/oracle/graal/blob/master/compiler/README.md > > I'm still a little confused as to one specific though. Given that the > workaround is happy to use a pre-supplied JDK8 to perform the build > (modulo inclusion of the JVMCI jars overlay) why was there a need to > modify the hotspot sources that sit in the graal-jvmci-8 repo? Are these > hotspot changes needed to be able to run the JDK8 version of Graal on > JDK8? i.e. does this mean it is not possible to use Graal on a standard > jdk8 release? > >> In terms of making Graal not require a JVMCI JDK8 to build, one would >> need to factor out all code using API specific to a JDK version. For >> each body of such code, you'd have a "placeholder" source file >> specifying its API and overlays for each JDK version. Currently, we >> collapse the JDK8 overlay into the placeholder. As a concrete example >> of what I mean, today we have: >> >> src/org.graalvm.compiler.serviceprovider/src/org/graalvm/compiler/serviceprovider/GraalServices.java >> >> src/org.graalvm.compiler.serviceprovider.jdk9/src/org/graalvm/compiler/serviceprovider/GraalServices.java> >> Where the first file specifies the API for GraalServices as well as >> its JDK8 implementation. >> >> We need to move to this instead: >> >> src/org.graalvm.compiler.serviceprovider/src/org/graalvm/compiler/serviceprovider/GraalServices.java >> >> src/org.graalvm.compiler.serviceprovider.jdk8/src/org/graalvm/compiler/serviceprovider/GraalServices.java> > src/org.graalvm.compiler.serviceprovider.jdk9/src/org/graalvm/compiler/serviceprovider/GraalServices.java >> >> Where the first file specifies only the API and all its methods >> simply throw some exception. >> >> In addition to the Java code changes, you'd also need to modify mx to >> consider JDK8 overlays (until now, overlay support is mostly in the >> JDK9+ parts of mx). > > Ok, thanks. I will try to use the recommended workaround and also look > at what is involved in fixing the problem in the Graal tree. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ... From kovariadam at gmail.com Sun Jul 22 13:08:01 2018 From: kovariadam at gmail.com (=?utf-8?Q?Adam_K=C3=B6v=C3=A1ri?=) Date: Sun, 22 Jul 2018 15:08:01 +0200 Subject: NPE in PolyglotLanguageContext.toHostValue Message-ID: <5b5481b0.1c69fb81.79c3c.c380@mx.google.com> Hello, I am very interested in learning the Truffle API, I find it really amazing so far. I am trying to implement a simple expression language [1], based on SimpleLanguage project, but I got stuck and I am not really sure where the problem might be. Perhaps someone understands what this means? org.graalvm.polyglot.PolyglotException: java.lang.NullPointerException at com.oracle.truffle.api.vm.PolyglotLanguageContext.toHostValue(PolyglotLanguageContext.java:585) at com.oracle.truffle.api.vm.PolyglotContextImpl.eval(PolyglotContextImpl.java:789) at org.graalvm.polyglot.Context.eval(Context.java:313) at org.graalvm.polyglot.Context.eval(Context.java:338) at smol.SmolSimpleExpressionTest.unitValueTest(SmolSimpleExpressionTest.java:74) ? This can be easily reproduced by running: $ mvn tests My java version: $ java -version java version "1.8.0_172" Java(TM) SE Runtime Environment (build 1.8.0_172-b11) GraalVM 1.0.0-rc3 (build 25.71-b01-internal-jvmci-0.45, mixed mode) Would someone be able to advice, any ideas or pointers are most welcome. Thanks, Adam [1] https://github.com/akovari/smol From aph at redhat.com Sun Jul 29 23:56:55 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 30 Jul 2018 00:56:55 +0100 Subject: Latest Graal and AArch64 WTF? In-Reply-To: <24c4470b-6dab-f38f-b7ae-6bed6f33274d@samersoff.net> References: <090e9326-fa65-d924-bb6c-4a3367a0169c@redhat.com> <68DFF843-41D2-48F5-BE47-8C793A415513@oracle.com> <07fb1007-fb19-084d-40c2-08732e8d69fd@redhat.com> <24c4470b-6dab-f38f-b7ae-6bed6f33274d@samersoff.net> Message-ID: <6d41d432-f9da-7b45-75ca-96ccca007f80@redhat.com> On 07/29/2018 03:58 PM, Dmitry Samersoff wrote: > JDK8_STOCK=/export/dsamersoff/jdk1.8.0_172 > JDK11_HOME=/export/dsamersoff/esc/graal/jdk/build/linux-aarch64-normal-server-fastdebug/jdk > JDK8_HOME=/export/dsamersoff/esc/graal/graal-jvmci-8/jdk1.8.0_172/linux-aarch64/product So, which files did you download from where to get these? Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Mon Jul 30 08:59:25 2018 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 30 Jul 2018 09:59:25 +0100 Subject: Latest Graal and AArch64 WTF? In-Reply-To: <24c4470b-6dab-f38f-b7ae-6bed6f33274d@samersoff.net> References: <090e9326-fa65-d924-bb6c-4a3367a0169c@redhat.com> <68DFF843-41D2-48F5-BE47-8C793A415513@oracle.com> <07fb1007-fb19-084d-40c2-08732e8d69fd@redhat.com> <24c4470b-6dab-f38f-b7ae-6bed6f33274d@samersoff.net> Message-ID: Hi Dmitry, On 29/07/18 15:58, Dmitry Samersoff wrote: > Finally, I end up with script below building graal on AArch64 > > ===================================================== > #!/bin/sh > > JDK8_STOCK=/export/dsamersoff/jdk1.8.0_172 > JDK11_HOME=/export/dsamersoff/esc/graal/jdk/build/linux-aarch64-normal-server-fastdebug/jdk > JDK8_HOME=/export/dsamersoff/esc/graal/graal-jvmci-8/jdk1.8.0_172/linux-aarch64/product > > JAVA_HOME=${JDK11_HOME} > export JAVA_HOME > > ( > cd graal-jvmci-8 > ../mx/mx --java-home=${JDK8_STOCK} --vmbuild=product build --no-native > ) > > cd graal/compiler > ../../mx/mx --java-home=${JDK11_HOME} --extra-java-homes=${JDK8_HOME} -v > build > > ============================================================================= When you say "I end up with script below building graal on AArch64" what exactly are you claiming to have achieved? Are you saying that the product of the graal-jvmci-8 --no-native build (i.e. the code installed in subdir jdk1.8.0_172/linux-aarch64/product) is a jdk8 image that is capable of running the Graal compiler? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Zhongwei.Yao at arm.com Tue Jul 10 03:24:25 2018 From: Zhongwei.Yao at arm.com (Zhongwei Yao) Date: Tue, 10 Jul 2018 03:24:25 -0000 Subject: Will there be any "Graal Sync" for JDK 11 repo Message-ID: Hi, all, Since the following patch fixed a critical issue for ARMv8.1: https://github.com/oracle/graal/pull/484/commits/af8e8b56b93e14bcdb808f2ca8079e9256879af1 Without this fix, current OpenJDK AOT feature on ARMv8.1 system is not able to work. So my question is whether this fix will be included in the JDK 11 by some Graal to JDK 11 Sync? If not, shall I manually fix it in JDK11? -- Best regards, Zhongwei