From stewartd.qdt at qualcommdatacenter.com Fri Jun 1 14:41:21 2018 From: stewartd.qdt at qualcommdatacenter.com (stewartd.qdt) Date: Fri, 1 Jun 2018 14:41:21 +0000 Subject: Build issues Message-ID: <656b54c9085d4782ab036c20f4a1283e@NASANEXM01E.na.qualcomm.com> I was on holiday all this week and part of last. I'm attempting to build the latest Graal, using the tip of OpenJDK, as I've been doing for quite some time. But now it appears it doesn't work, as I get a lot of lines like: project org.graalvm.options was removed as JDK 1.8 is not available ... I never had an issue using OpenJDK 11 with Graal until now. Did something change that I am unaware of? Is JDK8 now required? I'm sure it is something simplistic. Daniel From doug.simon at oracle.com Fri Jun 1 14:54:36 2018 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 1 Jun 2018 16:54:36 +0200 Subject: mx: --strict-compliance is now the only supported mode In-Reply-To: <33169D9B-6891-4DBE-B53F-D556A3FB09DA@oracle.com> References: <33169D9B-6891-4DBE-B53F-D556A3FB09DA@oracle.com> Message-ID: <11EB13B6-4886-4CFA-854C-FAE005434130@oracle.com> Historically, mx has used a non-strict algorithm when deciding which JDK to use for compiling a project with Java compliance N. The motivation was to support using a single JDK for all compilation. For Java code that only uses public JDK API, this was not a problem. However, both Graal and SVM use non-public JDK API which complicates things. To make it possible to use javac from JDK 9 with a `--release 8` option to compile a project that uses JDK 8 internal API (e.g. sun.misc.Unsafe), mx provided skeletons for the API in question (e.g., Unsafe.java ) since the `--release` mechanism only provides symbol for public JDK API. However, this approach did not scale as it meant skeletons need to be provided for every internal API used by any mx project. A better approach is to simply enforce a strict JDK matching algorithm. That is, if a project has a Java compliance of 8, then a JDK 8 must be made available (via JAVA_HOME/EXTRA_JAVA_HOMES or --java-home/--extra-java-homes). Mx has now been changed to enforce this. Prior to this change, a Java compliance could be either exact or open ended: Compliance Value Compatible JDKs for compilation 8 JDK8 9+ JDK9, JDK10, JDK11, ... Since a project may use internal API that spans only a fixed set of JDKs, Java compliance now also supports a fixed range: Compliance Value Compatible JDKs for compilation 8 JDK8 9+ JDK9, JDK10, JDK11, ... 9..10 JDK9, JDK10 The lower bound in a fixed range specifies the language level. That is, it will be used as the value for the -source and -target javac options. One noticeable impact is that the auto-JDK-selection in mx has been moved to a separate utility: select_jdk.py. When mx cannot find a JDK it needs, you will now get an error message such as: -------------------------------------------------- Could not find a JDK The following JDKs are available: /Library/Java/JavaVirtualMachines/graalvm-1.0.0-rc1/Contents/Home /Library/Java/JavaVirtualMachines/jdk-10.jdk/Contents/Home /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home /Library/Java/JavaVirtualMachines/jdk-9.0.4.jdk/Contents/Home /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home /Library/Java/JavaVirtualMachines/jdk8u172-b11 /Library/Java/JavaVirtualMachines/labsjdk-20180522-073957 /Library/Java/JavaVirtualMachines/labsjdk1.8.0_161-jvmci-0.42/Contents/Home /Library/Java/JavaVirtualMachines/labsjdk1.8.0_171-jvmci-0.43/Contents/Home /Library/Java/JavaVirtualMachines/openjdk-10.jdk/Contents/Home Specify one with the --java-home or --extra-java-homes option or with the JAVA_HOME or EXTRA_JAVA_HOMES environment variable. Or run `/Users/dsimon/mx/select_jdk.py -p /Users/dsimon/graal/graal/compiler` to set and persist these variables in /Users/dsimon/graal/graal/compiler/mx.compiler/env. -------------------------------------------------- The last line shows you how to run the select_jdk.py utility to configure your env file. This utility can also be used to define a `select_jdk` shell function as described here: https://github.com/graalvm/mx/blob/master/select_jdk.py#L118-L129 Please feel free to reply or open mx issues on GitHub if you run into any problems as a result of this change. -Doug From gilles.m.duboscq at oracle.com Fri Jun 1 16:38:53 2018 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Fri, 1 Jun 2018 18:38:53 +0200 Subject: Build issues In-Reply-To: <656b54c9085d4782ab036c20f4a1283e@NASANEXM01E.na.qualcomm.com> References: <656b54c9085d4782ab036c20f4a1283e@NASANEXM01E.na.qualcomm.com> Message-ID: <29f7939f-445e-1eec-d105-45428ec2a8d9@oracle.com> Hi Daniel, This is due to a change in how `mx` builds. You now need to provide a JDK 8 to build graal. You can add the path to a JDK 8 in the EXTRA_JAVA_HOMES environment variable or with the --extra-java-homes argument to `mx`. Doug explained this in more details in a separate email on this list ("mx: --strict-compliance is now the only supported mode"). Gilles On 01/06/18 16:41, stewartd.qdt wrote: > I was on holiday all this week and part of last. I'm attempting to build the latest Graal, using the tip of OpenJDK, as I've been doing for quite some time. But now it appears it doesn't work, as I get a lot of lines like: > > project org.graalvm.options was removed as JDK 1.8 is not available > ... > > I never had an issue using OpenJDK 11 with Graal until now. Did something change that I am unaware of? Is JDK8 now required? I'm sure it is something simplistic. > > Daniel > From doug.simon at oracle.com Fri Jun 1 16:55:06 2018 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 1 Jun 2018 18:55:06 +0200 Subject: mx: --strict-compliance is now the only supported mode In-Reply-To: <11EB13B6-4886-4CFA-854C-FAE005434130@oracle.com> References: <33169D9B-6891-4DBE-B53F-D556A3FB09DA@oracle.com> <11EB13B6-4886-4CFA-854C-FAE005434130@oracle.com> Message-ID: <97544CD9-7FD9-4FD7-BDCB-3659AB493EDE@oracle.com> Note that the Graal sources in the JDK *do not* need multiple JDKs to be compiled. That is because we flatten[1] versioned sources when updating these sources. -Doug [1] https://github.com/oracle/graal/blob/master/compiler/mx.compiler/mx_compiler.py#L1256-L1257 > On 1 Jun 2018, at 16:54, Doug Simon wrote: > > Historically, mx has used a non-strict algorithm when deciding which JDK to use for compiling a project with Java compliance N. The motivation was to support using a single JDK for all compilation. For Java code that only uses public JDK API, this was not a problem. However, both Graal and SVM use non-public JDK API which complicates things. To make it possible to use javac from JDK 9 with a `--release 8` option to compile a project that uses JDK 8 internal API (e.g. sun.misc.Unsafe), mx provided skeletons for the API in question (e.g., Unsafe.java) since the `--release` mechanism only provides symbol for public JDK API. However, this approach did not scale as it meant skeletons need to be provided for every internal API used by any mx project. A better approach is to simply enforce a strict JDK matching algorithm. That is, if a project has a Java compliance of 8, then a JDK 8 must be made available (via JAVA_HOME/EXTRA_JAVA_HOMES or --java-home/--extra-java-homes). > > Mx has now been changed to enforce this. > Prior to this change, a Java compliance could be either exact or open ended: > Compliance Value Compatible JDKs for compilation > 8 JDK8 > 9+ JDK9, JDK10, JDK11, ... > > Since a project may use internal API that spans only a fixed set of JDKs, Java compliance now also supports a fixed range: > Compliance Value Compatible JDKs for compilation > 8 JDK8 > 9+ JDK9, JDK10, JDK11, ... > 9..10 JDK9, JDK10 > The lower bound in a fixed range specifies the language level. That is, it will be used as the value for the -source and -target javac options. > > One noticeable impact is that the auto-JDK-selection in mx has been moved to a separate utility: select_jdk.py. When mx cannot find a JDK it needs, you will now get an error message such as: > > -------------------------------------------------- > Could not find a JDK > The following JDKs are available: > /Library/Java/JavaVirtualMachines/graalvm-1.0.0-rc1/Contents/Home > /Library/Java/JavaVirtualMachines/jdk-10.jdk/Contents/Home > /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home > /Library/Java/JavaVirtualMachines/jdk-9.0.4.jdk/Contents/Home > /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home > /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home > /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home > /Library/Java/JavaVirtualMachines/jdk8u172-b11 > /Library/Java/JavaVirtualMachines/labsjdk-20180522-073957 > /Library/Java/JavaVirtualMachines/labsjdk1.8.0_161-jvmci-0.42/Contents/Home > /Library/Java/JavaVirtualMachines/labsjdk1.8.0_171-jvmci-0.43/Contents/Home > /Library/Java/JavaVirtualMachines/openjdk-10.jdk/Contents/Home > Specify one with the --java-home or --extra-java-homes option or with the JAVA_HOME or EXTRA_JAVA_HOMES environment variable. > Or run `/Users/dsimon/mx/select_jdk.py -p /Users/dsimon/graal/graal/compiler` to set and persist these variables in /Users/dsimon/graal/graal/compiler/mx.compiler/env. > -------------------------------------------------- > > The last line shows you how to run the select_jdk.py utility to configure your env file. > > This utility can also be used to define a `select_jdk` shell function as described here: > > https://github.com/graalvm/mx/blob/master/select_jdk.py#L118-L129 > > Please feel free to reply or open mx issues on GitHub if you run into any problems as a result of this change. > > -Doug > From doug.simon at oracle.com Sat Jun 2 11:31:56 2018 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 2 Jun 2018 13:31:56 +0200 Subject: Fwd: mx: --strict-compliance is now the only supported mode References: <97544CD9-7FD9-4FD7-BDCB-3659AB493EDE@oracle.com> Message-ID: As a result of the strict compliance change to mx, you now need an ARM JVMCI JDK8 to build Graal. Given that there is no JVMCI native port for ARM on JDK8, the solution is to create a JVMCI-jars-only JVMCI JDK8 for ARM. That is, take an ARM JDK8 binary (e.g. from http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html), set it as JAVA_HOME and then run `mx build --no-native` in graal-jvmci-8 (https://github.com/graalvm/graal-jvmci-8). This will produce a JDK that is an exact copy of the original with the JVMCI jars overlayed. Running `mx jdkhome` will show you where the copy was made. Obviously this JDK cannot be used to run Graal since all the native JVMCI code is missing but when assigned to the EXTRA_JAVA_HOMES env var, it will allow `mx build` to succeed. -Doug > Begin forwarded message: > > From: Doug Simon > Subject: Re: mx: --strict-compliance is now the only supported mode > Date: 1 June 2018 at 18:55:06 CEST > To: graal-dev , "hotspot-compiler-dev at openjdk.java.net compiler" > > Note that the Graal sources in the JDK *do not* need multiple JDKs to be compiled. That is because we flatten[1] versioned sources when updating these sources. > > -Doug > > [1] https://github.com/oracle/graal/blob/master/compiler/mx.compiler/mx_compiler.py#L1256-L1257 > >> On 1 Jun 2018, at 16:54, Doug Simon wrote: >> >> Historically, mx has used a non-strict algorithm when deciding which JDK to use for compiling a project with Java compliance N. The motivation was to support using a single JDK for all compilation. For Java code that only uses public JDK API, this was not a problem. However, both Graal and SVM use non-public JDK API which complicates things. To make it possible to use javac from JDK 9 with a `--release 8` option to compile a project that uses JDK 8 internal API (e.g. sun.misc.Unsafe), mx provided skeletons for the API in question (e.g., Unsafe.java) since the `--release` mechanism only provides symbol for public JDK API. However, this approach did not scale as it meant skeletons need to be provided for every internal API used by any mx project. A better approach is to simply enforce a strict JDK matching algorithm. That is, if a project has a Java compliance of 8, then a JDK 8 must be made available (via JAVA_HOME/EXTRA_JAVA_HOMES or --java-home/--extra-java-homes). >> >> Mx has now been changed to enforce this. >> Prior to this change, a Java compliance could be either exact or open ended: >> Compliance Value Compatible JDKs for compilation >> 8 JDK8 >> 9+ JDK9, JDK10, JDK11, ... >> >> Since a project may use internal API that spans only a fixed set of JDKs, Java compliance now also supports a fixed range: >> Compliance Value Compatible JDKs for compilation >> 8 JDK8 >> 9+ JDK9, JDK10, JDK11, ... >> 9..10 JDK9, JDK10 >> The lower bound in a fixed range specifies the language level. That is, it will be used as the value for the -source and -target javac options. >> >> One noticeable impact is that the auto-JDK-selection in mx has been moved to a separate utility: select_jdk.py. When mx cannot find a JDK it needs, you will now get an error message such as: >> >> -------------------------------------------------- >> Could not find a JDK >> The following JDKs are available: >> /Library/Java/JavaVirtualMachines/graalvm-1.0.0-rc1/Contents/Home >> /Library/Java/JavaVirtualMachines/jdk-10.jdk/Contents/Home >> /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home >> /Library/Java/JavaVirtualMachines/jdk-9.0.4.jdk/Contents/Home >> /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home >> /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home >> /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home >> /Library/Java/JavaVirtualMachines/jdk8u172-b11 >> /Library/Java/JavaVirtualMachines/labsjdk-20180522-073957 >> /Library/Java/JavaVirtualMachines/labsjdk1.8.0_161-jvmci-0.42/Contents/Home >> /Library/Java/JavaVirtualMachines/labsjdk1.8.0_171-jvmci-0.43/Contents/Home >> /Library/Java/JavaVirtualMachines/openjdk-10.jdk/Contents/Home >> Specify one with the --java-home or --extra-java-homes option or with the JAVA_HOME or EXTRA_JAVA_HOMES environment variable. >> Or run `/Users/dsimon/mx/select_jdk.py -p /Users/dsimon/graal/graal/compiler` to set and persist these variables in /Users/dsimon/graal/graal/compiler/mx.compiler/env. >> -------------------------------------------------- >> >> The last line shows you how to run the select_jdk.py utility to configure your env file. >> >> This utility can also be used to define a `select_jdk` shell function as described here: >> >> https://github.com/graalvm/mx/blob/master/select_jdk.py#L118-L129 >> >> Please feel free to reply or open mx issues on GitHub if you run into any problems as a result of this change. >> >> -Doug >> > From stewartd.qdt at qualcommdatacenter.com Mon Jun 4 14:58:58 2018 From: stewartd.qdt at qualcommdatacenter.com (stewartd.qdt) Date: Mon, 4 Jun 2018 14:58:58 +0000 Subject: getAndAddInt() breaks AOT compilation for AArch64 In-Reply-To: References: <9de6d9f5294d47479103091ace7fe110@NASANEXM01E.na.qualcomm.com> <95817229-7510-da47-050f-c344dbe530d7@redhat.com> <87910b7a-0045-43b1-4e18-8246a53e28c9@oracle.com> Message-ID: <4e8db75d6ce34de191e4803c377550b3@NASANEXM01E.na.qualcomm.com> I just uploaded a patch for this fix to https://github.com/oracle/graal/pull/446. It is essentially the same as Zhongwei proposed and does not contain any advanced handling for immediates. I think at this point simpler is better. It also appeared to me that Hotspot does not have special handling for the immediate cases either, so I chose the simple route. Please have a look and my apologies for the breakage. Daniel -----Original Message----- From: Zhongwei Yao [mailto:zhongwei.yao at linaro.org] Sent: Wednesday, May 30, 2018 5:43 AM To: dean.long at oracle.com Cc: Andrew Haley ; Daniel Stewart ; stewartd.qdt ; graal-dev at openjdk.java.net Subject: Re: getAndAddInt() breaks AOT compilation for AArch64 Hi, all, Since Daniel is on holiday, here are my 2 methods to get it pass: - one is a quick fix for this error (the fix doesn't include optimization for special-case integer values as Andrew mentioned). - and another is a workaround which disables "registerUnsafeReadAndAddPlugins" completely. Here are the patches: http://cr.openjdk.java.net/~zyao/getAndAddInt/ Both of them are OK when running "jaotc --output libjava.base.so --module java.base" and pass Graal unit tests. Could you take a review? And what shall I do if the patch is OK? Shall I create a pull request in Graal for it? Or should we just wait for Daniel's full fix for it? On 30 May 2018 at 06:51, wrote: > On 5/29/18 9:57 AM, Andrew Haley wrote: >> >> On 05/29/2018 05:45 PM, Daniel Stewart wrote: >>> >>> Unfortunately I'm on holiday until Friday and have no access to be >>> able to patch this. I'll work on it once I'm back if someone doesn't >>> get to it first. >>> >>> Sorry for the breakage. >> >> It's OK, we can work around it for now. Better that you get to fix >> it yourself. And if someone reading this is thinking about importing >> Graal to OpenJDK, this would not be a good time. >> :-) >> > > Can we include a work-around in the Graal import rather than delaying it? > > dl -- Best regards, Zhongwei From stefan.anzinger at oracle.com Mon Jun 4 15:27:53 2018 From: stefan.anzinger at oracle.com (Stefan Anzinger) Date: Mon, 4 Jun 2018 17:27:53 +0200 Subject: getAndAddInt() breaks AOT compilation for AArch64 In-Reply-To: <74169b68-7aa8-13b1-f9ae-13f90f1a75eb@oracle.com> References: <9de6d9f5294d47479103091ace7fe110@NASANEXM01E.na.qualcomm.com> <95817229-7510-da47-050f-c344dbe530d7@redhat.com> <87910b7a-0045-43b1-4e18-8246a53e28c9@oracle.com> <6a3418bc-5cc7-417e-c57a-7baa6f892eaa@redhat.com> <83162105-4edd-25e4-1ce1-16e8d2200281@redhat.com> <74169b68-7aa8-13b1-f9ae-13f90f1a75eb@oracle.com> Message-ID: On 05/30/2018 07:10 PM, dean.long at oracle.com wrote: > On 5/30/18 4:20 AM, Andrew Haley wrote: >> On 05/30/2018 10:43 AM, Andrew Haley wrote: >> I guess I don't have to create a pull request for this? >> > > I believe a pull request is going to be needed to get it upstream into > Graal, but I can include this patch in "JDK-8202670: Update Graal" to > allow the update to proceed. No PullRequest needed, the fix is already in the queue to be merged. It should be available on GitHub in the next hours. Stefan From stefan.anzinger at oracle.com Mon Jun 4 16:02:26 2018 From: stefan.anzinger at oracle.com (Stefan Anzinger) Date: Mon, 4 Jun 2018 18:02:26 +0200 Subject: getAndAddInt() breaks AOT compilation for AArch64 In-Reply-To: References: <9de6d9f5294d47479103091ace7fe110@NASANEXM01E.na.qualcomm.com> <95817229-7510-da47-050f-c344dbe530d7@redhat.com> <87910b7a-0045-43b1-4e18-8246a53e28c9@oracle.com> <6a3418bc-5cc7-417e-c57a-7baa6f892eaa@redhat.com> <83162105-4edd-25e4-1ce1-16e8d2200281@redhat.com> <74169b68-7aa8-13b1-f9ae-13f90f1a75eb@oracle.com> Message-ID: <83a12959-9c43-eb03-a952-3412c22cdaea@oracle.com> On 06/04/2018 05:27 PM, Stefan Anzinger wrote: > > > On 05/30/2018 07:10 PM, dean.long at oracle.com wrote: > > No PullRequest needed, the fix is already in the queue to be merged. It > should be available on GitHub in the next hours. Ok, PR is already opened. I'm going to integrate https://github.com/oracle/graal/pull/446 Stefan From aph at redhat.com Mon Jun 4 16:21:35 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 4 Jun 2018 17:21:35 +0100 Subject: getAndAddInt() breaks AOT compilation for AArch64 In-Reply-To: <4e8db75d6ce34de191e4803c377550b3@NASANEXM01E.na.qualcomm.com> References: <9de6d9f5294d47479103091ace7fe110@NASANEXM01E.na.qualcomm.com> <95817229-7510-da47-050f-c344dbe530d7@redhat.com> <87910b7a-0045-43b1-4e18-8246a53e28c9@oracle.com> <4e8db75d6ce34de191e4803c377550b3@NASANEXM01E.na.qualcomm.com> Message-ID: On 06/04/2018 03:58 PM, stewartd.qdt wrote: > It is essentially the same as Zhongwei proposed and does not contain any advanced handling for immediates. I think at this point simpler is better. It also appeared to me that Hotspot does not have special handling for the immediate cases either It does so! instruct get_and_addL(indirect mem, iRegLNoSp newval, iRegL incr) %{ match(Set newval (GetAndAddL mem incr)); ins_cost(INSN_COST * 10); format %{ "get_and_addL $newval, [$mem], $incr" %} ins_encode %{ __ atomic_add($newval$$Register, $incr$$Register, as_Register($mem$$base)); %} ins_pipe(pipe_serial); %} instruct get_and_addLi(indirect mem, iRegLNoSp newval, immLAddSub incr) %{ match(Set newval (GetAndAddL mem incr)); ins_cost(INSN_COST * 10); format %{ "get_and_addL $newval, [$mem], $incr" %} ins_encode %{ __ atomic_add($newval$$Register, $incr$$constant, as_Register($mem$$base)); %} ins_pipe(pipe_serial); %} > so I chose the simple route. Hmm. Given that actually fixing it properly with an immediate increment isn't hard, I'm not sure I agree. Sure, it's not a huge deal. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From stewartd.qdt at qualcommdatacenter.com Mon Jun 4 16:25:48 2018 From: stewartd.qdt at qualcommdatacenter.com (stewartd.qdt) Date: Mon, 4 Jun 2018 16:25:48 +0000 Subject: getAndAddInt() breaks AOT compilation for AArch64 In-Reply-To: References: <9de6d9f5294d47479103091ace7fe110@NASANEXM01E.na.qualcomm.com> <95817229-7510-da47-050f-c344dbe530d7@redhat.com> <87910b7a-0045-43b1-4e18-8246a53e28c9@oracle.com> <4e8db75d6ce34de191e4803c377550b3@NASANEXM01E.na.qualcomm.com> Message-ID: <81e009810a424f44bd4a56b438d8b347@NASANEXM01E.na.qualcomm.com> Ah, I see! Thanks for pointing that out. I'll look at this as a separate patch. Daniel -----Original Message----- From: Andrew Haley [mailto:aph at redhat.com] Sent: Monday, June 4, 2018 12:22 PM To: stewartd.qdt ; graal-dev at openjdk.java.net Cc: Zhongwei Yao ; dean.long at oracle.com Subject: Re: getAndAddInt() breaks AOT compilation for AArch64 On 06/04/2018 03:58 PM, stewartd.qdt wrote: > It is essentially the same as Zhongwei proposed and does not contain > any advanced handling for immediates. I think at this point simpler is > better. It also appeared to me that Hotspot does not have special > handling for the immediate cases either It does so! instruct get_and_addL(indirect mem, iRegLNoSp newval, iRegL incr) %{ match(Set newval (GetAndAddL mem incr)); ins_cost(INSN_COST * 10); format %{ "get_and_addL $newval, [$mem], $incr" %} ins_encode %{ __ atomic_add($newval$$Register, $incr$$Register, as_Register($mem$$base)); %} ins_pipe(pipe_serial); %} instruct get_and_addLi(indirect mem, iRegLNoSp newval, immLAddSub incr) %{ match(Set newval (GetAndAddL mem incr)); ins_cost(INSN_COST * 10); format %{ "get_and_addL $newval, [$mem], $incr" %} ins_encode %{ __ atomic_add($newval$$Register, $incr$$constant, as_Register($mem$$base)); %} ins_pipe(pipe_serial); %} > so I chose the simple route. Hmm. Given that actually fixing it properly with an immediate increment isn't hard, I'm not sure I agree. Sure, it's not a huge deal. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vladimir.kozlov at oracle.com Mon Jun 4 17:38:32 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 4 Jun 2018 10:38:32 -0700 Subject: RFR (S) 8204237: Clean up incorrectly included .inline.hpp files from jvmciJavaClasses.hpp In-Reply-To: <05e83d76-d784-6360-3b88-06c5db1848c2@oracle.com> References: <05e83d76-d784-6360-3b88-06c5db1848c2@oracle.com> Message-ID: <2463b3b2-317a-5e2e-4fb6-3cc113b8b576@oracle.com> Looks good to me. We need review from Labs and push it up-stream to Lab's jvmci repo. Thanks, Vladimir On 6/4/18 10:12 AM, coleen.phillimore at oracle.com wrote: > Summary: Reexpand macro to provide non-inline functions. > > open webrev at http://cr.openjdk.java.net/~coleenp/8204237.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8204237 > > Ran mach5 hs-tier1-2 on 4 Oracle platforms.?? There are no > target-dependent changes. > > Thanks, > Coleen From coleen.phillimore at oracle.com Mon Jun 4 18:41:05 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 4 Jun 2018 14:41:05 -0400 Subject: RFR (S) 8204237: Clean up incorrectly included .inline.hpp files from jvmciJavaClasses.hpp In-Reply-To: <2463b3b2-317a-5e2e-4fb6-3cc113b8b576@oracle.com> References: <05e83d76-d784-6360-3b88-06c5db1848c2@oracle.com> <2463b3b2-317a-5e2e-4fb6-3cc113b8b576@oracle.com> Message-ID: <5498e07a-8899-72fe-6809-5a8b12f696c5@oracle.com> Thanks Vladimir and for including the graal-dev mailing list. Coleen On 6/4/18 1:38 PM, Vladimir Kozlov wrote: > Looks good to me. > > We need review from Labs and push it up-stream to Lab's jvmci repo. > > Thanks, > Vladimir > > On 6/4/18 10:12 AM, coleen.phillimore at oracle.com wrote: >> Summary: Reexpand macro to provide non-inline functions. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8204237.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8204237 >> >> Ran mach5 hs-tier1-2 on 4 Oracle platforms.?? There are no >> target-dependent changes. >> >> Thanks, >> Coleen From lars.schuetze at tu-dresden.de Tue Jun 5 11:05:52 2018 From: lars.schuetze at tu-dresden.de (Lars Schuetze) Date: Tue, 5 Jun 2018 11:05:52 +0000 Subject: graal-dev Digest, Vol 74, Issue 16 In-Reply-To: References: Message-ID: Hello Jaroslav, hello Christian, Thanks for your responses and sorry for my long delayed answer. Comments are in between your answers. Cheers, Lars Sch?tze ------------------------------ Message: 3 Date: Fri, 20 Apr 2018 09:40:09 +0200 From: Jaroslav Tulach > To: graal-dev at openjdk.java.net Subject: Re: Change other languages behaviour from own Truffle language Message-ID: <3465599.iYtrGxq7Rf at pracovni> Content-Type: text/plain; charset="UTF-8" Hello Lars, this is interesting topic. On p?tek 20. dubna 2018 6:22:29 CEST Lars Schuetze wrote: We currently do research on role-oriented programming languages. Role-orientation is an enhancement of object-orientation such that objects can play roles. I assume [DCI](http://wiki.apidesign.org/wiki/DCI) is an example of such role orientation. Yes, DCI is one of the early examples, ie., the program can be composed out of parts that are modelled in isolation (ie. grouped wrt. their context). Well known implementations in programming languages are Object Teams / Java [OTJ](https://www.eclipse.org/objectteams/) or another implementation of one of my colleagues named [SCROLL](https://github.com/max-leuthaeuser/SCROLL). They both implement roles and context (the latter is named Teams in OTJ, Compartment in SCROLL). However, OTJ resembles crosscutting (ie. aspect-oriented) roles, where SCROLL resembles fine-grained (ie. like dynamic programming languages) roles that are bound to individual objects. They both implement roles from the different ends of a scale. By doing so, their type and behaviour (ie., method dispatch) is changed. For example, first a.m() dispatches to method m implemented in class A. But after playing the role r, a.m() will be dispatched to method f in R. "after playing" or "while playing"? As far as I know in DCI the objects can be added to an "interaction" and while they are in the interaction they play the roles. Outside of (and "after") the interaction the objects behave normally. Actually, I meant something ?after beginning to play? because roles can also be stopped playing. This is similar to DCI interactions. However, for OTJ role types define a priori which class is playing that role (e.g., class RoleType playedBy SomeSpecificClass) while SCROLL allows to play roles by different objects of different types. This resembles dynamic programming languages. Also, there exist operators like in aspect-orientation that can change instances of classes in a crosscutting manner. Roles themselves define methods etc. just like normal classes. However, they cannot exist on their own. They always have to be played by objects. Currently, there exist some implementations for these languages. For example, SCROLL (Scala Roles Language) [1] is implemented in Scala using the Dynamic trait and a handwritten dispatch implementation in userland to cope with the different memory model of roles. Eclipse ObjectTeams on the other hand is implemented in Java as an extension of JDT and also employs a load time compiler built with the ASM library. It is able to adapt existing and compiled applications with roles. It also has a handwritten runtime in userland. Java and Scala are statically compiled languages and the JVM doesn't make this kind of meta-programming completely easy. (Truffle) Dynamic languages may be more suited for this kind of manipulations by their natural virtue. My question would be if by using Truffle we would be able to implement such a behaviour that when calling a method a.m() in language A it will be dispatched to a method r.f() in our language? I believe it could be done with the decorator. All Truffle languages are supposed to work with [foreign objects](http://www.graalvm.org/truffle/javadoc/ com/oracle/truffle/api/interop/TruffleObject.html] - if you can wrap/decorate the object "a" from language A by your instance and pass it back, you will control everything including dispatch. The decorator pattern is also a possible implementation for roles in object-oriented programming. This also is similar to composition filters (ie. the filters decide how messages are passed) which also allow to implement some notion of roles. I see that we could use Truffle to implement a language that can have that behaviour in its own but I don?t see if it is possible to change the behaviour of other languages from ours. By passing your own instance of `TruffleObject` into a foreign language you basically take over all the [classical operations/messages](http:// www.graalvm.org/truffle/javadoc/com/oracle/truffle/api/interop/Message.html) languages perform. Invocation, property access, etc. all gets routed through you and you can perform any magic you need. I'd suggest you start with [MessageResolution](http://www.graalvm.org/truffle/ javadoc/com/oracle/truffle/api/interop/MessageResolution.html) sample. That should give you overview of the possibilities. Good luck. -jt ------------------------------ Message: 4 Date: Fri, 20 Apr 2018 09:37:20 +0000 From: Christian Humer > To: Lars Sch?tze > Cc: graal-dev at openjdk.java.net Subject: Re: Change other languages behaviour from own Truffle language Message-ID: > Content-Type: text/plain; charset="UTF-8" Hi Lars, I think Jaroslav already gave a good answer. I'd like the add that the problem with the proposed approach is that interop is not a full abstraction of the target language. It only abstracts part of the target language functionality. While we have the aim to close this gap as much as possible, you will experience a difference when you take, e.g. a JavaScript object wrap it using your own TruffleObject to intercept the behavior and then pass it again to JavaScript. The reason is that JavaScript handles JavaScript objects different to interop objects. So while I think this it is a good approach for a research prototype, the challenge will be to support it fully to preserve full language semantics. Also it requires to wrap all the objects which might come at a cost. Current implementations already pay a high cost for these features (and possible memory leaks) because context?s need to store instances of classes that are already playing instances of roles (ie. state is preserved and stored in instances). For example, because of features provided by SCROLL it stores a view of the object graph again in the runtime. If we are willing the change the languages for this feature, more solutions to this problem become available. For example, we could also use internal keys in interop. I am roughly thinking about something like magic methods. There could be some convention for an object that if it has an internal key called "__call_handler__" that it invokes that handler if its defined on the object. The language would need to implement support for this magic method for all of its dispatches. Sounds interesting, if the object does not play multiple roles at once. Otherwise, I think we need such a ?__call_handler__? for each active context the object is part of. Normally, the partial order of functions is defined by the order of context activation (ie. least activated context has highest priority), but SCROLL allows user defined dispatch queries which allow a reordering PER roleplaying object by user-defined dispatch queries. A third option that comes to my mind, would be to standardize invokes (receiver, target, arguments) in Truffle and allow instrumentation of those as cross cutting concern. That would be awesome. Cheers, - Christian Humer On Fri, Apr 20, 2018 at 9:40 AM Jaroslav Tulach > wrote: Hello Lars, this is interesting topic. On p?tek 20. dubna 2018 6:22:29 CEST Lars Schuetze wrote: We currently do research on role-oriented programming languages. Role-orientation is an enhancement of object-orientation such that objects can play roles. I assume [DCI](http://wiki.apidesign.org/wiki/DCI) is an example of such role orientation. By doing so, their type and behaviour (ie., method dispatch) is changed. For example, first a.m() dispatches to method m implemented in class A. But after playing the role r, a.m() will be dispatched to method f in R. "after playing" or "while playing"? As far as I know in DCI the objects can be added to an "interaction" and while they are in the interaction they play the roles. Outside of (and "after") the interaction the objects behave normally. Also, there exist operators like in aspect-orientation that can change instances of classes in a crosscutting manner. Roles themselves define methods etc. just like normal classes. However, they cannot exist on their own. They always have to be played by objects. Currently, there exist some implementations for these languages. For example, SCROLL (Scala Roles Language) [1] is implemented in Scala using the Dynamic trait and a handwritten dispatch implementation in userland to cope with the different memory model of roles. Eclipse ObjectTeams on the other hand is implemented in Java as an extension of JDT and also employs a load time compiler built with the ASM library. It is able to adapt existing and compiled applications with roles. It also has a handwritten runtime in userland. Java and Scala are statically compiled languages and the JVM doesn't make this kind of meta-programming completely easy. (Truffle) Dynamic languages may be more suited for this kind of manipulations by their natural virtue. My question would be if by using Truffle we would be able to implement such a behaviour that when calling a method a.m() in language A it will be dispatched to a method r.f() in our language? I believe it could be done with the decorator. All Truffle languages are supposed to work with [foreign objects]( http://www.graalvm.org/truffle/javadoc/ com/oracle/truffle/api/interop/TruffleObject.html ] - if you can wrap/decorate the object "a" from language A by your instance and pass it back, you will control everything including dispatch. I see that we could use Truffle to implement a language that can have that behaviour in its own but I don?t see if it is possible to change the behaviour of other languages from ours. By passing your own instance of `TruffleObject` into a foreign language you basically take over all the [classical operations/messages](http:// www.graalvm.org/truffle/javadoc/com/oracle/truffle/api/interop/Message.html) languages perform. Invocation, property access, etc. all gets routed through you and you can perform any magic you need. I'd suggest you start with [MessageResolution]( http://www.graalvm.org/truffle/ javadoc/com/oracle/truffle/api/interop/MessageResolution.html ) sample. That should give you overview of the possibilities. Good luck. -jt End of graal-dev Digest, Vol 74, Issue 16 ***************************************** From doug.simon at oracle.com Tue Jun 5 13:34:06 2018 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 5 Jun 2018 15:34:06 +0200 Subject: RFR (S) 8204237: Clean up incorrectly included .inline.hpp files from jvmciJavaClasses.hpp In-Reply-To: <5498e07a-8899-72fe-6809-5a8b12f696c5@oracle.com> References: <05e83d76-d784-6360-3b88-06c5db1848c2@oracle.com> <2463b3b2-317a-5e2e-4fb6-3cc113b8b576@oracle.com> <5498e07a-8899-72fe-6809-5a8b12f696c5@oracle.com> Message-ID: The changes look ok to me. I don't think there's any need for an "up stream" push Vladimir as these are only JVMCI changes, not Graal changes. -Doug > On 4 Jun 2018, at 20:41, coleen.phillimore at oracle.com wrote: > > > Thanks Vladimir and for including the graal-dev mailing list. > Coleen > > On 6/4/18 1:38 PM, Vladimir Kozlov wrote: >> Looks good to me. >> >> We need review from Labs and push it up-stream to Lab's jvmci repo. >> >> Thanks, >> Vladimir >> >> On 6/4/18 10:12 AM, coleen.phillimore at oracle.com wrote: >>> Summary: Reexpand macro to provide non-inline functions. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8204237.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8204237 >>> >>> Ran mach5 hs-tier1-2 on 4 Oracle platforms. There are no target-dependent changes. >>> >>> Thanks, >>> Coleen > From dean.long at oracle.com Wed Jun 6 00:23:41 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 5 Jun 2018 17:23:41 -0700 Subject: RFR(S) 8204199: Test fails after 8202670 Graal update Message-ID: <97dccb58-f05c-b9eb-619e-d63c77d31d4f@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8204199 http://cr.openjdk.java.net/~dlong/8204199/webrev/ I cherry-picked the fix for this from Graal, rather than wait for 8204231. Graal change is here: https://github.com/oracle/graal/commit/80b18b329f04b8ef75b4c367413a2de51c82f3d9 dl From tobias.hartmann at oracle.com Wed Jun 6 06:50:04 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 6 Jun 2018 08:50:04 +0200 Subject: RFR(S) 8204199: Test fails after 8202670 Graal update In-Reply-To: <97dccb58-f05c-b9eb-619e-d63c77d31d4f@oracle.com> References: <97dccb58-f05c-b9eb-619e-d63c77d31d4f@oracle.com> Message-ID: <91e2f14b-d719-b572-8e59-297cc9912b0e@oracle.com> Hi Dean, looks good. Best regards, Tobias On 06.06.2018 02:23, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8204199 > http://cr.openjdk.java.net/~dlong/8204199/webrev/ > > I cherry-picked the fix for this from Graal, rather than wait for 8204231. > > Graal change is here: > > https://github.com/oracle/graal/commit/80b18b329f04b8ef75b4c367413a2de51c82f3d9 > > dl From stewartd.qdt at qualcommdatacenter.com Wed Jun 6 15:47:28 2018 From: stewartd.qdt at qualcommdatacenter.com (stewartd.qdt) Date: Wed, 6 Jun 2018 15:47:28 +0000 Subject: getAndAddInt() breaks AOT compilation for AArch64 In-Reply-To: <81e009810a424f44bd4a56b438d8b347@NASANEXM01E.na.qualcomm.com> References: <9de6d9f5294d47479103091ace7fe110@NASANEXM01E.na.qualcomm.com> <95817229-7510-da47-050f-c344dbe530d7@redhat.com> <87910b7a-0045-43b1-4e18-8246a53e28c9@oracle.com> <4e8db75d6ce34de191e4803c377550b3@NASANEXM01E.na.qualcomm.com> <81e009810a424f44bd4a56b438d8b347@NASANEXM01E.na.qualcomm.com> Message-ID: <81934358d61f4f3fbd8c213a1208f813@NASANEXM01E.na.qualcomm.com> Please review the patch at https://github.com/oracle/graal/pull/453, which attempts to implement the support for immediate values in getAndAddInt(). Daniel -----Original Message----- From: stewartd.qdt Sent: Monday, June 4, 2018 12:26 PM To: Andrew Haley ; stewartd.qdt ; graal-dev at openjdk.java.net Cc: Zhongwei Yao ; dean.long at oracle.com Subject: RE: getAndAddInt() breaks AOT compilation for AArch64 Ah, I see! Thanks for pointing that out. I'll look at this as a separate patch. Daniel -----Original Message----- From: Andrew Haley [mailto:aph at redhat.com] Sent: Monday, June 4, 2018 12:22 PM To: stewartd.qdt ; graal-dev at openjdk.java.net Cc: Zhongwei Yao ; dean.long at oracle.com Subject: Re: getAndAddInt() breaks AOT compilation for AArch64 On 06/04/2018 03:58 PM, stewartd.qdt wrote: > It is essentially the same as Zhongwei proposed and does not contain > any advanced handling for immediates. I think at this point simpler is > better. It also appeared to me that Hotspot does not have special > handling for the immediate cases either It does so! instruct get_and_addL(indirect mem, iRegLNoSp newval, iRegL incr) %{ match(Set newval (GetAndAddL mem incr)); ins_cost(INSN_COST * 10); format %{ "get_and_addL $newval, [$mem], $incr" %} ins_encode %{ __ atomic_add($newval$$Register, $incr$$Register, as_Register($mem$$base)); %} ins_pipe(pipe_serial); %} instruct get_and_addLi(indirect mem, iRegLNoSp newval, immLAddSub incr) %{ match(Set newval (GetAndAddL mem incr)); ins_cost(INSN_COST * 10); format %{ "get_and_addL $newval, [$mem], $incr" %} ins_encode %{ __ atomic_add($newval$$Register, $incr$$constant, as_Register($mem$$base)); %} ins_pipe(pipe_serial); %} > so I chose the simple route. Hmm. Given that actually fixing it properly with an immediate increment isn't hard, I'm not sure I agree. Sure, it's not a huge deal. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vladimir.kozlov at oracle.com Wed Jun 6 16:33:27 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 6 Jun 2018 09:33:27 -0700 Subject: RFR(S) 8204199: Test fails after 8202670 Graal update In-Reply-To: <91e2f14b-d719-b572-8e59-297cc9912b0e@oracle.com> References: <97dccb58-f05c-b9eb-619e-d63c77d31d4f@oracle.com> <91e2f14b-d719-b572-8e59-297cc9912b0e@oracle.com> Message-ID: <754b8285-dc83-bbfa-c080-a869dbd05492@oracle.com> +1 Thanks, Vladimir On 6/5/18 11:50 PM, Tobias Hartmann wrote: > Hi Dean, > > looks good. > > Best regards, > Tobias > > On 06.06.2018 02:23, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8204199 >> http://cr.openjdk.java.net/~dlong/8204199/webrev/ >> >> I cherry-picked the fix for this from Graal, rather than wait for 8204231. >> >> Graal change is here: >> >> https://github.com/oracle/graal/commit/80b18b329f04b8ef75b4c367413a2de51c82f3d9 >> >> dl From dean.long at oracle.com Wed Jun 6 16:37:05 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 6 Jun 2018 09:37:05 -0700 Subject: RFR(S) 8204199: Test fails after 8202670 Graal update In-Reply-To: <754b8285-dc83-bbfa-c080-a869dbd05492@oracle.com> References: <97dccb58-f05c-b9eb-619e-d63c77d31d4f@oracle.com> <91e2f14b-d719-b572-8e59-297cc9912b0e@oracle.com> <754b8285-dc83-bbfa-c080-a869dbd05492@oracle.com> Message-ID: <5a7863dc-74a4-9bff-5e3b-9efe5f541ce0@oracle.com> Thanks Tobias and Vladimir. dl On 6/6/18 9:33 AM, Vladimir Kozlov wrote: > +1 > > Thanks, > Vladimir > > On 6/5/18 11:50 PM, Tobias Hartmann wrote: >> Hi Dean, >> >> looks good. >> >> Best regards, >> Tobias >> >> On 06.06.2018 02:23, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8204199 >>> http://cr.openjdk.java.net/~dlong/8204199/webrev/ >>> >>> I cherry-picked the fix for this from Graal, rather than wait for >>> 8204231. >>> >>> Graal change is here: >>> >>> https://github.com/oracle/graal/commit/80b18b329f04b8ef75b4c367413a2de51c82f3d9 >>> >>> >>> dl From charig at gmail.com Wed Jun 13 19:16:48 2018 From: charig at gmail.com (Guido Chari) Date: Wed, 13 Jun 2018 21:16:48 +0200 Subject: =?UTF-8?Q?CfP=3A_3rd_Workshop_on_Meta=2DProgramming_Techniques_and?= =?UTF-8?Q?_Reflection_=28Meta=E2=80=9918=29=2C_Co=2Dlocated_with_SPLASH_2018?= Message-ID: *======================================================================== Call for Papers 3rd Workshop on Meta-Programming Techniques and Reflection (Meta?18) Co-located with SPLASH 2018 November 6, 2018, Boston, USA https://2018.splashcon.org/track/meta-2018 Follow us on twitter @MetaAtSPLASH======================================================================== The Meta?18 workshop aims to bring together researchers working onmetaprogramming and reflection, as well as users buildingapplications, language extensions, or software tools using them.The changing hardware and software landscape, and the increasedheterogeneity of systems make metaprogramming once more an importantresearch topic to handle the associate complexity. The challenges which metaprogramming faces are manifold. They startwith typing of reflective programs, continue with performance andtooling, and reach into the empirical field to understand howmetaprogramming is used and how it affects software maintainability.While industry accepted metaprogramming on a wide scale with Ruby,Scala, JavaScript and others, academia still needs to bring it tothe same level of convenience, tooling, and understanding as fordirect programming styles. Contributions to the workshop are welcome on a wide range of topicsrelated to the design, implementation, and application ofmetaprogramming techniques, as well as empirical studies on typingmodels for such systems and languages.### Topics of InterestThe workshop is a venue for all approaches that embracemetaprogramming, from static to dynamic techniques:- reflection, meta-level architectures, staging, open language runtimes applications to middleware, frameworks, and DSLs- optimization techniques - contract systems, or typing of reflective programs - reflection and metaobject protocols to enable tooling- case studies and evaluation of such techniques, e.g., to build applications, language extensions, or tools- empirical evaluation of metaprogramming solutions- security in reflective systems and capability-based designs- meta-level architectures and reflective middleware for modern runtime platforms (e.g. IoT, cyber-physical systems, mobile/cloud/grid computing, etc)- surveys, conceptualization, and taxonomization of existing approachesIn short, we invite contributions to the workshop on a wide range oftopics related to design, implementation, and application ofreflective APIs and meta-programming techniques, as well asempirical studies and typing for such systems and languages.### Workshop Format and SubmissionsThis workshop welcomes the presentation of new ideas and emergingproblems as well as mature work as part of a mini-conference format.Furthermore, we plan interactive brainstorming and demonstrationsessions between the formal presentations to enable an activeexchange of ideas. Papers submitted by the first deadline will be considered forpublication in the ACM DL, if not requested otherwise by the authors.Thus, they will be part of SPLASH workshop proceedings.For all papers, use of the SIGPLAN acmart style is mandatory: http://www.sigplan.org/Resources/Author/ .Please use the provided double-column templates for Latex or Word. technical paper: max. 8 pages, excluding references position and work-in-progress paper: 1-4 pages, excluding references technology demos or a posters: 1-page abstractDemos, posters, position and work-in-progress papers can be submittedon a second, later deadline to discuss the latest results and currentwork, but will not be considered for publication in the ACM DL.For the submission, please use the submission system at: https://meta18.hotcrp.com/ ### Important Dates7 Aug 2018 - Abstract Submission17 Aug 2018 - Paper Submission (considered for ACM DL)14 Sep 2018 - Notification7 Sep 2018 - Demo, position or work-in-progress paper submission30 Sep 2018 - Demo, position or work-in-progress paper notification6 Nov 2018 - Workshop### Organizing CommitteeGuido Chari, Czech Technical University Elisa Gonzalez Boix, Vrije Universiteit BrusselStefan Marr, University of Kent### Program CommitteeAnya Helene Bagge, University of Bergen, NorwayCamilo Bruni, Google, GermanyWalter Cazzola, Universit? degli Studi di Milano, ItalyPascal Costanza, imecMarcus Denker, INRIA, LilleMatthew Flatt, University of Utah, United StatesDiego Garbervetsky, University of Buenos Aires, ArgentinaEduardo Guerra, INPE, National Institute for Space ResearchPablo Inostroza, CWI, NetherlandsHidehiko Masuhara, Tokyo Institute of Technology ,JapanTom Van Cutsem, Nokia Bell Labs, Belgium* From java at stefan-marr.de Thu Jun 14 15:42:17 2018 From: java at stefan-marr.de (Stefan Marr) Date: Thu, 14 Jun 2018 16:42:17 +0100 Subject: =?utf-8?Q?=5BCFP=5D_Workshop_on_Virtual_Machines_and_Language_Imp?= =?utf-8?Q?lementations_=28VMIL=E2=80=9918=29?= Message-ID: <3CBA3996-37C8-4FAB-90F6-965D4E04E1EF@stefan-marr.de> ======================================================================== Call for Papers Workshop on Virtual Machines and Language Implementations (VMIL?18) Co-located with SPLASH 2018 November 4, 2018, Boston, USA https://2018.splashcon.org/track/vmil-2018 Follow us on twitter @vmil18 ======================================================================== The concept of virtual machines is pervasive in the design and implementation of programming systems. Virtual machines and the languages they implement are crucial in the specification, implementation and/or user-facing deployment of most programming technologies. The VMIL workshop is a forum for researchers and cutting-edge practitioners in language virtual machines, the intermediate languages they use, and related issues. The workshop is intended to be welcoming to a wide range of topics and perspectives, covering all areas relevant to the workshop?s theme. Aspects of interest include, but are not limited to: - design issues in VMs and IRs (e.g. IR design, VM modularity, polyglotism) - compilation (static and dynamic compilation strategies, optimizations, data representations) - memory management - concurrency (both internal and user-facing) - tool support and related infrastructure (profiling, debugging, liveness, persistence) - the experience of VM development (use of high-level languages, bootstrapping and self-hosting, reusability, portability, developer tooling, etc) - empirical studies on related topics, such as usage patterns, the usability of languages or tools, experimental methodology, or benchmark design #### Submission Guidelines We invite high-quality papers in the following two categories: Research and experience papers: These submissions should describe work that advances the current state of the art in the above or related areas. The suggested length of these submissions is 6-10 pages (maximum 10pp). Work-in-progress or position papers: These papers should document ongoing efforts in an area of interest which have not yet yielded final results, and/or should present and defend the authors' position on a topic related to the broad area of the workshop. The suggested length of these submissions is 4-6 pages (maximum 6pp). For the first submission deadline, all paper types are considered for publication in the ACM Digital Library, except if the authors prefer not to be included. Publication of work-in-progress and position papers at VMIL is not intended to preclude later publication elsewhere. Submissions will be judged on novelty, clarity, timeliness, relevance, and potential to stimulate discussion during the workshop. For the second deadline, we will consider only work-in-progress and position papers. These will not be published in the ACM DL, and will only appear on the web site. The address of the submission site is: https://vmil18.hotcrp.com/ #### Important Dates All deadlines are Anywhere on Earth (AoE), i.e. GMT/UTC?12:00 hour Abstract Submission 07 August 2018 Paper Submission 17 August 2018 Paper Notification 14 September 2018 ACM Camera Ready Deadline 28 September 2018 ?Late submission? deadline 07 September 2018 (WIP/position papers only) ?Late submission? notification 30 September 2018 Workshop Date 04 November 2018 #### Format Instructions Please use the SIGPLAN acmart style for all papers: http://www.sigplan.org/Resources/Author/. The provided double-column template is available for Latex and Word. #### Program Committee Stephen Kell, University of Cambridge Stefan Marr, University of Kent Leif Andersen, Northeastern University Steve Blackburn, Australian National University Stephen Dolan, University of Cambridge Apala Guha, Simon Fraser University Christine H. Flood, Red Hat Roberto Ierusalimschy, PUC-Rio Tomas Kalibera, Czech Technical University Christos Kotselidis, The University of Manchester Doug Lea, State University of New York (SUNY) Oswego Sanhong Li, Alibaba Inc. Mark Marron, Microsoft Research Erez Petrank, Technion Julien Ponge, INSA Lyon, CITI Laboratory / Red Hat Richard Roberts, Victoria University of Wellington Jeremy Singer, University of Glasgow Sam Tobin-Hochstadt, Indiana University -- Stefan Marr School of Computing, University of Kent http://stefan-marr.de/research/ From dean.long at oracle.com Thu Jun 14 21:34:18 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 14 Jun 2018 14:34:18 -0700 Subject: RFR(XL) 8204231: Update Graal Message-ID: <121d47ae-589a-8d13-b716-ea904256e7f5@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8204231 http://cr.openjdk.java.net/~dlong/8204231/webrev/ Graal changes: dca1ec9 Thu Jun 14 06:27:22 2018 -0700??? Alfonso? Peterssen java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java fails with Graal. d1b5595 Thu Jun 14 01:58:13 2018 -0700??? Alfonso? Peterssen [GR-10242] Canonicalization of unsafe memory accesses back to field accesses re-introduces memory barriers. 00146ee Thu Jun 14 00:45:33 2018 -0700??? Alfonso? Peterssen [GR-10107] Implement missing Unsafe intrinsics for opaque/acquire/release operations. 61dde59 Wed Jun 13 06:57:53 2018 -0700????? Christian Wimmer [GR-9442] Intrinsify old and new Unsafe methods on JDK 9 and later. 46c0955 Wed Jun 13 05:42:17 2018 -0700??????????? Doug Simon [GR-10367] Ignore Object.notify intrinsics when unavailble. ba18055 Tue Jun 12 14:51:17 2018 -0700??????????? Doug Simon [GR-10349] Revert to list for StructuredGraph.methods. da05112 Tue Jun 12 07:43:40 2018 -0700??????????? Doug Simon [GR-10308] Ensure all inlined methods are recorded. 1682b57 Thu Jun 7 22:36:55 2018 -0700?????? Stefan Anzinger [GR-10269] Allow AtomicReadAndAdd with immediate delta. 298475e Thu Jun 7 13:39:07 2018 -0700??????????? Doug Simon [GR-10265] Enforce adjustment of CheckGraalIntrinsics as new plugins are added. c9bf1f20 Thu Jun 7 12:38:48 2018 -0700??????????? Yudi Zheng [GR-6969] Temporarily disable AVX512 usages. ae4804b Thu Jun 7 09:29:18 2018 -0700???????? Codrut Stancu [GR-10266] Fix NoClassDefFoundError when loading a Class constant that references a missing class. bea6f26 Wed Jun 6 11:46:47 2018 -0700??????????? Doug Simon [GR-10258] Use Files API for copying file in chunks to prevent OOME. 4e36bac Wed Jun 6 03:47:29 2018 -0700?????? Stefan Anzinger [GR-10217] AArch64: Add support for the SWP instruction and the AtomicReadAndWriteOp. 2e4dc72 Wed Jun 6 03:03:09 2018 -0700????? Christian Wimmer [GR-10173] Handle corner case for MERGE_EXPLODE when loop is not reached during partial evaluation. 527a71e Wed Jun 6 00:01:47 2018 -0700?? Aleksandar Prokopec [GR-10165] Update copyright. 437ec5e Tue Jun 5 04:59:06 2018 -0700??????????? Doug Simon [GR-10213] Avoid NPE if SyncKnobs is NULL. 57a6bac Tue Jun 5 03:41:11 2018 -0700?????? Stefan Anzinger [GR-10103] AArch64LIRGenerator.emitAtomicReadAndAdd make delta allocatable. 079591a Tue Jun 5 02:54:46 2018 -0700?????? Stefan Anzinger [GR-10190] Added Classpath exception to all sources. 80b18b3 Mon Jun 4 06:31:28 2018 -0700?? Aleksandar Prokopec [GR-10165] Unsafe.compareAndExchange regression on JDK 11. f38ba63 Fri Jun 1 09:39:19 2018 -0700??????????? Doug Simon [GR-10004] Remove unnecessary reflection code. 376bcf5 Thu May 31 12:07:32 2018 -0700?? Aleksandar Prokopec [GR-9896] The result of code execution is different for Graal and Interpreter/C2. d03d813 Thu May 31 10:05:51 2018 -0700????? Christian Wimmer [GR-9995] Insert deoptimization proxy nodes also for deopt entry at method start. 000ff1e Wed May 30 12:14:21 2018 -0700??????????? Yudi Zheng [GR-6987] Move vectorization backend to graal-core. f7f3f25 Wed May 30 03:20:42 2018 -0700??????????? Doug Simon [GR-10072] Make GraalCompilerTest more thread safe. dl From vladimir.kozlov at oracle.com Thu Jun 14 21:36:58 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Jun 2018 14:36:58 -0700 Subject: RFR(XL) 8204231: Update Graal In-Reply-To: <121d47ae-589a-8d13-b716-ea904256e7f5@oracle.com> References: <121d47ae-589a-8d13-b716-ea904256e7f5@oracle.com> Message-ID: <0809a3d7-8f55-c536-854c-415fb6d72473@oracle.com> Good. Thanks, Vladimir On 6/14/18 2:34 PM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8204231 > http://cr.openjdk.java.net/~dlong/8204231/webrev/ > > Graal changes: > > dca1ec9 Thu Jun 14 06:27:22 2018 -0700??? Alfonso? Peterssen > java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java > fails with Graal. > d1b5595 Thu Jun 14 01:58:13 2018 -0700??? Alfonso? Peterssen [GR-10242] > Canonicalization of unsafe memory accesses back to field accesses > re-introduces memory barriers. > 00146ee Thu Jun 14 00:45:33 2018 -0700??? Alfonso? Peterssen [GR-10107] > Implement missing Unsafe intrinsics for opaque/acquire/release operations. > 61dde59 Wed Jun 13 06:57:53 2018 -0700????? Christian Wimmer [GR-9442] > Intrinsify old and new Unsafe methods on JDK 9 and later. > 46c0955 Wed Jun 13 05:42:17 2018 -0700??????????? Doug Simon [GR-10367] > Ignore Object.notify intrinsics when unavailble. > ba18055 Tue Jun 12 14:51:17 2018 -0700??????????? Doug Simon [GR-10349] > Revert to list for StructuredGraph.methods. > da05112 Tue Jun 12 07:43:40 2018 -0700??????????? Doug Simon [GR-10308] > Ensure all inlined methods are recorded. > 1682b57 Thu Jun 7 22:36:55 2018 -0700?????? Stefan Anzinger [GR-10269] > Allow AtomicReadAndAdd with immediate delta. > 298475e Thu Jun 7 13:39:07 2018 -0700??????????? Doug Simon [GR-10265] > Enforce adjustment of CheckGraalIntrinsics as new plugins are added. > c9bf1f20 Thu Jun 7 12:38:48 2018 -0700??????????? Yudi Zheng [GR-6969] > Temporarily disable AVX512 usages. > ae4804b Thu Jun 7 09:29:18 2018 -0700???????? Codrut Stancu [GR-10266] > Fix NoClassDefFoundError when loading a Class constant that references a > missing class. > bea6f26 Wed Jun 6 11:46:47 2018 -0700??????????? Doug Simon [GR-10258] > Use Files API for copying file in chunks to prevent OOME. > 4e36bac Wed Jun 6 03:47:29 2018 -0700?????? Stefan Anzinger [GR-10217] > AArch64: Add support for the SWP instruction and the AtomicReadAndWriteOp. > 2e4dc72 Wed Jun 6 03:03:09 2018 -0700????? Christian Wimmer [GR-10173] > Handle corner case for MERGE_EXPLODE when loop is not reached during > partial evaluation. > 527a71e Wed Jun 6 00:01:47 2018 -0700?? Aleksandar Prokopec [GR-10165] > Update copyright. > 437ec5e Tue Jun 5 04:59:06 2018 -0700??????????? Doug Simon [GR-10213] > Avoid NPE if SyncKnobs is NULL. > 57a6bac Tue Jun 5 03:41:11 2018 -0700?????? Stefan Anzinger [GR-10103] > AArch64LIRGenerator.emitAtomicReadAndAdd make delta allocatable. > 079591a Tue Jun 5 02:54:46 2018 -0700?????? Stefan Anzinger [GR-10190] > Added Classpath exception to all sources. > 80b18b3 Mon Jun 4 06:31:28 2018 -0700?? Aleksandar Prokopec [GR-10165] > Unsafe.compareAndExchange regression on JDK 11. > f38ba63 Fri Jun 1 09:39:19 2018 -0700??????????? Doug Simon [GR-10004] > Remove unnecessary reflection code. > 376bcf5 Thu May 31 12:07:32 2018 -0700?? Aleksandar Prokopec [GR-9896] > The result of code execution is different for Graal and Interpreter/C2. > d03d813 Thu May 31 10:05:51 2018 -0700????? Christian Wimmer [GR-9995] > Insert deoptimization proxy nodes also for deopt entry at method start. > 000ff1e Wed May 30 12:14:21 2018 -0700??????????? Yudi Zheng [GR-6987] > Move vectorization backend to graal-core. > f7f3f25 Wed May 30 03:20:42 2018 -0700??????????? Doug Simon [GR-10072] > Make GraalCompilerTest more thread safe. > > dl > From dean.long at oracle.com Thu Jun 14 21:41:21 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 14 Jun 2018 14:41:21 -0700 Subject: RFR(XL) 8204231: Update Graal In-Reply-To: <0809a3d7-8f55-c536-854c-415fb6d72473@oracle.com> References: <121d47ae-589a-8d13-b716-ea904256e7f5@oracle.com> <0809a3d7-8f55-c536-854c-415fb6d72473@oracle.com> Message-ID: Thanks Vladimir. dl On 6/14/18 2:36 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 6/14/18 2:34 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8204231 >> http://cr.openjdk.java.net/~dlong/8204231/webrev/ >> >> Graal changes: >> >> dca1ec9 Thu Jun 14 06:27:22 2018 -0700??? Alfonso? Peterssen >> java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java >> fails with Graal. >> d1b5595 Thu Jun 14 01:58:13 2018 -0700??? Alfonso? Peterssen >> [GR-10242] Canonicalization of unsafe memory accesses back to field >> accesses re-introduces memory barriers. >> 00146ee Thu Jun 14 00:45:33 2018 -0700??? Alfonso? Peterssen >> [GR-10107] Implement missing Unsafe intrinsics for >> opaque/acquire/release operations. >> 61dde59 Wed Jun 13 06:57:53 2018 -0700????? Christian Wimmer >> [GR-9442] Intrinsify old and new Unsafe methods on JDK 9 and later. >> 46c0955 Wed Jun 13 05:42:17 2018 -0700??????????? Doug Simon >> [GR-10367] Ignore Object.notify intrinsics when unavailble. >> ba18055 Tue Jun 12 14:51:17 2018 -0700??????????? Doug Simon >> [GR-10349] Revert to list for StructuredGraph.methods. >> da05112 Tue Jun 12 07:43:40 2018 -0700??????????? Doug Simon >> [GR-10308] Ensure all inlined methods are recorded. >> 1682b57 Thu Jun 7 22:36:55 2018 -0700?????? Stefan Anzinger >> [GR-10269] Allow AtomicReadAndAdd with immediate delta. >> 298475e Thu Jun 7 13:39:07 2018 -0700??????????? Doug Simon >> [GR-10265] Enforce adjustment of CheckGraalIntrinsics as new plugins >> are added. >> c9bf1f20 Thu Jun 7 12:38:48 2018 -0700??????????? Yudi Zheng >> [GR-6969] Temporarily disable AVX512 usages. >> ae4804b Thu Jun 7 09:29:18 2018 -0700???????? Codrut Stancu >> [GR-10266] Fix NoClassDefFoundError when loading a Class constant >> that references a missing class. >> bea6f26 Wed Jun 6 11:46:47 2018 -0700??????????? Doug Simon >> [GR-10258] Use Files API for copying file in chunks to prevent OOME. >> 4e36bac Wed Jun 6 03:47:29 2018 -0700?????? Stefan Anzinger >> [GR-10217] AArch64: Add support for the SWP instruction and the >> AtomicReadAndWriteOp. >> 2e4dc72 Wed Jun 6 03:03:09 2018 -0700????? Christian Wimmer >> [GR-10173] Handle corner case for MERGE_EXPLODE when loop is not >> reached during partial evaluation. >> 527a71e Wed Jun 6 00:01:47 2018 -0700?? Aleksandar Prokopec >> [GR-10165] Update copyright. >> 437ec5e Tue Jun 5 04:59:06 2018 -0700??????????? Doug Simon >> [GR-10213] Avoid NPE if SyncKnobs is NULL. >> 57a6bac Tue Jun 5 03:41:11 2018 -0700?????? Stefan Anzinger >> [GR-10103] AArch64LIRGenerator.emitAtomicReadAndAdd make delta >> allocatable. >> 079591a Tue Jun 5 02:54:46 2018 -0700?????? Stefan Anzinger >> [GR-10190] Added Classpath exception to all sources. >> 80b18b3 Mon Jun 4 06:31:28 2018 -0700?? Aleksandar Prokopec >> [GR-10165] Unsafe.compareAndExchange regression on JDK 11. >> f38ba63 Fri Jun 1 09:39:19 2018 -0700??????????? Doug Simon >> [GR-10004] Remove unnecessary reflection code. >> 376bcf5 Thu May 31 12:07:32 2018 -0700?? Aleksandar Prokopec >> [GR-9896] The result of code execution is different for Graal and >> Interpreter/C2. >> d03d813 Thu May 31 10:05:51 2018 -0700????? Christian Wimmer >> [GR-9995] Insert deoptimization proxy nodes also for deopt entry at >> method start. >> 000ff1e Wed May 30 12:14:21 2018 -0700??????????? Yudi Zheng >> [GR-6987] Move vectorization backend to graal-core. >> f7f3f25 Wed May 30 03:20:42 2018 -0700??????????? Doug Simon >> [GR-10072] Make GraalCompilerTest more thread safe. >> >> dl >> From dean.long at oracle.com Thu Jun 14 21:48:37 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 14 Jun 2018 14:48:37 -0700 Subject: RFR(XL) 8204231: Update Graal In-Reply-To: <0809a3d7-8f55-c536-854c-415fb6d72473@oracle.com> References: <121d47ae-589a-8d13-b716-ea904256e7f5@oracle.com> <0809a3d7-8f55-c536-854c-415fb6d72473@oracle.com> Message-ID: <318ee23e-e83e-d861-7bcc-d6fc0c778e8c@oracle.com> Yudi pointed out that I missed including the fix for JDK-8195633 , which just went in.? Let me respin this. dl On 6/14/18 2:36 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 6/14/18 2:34 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8204231 >> http://cr.openjdk.java.net/~dlong/8204231/webrev/ >> >> Graal changes: >> >> dca1ec9 Thu Jun 14 06:27:22 2018 -0700??? Alfonso? Peterssen >> java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java >> fails with Graal. >> d1b5595 Thu Jun 14 01:58:13 2018 -0700??? Alfonso? Peterssen >> [GR-10242] Canonicalization of unsafe memory accesses back to field >> accesses re-introduces memory barriers. >> 00146ee Thu Jun 14 00:45:33 2018 -0700??? Alfonso? Peterssen >> [GR-10107] Implement missing Unsafe intrinsics for >> opaque/acquire/release operations. >> 61dde59 Wed Jun 13 06:57:53 2018 -0700????? Christian Wimmer >> [GR-9442] Intrinsify old and new Unsafe methods on JDK 9 and later. >> 46c0955 Wed Jun 13 05:42:17 2018 -0700??????????? Doug Simon >> [GR-10367] Ignore Object.notify intrinsics when unavailble. >> ba18055 Tue Jun 12 14:51:17 2018 -0700??????????? Doug Simon >> [GR-10349] Revert to list for StructuredGraph.methods. >> da05112 Tue Jun 12 07:43:40 2018 -0700??????????? Doug Simon >> [GR-10308] Ensure all inlined methods are recorded. >> 1682b57 Thu Jun 7 22:36:55 2018 -0700?????? Stefan Anzinger >> [GR-10269] Allow AtomicReadAndAdd with immediate delta. >> 298475e Thu Jun 7 13:39:07 2018 -0700??????????? Doug Simon >> [GR-10265] Enforce adjustment of CheckGraalIntrinsics as new plugins >> are added. >> c9bf1f20 Thu Jun 7 12:38:48 2018 -0700??????????? Yudi Zheng >> [GR-6969] Temporarily disable AVX512 usages. >> ae4804b Thu Jun 7 09:29:18 2018 -0700???????? Codrut Stancu >> [GR-10266] Fix NoClassDefFoundError when loading a Class constant >> that references a missing class. >> bea6f26 Wed Jun 6 11:46:47 2018 -0700??????????? Doug Simon >> [GR-10258] Use Files API for copying file in chunks to prevent OOME. >> 4e36bac Wed Jun 6 03:47:29 2018 -0700?????? Stefan Anzinger >> [GR-10217] AArch64: Add support for the SWP instruction and the >> AtomicReadAndWriteOp. >> 2e4dc72 Wed Jun 6 03:03:09 2018 -0700????? Christian Wimmer >> [GR-10173] Handle corner case for MERGE_EXPLODE when loop is not >> reached during partial evaluation. >> 527a71e Wed Jun 6 00:01:47 2018 -0700?? Aleksandar Prokopec >> [GR-10165] Update copyright. >> 437ec5e Tue Jun 5 04:59:06 2018 -0700??????????? Doug Simon >> [GR-10213] Avoid NPE if SyncKnobs is NULL. >> 57a6bac Tue Jun 5 03:41:11 2018 -0700?????? Stefan Anzinger >> [GR-10103] AArch64LIRGenerator.emitAtomicReadAndAdd make delta >> allocatable. >> 079591a Tue Jun 5 02:54:46 2018 -0700?????? Stefan Anzinger >> [GR-10190] Added Classpath exception to all sources. >> 80b18b3 Mon Jun 4 06:31:28 2018 -0700?? Aleksandar Prokopec >> [GR-10165] Unsafe.compareAndExchange regression on JDK 11. >> f38ba63 Fri Jun 1 09:39:19 2018 -0700??????????? Doug Simon >> [GR-10004] Remove unnecessary reflection code. >> 376bcf5 Thu May 31 12:07:32 2018 -0700?? Aleksandar Prokopec >> [GR-9896] The result of code execution is different for Graal and >> Interpreter/C2. >> d03d813 Thu May 31 10:05:51 2018 -0700????? Christian Wimmer >> [GR-9995] Insert deoptimization proxy nodes also for deopt entry at >> method start. >> 000ff1e Wed May 30 12:14:21 2018 -0700??????????? Yudi Zheng >> [GR-6987] Move vectorization backend to graal-core. >> f7f3f25 Wed May 30 03:20:42 2018 -0700??????????? Doug Simon >> [GR-10072] Make GraalCompilerTest more thread safe. >> >> dl >> From vladimir.kozlov at oracle.com Thu Jun 14 22:12:28 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Jun 2018 15:12:28 -0700 Subject: RFR(XL) 8204231: Update Graal In-Reply-To: <318ee23e-e83e-d861-7bcc-d6fc0c778e8c@oracle.com> References: <121d47ae-589a-8d13-b716-ea904256e7f5@oracle.com> <0809a3d7-8f55-c536-854c-415fb6d72473@oracle.com> <318ee23e-e83e-d861-7bcc-d6fc0c778e8c@oracle.com> Message-ID: Okay. Vladimir On 6/14/18 2:48 PM, dean.long at oracle.com wrote: > Yudi pointed out that I missed including the fix for JDK-8195633 > , which just went in. > Let me respin this. > > dl > > On 6/14/18 2:36 PM, Vladimir Kozlov wrote: >> Good. >> >> Thanks, >> Vladimir >> >> On 6/14/18 2:34 PM, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8204231 >>> http://cr.openjdk.java.net/~dlong/8204231/webrev/ >>> >>> Graal changes: >>> >>> dca1ec9 Thu Jun 14 06:27:22 2018 -0700??? Alfonso? Peterssen >>> java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java >>> fails with Graal. >>> d1b5595 Thu Jun 14 01:58:13 2018 -0700??? Alfonso? Peterssen >>> [GR-10242] Canonicalization of unsafe memory accesses back to field >>> accesses re-introduces memory barriers. >>> 00146ee Thu Jun 14 00:45:33 2018 -0700??? Alfonso? Peterssen >>> [GR-10107] Implement missing Unsafe intrinsics for >>> opaque/acquire/release operations. >>> 61dde59 Wed Jun 13 06:57:53 2018 -0700????? Christian Wimmer >>> [GR-9442] Intrinsify old and new Unsafe methods on JDK 9 and later. >>> 46c0955 Wed Jun 13 05:42:17 2018 -0700??????????? Doug Simon >>> [GR-10367] Ignore Object.notify intrinsics when unavailble. >>> ba18055 Tue Jun 12 14:51:17 2018 -0700??????????? Doug Simon >>> [GR-10349] Revert to list for StructuredGraph.methods. >>> da05112 Tue Jun 12 07:43:40 2018 -0700??????????? Doug Simon >>> [GR-10308] Ensure all inlined methods are recorded. >>> 1682b57 Thu Jun 7 22:36:55 2018 -0700?????? Stefan Anzinger >>> [GR-10269] Allow AtomicReadAndAdd with immediate delta. >>> 298475e Thu Jun 7 13:39:07 2018 -0700??????????? Doug Simon >>> [GR-10265] Enforce adjustment of CheckGraalIntrinsics as new plugins >>> are added. >>> c9bf1f20 Thu Jun 7 12:38:48 2018 -0700??????????? Yudi Zheng >>> [GR-6969] Temporarily disable AVX512 usages. >>> ae4804b Thu Jun 7 09:29:18 2018 -0700???????? Codrut Stancu >>> [GR-10266] Fix NoClassDefFoundError when loading a Class constant >>> that references a missing class. >>> bea6f26 Wed Jun 6 11:46:47 2018 -0700??????????? Doug Simon >>> [GR-10258] Use Files API for copying file in chunks to prevent OOME. >>> 4e36bac Wed Jun 6 03:47:29 2018 -0700?????? Stefan Anzinger >>> [GR-10217] AArch64: Add support for the SWP instruction and the >>> AtomicReadAndWriteOp. >>> 2e4dc72 Wed Jun 6 03:03:09 2018 -0700????? Christian Wimmer >>> [GR-10173] Handle corner case for MERGE_EXPLODE when loop is not >>> reached during partial evaluation. >>> 527a71e Wed Jun 6 00:01:47 2018 -0700?? Aleksandar Prokopec >>> [GR-10165] Update copyright. >>> 437ec5e Tue Jun 5 04:59:06 2018 -0700??????????? Doug Simon >>> [GR-10213] Avoid NPE if SyncKnobs is NULL. >>> 57a6bac Tue Jun 5 03:41:11 2018 -0700?????? Stefan Anzinger >>> [GR-10103] AArch64LIRGenerator.emitAtomicReadAndAdd make delta >>> allocatable. >>> 079591a Tue Jun 5 02:54:46 2018 -0700?????? Stefan Anzinger >>> [GR-10190] Added Classpath exception to all sources. >>> 80b18b3 Mon Jun 4 06:31:28 2018 -0700?? Aleksandar Prokopec >>> [GR-10165] Unsafe.compareAndExchange regression on JDK 11. >>> f38ba63 Fri Jun 1 09:39:19 2018 -0700??????????? Doug Simon >>> [GR-10004] Remove unnecessary reflection code. >>> 376bcf5 Thu May 31 12:07:32 2018 -0700?? Aleksandar Prokopec >>> [GR-9896] The result of code execution is different for Graal and >>> Interpreter/C2. >>> d03d813 Thu May 31 10:05:51 2018 -0700????? Christian Wimmer >>> [GR-9995] Insert deoptimization proxy nodes also for deopt entry at >>> method start. >>> 000ff1e Wed May 30 12:14:21 2018 -0700??????????? Yudi Zheng >>> [GR-6987] Move vectorization backend to graal-core. >>> f7f3f25 Wed May 30 03:20:42 2018 -0700??????????? Doug Simon >>> [GR-10072] Make GraalCompilerTest more thread safe. >>> >>> dl >>> > From dean.long at oracle.com Thu Jun 14 22:21:45 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 14 Jun 2018 15:21:45 -0700 Subject: RFR(XL) 8204231: Update Graal Message-ID: <17b3d677-157c-16e2-ef6e-6a037feae11b@oracle.com> [respin, missed a fix last time] https://bugs.openjdk.java.net/browse/JDK-8204231 http://cr.openjdk.java.net/~dlong/8204231/webrev/ Graal changes: 0acbecc Thu Jun 14 12:24:16 2018 -0700??????????? Yudi Zheng [GR-714] Subword parameters are treated as int. dca1ec9 Thu Jun 14 06:27:22 2018 -0700??? Alfonso? Peterssen java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java fails with Graal. d1b5595 Thu Jun 14 01:58:13 2018 -0700??? Alfonso? Peterssen [GR-10242] Canonicalization of unsafe memory accesses back to field accesses re-introduces memory barriers. 00146ee Thu Jun 14 00:45:33 2018 -0700??? Alfonso? Peterssen [GR-10107] Implement missing Unsafe intrinsics for opaque/acquire/release operations. 61dde59 Wed Jun 13 06:57:53 2018 -0700????? Christian Wimmer [GR-9442] Intrinsify old and new Unsafe methods on JDK 9 and later. 46c0955 Wed Jun 13 05:42:17 2018 -0700??????????? Doug Simon [GR-10367] Ignore Object.notify intrinsics when unavailble. ba18055 Tue Jun 12 14:51:17 2018 -0700??????????? Doug Simon [GR-10349] Revert to list for StructuredGraph.methods. da05112 Tue Jun 12 07:43:40 2018 -0700??????????? Doug Simon [GR-10308] Ensure all inlined methods are recorded. 1682b57 Thu Jun 7 22:36:55 2018 -0700?????? Stefan Anzinger [GR-10269] Allow AtomicReadAndAdd with immediate delta. 298475e Thu Jun 7 13:39:07 2018 -0700??????????? Doug Simon [GR-10265] Enforce adjustment of CheckGraalIntrinsics as new plugins are added. c9bf1f20 Thu Jun 7 12:38:48 2018 -0700??????????? Yudi Zheng [GR-6969] Temporarily disable AVX512 usages. ae4804b Thu Jun 7 09:29:18 2018 -0700???????? Codrut Stancu [GR-10266] Fix NoClassDefFoundError when loading a Class constant that references a missing class. bea6f26 Wed Jun 6 11:46:47 2018 -0700??????????? Doug Simon [GR-10258] Use Files API for copying file in chunks to prevent OOME. 4e36bac Wed Jun 6 03:47:29 2018 -0700?????? Stefan Anzinger [GR-10217] AArch64: Add support for the SWP instruction and the AtomicReadAndWriteOp. 2e4dc72 Wed Jun 6 03:03:09 2018 -0700????? Christian Wimmer [GR-10173] Handle corner case for MERGE_EXPLODE when loop is not reached during partial evaluation. 527a71e Wed Jun 6 00:01:47 2018 -0700?? Aleksandar Prokopec [GR-10165] Update copyright. 437ec5e Tue Jun 5 04:59:06 2018 -0700??????????? Doug Simon [GR-10213] Avoid NPE if SyncKnobs is NULL. 57a6bac Tue Jun 5 03:41:11 2018 -0700?????? Stefan Anzinger [GR-10103] AArch64LIRGenerator.emitAtomicReadAndAdd make delta allocatable. 079591a Tue Jun 5 02:54:46 2018 -0700?????? Stefan Anzinger [GR-10190] Added Classpath exception to all sources. 80b18b3 Mon Jun 4 06:31:28 2018 -0700?? Aleksandar Prokopec [GR-10165] Unsafe.compareAndExchange regression on JDK 11. f38ba63 Fri Jun 1 09:39:19 2018 -0700??????????? Doug Simon [GR-10004] Remove unnecessary reflection code. 376bcf5 Thu May 31 12:07:32 2018 -0700?? Aleksandar Prokopec [GR-9896] The result of code execution is different for Graal and Interpreter/C2. d03d813 Thu May 31 10:05:51 2018 -0700????? Christian Wimmer [GR-9995] Insert deoptimization proxy nodes also for deopt entry at method start. 000ff1e Wed May 30 12:14:21 2018 -0700??????????? Yudi Zheng [GR-6987] Move vectorization backend to graal-core. f7f3f25 Wed May 30 03:20:42 2018 -0700??????????? Doug Simon [GR-10072] Make GraalCompilerTest more thread safe. dl From vladimir.kozlov at oracle.com Thu Jun 14 23:21:55 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Jun 2018 16:21:55 -0700 Subject: RFR(XL) 8204231: Update Graal In-Reply-To: <17b3d677-157c-16e2-ef6e-6a037feae11b@oracle.com> References: <17b3d677-157c-16e2-ef6e-6a037feae11b@oracle.com> Message-ID: <60d340bd-b846-7649-c4e1-9b55185ac35e@oracle.com> Good. Vladimir On 6/14/18 3:21 PM, dean.long at oracle.com wrote: > [respin, missed a fix last time] > > https://bugs.openjdk.java.net/browse/JDK-8204231 > http://cr.openjdk.java.net/~dlong/8204231/webrev/ > > Graal changes: > > 0acbecc Thu Jun 14 12:24:16 2018 -0700??????????? Yudi Zheng [GR-714] > Subword parameters are treated as int. > dca1ec9 Thu Jun 14 06:27:22 2018 -0700??? Alfonso? Peterssen > java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java > fails with Graal. > d1b5595 Thu Jun 14 01:58:13 2018 -0700??? Alfonso? Peterssen [GR-10242] > Canonicalization of unsafe memory accesses back to field accesses > re-introduces memory barriers. > 00146ee Thu Jun 14 00:45:33 2018 -0700??? Alfonso? Peterssen [GR-10107] > Implement missing Unsafe intrinsics for opaque/acquire/release operations. > 61dde59 Wed Jun 13 06:57:53 2018 -0700????? Christian Wimmer [GR-9442] > Intrinsify old and new Unsafe methods on JDK 9 and later. > 46c0955 Wed Jun 13 05:42:17 2018 -0700??????????? Doug Simon [GR-10367] > Ignore Object.notify intrinsics when unavailble. > ba18055 Tue Jun 12 14:51:17 2018 -0700??????????? Doug Simon [GR-10349] > Revert to list for StructuredGraph.methods. > da05112 Tue Jun 12 07:43:40 2018 -0700??????????? Doug Simon [GR-10308] > Ensure all inlined methods are recorded. > 1682b57 Thu Jun 7 22:36:55 2018 -0700?????? Stefan Anzinger [GR-10269] > Allow AtomicReadAndAdd with immediate delta. > 298475e Thu Jun 7 13:39:07 2018 -0700??????????? Doug Simon [GR-10265] > Enforce adjustment of CheckGraalIntrinsics as new plugins are added. > c9bf1f20 Thu Jun 7 12:38:48 2018 -0700??????????? Yudi Zheng [GR-6969] > Temporarily disable AVX512 usages. > ae4804b Thu Jun 7 09:29:18 2018 -0700???????? Codrut Stancu [GR-10266] > Fix NoClassDefFoundError when loading a Class constant that references a > missing class. > bea6f26 Wed Jun 6 11:46:47 2018 -0700??????????? Doug Simon [GR-10258] > Use Files API for copying file in chunks to prevent OOME. > 4e36bac Wed Jun 6 03:47:29 2018 -0700?????? Stefan Anzinger [GR-10217] > AArch64: Add support for the SWP instruction and the AtomicReadAndWriteOp. > 2e4dc72 Wed Jun 6 03:03:09 2018 -0700????? Christian Wimmer [GR-10173] > Handle corner case for MERGE_EXPLODE when loop is not reached during > partial evaluation. > 527a71e Wed Jun 6 00:01:47 2018 -0700?? Aleksandar Prokopec [GR-10165] > Update copyright. > 437ec5e Tue Jun 5 04:59:06 2018 -0700??????????? Doug Simon [GR-10213] > Avoid NPE if SyncKnobs is NULL. > 57a6bac Tue Jun 5 03:41:11 2018 -0700?????? Stefan Anzinger [GR-10103] > AArch64LIRGenerator.emitAtomicReadAndAdd make delta allocatable. > 079591a Tue Jun 5 02:54:46 2018 -0700?????? Stefan Anzinger [GR-10190] > Added Classpath exception to all sources. > 80b18b3 Mon Jun 4 06:31:28 2018 -0700?? Aleksandar Prokopec [GR-10165] > Unsafe.compareAndExchange regression on JDK 11. > f38ba63 Fri Jun 1 09:39:19 2018 -0700??????????? Doug Simon [GR-10004] > Remove unnecessary reflection code. > 376bcf5 Thu May 31 12:07:32 2018 -0700?? Aleksandar Prokopec [GR-9896] > The result of code execution is different for Graal and Interpreter/C2. > d03d813 Thu May 31 10:05:51 2018 -0700????? Christian Wimmer [GR-9995] > Insert deoptimization proxy nodes also for deopt entry at method start. > 000ff1e Wed May 30 12:14:21 2018 -0700??????????? Yudi Zheng [GR-6987] > Move vectorization backend to graal-core. > f7f3f25 Wed May 30 03:20:42 2018 -0700??????????? Doug Simon [GR-10072] > Make GraalCompilerTest more thread safe. > > dl > From dean.long at oracle.com Fri Jun 15 04:58:02 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 14 Jun 2018 21:58:02 -0700 Subject: RFR(XL) 8204231: Update Graal In-Reply-To: <60d340bd-b846-7649-c4e1-9b55185ac35e@oracle.com> References: <17b3d677-157c-16e2-ef6e-6a037feae11b@oracle.com> <60d340bd-b846-7649-c4e1-9b55185ac35e@oracle.com> Message-ID: <017e4093-ae9e-11b0-5ea3-3fac6ef8c6da@oracle.com> Thanks again. dl On 6/14/18 4:21 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 6/14/18 3:21 PM, dean.long at oracle.com wrote: >> [respin, missed a fix last time] >> >> https://bugs.openjdk.java.net/browse/JDK-8204231 >> http://cr.openjdk.java.net/~dlong/8204231/webrev/ >> >> Graal changes: >> >> 0acbecc Thu Jun 14 12:24:16 2018 -0700??????????? Yudi Zheng [GR-714] >> Subword parameters are treated as int. >> dca1ec9 Thu Jun 14 06:27:22 2018 -0700??? Alfonso? Peterssen >> java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java >> fails with Graal. >> d1b5595 Thu Jun 14 01:58:13 2018 -0700??? Alfonso? Peterssen >> [GR-10242] Canonicalization of unsafe memory accesses back to field >> accesses re-introduces memory barriers. >> 00146ee Thu Jun 14 00:45:33 2018 -0700??? Alfonso? Peterssen >> [GR-10107] Implement missing Unsafe intrinsics for >> opaque/acquire/release operations. >> 61dde59 Wed Jun 13 06:57:53 2018 -0700????? Christian Wimmer >> [GR-9442] Intrinsify old and new Unsafe methods on JDK 9 and later. >> 46c0955 Wed Jun 13 05:42:17 2018 -0700??????????? Doug Simon >> [GR-10367] Ignore Object.notify intrinsics when unavailble. >> ba18055 Tue Jun 12 14:51:17 2018 -0700??????????? Doug Simon >> [GR-10349] Revert to list for StructuredGraph.methods. >> da05112 Tue Jun 12 07:43:40 2018 -0700??????????? Doug Simon >> [GR-10308] Ensure all inlined methods are recorded. >> 1682b57 Thu Jun 7 22:36:55 2018 -0700?????? Stefan Anzinger >> [GR-10269] Allow AtomicReadAndAdd with immediate delta. >> 298475e Thu Jun 7 13:39:07 2018 -0700??????????? Doug Simon >> [GR-10265] Enforce adjustment of CheckGraalIntrinsics as new plugins >> are added. >> c9bf1f20 Thu Jun 7 12:38:48 2018 -0700??????????? Yudi Zheng >> [GR-6969] Temporarily disable AVX512 usages. >> ae4804b Thu Jun 7 09:29:18 2018 -0700???????? Codrut Stancu >> [GR-10266] Fix NoClassDefFoundError when loading a Class constant >> that references a missing class. >> bea6f26 Wed Jun 6 11:46:47 2018 -0700??????????? Doug Simon >> [GR-10258] Use Files API for copying file in chunks to prevent OOME. >> 4e36bac Wed Jun 6 03:47:29 2018 -0700?????? Stefan Anzinger >> [GR-10217] AArch64: Add support for the SWP instruction and the >> AtomicReadAndWriteOp. >> 2e4dc72 Wed Jun 6 03:03:09 2018 -0700????? Christian Wimmer >> [GR-10173] Handle corner case for MERGE_EXPLODE when loop is not >> reached during partial evaluation. >> 527a71e Wed Jun 6 00:01:47 2018 -0700?? Aleksandar Prokopec >> [GR-10165] Update copyright. >> 437ec5e Tue Jun 5 04:59:06 2018 -0700??????????? Doug Simon >> [GR-10213] Avoid NPE if SyncKnobs is NULL. >> 57a6bac Tue Jun 5 03:41:11 2018 -0700?????? Stefan Anzinger >> [GR-10103] AArch64LIRGenerator.emitAtomicReadAndAdd make delta >> allocatable. >> 079591a Tue Jun 5 02:54:46 2018 -0700?????? Stefan Anzinger >> [GR-10190] Added Classpath exception to all sources. >> 80b18b3 Mon Jun 4 06:31:28 2018 -0700?? Aleksandar Prokopec >> [GR-10165] Unsafe.compareAndExchange regression on JDK 11. >> f38ba63 Fri Jun 1 09:39:19 2018 -0700??????????? Doug Simon >> [GR-10004] Remove unnecessary reflection code. >> 376bcf5 Thu May 31 12:07:32 2018 -0700?? Aleksandar Prokopec >> [GR-9896] The result of code execution is different for Graal and >> Interpreter/C2. >> d03d813 Thu May 31 10:05:51 2018 -0700????? Christian Wimmer >> [GR-9995] Insert deoptimization proxy nodes also for deopt entry at >> method start. >> 000ff1e Wed May 30 12:14:21 2018 -0700??????????? Yudi Zheng >> [GR-6987] Move vectorization backend to graal-core. >> f7f3f25 Wed May 30 03:20:42 2018 -0700??????????? Doug Simon >> [GR-10072] Make GraalCompilerTest more thread safe. >> >> dl >> From fbrasil at twitter.com Fri Jun 15 14:27:22 2018 From: fbrasil at twitter.com (Flavio Brasil) Date: Fri, 15 Jun 2018 07:27:22 -0700 Subject: Method Fusion proposal Message-ID: *Hi Graal developers,We?ve been exploring a new JIT optimization at Twitter that could significantly improve the efficiency of some of the high-level abstractions normally used in Scala. The project is at its early stage so we thought it?d be best to have your feedback on it sooner rather than later since you might be interested in collaborating on it.The initial design doc is available at http://tiny.cc/graal-method-fusion and open for comments.Thank you,Flavio BrasilVM Team @ Twitter* From gilles.m.duboscq at oracle.com Fri Jun 15 15:53:36 2018 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Fri, 15 Jun 2018 17:53:36 +0200 Subject: Method Fusion proposal In-Reply-To: References: Message-ID: Hi Flavio, Usually, the difficult part of this kind of transforms are the stacks ("framestates") that your are going to give to the VM along with the compiled code. In principle they should represent stacks and states that are possible to reach through the bytecodes that are being compiled so that things like deoptimization can work. In previous experimentation we concluded that HotSpot really doesn't like fake framestates. Maybe some of these HotSpot limitations could be lifted with some C++ changes?? Overall getting FrameState nodes that will work will be your biggest challenge: - what will be the bci of the FrameState for the introduced calls? - what values will be on the stack if deoptimization occurs for while the new calls or the re-written calls are on the stack? can execution proceed correctly? Gilles On 15/06/18 16:27, Flavio Brasil wrote: > *Hi Graal developers,We?ve been exploring a new JIT optimization at Twitter > that could significantly improve the efficiency of some of the high-level > abstractions normally used in Scala. The project is at its early stage so > we thought it?d be best to have your feedback on it sooner rather than > later since you might be interested in collaborating on it.The initial > design doc is available at http://tiny.cc/graal-method-fusion > and open for comments.Thank you,Flavio > BrasilVM Team @ Twitter* > From fbrasil at twitter.com Fri Jun 15 18:48:43 2018 From: fbrasil at twitter.com (Flavio Brasil) Date: Fri, 15 Jun 2018 11:48:43 -0700 Subject: Method Fusion proposal In-Reply-To: References: Message-ID: Thank you for the quick feedback, Gilles. Yes, building the frame state is currently where I'm stuck at. Would you be able to give some details on how the optimization that fuses sequential `StringBuilder.append` on Graal EE works? Are there plans to open source it? Best, Flavio On Fri, Jun 15, 2018 at 8:54 AM Gilles Duboscq wrote: > Hi Flavio, > > Usually, the difficult part of this kind of transforms are the stacks > ("framestates") that your are going to give to the VM along with the > compiled code. > > In principle they should represent stacks and states that are possible to > reach through the bytecodes that are being compiled so that things like > deoptimization can work. > > In previous experimentation we concluded that HotSpot really doesn't like > fake framestates. > Maybe some of these HotSpot limitations could be lifted with some C++ > changes?? > > Overall getting FrameState nodes that will work will be your biggest > challenge: > - what will be the bci of the FrameState for the introduced calls? > - what values will be on the stack if deoptimization occurs for while the > new calls or the re-written calls are on the stack? can execution proceed > correctly? > > Gilles > > On 15/06/18 16:27, Flavio Brasil wrote: > > *Hi Graal developers,We?ve been exploring a new JIT optimization at > Twitter > > that could significantly improve the efficiency of some of the high-level > > abstractions normally used in Scala. The project is at its early stage so > > we thought it?d be best to have your feedback on it sooner rather than > > later since you might be interested in collaborating on it.The initial > > design doc is available at *https://docs.google.com/document/d/139XJhODDMfcWBNi80-jSWNGrBEmggch72oaNA5LXF2I/edit#heading=h.uqhewhqfc5rs > * and > open for comments.Thank you,Flavio > > BrasilVM Team @ Twitter* > > > From fbrasil at twitter.com Fri Jun 15 18:50:53 2018 From: fbrasil at twitter.com (Flavio Brasil) Date: Fri, 15 Jun 2018 11:50:53 -0700 Subject: Method Fusion proposal Message-ID: ** Sorry, I'm resending since the initial email was detected as spam because of the tiny url Hi Graal developers, We?ve been exploring a new JIT optimization at Twitter that could significantly improve the efficiency of some of the high-level abstractions normally used in Scala. The project is at its early stage so we thought it?d be best to have your feedback on it sooner rather than later since you might be interested in collaborating on it. The initial design doc is available at *https://docs.google.com/document/d/139XJhODDMfcWBNi80-jSWNGrBEmggch72oaNA5LXF2I/edit#heading=h.uqhewhqfc5rs * and open for comments. Thank you, Flavio Brasil VM Team @ Twitter From tom.rodriguez at oracle.com Fri Jun 15 20:14:53 2018 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 15 Jun 2018 13:14:53 -0700 Subject: Method Fusion proposal In-Reply-To: References: Message-ID: <93571771-5cc1-8713-680a-956eaf6bae8b@oracle.com> Flavio Brasil wrote on 6/15/18 11:48 AM: > Thank you for the quick feedback, Gilles. > > Yes, building the frame state is currently where I'm stuck at. Would you be > able to give some details on how the optimization that fuses sequential > `StringBuilder.append` on Graal EE works? The strategy there is to ensure that the operations being fused produce no visible side effects and deoptimize back to the point where the whole operation started if anything happens to go wrong. So all deoptimization states come from the last side effect before the creation of the StringBuilder. That way we don't need to synthesize any frame states. That strategy doesn't work so well when the operations to be fused are large or where side effects might occur because there's no way to create a state that would allow you to resume execution. Having the compiler perform what's essentially bytecode rewriting on the fly doesn't work that easily either since you don't actually end up with executable bytecodes that you can deoptimize to. I think what you probably want is a hybrid approach where there are real bytecodes in the normal path to handle the fusion but there's a little compiler magic to select the fused pathway. Normal execution would always do the unfused pathway but Graal would decide how much of the fused pathway to use and possibly chain together sequences which get connected by inlining. The amount of magic in Graal should be kept to a minimum so that it doesn't have to do fixup that might be tricky or impossible. This is similar to the idea of doing lambda operations by building an expression tree and the final step is to apply that expression tree which might involve compiling or rewriting it into a more efficient form before execution. tom > Are there plans to open source it? > > Best, > > Flavio > > On Fri, Jun 15, 2018 at 8:54 AM Gilles Duboscq > wrote: > >> Hi Flavio, >> >> Usually, the difficult part of this kind of transforms are the stacks >> ("framestates") that your are going to give to the VM along with the >> compiled code. >> >> In principle they should represent stacks and states that are possible to >> reach through the bytecodes that are being compiled so that things like >> deoptimization can work. >> >> In previous experimentation we concluded that HotSpot really doesn't like >> fake framestates. >> Maybe some of these HotSpot limitations could be lifted with some C++ >> changes?? >> >> Overall getting FrameState nodes that will work will be your biggest >> challenge: >> - what will be the bci of the FrameState for the introduced calls? >> - what values will be on the stack if deoptimization occurs for while the >> new calls or the re-written calls are on the stack? can execution proceed >> correctly? >> >> Gilles >> >> On 15/06/18 16:27, Flavio Brasil wrote: >>> *Hi Graal developers,We?ve been exploring a new JIT optimization at >> Twitter >>> that could significantly improve the efficiency of some of the high-level >>> abstractions normally used in Scala. The project is at its early stage so >>> we thought it?d be best to have your feedback on it sooner rather than >>> later since you might be interested in collaborating on it.The initial >>> design doc is available at *https://docs.google.com/document/d/139XJhODDMfcWBNi80-jSWNGrBEmggch72oaNA5LXF2I/edit#heading=h.uqhewhqfc5rs >> * and >> open for comments.Thank you,Flavio >>> BrasilVM Team @ Twitter* >>> >>