From igor.ignatyev at oracle.com Fri Jun 1 07:27:14 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 1 Jun 2018 00:27:14 -0700 Subject: RFR(L) : 8202812 : [TESTBUG] Open source VM testbase compiler tests In-Reply-To: <5B10A4D4.5000206@oracle.com> References: <5B10A4D4.5000206@oracle.com> Message-ID: Hi MIsha, thanks for spotting that, I was pretty sure I removed this file. as it isn't needed, I'll remove it instead of updating legal notice. Cheers, -- Igor > On May 31, 2018, at 6:43 PM, Mikhailo Seledtsov wrote: > > Looks good to me. > > One comment though: > http://cr.openjdk.java.net/~iignatyev//8202812/webrev.00/test/hotspot/jtreg/vmTestbase/jit/graph/js_CGT.testlist.html > - copyright header needs to be updated > please update the copyright statement prior to integration; no need for a new webrev > > Thank you, > Misha > > On 5/18/18, 10:50 AM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8202812/webrev.00/index.html >>> 56733 lines changed: 56732 ins; 0 del; 1 mod; 1 >> Hi all, >> >> could you please review the patch which open sources compiler tests from vm testbase? these tests were developed in different time to cover different parts of JITs. >> >> As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8202812 >> webrev: http://cr.openjdk.java.net/~iignatyev/8202812/webrev.00/index.html >> testing: :vmTestbase_vm_compiler test group >> >> Thanks, >> -- Igor From dmitrij.pochepko at bell-sw.com Fri Jun 1 13:21:36 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 1 Jun 2018 16:21:36 +0300 Subject: RFR: 8189105: AARCH64: create intrinsic for sin and cos Message-ID: Hi, please review patch for JDK-8189105: AARCH64: create intrinsic for sin and cos This patch adds intrinsics for Math::sin(double) and Math::cos(double). It implements algorithm for sin and cos from sharedRuntimeTrig.cpp, which is a variation of classical libm algorithm implementation. Main difference is in heavy SIMD instructions usage, which shortens execution. Also few minor optimizations like pipelining instructions, range-check-based optimizations, optimized constants loading were applied. Performance: I created simple benchmark for sin and cos: http://cr.openjdk.java.net/~dpochepk/8189105/MathBench.java It checks few values, because of different algorithm branches are taken. Results summary: ThunderX2: up to x1.7 improvement ThunderX: up to x1.4 Cortex A53: up to x1.4 Cortex A73: up to 1.65 Detailed results can be seen here: http://cr.openjdk.java.net/~dpochepk/8189105/math-sin.xls Testing: I launched jdk jtreg test for sin/cos functions: (./test/jdk/java/lang/Math/SinCosCornerCasesTests.java) in both Xmixed and Xcomp modes Also I launched respective JCK tests (api/java_lang/Math/sin* and api/java_lang/Math/cos*) in both Xmixed and Xcomp modes All passed, no failures found. webrev: http://cr.openjdk.java.net/~dpochepk/8189105/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8189105 NOTE: This patch depends on my another patch for Math::log (JDK-8196402), which adds new instructions into assembler_aarch64.hpp: frecpe, faddpd, fmlavs, fmlsvs, fmulxvs Thanks, Dmitrij From aph at redhat.com Fri Jun 1 14:00:38 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 1 Jun 2018 15:00:38 +0100 Subject: RFR: 8189105: AARCH64: create intrinsic for sin and cos In-Reply-To: References: Message-ID: <4de41b0c-e318-c70f-a864-4f6c8bd14297@redhat.com> On 06/01/2018 02:21 PM, Dmitrij Pochepko wrote: > Also I launched respective JCK tests (api/java_lang/Math/sin* and > api/java_lang/Math/cos*) in both Xmixed and Xcomp modes > > All passed, no failures found. > > > webrev: http://cr.openjdk.java.net/~dpochepk/8189105/webrev.01/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8189105 I don't really know how to review this. It's a lot of hand-carved assembly code and it's very hard to read. It'd need to be very thoroughly tested. I hope you don't propose to rewrite the entire runtime library by hand. If you do, we need to have a proper discussion here about the risk:reward ratio. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rwestrel at redhat.com Fri Jun 1 14:42:48 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 01 Jun 2018 16:42:48 +0200 Subject: RFR(L): 8203197: C2: consider all paths in loop body for loop predication In-Reply-To: <70947906-550b-fb36-d390-370d5e1c362f@oracle.com> References: <70947906-550b-fb36-d390-370d5e1c362f@oracle.com> Message-ID: Hi Nils, Thanks for reviewing and testing this. > Test: open/test/hotspot/jtreg/serviceability/sa/TestPrintMdo.java and ./ClhsdbCDSCore.java fails. You have added one more trap reason, but it misses a name. > > vmStructs_jvmci.cpp misses _header._struct._trap. It doesn't break > anything since the bits aren't used by any jvmci consumer, but they > should be there for completeness. I will fix those. Roland. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwestrel at redhat.com Fri Jun 1 14:58:30 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 01 Jun 2018 16:58:30 +0200 Subject: RFR(L): 8203197: C2: consider all paths in loop body for loop predication In-Reply-To: <560a000a-01c1-eff8-7520-2dbb8460f041@oracle.com> References: <560a000a-01c1-eff8-7520-2dbb8460f041@oracle.com> Message-ID: Hi Vladimir, Thanks for reviewing this. > I think you should make new methodData layout as separate change. I want > it to be pushed and tested separately to make sure it does not cause any > issues. > I am fine with your approach. Few comments: > > +#ifndef _LP64 > + speculative_trap_padding, > +#endif > > why you need it? MethodData::bci_to_extra_data() makes assumption about the size of a SpeculativeTrapData. See assert there. If it doesn't hold I think that code is broken. > In c1_LIRAssembler_aarch64.cpp you replaced LogBytesPerWord with 0 > except last case. Why keep it in last case? That must be wrong. I'll double check that. > No changes for SPARC, PPC64, etc? Sparc should be ok from code inspection but I can't test it so I will need someone else to. I intended to ask for help for PPC64 etc. but I wanted to first get that review started and see if there were objections. > Did you take into account the dominating (loop exit) check when you move > a following check as profiling predicate? There could be dependencies > between them (klass check, for example, before field load and then NULL > check you want to move). I don't understand what you are referring to with loop exit. There can be dependencies between predicates as you say but they are kept in the order they are moved out of loop so dependent predicates are always executed after the ones they depend on. > Why Shenandoah's barriers checks do not convert into implicit NULL checks? It does. But still we want the barriers hoisted out of loop whenever possible. If the null check stays in the loop then it keeps the barrier in the loop as well. Roland. From gromero at linux.vnet.ibm.com Fri Jun 1 15:16:33 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 1 Jun 2018 12:16:33 -0300 Subject: RFR(S): 8204134: jtreg: Fix RTM abort provoker for various tests after "8149159: Clean up Unsafe" (Reviewed. Needs sponsor) In-Reply-To: References: Message-ID: Hi Igor, Vladimir, On 05/31/2018 01:24 PM, Vladimir Kozlov wrote: > On 5/30/18 8:34 PM, Igor Ignatyev wrote: >> Hi Gustavo, >> >> looks good and trivial to me. thanks for fixing that. > > +1 Thanks for reviewing. Could somebody sponsor that change, please? Best regards, Gustavo > Thanks, > Vladimir > >> >> Cheers, >> -- Igor >> >>> On May 30, 2018, at 7:04 PM, Gustavo Romero wrote: >>> >>> Hi, >>> >>> Could the following simple fix be reviewed please? >>> >>> webrev: http://cr.openjdk.java.net/~gromero/8204134/v1 >>> bug?? : https://bugs.openjdk.java.net/browse/JDK-8204134 >>> >>> Currently the following RTM tests are failing as change >>> "8149159: Clean up Unsafe" made addressSize() method in Unsafe not native >>> anymore: >>> >>> -FAILED: compiler/rtm/locking/TestRTMAbortRatio.java >>> -FAILED: compiler/rtm/locking/TestRTMAbortThreshold.java >>> -FAILED: compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java >>> -FAILED: compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java >>> -FAILED: compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java >>> -FAILED: compiler/rtm/locking/TestRTMLockingThreshold.java >>> -FAILED: compiler/rtm/locking/TestUseRTMDeopt.java >>> -FAILED: compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java >>> >>> >>> Native methods are used as RTM abort provokers in the RTM jtreg test suite. >>> As pageSize() method is still a native method replacing addressSize() by >>> pageSize() fixes the issue: >>> >>> +Passed: compiler/rtm/locking/TestRTMAbortRatio.java >>> +Passed: compiler/rtm/locking/TestRTMAbortThreshold.java >>> +Passed: compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java >>> +Passed: compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java >>> +Passed: compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java >>> +Passed: compiler/rtm/locking/TestRTMLockingThreshold.java >>> +Passed: compiler/rtm/locking/TestUseRTMDeopt.java >>> +Passed: compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java >>> >>> >>> Thank you. >>> >>> Best regards, >>> Gustavo >>> >> > From gromero at linux.vnet.ibm.com Fri Jun 1 15:22:08 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 1 Jun 2018 12:22:08 -0300 Subject: RFR(XS): 8204136: jtreg: Fix failing RTM test RTMSpinLoopCount In-Reply-To: <32A068DF-C845-4EB3-94EB-8AF8E2C7EBA9@oracle.com> References: <32A068DF-C845-4EB3-94EB-8AF8E2C7EBA9@oracle.com> Message-ID: Hi Igor, On 05/31/2018 12:37 AM, Igor Ignatyev wrote: > Hi Gustavo, > > the fix looks reasonable to me. Thanks a lot for reviewing it. I think I still need one additional review for that change? Best regards, Gustavo > Thanks, > -- Igor > >> On May 30, 2018, at 7:05 PM, Gustavo Romero wrote: >> >> Hi, >> >> Could the following change be reviewed please? >> >> webrev: http://cr.openjdk.java.net/~gromero/8204136/v1 >> bug : https://bugs.openjdk.java.net/browse/JDK-8204136 >> >> It throttles down RTMSpinLoopCount deltas in TestRTMSpinLoopCount to avoid >> a test timeout. Using current RTMSpinLoopCount values mostly makes the last >> tries fail (RTMSpinLoopCount = 1_000_000 or 10_000_000). The proposed >> increment is to make the next RTMSpinLoopCount value 10x greater than the >> previous one. >> >> Currently RTMSpinLoopCount can fail (error) sometimes due to timeout. >> (Please see: http://cr.openjdk.java.net/~gromero/misc/moog_spincountloop_timeout.log) >> >> The JVM behavior seems correct and indeed high RTMSpinLoopCount values >> like 10_000_000 should take a long time to complete (> 2 minutes). >> >> Thank you. >> >> >> Best regards, >> Gustavo >> > From gromero at linux.vnet.ibm.com Fri Jun 1 16:16:31 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 1 Jun 2018 13:16:31 -0300 Subject: RFR(XS): 8204135: jtreg: Fix failing RTM test TestUseRTMXendForLockBusy In-Reply-To: <3E280952-BCC3-4FB2-B22B-84E81FF10A04@oracle.com> References: <798cdc2a-ad0a-423f-351b-a8fc9eefc942@linux.vnet.ibm.com> <3E280952-BCC3-4FB2-B22B-84E81FF10A04@oracle.com> Message-ID: <41bd195a-2a7b-16b2-438c-89b8d308b84a@linux.vnet.ibm.com> Hi Igor, On 05/31/2018 12:53 AM, Igor Ignatyev wrote: > Hi Gustavo, > > Unfortunately, I don't recall any detail on this test. Filipp (added) might remember something. but I wouldn't expect him to answer though as he hasn't been actively contributing in open jdk lately. > > I have checked the history, the test hasn't been changed since its integration -- http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3c9c3ba62dfd. although your explanation sounds reasonable to me, I don't understand how the test passed before. OK. I'll wait Filipp's reply. He already helped me a while ago with some other RTM tests :-) Thanks for reviewing it and for checking the history. BTW, after change 8204134 [1], change 8204136 [2], and this change I finally got all RTM tests passing again on Intel. I'm fixing the RTM tests for Power and so I think it's good to agree on how it has to be on Intel. Regards, Gustavo [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-May/029144.html [2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-May/029146.html > Thanks, > -- Igor > >> On May 30, 2018, at 7:04 PM, Gustavo Romero > wrote: >> >> Hi, >> >> Could the following change be reviewed please? >> >> webrev: http://cr.openjdk.java.net/~gromero/8204135/v1 >> bug : https://bugs.openjdk.java.net/browse/JDK-8204135 >> >> It fixes currently failing RTM test "TestUseRTMXendForLockBusy" by changing >> in which cases UseRTMForStackLocks flags must be enabled/disabled. >> >> I could not track down on the timeline when exactly that test stopped to >> pass, however my understanding is that if inflateMonitor is 'false' that >> should /not/ imply that UseRTMForStackLocks is also 'false'. Thus I >> understand that for this particular test if inflated monitors are used, >> then UseRTMForStackLocks has to be disabled, i.e. 'false'. On the other >> hand, if inflated monitors are /not/ used, then UseRTMForStackLocks must be >> enabled. >> >> Currently the test is failing for the following cases where inflateMonitor >> is 'false', because it implies that UseRTMForStackLocks is disabled and so >> no abort statistics is generated (which is correct from the JVM's >> perspective): >> >> // stack lock, xabort on lock busy >> verifyXendForLockBusy(false, false); >> // stack lock, xend on lock busy >> verifyXendForLockBusy(false, true); >> >> In other words, "stack lock" case should imply UseRTMForStackLocks = 'true', >> not 'false'. >> >> Cases: >> // inflated lock, xabort on lock busy >> verifyXendForLockBusy(true, false); >> // inflated lock, xend on lock busy >> verifyXendForLockBusy(true, true); >> >> are not failing because UseRTMForStackLocks = 'true' and they will generate >> proper abort statistics when +UseRTMXendForLockBusy ('xend' is used to >> finish the transaction) or when -UseRTMXendForLockBusy ('xabort' is used >> to finish the transaction). >> >> So, in summing up: (a) inflated lock cases are not being tested correctly >> (since UseRTMForStackLocks is always enabled) and (b) stack lock cases are >> failing because UseRTMForStackLocks is always disabled. >> >> @Igor, it's a long time ago, but maybe you recall some details on that >> test... :-) >> >> >> Thank you. >> >> Best regards, >> Gustavo >> > From vladimir.kozlov at oracle.com Fri Jun 1 16:52:36 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 1 Jun 2018 09:52:36 -0700 Subject: RFR(L) : 8202812 : [TESTBUG] Open source VM testbase compiler tests In-Reply-To: References: <6abc20ff-f125-80cf-98d6-2e69f0181673@oracle.com> Message-ID: On 5/31/18 12:19 PM, Igor Ignatyev wrote: >> On May 31, 2018, at 12:06 PM, Vladimir Kozlov wrote: >> >> Looks good to me. > thanks for reviewing it! > >> I don't understand how these tests trigger JIT compilation? main() does not have any loops. > which test/tests are you asking about? I've looked at a few tests, all of them do have loops (not necessary right in main). in any case, this is how these tests were for a long time, they definitely require reevaluation and rewriting. Almost all /jit/ tests don't have loops: http://cr.openjdk.java.net/~iignatyev//8202812/webrev.00/test/hotspot/jtreg/vmTestbase/jit/DivTest/DivTest.java.html http://cr.openjdk.java.net/~iignatyev//8202812/webrev.00/test/hotspot/jtreg/vmTestbase/jit/bounds/bounds.java.html They like just JCK tests to me. Should we run them with -Xcomp? Or you have a "driver" which trigger JIT compilation for these tests? > >> Where is GoldChecker class? > GoldChecker is defined in test/hotspot/jtreg/vmTestbase/nsk/share/GoldChecker.java, which has been integrated by 8199643: [TESTBUG] Open source common VM testbase code. > >> What --java flag mean in @run command? > "--java" isn't a flag of @run, it's the flag of ExecDriver (test/hotspot/jtreg/vmTestbase/ExecDriver.java) which makes it to interpret the rest of arguments as regular arguments of java. ExecDriver is needed by some tests b/c they either run package-private classes (which regular jtreg's @run can't do) or use zero-exit code to signalize passed status (jtreg treats only 95 as passed). ExecDriver was used to reduce changes in the tests during their conversion to jtreg format and eventually it should go for good. Okay. Thanks, Vladimir > > Thanks, > -- Igor >> >> Thanks, >> Vladimir >> >> On 5/18/18 10:50 AM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8202812/webrev.00/index.html >>>> 56733 lines changed: 56732 ins; 0 del; 1 mod; 1 >>> Hi all, >>> could you please review the patch which open sources compiler tests from vm testbase? these tests were developed in different time to cover different parts of JITs. >>> As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8202812 >>> webrev: http://cr.openjdk.java.net/~iignatyev/8202812/webrev.00/index.html >>> testing: :vmTestbase_vm_compiler test group >>> Thanks, >>> -- Igor > 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 igor.ignatyev at oracle.com Fri Jun 1 20:28:36 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 1 Jun 2018 13:28:36 -0700 Subject: RFR(L) : 8202812 : [TESTBUG] Open source VM testbase compiler tests In-Reply-To: References: <6abc20ff-f125-80cf-98d6-2e69f0181673@oracle.com> Message-ID: <49DB8A18-71D3-4352-8351-E7AF53A6F888@oracle.com> Vladimir, I've filed 8204248[1] to reevaluate these tests from (at least) triggering JIT compilation perspective (at most overall value for testing). as this patch doesn't really introduce these tests, I don't consider their current state as blocker for open sourcing. so if you don't object, I'll push 8202812 patch and we will work on 8204248 later. [1] https://bugs.openjdk.java.net/browse/JDK-8204248 -- Igor > On Jun 1, 2018, at 9:52 AM, Vladimir Kozlov wrote: > > On 5/31/18 12:19 PM, Igor Ignatyev wrote: >>> On May 31, 2018, at 12:06 PM, Vladimir Kozlov wrote: >>> >>> Looks good to me. >> thanks for reviewing it! >>> I don't understand how these tests trigger JIT compilation? main() does not have any loops. >> which test/tests are you asking about? I've looked at a few tests, all of them do have loops (not necessary right in main). in any case, this is how these tests were for a long time, they definitely require reevaluation and rewriting. > > Almost all /jit/ tests don't have loops: > > http://cr.openjdk.java.net/~iignatyev//8202812/webrev.00/test/hotspot/jtreg/vmTestbase/jit/DivTest/DivTest.java.html > http://cr.openjdk.java.net/~iignatyev//8202812/webrev.00/test/hotspot/jtreg/vmTestbase/jit/bounds/bounds.java.html > > They like just JCK tests to me. Should we run them with -Xcomp? Or you have a "driver" which trigger JIT compilation for these tests? > >>> Where is GoldChecker class? >> GoldChecker is defined in test/hotspot/jtreg/vmTestbase/nsk/share/GoldChecker.java, which has been integrated by 8199643: [TESTBUG] Open source common VM testbase code. >>> What --java flag mean in @run command? >> "--java" isn't a flag of @run, it's the flag of ExecDriver (test/hotspot/jtreg/vmTestbase/ExecDriver.java) which makes it to interpret the rest of arguments as regular arguments of java. ExecDriver is needed by some tests b/c they either run package-private classes (which regular jtreg's @run can't do) or use zero-exit code to signalize passed status (jtreg treats only 95 as passed). ExecDriver was used to reduce changes in the tests during their conversion to jtreg format and eventually it should go for good. > > Okay. > > Thanks, > Vladimir > >> Thanks, >> -- Igor >>> >>> Thanks, >>> Vladimir >>> >>> On 5/18/18 10:50 AM, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8202812/webrev.00/index.html >>>>> 56733 lines changed: 56732 ins; 0 del; 1 mod; 1 >>>> Hi all, >>>> could you please review the patch which open sources compiler tests from vm testbase? these tests were developed in different time to cover different parts of JITs. >>>> As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8202812 >>>> webrev: http://cr.openjdk.java.net/~iignatyev/8202812/webrev.00/index.html >>>> testing: :vmTestbase_vm_compiler test group >>>> Thanks, >>>> -- Igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Fri Jun 1 21:09:49 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 1 Jun 2018 14:09:49 -0700 Subject: RFR(L) : 8202812 : [TESTBUG] Open source VM testbase compiler tests In-Reply-To: <49DB8A18-71D3-4352-8351-E7AF53A6F888@oracle.com> References: <6abc20ff-f125-80cf-98d6-2e69f0181673@oracle.com> <49DB8A18-71D3-4352-8351-E7AF53A6F888@oracle.com> Message-ID: <808b0ff7-fdec-cc2c-b05f-4ba5dd012259@oracle.com> Good. Thank you Vladimir On 6/1/18 1:28 PM, Igor Ignatyev wrote: > Vladimir, > > I've filed 8204248[1] to reevaluate these tests from (at least) triggering JIT compilation perspective (at most overall value for testing). as this patch doesn't really introduce these tests, I don't consider their current state as blocker for open sourcing. so if you don't object, I'll push 8202812 patch and we will work on 8204248 later. > > [1] https://bugs.openjdk.java.net/browse/JDK-8204248 > > -- Igor > >> On Jun 1, 2018, at 9:52 AM, Vladimir Kozlov wrote: >> >> On 5/31/18 12:19 PM, Igor Ignatyev wrote: >>>> On May 31, 2018, at 12:06 PM, Vladimir Kozlov wrote: >>>> >>>> Looks good to me. >>> thanks for reviewing it! >>>> I don't understand how these tests trigger JIT compilation? main() does not have any loops. >>> which test/tests are you asking about? I've looked at a few tests, all of them do have loops (not necessary right in main). in any case, this is how these tests were for a long time, they definitely require reevaluation and rewriting. >> >> Almost all /jit/ tests don't have loops: >> >> http://cr.openjdk.java.net/~iignatyev//8202812/webrev.00/test/hotspot/jtreg/vmTestbase/jit/DivTest/DivTest.java.html >> http://cr.openjdk.java.net/~iignatyev//8202812/webrev.00/test/hotspot/jtreg/vmTestbase/jit/bounds/bounds.java.html >> >> They like just JCK tests to me. Should we run them with -Xcomp? Or you have a "driver" which trigger JIT compilation for these tests? >> >>>> Where is GoldChecker class? >>> GoldChecker is defined in test/hotspot/jtreg/vmTestbase/nsk/share/GoldChecker.java, which has been integrated by 8199643: [TESTBUG] Open source common VM testbase code. >>>> What --java flag mean in @run command? >>> "--java" isn't a flag of @run, it's the flag of ExecDriver (test/hotspot/jtreg/vmTestbase/ExecDriver.java) which makes it to interpret the rest of arguments as regular arguments of java. ExecDriver is needed by some tests b/c they either run package-private classes (which regular jtreg's @run can't do) or use zero-exit code to signalize passed status (jtreg treats only 95 as passed). ExecDriver was used to reduce changes in the tests during their conversion to jtreg format and eventually it should go for good. >> >> Okay. >> >> Thanks, >> Vladimir >> >>> Thanks, >>> -- Igor >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 5/18/18 10:50 AM, Igor Ignatyev wrote: >>>>> http://cr.openjdk.java.net/~iignatyev//8202812/webrev.00/index.html >>>>>> 56733 lines changed: 56732 ins; 0 del; 1 mod; 1 >>>>> Hi all, >>>>> could you please review the patch which open sources compiler tests from vm testbase? these tests were developed in different time to cover different parts of JITs. >>>>> As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8202812 >>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8202812/webrev.00/index.html >>>>> testing: :vmTestbase_vm_compiler test group >>>>> Thanks, >>>>> -- Igor > From dmitrij.pochepko at bell-sw.com Fri Jun 1 21:43:47 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Sat, 02 Jun 2018 00:43:47 +0300 Subject: RFR: 8189105: AARCH64: create intrinsic for sin and cos References: <4de41b0c-e318-c70f-a864-4f6c8bd14297@redhat.com> Message-ID: <921531527889427@web57g.yandex.ru> An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Fri Jun 1 21:57:44 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 1 Jun 2018 14:57:44 -0700 Subject: RFR(L): 8203197: C2: consider all paths in loop body for loop predication In-Reply-To: References: <560a000a-01c1-eff8-7520-2dbb8460f041@oracle.com> Message-ID: <2adf40c0-6e38-e35c-c3f1-4829fca92181@oracle.com> On 6/1/18 7:58 AM, Roland Westrelin wrote: > > Hi Vladimir, > > Thanks for reviewing this. > >> I think you should make new methodData layout as separate change. I want >> it to be pushed and tested separately to make sure it does not cause any >> issues. >> I am fine with your approach. Few comments: >> >> +#ifndef _LP64 >> + speculative_trap_padding, >> +#endif >> >> why you need it? > > MethodData::bci_to_extra_data() makes assumption about the size of a > SpeculativeTrapData. See assert there. If it doesn't hold I think that > code is broken. SpeculativeTrapData has only one cell for Method* which should be only one cell, even in 32-bit VM. Change it to 2 cells is wrong I think. I think old assumption is invalid with your changes: // This code assumes an entry for a SpeculativeTrapData is 2 cells because you changed header size for 32 bit - it is now 2 cells. It may actually cause issues (with 32-bit VM) in other places with similar assumption. An other issue is that header can't be allocated/set/load atomically in 32-bit VM as MethodData::bci_to_extra_data_helper() expecting. Please, evaluate these issues. > >> In c1_LIRAssembler_aarch64.cpp you replaced LogBytesPerWord with 0 >> except last case. Why keep it in last case? > > That must be wrong. I'll double check that. > >> No changes for SPARC, PPC64, etc? > > Sparc should be ok from code inspection but I can't test it so I will > need someone else to. I intended to ask for help for PPC64 etc. but I > wanted to first get that review started and see if there were > objections. Okay. > >> Did you take into account the dominating (loop exit) check when you move >> a following check as profiling predicate? There could be dependencies >> between them (klass check, for example, before field load and then NULL >> check you want to move). > > I don't understand what you are referring to with loop exit. > There can be dependencies between predicates as you say but they are > kept in the order they are moved out of loop so dependent predicates are > always executed after the ones they depend on. Then I don't understand your changes. I thought you move out checks (as new predicates) which have profiling information which means you have an other valid path branch from dominating check. Such check can't be moved from loop as I remember. I don't think you can move out from loop loop exit checks. Please, explain which checks you moved from loop as profiling predicates without moving dominating checks. > >> Why Shenandoah's barriers checks do not convert into implicit NULL checks? > > It does. But still we want the barriers hoisted out of loop whenever > possible. If the null check stays in the loop then it keeps the barrier > in the loop as well. Got it. Thanks, Vladimir > > Roland. > From igor.ignatyev at oracle.com Fri Jun 1 23:11:36 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 1 Jun 2018 16:11:36 -0700 Subject: RFR(S): 8204134: jtreg: Fix RTM abort provoker for various tests after "8149159: Clean up Unsafe" (Reviewed. Needs sponsor) In-Reply-To: References: Message-ID: > On Jun 1, 2018, at 8:16 AM, Gustavo Romero wrote: > > Hi Igor, Vladimir, > > On 05/31/2018 01:24 PM, Vladimir Kozlov wrote: >> On 5/30/18 8:34 PM, Igor Ignatyev wrote: >>> Hi Gustavo, >>> >>> looks good and trivial to me. thanks for fixing that. >> +1 > > Thanks for reviewing. > > Could somebody sponsor that change, please? > I'll sponsor this. -- Igor 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 dmitrij.pochepko at bell-sw.com Sat Jun 2 16:50:55 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Sat, 02 Jun 2018 20:50:55 +0400 Subject: RFR: 8189105: AARCH64: create intrinsic for sin and cos In-Reply-To: <4de41b0c-e318-c70f-a864-4f6c8bd14297@redhat.com> References: <4de41b0c-e318-c70f-a864-4f6c8bd14297@redhat.com> Message-ID: <5B12CAEF.8050105@bell-sw.com> (mail client sent as html, resending as plain text) > On 06/01/2018 02:21 PM, Dmitrij Pochepko wrote: >> Also I launched respective JCK tests (api/java_lang/Math/sin* and >> api/java_lang/Math/cos*) in both Xmixed and Xcomp modes >> >> All passed, no failures found. >> >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8189105/webrev.01/ >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8189105 > > I don't really know how to review this. It's a lot of hand-carved > assembly code and it's very hard to read. It'd need to be very > thoroughly tested. It is a vectorized version of existing C code algorithm, so existing jtreg tests specifically written for it are best suitable to test it and were found to be sufficient. During development these test cases were very helpful since they cover all the branches of this algorithm. All relevant JCK tests also passed. The comments in this intrinsic second these in C code for ease of maintenance. > > I hope you don't propose to rewrite the entire runtime library by > hand. If you do, we need to have a proper discussion here about the > risk:reward ratio. > I agree with you and I definitely don't propose that. I think it needs to be decided on a case-by-case basis (for example, we took an algorithm for log() from other HotSpot ports because it turned out to be simpler and faster then vectorized libm, which I also implemented). For sin/cos we're seeing consistent and significant improvement across all AARCH64 microarchitectures we have access to. This code is also very isolated, and the risk:reward ratio here IMO is worth it. It would be difficult to justify why AARCH64 should suffer from absence of intrinsics implemented in other ports. For sin/cos we are in a much better position then other ports which introduced new algorithms without tests specifically crafted for it (and these patches were accepted). I first started to implement sin/cos as it is done for x86 but abandoned it as the code would be more difficult to maintain and the improvement was not as significant. From goetz.lindenmaier at sap.com Sun Jun 3 06:39:09 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Sun, 3 Jun 2018 06:39:09 +0000 Subject: RFR(XS): 8204136: jtreg: Fix failing RTM test RTMSpinLoopCount In-Reply-To: References: <32A068DF-C845-4EB3-94EB-8AF8E2C7EBA9@oracle.com> Message-ID: <03984939db6b4b3eb6e32f9d8d86bd9e@sap.com> Hi Gustavo, Looks good. I will sponsor this and others for you. Best regards, Goetz. > -----Original Message----- > From: Gustavo Romero > Sent: Friday, June 1, 2018 5:22 PM > To: Igor Ignatyev > Cc: hotspot-compiler-dev at openjdk.java.net; Doerr, Martin > ; Lindenmaier, Goetz > > Subject: Re: RFR(XS): 8204136: jtreg: Fix failing RTM test RTMSpinLoopCount > > Hi Igor, > > On 05/31/2018 12:37 AM, Igor Ignatyev wrote: > > Hi Gustavo, > > > > the fix looks reasonable to me. > > Thanks a lot for reviewing it. > > I think I still need one additional review for that change? > > > Best regards, > Gustavo > > > Thanks, > > -- Igor > > > >> On May 30, 2018, at 7:05 PM, Gustavo Romero > wrote: > >> > >> Hi, > >> > >> Could the following change be reviewed please? > >> > >> webrev: http://cr.openjdk.java.net/~gromero/8204136/v1 > >> bug : https://bugs.openjdk.java.net/browse/JDK-8204136 > >> > >> It throttles down RTMSpinLoopCount deltas in TestRTMSpinLoopCount to > avoid > >> a test timeout. Using current RTMSpinLoopCount values mostly makes > the last > >> tries fail (RTMSpinLoopCount = 1_000_000 or 10_000_000). The proposed > >> increment is to make the next RTMSpinLoopCount value 10x greater than > the > >> previous one. > >> > >> Currently RTMSpinLoopCount can fail (error) sometimes due to timeout. > >> (Please see: > http://cr.openjdk.java.net/~gromero/misc/moog_spincountloop_timeout.lo > g) > >> > >> The JVM behavior seems correct and indeed high RTMSpinLoopCount > values > >> like 10_000_000 should take a long time to complete (> 2 minutes). > >> > >> Thank you. > >> > >> > >> Best regards, > >> Gustavo > >> > > From goetz.lindenmaier at sap.com Sun Jun 3 08:11:52 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Sun, 3 Jun 2018 08:11:52 +0000 Subject: RFR(S): 8204134: jtreg: Fix RTM abort provoker for various tests after "8149159: Clean up Unsafe" (Reviewed. Needs sponsor) In-Reply-To: References: Message-ID: Hi Igor, If you don't mind, I could push it right now ... Best, Goetz. > -----Original Message----- > From: hotspot-compiler-dev bounces at openjdk.java.net> On Behalf Of Igor Ignatyev > Sent: Saturday, June 2, 2018 1:12 AM > To: Gustavo Romero > Cc: Vladimir Kozlov ; hotspot-compiler- > dev at openjdk.java.net > Subject: Re: RFR(S): 8204134: jtreg: Fix RTM abort provoker for various tests > after "8149159: Clean up Unsafe" (Reviewed. Needs sponsor) > > > > > On Jun 1, 2018, at 8:16 AM, Gustavo Romero > wrote: > > > > Hi Igor, Vladimir, > > > > On 05/31/2018 01:24 PM, Vladimir Kozlov wrote: > >> On 5/30/18 8:34 PM, Igor Ignatyev wrote: > >>> Hi Gustavo, > >>> > >>> looks good and trivial to me. thanks for fixing that. > >> +1 > > > > Thanks for reviewing. > > > > Could somebody sponsor that change, please? > > > > I'll sponsor this. > > -- Igor From gromero at linux.vnet.ibm.com Mon Jun 4 03:47:17 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 4 Jun 2018 00:47:17 -0300 Subject: RFR(S): 8204134: jtreg: Fix RTM abort provoker for various tests after "8149159: Clean up Unsafe" (Reviewed. Needs sponsor) In-Reply-To: References: Message-ID: <3601c9cd-752e-f17b-5ad5-704fbe64b0be@linux.vnet.ibm.com> Hi Igor, Goetz Thanks for sponsoring it! Best regards, Gustavo On 06/03/2018 05:11 AM, Lindenmaier, Goetz wrote: > Hi Igor, > > If you don't mind, I could push it right now ... > > Best, > Goetz. > >> -----Original Message----- >> From: hotspot-compiler-dev > bounces at openjdk.java.net> On Behalf Of Igor Ignatyev >> Sent: Saturday, June 2, 2018 1:12 AM >> To: Gustavo Romero >> Cc: Vladimir Kozlov ; hotspot-compiler- >> dev at openjdk.java.net >> Subject: Re: RFR(S): 8204134: jtreg: Fix RTM abort provoker for various tests >> after "8149159: Clean up Unsafe" (Reviewed. Needs sponsor) >> >> >> >>> On Jun 1, 2018, at 8:16 AM, Gustavo Romero >> wrote: >>> >>> Hi Igor, Vladimir, >>> >>> On 05/31/2018 01:24 PM, Vladimir Kozlov wrote: >>>> On 5/30/18 8:34 PM, Igor Ignatyev wrote: >>>>> Hi Gustavo, >>>>> >>>>> looks good and trivial to me. thanks for fixing that. >>>> +1 >>> >>> Thanks for reviewing. >>> >>> Could somebody sponsor that change, please? >>> >> >> I'll sponsor this. >> >> -- Igor > From gromero at linux.vnet.ibm.com Mon Jun 4 03:52:14 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 4 Jun 2018 00:52:14 -0300 Subject: RFR(XS): 8204136: jtreg: Fix failing RTM test RTMSpinLoopCount In-Reply-To: <03984939db6b4b3eb6e32f9d8d86bd9e@sap.com> References: <32A068DF-C845-4EB3-94EB-8AF8E2C7EBA9@oracle.com> <03984939db6b4b3eb6e32f9d8d86bd9e@sap.com> Message-ID: <27ddd6c8-fe97-70ae-e7e4-d3543b818302@linux.vnet.ibm.com> Hi Goetz, On 06/03/2018 03:39 AM, Lindenmaier, Goetz wrote: > Looks good. > I will sponsor this and others for you. Thanks for reviewing and sponsoring the changes! Igor, thanks for reviewing the change! Best regards, Gustavo > Best regards, > Goetz. > >> -----Original Message----- >> From: Gustavo Romero >> Sent: Friday, June 1, 2018 5:22 PM >> To: Igor Ignatyev >> Cc: hotspot-compiler-dev at openjdk.java.net; Doerr, Martin >> ; Lindenmaier, Goetz >> >> Subject: Re: RFR(XS): 8204136: jtreg: Fix failing RTM test RTMSpinLoopCount >> >> Hi Igor, >> >> On 05/31/2018 12:37 AM, Igor Ignatyev wrote: >>> Hi Gustavo, >>> >>> the fix looks reasonable to me. >> >> Thanks a lot for reviewing it. >> >> I think I still need one additional review for that change? >> >> >> Best regards, >> Gustavo >> >>> Thanks, >>> -- Igor >>> >>>> On May 30, 2018, at 7:05 PM, Gustavo Romero >> wrote: >>>> >>>> Hi, >>>> >>>> Could the following change be reviewed please? >>>> >>>> webrev: http://cr.openjdk.java.net/~gromero/8204136/v1 >>>> bug : https://bugs.openjdk.java.net/browse/JDK-8204136 >>>> >>>> It throttles down RTMSpinLoopCount deltas in TestRTMSpinLoopCount to >> avoid >>>> a test timeout. Using current RTMSpinLoopCount values mostly makes >> the last >>>> tries fail (RTMSpinLoopCount = 1_000_000 or 10_000_000). The proposed >>>> increment is to make the next RTMSpinLoopCount value 10x greater than >> the >>>> previous one. >>>> >>>> Currently RTMSpinLoopCount can fail (error) sometimes due to timeout. >>>> (Please see: >> http://cr.openjdk.java.net/~gromero/misc/moog_spincountloop_timeout.lo >> g) >>>> >>>> The JVM behavior seems correct and indeed high RTMSpinLoopCount >> values >>>> like 10_000_000 should take a long time to complete (> 2 minutes). >>>> >>>> Thank you. >>>> >>>> >>>> Best regards, >>>> Gustavo >>>> >>> > From goetz.lindenmaier at sap.com Mon Jun 4 10:34:31 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 4 Jun 2018 10:34:31 +0000 Subject: RFR(XS): 8204277: [testbug] fix DisassembleCodeBlobTest. Message-ID: <2d983130fe7947e49b495147dbe7d636@sap.com> Hi, this test fails because the first call to the disassembler prints the architecture: [Disassembling for mach='i386:x86-64'] Thus comparing the first and second result fails. Instead, compare 2. and 3. result. http://cr.openjdk.java.net/~goetz/wr18/8204277-fixDisassTest/01/ Best regards, Goetz. From tobias.hartmann at oracle.com Mon Jun 4 10:57:31 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 4 Jun 2018 12:57:31 +0200 Subject: RFR(XS): 8204277: [testbug] fix DisassembleCodeBlobTest. In-Reply-To: <2d983130fe7947e49b495147dbe7d636@sap.com> References: <2d983130fe7947e49b495147dbe7d636@sap.com> Message-ID: <05c1bf21-4696-5819-81fe-8ffa7cdb6781@oracle.com> Hi Goetz, looks good to me. Little typo: "veriy" -> "very". Best regards, Tobias On 04.06.2018 12:34, Lindenmaier, Goetz wrote: > Hi, > > this test fails because the first call to the disassembler prints the architecture: > [Disassembling for mach='i386:x86-64'] > > Thus comparing the first and second result fails. Instead, compare 2. and 3. result. > http://cr.openjdk.java.net/~goetz/wr18/8204277-fixDisassTest/01/ > > Best regards, > Goetz. > From aph at redhat.com Mon Jun 4 10:59:16 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 4 Jun 2018 11:59:16 +0100 Subject: RFR: 8189105: AARCH64: create intrinsic for sin and cos In-Reply-To: <5B12CAEF.8050105@bell-sw.com> References: <4de41b0c-e318-c70f-a864-4f6c8bd14297@redhat.com> <5B12CAEF.8050105@bell-sw.com> Message-ID: <2bd89c11-d234-ceae-3b04-4c547ef5836c@redhat.com> On 06/02/2018 05:50 PM, Dmitrij Pochepko wrote: > (mail client sent as html, resending as plain text) > > > On 06/01/2018 02:21 PM, Dmitrij Pochepko wrote: > >> Also I launched respective JCK tests (api/java_lang/Math/sin* and > >> api/java_lang/Math/cos*) in both Xmixed and Xcomp modes > >> > >> All passed, no failures found. > >> > >> > >> webrev: http://cr.openjdk.java.net/~dpochepk/8189105/webrev.01/ > >> > >> CR: https://bugs.openjdk.java.net/browse/JDK-8189105 > > > > I don't really know how to review this. It's a lot of hand-carved > > assembly code and it's very hard to read. It'd need to be very > > thoroughly tested. > > It is a vectorized version of existing C code algorithm, Which existing C cpde algorithm? > so existing jtreg tests specifically written for it are best > suitable to test it and were found to be sufficient. During > development these test cases were very helpful since they cover all > the branches of this algorithm. All relevant JCK tests also > passed. The comments in this intrinsic second these in C code for > ease of maintenance. > > > > > I hope you don't propose to rewrite the entire runtime library by > > hand. If you do, we need to have a proper discussion here about the > > risk:reward ratio. > > I agree with you and I definitely don't propose that. I think it > needs to be decided on a case-by-case basis (for example, we took an > algorithm for log() from other HotSpot ports because it turned out > to be simpler and faster then vectorized libm, which I also > implemented). For sin/cos we're seeing consistent and significant > improvement across all AARCH64 microarchitectures we have access > to. This code is also very isolated, and the risk:reward ratio here > IMO is worth it. > > It would be difficult to justify why AARCH64 should suffer from > absence of intrinsics implemented in other ports. For sin/cos we are > in a much better position then other ports which introduced new > algorithms without tests specifically crafted for it (and these > patches were accepted). I first started to implement sin/cos as it > is done for x86 but abandoned it as the code would be more difficult > to maintain and the improvement was not as significant. Indeed, so let's try to make this as good as we can. If this is going to be maintained we need more documentation. Please provide full pseudocode for the program; if the original C algorithm is completely unchanged that'll be fine, but if you have changed it in any way please change the C accordingly. Also, note that on x86 everything (C1, C2, template interpreter) calls the intrinsic. This is because we do not want to see any difference, even in a single bit, between them. It is essential that we follow x86 in this regard for all intrinsics. You can just copy the x86 code to do this. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From goetz.lindenmaier at sap.com Mon Jun 4 12:15:30 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 4 Jun 2018 12:15:30 +0000 Subject: RFR(XS): 8204277: [testbug] fix DisassembleCodeBlobTest. In-Reply-To: <05c1bf21-4696-5819-81fe-8ffa7cdb6781@oracle.com> References: <2d983130fe7947e49b495147dbe7d636@sap.com> <05c1bf21-4696-5819-81fe-8ffa7cdb6781@oracle.com> Message-ID: <7cacbe112e194a68b0bbe22a5ff16c81@sap.com> Hi Tobias, thanks for reviewing. I fixed the typo. Is this trivial enough to be pushed? Best regards Goetz. > -----Original Message----- > From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] > Sent: Montag, 4. Juni 2018 12:58 > To: Lindenmaier, Goetz ; hotspot-compiler- > dev at openjdk.java.net > Subject: Re: RFR(XS): 8204277: [testbug] fix DisassembleCodeBlobTest. > > Hi Goetz, > > looks good to me. Little typo: "veriy" -> "very". > > Best regards, > Tobias > > On 04.06.2018 12:34, Lindenmaier, Goetz wrote: > > Hi, > > > > this test fails because the first call to the disassembler prints the > architecture: > > [Disassembling for mach='i386:x86-64'] > > > > Thus comparing the first and second result fails. Instead, compare 2. and 3. > result. > > http://cr.openjdk.java.net/~goetz/wr18/8204277-fixDisassTest/01/ > > > > Best regards, > > Goetz. > > From tobias.hartmann at oracle.com Mon Jun 4 12:17:51 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 4 Jun 2018 14:17:51 +0200 Subject: RFR(XS): 8204277: [testbug] fix DisassembleCodeBlobTest. In-Reply-To: <7cacbe112e194a68b0bbe22a5ff16c81@sap.com> References: <2d983130fe7947e49b495147dbe7d636@sap.com> <05c1bf21-4696-5819-81fe-8ffa7cdb6781@oracle.com> <7cacbe112e194a68b0bbe22a5ff16c81@sap.com> Message-ID: <21764cd2-4b6b-012d-7165-cc21e8dddf06@oracle.com> On 04.06.2018 14:15, Lindenmaier, Goetz wrote: > Is this trivial enough to be pushed? Yes, I think so. Best regards, Tobias From rwestrel at redhat.com Mon Jun 4 14:05:26 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 04 Jun 2018 16:05:26 +0200 Subject: RFR(L): 8203197: C2: consider all paths in loop body for loop predication In-Reply-To: <2adf40c0-6e38-e35c-c3f1-4829fca92181@oracle.com> References: <560a000a-01c1-eff8-7520-2dbb8460f041@oracle.com> <2adf40c0-6e38-e35c-c3f1-4829fca92181@oracle.com> Message-ID: Hi Vladimir, > SpeculativeTrapData has only one cell for Method* which should be only > one cell, even in 32-bit VM. Change it to 2 cells is wrong I think. > > I think old assumption is invalid with your changes: > > // This code assumes an entry for a SpeculativeTrapData is 2 cells > > because you changed header size for 32 bit - it is now 2 cells. The extra data area where the speculative traps are stored is allocated with: // Add some extra DataLayout cells (at least one) to track stray traps. int extra_data_count = compute_extra_data_count(data_size, empty_bc_count, needs_speculative_traps); object_size += extra_data_count * DataLayout::compute_size_in_bytes(0); // Add a cell to record information about modified arguments. int arg_size = method->size_of_parameters(); object_size += DataLayout::compute_size_in_bytes(arg_size+1); So 1) extra_data_count * DataLayout::compute_size_in_bytes(0) guarantees the size of the space for traps is a multiple of the header size so a multiple of 2 cells on 32 bits 2) space is reserved after the traps for entries with tag DataLayout::arg_info_data_tag. That stuff is still inside the extra data area. When MethodData::bci_to_extra_data() allocates a new trap in the extra data area, it must make sure there's still space available. It checks that there's room by finding the last trap in the area, moving to the next entry and checking if: - it's still within the extra data area - it's not an arg_info_data_tag, i.e. we're not overflowing in the argument area - if the trap is a speculative trap it also needs to check that there's room, not only for the header, but also for the Method* Now if traps are either 2 (regular traps) or 3 (speculative traps) cells, that code cannot be left as is. Let say we have 6 cells for extra data. We allocate a regular trap and a speculative trap. Next entry is at cell number 5 (assuming they are numbered from 0). Let's say now we want to allocate a regular trap. We're still within the extra data area (but don't have sufficient room), we're half way on the first arg info but reading the tag can't be used to reliably tell us that. Adding the padding allows us to keep the existing logic. > It may actually cause issues (with 32-bit VM) in other places with > similar assumption. > > An other issue is that header can't be allocated/set/load atomically in > 32-bit VM as MethodData::bci_to_extra_data_helper() expecting. The header contains: bci/tag, flags and traps bci/tag are constant. They are set once for all when the MethodData is built. There's an exception for traps as discussed above but then allocation happens under a lock and once a trap is allocated the bci/tag is constant. So, the only things being updated are flags and traps. It's possible we loose an update because of concurrency but that was true before and the change doesn't make it worse. I don't see what other problem the lack of atomicity could cause. The method data is laid out statically in a way that, AFAICT, is quite robust to a 2 cell header. Once it is built, updates mostly happen in fields of the individual profile data. So I don't really see what else could break. > Then I don't understand your changes. I thought you move out checks (as > new predicates) which have profiling information which means you have an > other valid path branch from dominating check. Such check can't be moved > from loop as I remember. I don't think you can move out from loop loop > exit checks. > > Please, explain which checks you moved from loop as profiling predicates > without moving dominating checks. Say we have: while() { if (some_condition) { // both branches profiled taken if (!null_check) unc(null_check); if (!range_check) unc(range_check); ... } } The existing loop predication wouldn't consider those predicates. My change does if there's a speculated pay off. if (!null_check) unc(profile_predicate); if (!range_check) unc(profile_predicate); while() { if (some_condition) { // both branches profiled taken ... } } It's otherwise strictly identical to the existing loop predication: predicates are moved only if all inputs are loop independent. Now: while() { if (!null_check1) unc(null_check); if (!range_check1) unc(range_check); ... if (some_condition) { // both branches profiled taken if (!null_check2) unc(null_check); if (!range_check2) unc(range_check); ... } } becomes: if (!null_check1) unc(predicate); if (!range_check1) unc(predicate); if (!null_check2) unc(profile_predicate); if (!range_check2) unc(profile_predicate); while() { ... if (some_condition) { // both branches profiled taken ... } } that's because loop predication is now more speculative, so it's more likely to fail and I don't want a failure with profile predicates to disable predication entirely and cause a regression. First, a pass over the loop body moves regular predicates out of the loop and then a second pass moves other predicates as profile predicates. There can be dependencies between predicates. Dependencies are preserved because predicates are kept out of the loop in the order they were moved out of loop. With this: while() { if (!null_check1) unc(null_check); if (!range_check1) unc(range_check); ... if (some_condition) { // both branches profiled taken if (!null_check2) unc(null_check); if (!range_check2) unc(range_check); ... } if (!null_check3) unc(null_check); if (!range_check3) unc(range_check); } Let's say, the first time loop predication is applies, it finds null_check1/range_check1 and null_check2/range_check2 to hoist but not null_check3/range_check3 because they are not loop independent at that point. if (!null_check1) unc(predicate); if (!range_check1) unc(predicate); if (!null_check2) unc(profile_predicate); if (!range_check2) unc(profile_predicate); while() { ... if (some_condition) { // both branches profiled taken ... } if (!null_check3) unc(null_check); if (!range_check3) unc(range_check); } Now let's say a later loop predication pass finds it can hoist null_check3/range_check3. To guarantee correct ordering of predicates, they will be moved as profile_predicates even though they are not in a branch: if (!null_check1) unc(predicate); if (!range_check1) unc(predicate); if (!null_check2) unc(profile_predicate); if (!range_check2) unc(profile_predicate); if (!null_check3) unc(profile_predicate); if (!range_check3) unc(profile_predicate); while() { ... if (some_condition) { // both branches profiled taken ... } } When you say loop exit are you talking about something like? while() { if (some_condition) { // both branches profiled taken break; } if (!null_check) unc(null_check); if (!range_check) unc(range_check); ... } It would be optimized as: if (!null_check) unc(profile_predicate); if (!range_check) unc(profile_predicate); while() { if (some_condition) { // both branches profiled taken break; } } As long as inputs for the tests are loop independent I don't see why that would be illegal. Worst case, they trigger a deopt and next compilation won't apply profile predication. Roland. From dmitrij.pochepko at bell-sw.com Mon Jun 4 15:50:32 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Mon, 4 Jun 2018 18:50:32 +0300 Subject: RFR: 8204289: AARCH64: enable math intrinsics usage in interpreter and C1 Message-ID: <6bd4bccb-befb-0523-d75e-2c5a99c4ee34@bell-sw.com> Hi all, please review patch for JDK-8204289: AARCH64: enable math intrinsics usage in interpreter and C1 This patch enables usage of math intrinsics for interpreter and C1 in case intrinsics are implemented. Code follows that of x86 port. Testing: I've merged this patch with implemented intrinsic and launched jtreg tests and benchmark in 2 more modes: -Xint and -XX:TieredStopAtLevel=3 Benchmark scores were improved as expected of intrinsic. All tests passed. webrev: http://cr.openjdk.java.net/~dpochepk/8204289/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8204289 Thanks, Dmitrij From dmitrij.pochepko at bell-sw.com Mon Jun 4 15:50:37 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Mon, 4 Jun 2018 18:50:37 +0300 Subject: RFR: 8189105: AARCH64: create intrinsic for sin and cos In-Reply-To: <2bd89c11-d234-ceae-3b04-4c547ef5836c@redhat.com> References: <4de41b0c-e318-c70f-a864-4f6c8bd14297@redhat.com> <5B12CAEF.8050105@bell-sw.com> <2bd89c11-d234-ceae-3b04-4c547ef5836c@redhat.com> Message-ID: On 04.06.2018 13:59, Andrew Haley wrote: > On 06/02/2018 05:50 PM, Dmitrij Pochepko wrote: >> (mail client sent as html, resending as plain text) >> >> > On 06/01/2018 02:21 PM, Dmitrij Pochepko wrote: >> >> Also I launched respective JCK tests (api/java_lang/Math/sin* and >> >> api/java_lang/Math/cos*) in both Xmixed and Xcomp modes >> >> >> >> All passed, no failures found. >> >> >> >> >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8189105/webrev.01/ >> >> >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8189105 >> > >> > I don't really know how to review this. It's a lot of hand-carved >> > assembly code and it's very hard to read. It'd need to be very >> > thoroughly tested. >> >> It is a vectorized version of existing C code algorithm, > Which existing C cpde algorithm? this is a hotspot copy of fdlibm trigonometric functions in hotspot/src/share/runtime/sharedRuntimeTrig.cpp I added respective comment in intrinsic. > >> so existing jtreg tests specifically written for it are best >> suitable to test it and were found to be sufficient. During >> development these test cases were very helpful since they cover all >> the branches of this algorithm. All relevant JCK tests also >> passed. The comments in this intrinsic second these in C code for >> ease of maintenance. >> >> > >> > I hope you don't propose to rewrite the entire runtime library by >> > hand. If you do, we need to have a proper discussion here about the >> > risk:reward ratio. >> >> I agree with you and I definitely don't propose that. I think it >> needs to be decided on a case-by-case basis (for example, we took an >> algorithm for log() from other HotSpot ports because it turned out >> to be simpler and faster then vectorized libm, which I also >> implemented). For sin/cos we're seeing consistent and significant >> improvement across all AARCH64 microarchitectures we have access >> to. This code is also very isolated, and the risk:reward ratio here >> IMO is worth it. >> >> It would be difficult to justify why AARCH64 should suffer from >> absence of intrinsics implemented in other ports. For sin/cos we are >> in a much better position then other ports which introduced new >> algorithms without tests specifically crafted for it (and these >> patches were accepted). I first started to implement sin/cos as it >> is done for x86 but abandoned it as the code would be more difficult >> to maintain and the improvement was not as significant. > Indeed, so let's try to make this as good as we can. If this is going > to be maintained we need more documentation. Please provide full > pseudocode for the program; if the original C algorithm is completely > unchanged that'll be fine, but if you have changed it in any way > please change the C accordingly. There were no changes in algorithm. Just vectorized version of code in hotspot/src/share/runtime/sharedRuntimeTrig.cpp with minor optimizations. I created detailed comment in macroAssembler_aarch64_trig.cpp which explains how this optimized version is different from the original. I don't think it's convenient to copy all C code, because macroAssembler_aarch64_trig.cpp is basically optimized assembler to whole 890-lines-long sharedRuntimeTrig.cpp except dtan function. > > Also, note that on x86 everything (C1, C2, template interpreter) calls > the intrinsic. This is because we do not want to see any difference, > even in a single bit, between them. It is essential that we follow > x86 in this regard for all intrinsics. You can just copy the x86 code > to do this. > You're right. I created separate CR to enable all possible math intrinsics usage for C1 and interpreter: https://bugs.openjdk.java.net/browse/JDK-8204289, which is independent from sin/cos and log intrinsic code. And I also minimally updated sin/cos patch. Respective generation call is moved from generate_all() to generate_initial() for interpreter to use initialized stub routine address. Please take a look at webrev.02: http://cr.openjdk.java.net/~dpochepk/8189105/webrev.02/ Thanks, Dmitrij -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Mon Jun 4 17:12:24 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 4 Jun 2018 13:12:24 -0400 Subject: RFR (S) 8204237: Clean up incorrectly included .inline.hpp files from jvmciJavaClasses.hpp Message-ID: <05e83d76-d784-6360-3b88-06c5db1848c2@oracle.com> 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 vladimir.kozlov at oracle.com Mon Jun 4 17:12:26 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 4 Jun 2018 10:12:26 -0700 Subject: A bug in the AOT runtime In-Reply-To: <49ae026c-4e17-e090-fdba-c410b3722976@redhat.com> References: <49ae026c-4e17-e090-fdba-c410b3722976@redhat.com> Message-ID: CCing to hotspot-compiler because we are responsible for AOT. Andrew, it looks like next bug which I unfortunately did not have time to look on: https://bugs.openjdk.java.net/browse/JDK-8146029 It did not show up on Linux because usually CodeCache and and AOTed code are located near each other on Linux. Currently I am planning to look on it after JDK 11. Regards, Vladimir On 6/4/18 7:51 AM, Andrew Haley wrote: > I saw an extreme slowdown when running AOT-compiled code. > > It's a situation where we get stuck perpetually calling the IC miss > code every time a method is invoked, and it never gets fixed. This > happens when the AOT library is loaded more than 2G away from the code > buffer, so calls cannot reach from compiled to AOT-compiled code. > > The symptom looks like this: > > FALSE IC miss (invokeinterface) converting to compiled call to jdk.internal.jrtfs.JrtPath::toString code: 0x00007f58bca9b570 > IC miss (invokeinterface) call to java.util.ArrayList$ArrayListSpliterator::tryAdvance code: 0x00007f58bcaa9680 > FALSE IC miss (invokeinterface) converting to compiled call to java.util.ArrayList$ArrayListSpliterator::tryAdvance code: 0x00007f58bcaa9680 > IC miss (invokeinterface) call to jdk.internal.jrtfs.JrtPath::getFileName code: 0x00007f58bca9e6f0 > FALSE IC miss (invokeinterface) converting to compiled call to jdk.internal.jrtfs.JrtPath::getFileName code: 0x00007f58bca9e6f0 > IC miss (invokeinterface) call to jdk.internal.jrtfs.JrtPath::getFileName code: 0x00007f58bca9e6f0 > FALSE IC miss (invokeinterface) converting to compiled call to jdk.internal.jrtfs.JrtPath::getFileName code: 0x00007f58bca9e6f0 > IC miss (invokeinterface) call to jdk.internal.jrtfs.JrtPath::toString code: 0x00007f58bca9b570 > FALSE IC miss (invokeinterface) converting to compiled call to jdk.internal.jrtfs.JrtPath::toString code: 0x00007f58bca9b570 > IC miss (invokeinterface) call to java.util.ArrayList$ArrayListSpliterator::tryAdvance code: 0x00007f58bcaa9680 > > ... and the call misses every time, never to be fixed up. > > This is how it happens: > > We have a call to the IC miss stub which is caused not by a true IC > miss (i.e. different classes) but by AOT-compiled code becoming > available. We hit a transition stub, and that diverts us to the IC > miss handler. > > This is the logic in the transition stub. The relevant part for us is > the second part: > > __ load_klass(temp, receiver); > __ cmpptr(temp, Address(holder, CompiledICHolder::holder_klass_offset())); > __ movptr(rbx, Address(holder, CompiledICHolder::holder_metadata_offset())); > __ jcc(Assembler::equal, ok); > __ jump(RuntimeAddress(SharedRuntime::get_ic_miss_stub())); > > __ bind(ok); > // Method might have been compiled since the call site was patched to > // interpreted if that is the case treat it as a miss so we can get > // the call site corrected. > __ cmpptr(Address(rbx, in_bytes(Method::code_offset())), (int32_t)NULL_WORD); > __ jcc(Assembler::equal, skip_fixup); > __ jump(RuntimeAddress(SharedRuntime::get_ic_miss_stub())); > > Because we have AOT-compiled code, the cmpptr with NULL failes and we > enter SharedRuntime::handle_wrong_method_ic_miss(). If the call from > compiled to AOT code cannot reach, we're going to need a stub. We now > execute this code: > > if (entry != NULL && !far_c2a) { > // Call to near compiled code (nmethod or aot). > > ** We can't do this because the branch is too far > > info.set_compiled_entry(entry, is_optimized ? NULL : receiver_klass, is_optimized); > } else { > if (is_optimized) { > if (far_c2a) { > // Call to aot code from nmethod. > info.set_aot_entry(entry, method()); > } else { > // Use stub entry > info.set_interpreter_entry(method()->get_c2i_entry(), method()); > } > } else { > > ** We do this > > // Use icholder entry > assert(method_code == NULL || method_code->is_compiled(), "must be compiled"); > CompiledICHolder* holder = new CompiledICHolder(method(), receiver_klass); > info.set_icholder_entry(method()->get_c2i_unverified_entry(), holder); > } > } > > So, we still have a transition stub, and it will do the same thing as > last time. > > When we compare Method::_code with NULL, we will find that it is not > NULL: it is the AOT-compiled entry point. So we will call the IC miss > stub. Every time, around and around. > > What we actually need, I think, is a different kind of transition stub > that does not check that Method::_code is zero but instead jumps > straight to the AOT-compiled code. > 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 aph at redhat.com Mon Jun 4 17:45:12 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 4 Jun 2018 18:45:12 +0100 Subject: A bug in the AOT runtime In-Reply-To: References: <49ae026c-4e17-e090-fdba-c410b3722976@redhat.com> Message-ID: On 06/04/2018 06:12 PM, Vladimir Kozlov wrote: > Andrew, it looks like next bug which I unfortunately did not have time > to look on: > > https://bugs.openjdk.java.net/browse/JDK-8146029 > > It did not show up on Linux because usually CodeCache and and AOTed code > are located near each other on Linux. > > Currently I am planning to look on it after JDK 11. OK. That issue is too secret for me to see it. I'll fix the issue on AArch64 another way, anyway. Thanks. -- 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:51:40 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 4 Jun 2018 10:51:40 -0700 Subject: A bug in the AOT runtime In-Reply-To: References: <49ae026c-4e17-e090-fdba-c410b3722976@redhat.com> Message-ID: <635be2d8-0561-6fdc-4732-6d1b7e5befe4@oracle.com> Sorry, I forgot to opened it (was filed long ago). You can see it - nothing secret there. I had the same observation on Solaris x86 as you are on aarch64. Regards, Vladimir On 6/4/18 10:45 AM, Andrew Haley wrote: > On 06/04/2018 06:12 PM, Vladimir Kozlov wrote: >> Andrew, it looks like next bug which I unfortunately did not have time >> to look on: >> >> https://bugs.openjdk.java.net/browse/JDK-8146029 >> >> It did not show up on Linux because usually CodeCache and and AOTed code >> are located near each other on Linux. >> >> Currently I am planning to look on it after JDK 11. > > OK. That issue is too secret for me to see it. I'll fix the issue on > AArch64 another way, anyway. Thanks. > 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 leonid.mesnik at oracle.com Tue Jun 5 01:02:21 2018 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Mon, 4 Jun 2018 18:02:21 -0700 Subject: RFR(XXS): 8204103: Mark test serviceability/dcmd/compiler/CompilerQueueTest.java as intermittent and exclude it from tier1 In-Reply-To: References: <482434D6-4374-4E04-890F-D6DCB005FF20@oracle.com> <410FD58C-C8CB-4254-B7BB-FC712BC8D28E@oracle.com> Message-ID: <975CE5EB-F26A-457A-824B-FA436293D103@oracle.com> Thank you. Leonid > On Jun 4, 2018, at 5:09 PM, jesper.wilhelmsson at oracle.com wrote: > > Looks good. > I'll sponsor this change. > /Jesper > >> On 31 May 2018, at 19:59, Leonid Mesnik wrote: >> >> Thank you for review. >> >> It becomes a part of hotspot_tier2_runtime now and executed in tier2. (Also in tier3 and higher tiers with other options.) >> >> Leonid >> >>> On May 31, 2018, at 10:47 AM, Vladimir Kozlov wrote: >>> >>> Looks fine. In what tier the test will be run? >>> >>> Thanks, >>> Vladimir >>> >>> On 5/31/18 10:11 AM, Leonid Mesnik wrote: >>>> Hi >>>> Please review following tiny fix which marks test serviceability/dcmd/compiler/CompilerQueueTest.java as intermittent and exclude it from tier1. >>>> The test intermittently fails (1-2 times in 1000 runs) because of https://bugs.openjdk.java.net/browse/JDK-8158374. >>>> Tier1 should be stable and don't contain any tests with known issues. It should always pass if there are no regression introduced by new fix. So this test should be excluded from tier1. >>>> Also fix marks this test with corresponding key like it is done for jdk, langtoools and nashorn tests. >>>> webrev: http://cr.openjdk.java.net/~lmesnik/8204103/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8204103 >>>> I verified that tier1 runs and doesn't contain this test now. >>>> See more information about intermittent keyword in https://bugs.openjdk.java.net/browse/JDK-8075565 >>>> Leonid >> > From rwestrel at redhat.com Tue Jun 5 07:33:11 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 05 Jun 2018 09:33:11 +0200 Subject: RFR(S): 8202747: C2: assert(mode == ControlAroundStripMined && use == sfpt) failed: missed a node In-Reply-To: References: Message-ID: Any one else for this one? Roland. 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 coleen.phillimore at oracle.com Tue Jun 5 13:43:39 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 5 Jun 2018 09:43:39 -0400 Subject: RFR (S) 8204237: Clean up incorrectly included .inline.hpp files from jvmciJavaClasses.hpp In-Reply-To: References: <05e83d76-d784-6360-3b88-06c5db1848c2@oracle.com> <2463b3b2-317a-5e2e-4fb6-3cc113b8b576@oracle.com> <5498e07a-8899-72fe-6809-5a8b12f696c5@oracle.com> Message-ID: <17aac388-30ce-d760-4f7d-5a6f9ddee596@oracle.com> Thank you for reviewing, Doug!? I think this should merge fine with the graal changes going in either direction. Coleen On 6/5/18 9:34 AM, Doug Simon wrote: > 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 aph at redhat.com Tue Jun 5 15:26:36 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Jun 2018 16:26:36 +0100 Subject: RFR: 8204341: AArch64: AOT runtime does not need a workaround for far calls Message-ID: On AArch64 we use trampoline calls which can reach to AOT code wherever it is in the address space, so we need no special handling for out-of-range calls. We must also ensure that if we're using AOT we force trampolines to be generated. http://cr.openjdk.java.net/~aph/8204341/ -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Jun 5 15:27:27 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Jun 2018 16:27:27 +0100 Subject: A bug in the AOT runtime In-Reply-To: <635be2d8-0561-6fdc-4732-6d1b7e5befe4@oracle.com> References: <49ae026c-4e17-e090-fdba-c410b3722976@redhat.com> <635be2d8-0561-6fdc-4732-6d1b7e5befe4@oracle.com> Message-ID: <4bcdb0e9-5d35-7cd1-784a-2eea3f7d7018@redhat.com> On 06/04/2018 06:51 PM, Vladimir Kozlov wrote: > Sorry, I forgot to opened it (was filed long ago). You can see it - > nothing secret there. I had the same observation on Solaris x86 as you > are on aarch64. Thanks. I posted an RFR for the workaround as "RFR: 8204341: AArch64: AOT runtime does not need a workaround for far calls" -- 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 Tue Jun 5 15:35:35 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 5 Jun 2018 08:35:35 -0700 Subject: RFR: 8204341: AArch64: AOT runtime does not need a workaround for far calls In-Reply-To: References: Message-ID: Looks good. Lucky you - you have already functionality to deal with far calls. From changes it seems you will always use trampolines for calls (regardless distance). Right? Thanks, Vladimir On 6/5/18 8:26 AM, Andrew Haley wrote: > On AArch64 we use trampoline calls which can reach to AOT code > wherever it is in the address space, so we need no special handling > for out-of-range calls. We must also ensure that if we're using AOT we > force trampolines to be generated. > > http://cr.openjdk.java.net/~aph/8204341/ > From aph at redhat.com Tue Jun 5 15:44:33 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Jun 2018 16:44:33 +0100 Subject: RFR: 8204341: AArch64: AOT runtime does not need a workaround for far calls In-Reply-To: References: Message-ID: <01d7c15a-30fb-25b4-8430-c76234157729@redhat.com> On 06/05/2018 04:35 PM, Vladimir Kozlov wrote: > Lucky you - you have already functionality to deal with far calls. > From changes it seems you will always use trampolines for calls > (regardless distance). Right? Not exactly. The trampolines are always generated, but are only used if a branch does not reach. -- 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 Tue Jun 5 16:17:40 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 5 Jun 2018 09:17:40 -0700 Subject: RFR: 8204341: AArch64: AOT runtime does not need a workaround for far calls In-Reply-To: <01d7c15a-30fb-25b4-8430-c76234157729@redhat.com> References: <01d7c15a-30fb-25b4-8430-c76234157729@redhat.com> Message-ID: <6ee77101-aa95-6626-9528-3edeece9ed14@oracle.com> On 6/5/18 8:44 AM, Andrew Haley wrote: > On 06/05/2018 04:35 PM, Vladimir Kozlov wrote: > >> Lucky you - you have already functionality to deal with far calls. >> From changes it seems you will always use trampolines for calls >> (regardless distance). Right? > > Not exactly. The trampolines are always generated, but are only used > if a branch does not reach. > I thought that far_branches() returning always true in UseAOT case will cause using trampolines. So it is different. Thanks, Vladimir From aph at redhat.com Tue Jun 5 16:35:09 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Jun 2018 17:35:09 +0100 Subject: RFR: 8204341: AArch64: AOT runtime does not need a workaround for far calls In-Reply-To: <6ee77101-aa95-6626-9528-3edeece9ed14@oracle.com> References: <01d7c15a-30fb-25b4-8430-c76234157729@redhat.com> <6ee77101-aa95-6626-9528-3edeece9ed14@oracle.com> Message-ID: <53b07d5e-846e-9824-5ae1-c4bb07846140@redhat.com> On 06/05/2018 05:17 PM, Vladimir Kozlov wrote: > On 6/5/18 8:44 AM, Andrew Haley wrote: >> On 06/05/2018 04:35 PM, Vladimir Kozlov wrote: >> >>> Lucky you - you have already functionality to deal with far calls. >>> From changes it seems you will always use trampolines for calls >>> (regardless distance). Right? >> >> Not exactly. The trampolines are always generated, but are only used >> if a branch does not reach. > > I thought that far_branches() returning always true in UseAOT case > will cause using trampolines. So it is different. far_branches() returns true if we need to generate trampolines: we only use them in the patching code if a branch won't reach. -- 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 Tue Jun 5 16:40:36 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 5 Jun 2018 09:40:36 -0700 Subject: RFR: 8204341: AArch64: AOT runtime does not need a workaround for far calls In-Reply-To: <53b07d5e-846e-9824-5ae1-c4bb07846140@redhat.com> References: <01d7c15a-30fb-25b4-8430-c76234157729@redhat.com> <6ee77101-aa95-6626-9528-3edeece9ed14@oracle.com> <53b07d5e-846e-9824-5ae1-c4bb07846140@redhat.com> Message-ID: <546560eb-28c9-39d8-9d97-1cc3280640db@oracle.com> Got it. Thanks. Vladimir On 6/5/18 9:35 AM, Andrew Haley wrote: > On 06/05/2018 05:17 PM, Vladimir Kozlov wrote: >> On 6/5/18 8:44 AM, Andrew Haley wrote: >>> On 06/05/2018 04:35 PM, Vladimir Kozlov wrote: >>> >>>> Lucky you - you have already functionality to deal with far calls. >>>> From changes it seems you will always use trampolines for calls >>>> (regardless distance). Right? >>> >>> Not exactly. The trampolines are always generated, but are only used >>> if a branch does not reach. >> >> I thought that far_branches() returning always true in UseAOT case >> will cause using trampolines. So it is different. > > far_branches() returns true if we need to generate trampolines: we > only use them in the patching code if a branch won't reach. > From aph at redhat.com Tue Jun 5 16:53:34 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Jun 2018 17:53:34 +0100 Subject: RFR: 8204348: AArch64: Remove C2 address reshaping code Message-ID: <8599ddde-75e1-4bd2-5abd-26d300bf4a69@redhat.com> Compile::reshape_address() in aarch64.ad makes some changes which in theory should generate better code. However, after recent changes to C2's loop unrolling, reshape_address() causes many new temporaries to be generated. We run out of registers and they are spilled to stack slots, slowing down inner loops. Benchmarking reveals that we would be better off without Compile::reshape_address(). http://cr.openjdk.java.net/~aph/8204348/ OK? -- 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 Tue Jun 5 16:56:41 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 5 Jun 2018 09:56:41 -0700 Subject: RFR(S): 8202747: C2: assert(mode == ControlAroundStripMined && use == sfpt) failed: missed a node In-Reply-To: References: Message-ID: Seems fine. Thanks, Vladimir On 5/17/18 1:48 AM, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8202747/webrev.00/ > > When cloning a strip mined loop nest, verification code catches a data > node that's not referenced from the safepoint node but is found to be in > the outer loop. That's caused by another transformation in the same > round of loop opts that pessimistically assigned control in the outer > loop to the data node. The fix I propose is to locate those nodes that > shouldn't be in the outer loop and fix their control during loop > cloning. > > Roland. > From vladimir.kozlov at oracle.com Tue Jun 5 17:07:07 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 5 Jun 2018 10:07:07 -0700 Subject: RFR: 8204348: AArch64: Remove C2 address reshaping code In-Reply-To: <8599ddde-75e1-4bd2-5abd-26d300bf4a69@redhat.com> References: <8599ddde-75e1-4bd2-5abd-26d300bf4a69@redhat.com> Message-ID: <7fb491d5-a175-0367-4be5-153933dee697@oracle.com> Good. Thanks, Vladimir On 6/5/18 9:53 AM, Andrew Haley wrote: > Compile::reshape_address() in aarch64.ad makes some changes which in > theory should generate better code. However, after recent changes to > C2's loop unrolling, reshape_address() causes many new temporaries to > be generated. We run out of registers and they are spilled to stack > slots, slowing down inner loops. > > Benchmarking reveals that we would be better off without > Compile::reshape_address(). > > http://cr.openjdk.java.net/~aph/8204348/ > > OK? > From dmitrij.pochepko at bell-sw.com Tue Jun 5 19:46:04 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Tue, 5 Jun 2018 22:46:04 +0300 Subject: RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler Message-ID: Hi all, please review small patch for 8204353 - AARCH64: optimize FPU load and stores in macroAssembler This patch optimize fpu stores and loads by using ld1/st1 instructions which handle 4 registers instead of ldp/stp (2 registers). It makes respective code up to 2 times smaller. Thus it has more changes to be optimized in CPU. Testing: I run hotspot jtreg compiler tests as sanity with patched and unpatched build. No new failures found. CR: https://bugs.openjdk.java.net/browse/JDK-8204353 webrev: http://cr.openjdk.java.net/~dpochepk/8204353/webrev.01/ Thanks, Dmitrij From vladimir.x.ivanov at oracle.com Tue Jun 5 21:42:41 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 6 Jun 2018 00:42:41 +0300 Subject: [11] RFR (S): 8203480: IncompatibleClassChangeError thrown at sites linked to default interface methods Message-ID: <77c87ad3-8ce9-1e4d-4005-f578fab06fca@oracle.com> http://cr.openjdk.java.net/~vlivanov/8203480/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8203480 JDK-8072008 enabled MethodHandle linker elimination when MemberName is a compile-time constant, but target method isn't inlined. It involves method resolution step and attached method + linker are used to initiate it. The problematic case is invokevirtual on a default method. As an example: interface I { default m() {} } class T implements I {} invokevirtual T.m() =R=> I.m() findVirtual(T.class, "m", ...) => DMH: MH.linkToVirtual(..., I.m()) During call site resolution, "invokevirtual I.m()" resolution is initiated and it fails link-time checks ending with an ICCE. The fix is to adjust invocation mode for default methods from invokevirtual to invokeinterface: resolution succeeds for "invokeinterface I.m()" and it does the right thing. Testing: hs-precheckin-comp, hs-tier1, hs-tier2 (-XX:+-StressMethodHandleLinkerInlining) Thanks! Best regards, Vladimir Ivanov From Derek.White at cavium.com Tue Jun 5 21:48:41 2018 From: Derek.White at cavium.com (White, Derek) Date: Tue, 5 Jun 2018 21:48:41 +0000 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: References: Message-ID: Hi Dmitrij, That looks like it could help. The related question I've had on the back-burner for a while is WHY are we saving/restoring 42 registers in gen_write_ref_array_pre_barrier/ gen_write_ref_array_post_barrier? We don't do that around any other calls to call_VM_leaf. No other port saves the entire register set, even the arm64 port. They just save a few registers that are in use. - Derek > -----Original Message----- > From: aarch64-port-dev [mailto:aarch64-port-dev- > bounces at openjdk.java.net] On Behalf Of Dmitrij Pochepko > Sent: Tuesday, June 05, 2018 3:46 PM > To: hotspot-compiler-dev at openjdk.java.net; aarch64-port- > dev at openjdk.java.net > Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load > and stores in macroAssembler > > Hi all, > > please review small patch for 8204353 - AARCH64: optimize FPU load and > stores in macroAssembler > > This patch optimize fpu stores and loads by using ld1/st1 instructions which > handle 4 registers instead of ldp/stp (2 registers). It makes respective code > up to 2 times smaller. Thus it has more changes to be optimized in CPU. > > > Testing: I run hotspot jtreg compiler tests as sanity with patched and > unpatched build. No new failures found. > > > CR: https://bugs.openjdk.java.net/browse/JDK-8204353 > > webrev: http://cr.openjdk.java.net/~dpochepk/8204353/webrev.01/ > > > Thanks, > > Dmitrij 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 aph at redhat.com Wed Jun 6 07:59:13 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jun 2018 08:59:13 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: References: Message-ID: On 06/05/2018 08:46 PM, Dmitrij Pochepko wrote: > webrev: http://cr.openjdk.java.net/~dpochepk/8204353/webrev.01/ OK, seems reasonable. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Jun 6 08:12:18 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jun 2018 09:12:18 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: References: Message-ID: <5d5e6c96-239c-557d-d2f1-4be377b83935@redhat.com> On 06/05/2018 10:48 PM, White, Derek wrote: > The related question I've had on the back-burner for a while is WHY > are we saving/restoring 42 registers in > gen_write_ref_array_pre_barrier/ gen_write_ref_array_post_barrier? Please point me to the exact line of code you are talking about. > We don't do that around any other calls to call_VM_leaf. > > No other port saves the entire register set, even the arm64 > port. They just save a few registers that are in use. You don't know which registers are in use. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Jun 6 08:23:11 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jun 2018 09:23:11 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: References: Message-ID: <56064140-2348-acb5-1859-5ac4c9e6ee30@redhat.com> On 06/06/2018 08:59 AM, Andrew Haley wrote: > On 06/05/2018 08:46 PM, Dmitrij Pochepko wrote: >> webrev: http://cr.openjdk.java.net/~dpochepk/8204353/webrev.01/ > > OK, seems reasonable. Hold on, no. I replied too quickly. 2572 void MacroAssembler::push_call_clobbered_registers() { 2573 int step = 4 * wordSize; 2574 push(RegSet::range(r0, r18) - RegSet::of(rscratch1, rscratch2), sp); 2575 sub(sp, sp, step); 2576 mov(rscratch1, -step); 2577 // Push v0-v7, v16-v31. 2578 for (int i = 31; i>= 4; i -= 4) { 2579 if (i <= v7->encoding() || i >= v16->encoding()) 2580 st1(as_FloatRegister(i-3), as_FloatRegister(i-2), as_FloatRegister(i-1), 2581 as_FloatRegister(i), T1D, Address(sp, rscratch1)); 2582 } 2583 st1(as_FloatRegister(0), as_FloatRegister(1), as_FloatRegister(2), 2584 as_FloatRegister(3), T1D, Address(sp)); 2585 } What is "step" in rscratch1 used for here? Where do we push the registers? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rwestrel at redhat.com Wed Jun 6 08:47:50 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 06 Jun 2018 10:47:50 +0200 Subject: RFR: 8204348: AArch64: Remove C2 address reshaping code In-Reply-To: <8599ddde-75e1-4bd2-5abd-26d300bf4a69@redhat.com> References: <8599ddde-75e1-4bd2-5abd-26d300bf4a69@redhat.com> Message-ID: > http://cr.openjdk.java.net/~aph/8204348/ Looks good to me. Roland. From rwestrel at redhat.com Wed Jun 6 08:48:33 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 06 Jun 2018 10:48:33 +0200 Subject: RFR(S): 8202747: C2: assert(mode == ControlAroundStripMined && use == sfpt) failed: missed a node In-Reply-To: <372497b1-ef88-5e6b-0257-4e7ed17fb2f4@oracle.com> References: <372497b1-ef88-5e6b-0257-4e7ed17fb2f4@oracle.com> Message-ID: Hi Nils, > I am testing this together with 8203197 now. Any update on testing? Can I push this? Thanks, Roland. From rwestrel at redhat.com Wed Jun 6 08:48:46 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 06 Jun 2018 10:48:46 +0200 Subject: RFR(S): 8202747: C2: assert(mode == ControlAroundStripMined && use == sfpt) failed: missed a node In-Reply-To: References: Message-ID: > Seems fine. Thanks for the review. Roland. From dmitrij.pochepko at bell-sw.com Wed Jun 6 11:16:18 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 06 Jun 2018 15:16:18 +0400 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: <56064140-2348-acb5-1859-5ac4c9e6ee30@redhat.com> References: <56064140-2348-acb5-1859-5ac4c9e6ee30@redhat.com> Message-ID: <5B17C282.6030009@bell-sw.com> 06.06.2018 12:23, Andrew Haley ?????: > On 06/06/2018 08:59 AM, Andrew Haley wrote: >> On 06/05/2018 08:46 PM, Dmitrij Pochepko wrote: >>> webrev: http://cr.openjdk.java.net/~dpochepk/8204353/webrev.01/ >> >> OK, seems reasonable. > > Hold on, no. I replied too quickly. > > 2572 void MacroAssembler::push_call_clobbered_registers() { > 2573 int step = 4 * wordSize; > 2574 push(RegSet::range(r0, r18) - RegSet::of(rscratch1, rscratch2), sp); > 2575 sub(sp, sp, step); > 2576 mov(rscratch1, -step); > 2577 // Push v0-v7, v16-v31. > 2578 for (int i = 31; i>= 4; i -= 4) { > 2579 if (i <= v7->encoding() || i >= v16->encoding()) > 2580 st1(as_FloatRegister(i-3), as_FloatRegister(i-2), as_FloatRegister(i-1), > 2581 as_FloatRegister(i), T1D, Address(sp, rscratch1)); > > 2582 } > 2583 st1(as_FloatRegister(0), as_FloatRegister(1), as_FloatRegister(2), > 2584 as_FloatRegister(3), T1D, Address(sp)); > 2585 } > > What is "step" in rscratch1 used for here? Where do we push the registers? > You're probably referring to confusing addressing notation here. I was confused originally as well. According to AARCH64 specification, ld* and st* instructions has 3 addressing modes: 1) base register, no offset 2) post-index, immediate value 3) post-index, register value (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0802b/LD1_advsimd_sngl_vector.html) Address class was designed with post-index to be an immediate values, so, that is probably why "register post-index" mode for ld/st is using regular "register offset" mode, treating it as "register post-index". My patch is using this "register post-index" mode to have less instructions generated. I was a bit confused when first tried to use this mode and found such specifics. I had to recheck specific instruction generation code to be sure. Thanks, Dmitrij From aph at redhat.com Wed Jun 6 11:41:20 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jun 2018 12:41:20 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: <5B17C282.6030009@bell-sw.com> References: <56064140-2348-acb5-1859-5ac4c9e6ee30@redhat.com> <5B17C282.6030009@bell-sw.com> Message-ID: On 06/06/2018 12:16 PM, Dmitrij Pochepko wrote: > You're probably referring to confusing addressing notation here. I was > confused originally as well. > > According to AARCH64 specification, ld* and st* instructions has 3 > addressing modes: > 1) base register, no offset > 2) post-index, immediate value > 3) post-index, register value > (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0802b/LD1_advsimd_sngl_vector.html) > > Address class was designed with post-index to be an immediate values, > so, that is probably why "register post-index" mode for ld/st is using > regular "register offset" mode, treating it as "register post-index". > > My patch is using this "register post-index" mode to have less > instructions generated. I was a bit confused when first tried to use > this mode and found such specifics. I had to recheck specific > instruction generation code to be sure. Oh no, that is too horrible. We must fix that before using this addressing mode for anything else. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Jun 6 12:15:26 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jun 2018 13:15:26 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: References: <56064140-2348-acb5-1859-5ac4c9e6ee30@redhat.com> <5B17C282.6030009@bell-sw.com> Message-ID: On 06/06/2018 12:41 PM, Andrew Haley wrote: > On 06/06/2018 12:16 PM, Dmitrij Pochepko wrote: >> You're probably referring to confusing addressing notation here. I was >> confused originally as well. >> >> According to AARCH64 specification, ld* and st* instructions has 3 >> addressing modes: >> 1) base register, no offset >> 2) post-index, immediate value >> 3) post-index, register value >> (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0802b/LD1_advsimd_sngl_vector.html) >> >> Address class was designed with post-index to be an immediate values, >> so, that is probably why "register post-index" mode for ld/st is using >> regular "register offset" mode, treating it as "register post-index". >> >> My patch is using this "register post-index" mode to have less >> instructions generated. I was a bit confused when first tried to use >> this mode and found such specifics. I had to recheck specific >> instruction generation code to be sure. > > Oh no, that is too horrible. We must fix that before using this > addressing mode for anything else. But is it even true? I just grepped for st1 and I can find no examples of it being used in that way. Are there any? I do see this, which looks fine: st1(Vtmp1, Vtmp2, T16B, post(dst, 32)); -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Wed Jun 6 12:30:32 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 6 Jun 2018 15:30:32 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: References: <56064140-2348-acb5-1859-5ac4c9e6ee30@redhat.com> <5B17C282.6030009@bell-sw.com> Message-ID: On 06.06.2018 15:15, Andrew Haley wrote: > On 06/06/2018 12:41 PM, Andrew Haley wrote: >> On 06/06/2018 12:16 PM, Dmitrij Pochepko wrote: >>> You're probably referring to confusing addressing notation here. I was >>> confused originally as well. >>> >>> According to AARCH64 specification, ld* and st* instructions has 3 >>> addressing modes: >>> 1) base register, no offset >>> 2) post-index, immediate value >>> 3) post-index, register value >>> (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0802b/LD1_advsimd_sngl_vector.html) >>> >>> Address class was designed with post-index to be an immediate values, >>> so, that is probably why "register post-index" mode for ld/st is using >>> regular "register offset" mode, treating it as "register post-index". >>> >>> My patch is using this "register post-index" mode to have less >>> instructions generated. I was a bit confused when first tried to use >>> this mode and found such specifics. I had to recheck specific >>> instruction generation code to be sure. >> Oh no, that is too horrible. We must fix that before using this >> addressing mode for anything else. > But is it even true? I just grepped for st1 and I can find no examples > of it being used in that way. Are there any? I do see this, which looks > fine: > > st1(Vtmp1, Vtmp2, T16B, post(dst, 32)); > I believe I'm the first one to use ld/st with register post-index addressing mode in hotspot. You can take a look here: http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/cpu/aarch64/assembler_aarch64.hpp#l2068 As you can see, switch by a.getMode() has 3 cases: 1) "base_plus_offset" (expecting only 0 offset. This is for "base register, no offset" ld/st addressing mode 2) "post"- this if for immediate post-index mode 3) "base_plus_offset_reg" which is treated further as register post-index mode. I'll create separate issue and patch, which will add new address mode (something like: "post_reg"). And final syntax for such mode usage will be ... Address(post(, )), which makes it more readable. After that I'll update this fpu ld/st optimization patch accordingly. How about that? Thanks, Dmitrij -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Wed Jun 6 12:37:07 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jun 2018 13:37:07 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: References: <56064140-2348-acb5-1859-5ac4c9e6ee30@redhat.com> <5B17C282.6030009@bell-sw.com> Message-ID: On 06/06/2018 01:30 PM, Dmitrij Pochepko wrote: > You can take a look here: > http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/cpu/aarch64/assembler_aarch64.hpp#l2068 > As you can see, switch by a.getMode() has 3 cases: > > 1) "base_plus_offset" (expecting only 0 offset. This is for "base > register, no offset" ld/st addressing mode > 2) "post"- this if for immediate post-index mode > 3) "base_plus_offset_reg" which is treated further as register > post-index mode. Well, yes, but I can't see that being [ab]used anywhere in the existing source. > I'll create separate issue and patch, which will add new address mode > (something like: "post_reg"). And final syntax for such mode usage will > be ... Address(post(, )), which makes it more readable. Yes. And please disallow the use of Address(reg, reg) while you're doing that. > After that I'll update this fpu ld/st optimization patch accordingly. OK. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Wed Jun 6 13:33:36 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 6 Jun 2018 16:33:36 +0300 Subject: RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly Message-ID: Hi all, please review patch for: JDK-8204473 -? AARCH64: register post-index addressing mode is not supported directly This patch adds new addressing mode: "post_reg"? (register post-index) with respective changes in code. It is used for ld* and st* instructions. Before this patch, this mode could be enabled by using base_plus_offset_reg, which makes code confusing. Testing: I launched hotspot jtreg compiler tests to ensure nothing is broken. No new failures found. webrev: http://cr.openjdk.java.net/~dpochepk/8204473/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8204473 Thanks, Dmitrij From dmitrij.pochepko at bell-sw.com Wed Jun 6 13:43:38 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 6 Jun 2018 16:43:38 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: References: <56064140-2348-acb5-1859-5ac4c9e6ee30@redhat.com> <5B17C282.6030009@bell-sw.com> Message-ID: On 06.06.2018 15:37, Andrew Haley wrote: > On 06/06/2018 01:30 PM, Dmitrij Pochepko wrote: >> You can take a look here: >> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/cpu/aarch64/assembler_aarch64.hpp#l2068 >> As you can see, switch by a.getMode() has 3 cases: >> >> 1) "base_plus_offset" (expecting only 0 offset. This is for "base >> register, no offset" ld/st addressing mode >> 2) "post"- this if for immediate post-index mode >> 3) "base_plus_offset_reg" which is treated further as register >> post-index mode. > Well, yes, but I can't see that being [ab]used anywhere in the existing > source. > >> I'll create separate issue and patch, which will add new address mode >> (something like: "post_reg"). And final syntax for such mode usage will >> be ... Address(post(, )), which makes it more readable. > Yes. And please disallow the use of Address(reg, reg) while you're doing > that. > >> After that I'll update this fpu ld/st optimization patch accordingly. > OK. > Please take a look at webrev.02: http://cr.openjdk.java.net/~dpochepk/8204353/webrev.02/ The only change is to match changes in JDK-8204473 -? AARCH64: register post-index addressing mode is not supported directly 2 entries of "Address(sp, rscratch1)" is now "Address(post(sp, rscratch1))" I relaunched hotspot jtreg compiler tests as sanity with both patches. No new failures found. Thanks, Dmitrij 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 aph at redhat.com Wed Jun 6 16:37:03 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jun 2018 17:37:03 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly In-Reply-To: References: Message-ID: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> On 06/06/2018 02:33 PM, Dmitrij Pochepko wrote: > Hi all, > > please review patch for: JDK-8204473 -? AARCH64: register post-index > addressing mode is not supported directly > > This patch adds new addressing mode: "post_reg"? (register post-index) > with respective changes in code. It is used for ld* and st* > instructions. Before this patch, this mode could be enabled by using > base_plus_offset_reg, which makes code confusing. > > > Testing: I launched hotspot jtreg compiler tests to ensure nothing is > broken. No new failures found. > > > webrev: http://cr.openjdk.java.net/~dpochepk/8204473/webrev.01/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8204473 Did you run a debug build? # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/assembler_aarch64.hpp:2089 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/local/jdk-jdk/src/hotspot/cpu/aarch64/assembler_aarch64.hpp:2089), pid=31485, tid=31486 # Error: ShouldNotReachHere() # # JRE version: (11.0) (slowdebug build ) # Java VM: OpenJDK 64-Bit Server VM (slowdebug 11-internal+0-adhoc.aph.jdk-jdk, mixed mode, aot, sharing, tiered, compressed oops, g1 gc, linux-aarch64) # Core dump will be written. Default location: /local/jdk-jdk/build/linux-aarch64-normal-server-slowdebug/jdk/bin/core.31485 # # An error report file with more information is saved as: # /local/jdk-jdk/build/linux-aarch64-normal-server-slowdebug/jdk/bin/hs_err_pid31485.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # Current thread is 31486 Dumping core ... -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Wed Jun 6 16:59:13 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 6 Jun 2018 19:59:13 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly In-Reply-To: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> References: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> Message-ID: On 06.06.2018 19:37, Andrew Haley wrote: > On 06/06/2018 02:33 PM, Dmitrij Pochepko wrote: >> Hi all, >> >> please review patch for: JDK-8204473 -? AARCH64: register post-index >> addressing mode is not supported directly >> >> This patch adds new addressing mode: "post_reg"? (register post-index) >> with respective changes in code. It is used for ld* and st* >> instructions. Before this patch, this mode could be enabled by using >> base_plus_offset_reg, which makes code confusing. >> >> >> Testing: I launched hotspot jtreg compiler tests to ensure nothing is >> broken. No new failures found. >> >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8204473/webrev.01/ >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8204473 > Did you run a debug build? > > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/assembler_aarch64.hpp:2089 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/local/jdk-jdk/src/hotspot/cpu/aarch64/assembler_aarch64.hpp:2089), pid=31485, tid=31486 > # Error: ShouldNotReachHere() > # > # JRE version: (11.0) (slowdebug build ) > # Java VM: OpenJDK 64-Bit Server VM (slowdebug 11-internal+0-adhoc.aph.jdk-jdk, mixed mode, aot, sharing, tiered, compressed oops, g1 gc, linux-aarch64) > # Core dump will be written. Default location: /local/jdk-jdk/build/linux-aarch64-normal-server-slowdebug/jdk/bin/core.31485 > # > # An error report file with more information is saved as: > # /local/jdk-jdk/build/linux-aarch64-normal-server-slowdebug/jdk/bin/hs_err_pid31485.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.java.com/bugreport/crash.jsp > # > Current thread is 31486 > Dumping core ... > Ahh, sorry. Missed single existing [ab]usage of such addressing in fastdebug mode: http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/cpu/aarch64/assembler_aarch64.cpp#l1179 However, there is a confusing comment there: "// BEGIN? Generated code -- do not edit // Generated by aarch64-asmtest.py" What should we do about it? I don't see aarch64-asmtest.py to edit. Do we need to edit this smoke test directly despite this comment? Thanks, Dmitrij From vladimir.kozlov at oracle.com Wed Jun 6 17:01:41 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 6 Jun 2018 10:01:41 -0700 Subject: [11] RFR (S): 8203480: IncompatibleClassChangeError thrown at sites linked to default interface methods In-Reply-To: <77c87ad3-8ce9-1e4d-4005-f578fab06fca@oracle.com> References: <77c87ad3-8ce9-1e4d-4005-f578fab06fca@oracle.com> Message-ID: <4c1d8d99-a358-7d33-7c77-5608446edcba@oracle.com> Looks good. Thanks, Vladimir On 6/5/18 2:42 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8203480/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8203480 > > JDK-8072008 enabled MethodHandle linker elimination when MemberName is a > compile-time constant, but target method isn't inlined. It involves > method resolution step and attached method + linker are used to initiate > it. > > The problematic case is invokevirtual on a default method. As an example: > > ? interface I { default m() {} } > ? class T implements I {} > > ? invokevirtual T.m() =R=> I.m() > ? findVirtual(T.class, "m", ...) => DMH: MH.linkToVirtual(..., I.m()) > > During call site resolution, "invokevirtual I.m()" resolution is > initiated and it fails link-time checks ending with an ICCE. > > The fix is to adjust invocation mode for default methods from > invokevirtual to invokeinterface: resolution succeeds for > "invokeinterface I.m()" and it does the right thing. > > Testing: hs-precheckin-comp, hs-tier1, hs-tier2 > (-XX:+-StressMethodHandleLinkerInlining) > > Thanks! > > Best regards, > Vladimir Ivanov From dmitrij.pochepko at bell-sw.com Wed Jun 6 17:14:12 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 6 Jun 2018 20:14:12 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly In-Reply-To: References: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> Message-ID: <0a44de57-d2ce-8386-ed82-0ab34d40479f@bell-sw.com> On 06.06.2018 19:59, Dmitrij Pochepko wrote: > > > On 06.06.2018 19:37, Andrew Haley wrote: >> On 06/06/2018 02:33 PM, Dmitrij Pochepko wrote: >>> Hi all, >>> >>> please review patch for: JDK-8204473 -? AARCH64: register post-index >>> addressing mode is not supported directly >>> >>> This patch adds new addressing mode: "post_reg"? (register post-index) >>> with respective changes in code. It is used for ld* and st* >>> instructions. Before this patch, this mode could be enabled by using >>> base_plus_offset_reg, which makes code confusing. >>> >>> >>> Testing: I launched hotspot jtreg compiler tests to ensure nothing is >>> broken. No new failures found. >>> >>> >>> webrev: http://cr.openjdk.java.net/~dpochepk/8204473/webrev.01/ >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8204473 >> Did you run a debug build? >> >> # To suppress the following error report, specify this argument >> # after -XX: or in .hotspotrc: >> SuppressErrorAt=/assembler_aarch64.hpp:2089 >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> #? Internal Error >> (/local/jdk-jdk/src/hotspot/cpu/aarch64/assembler_aarch64.hpp:2089), >> pid=31485, tid=31486 >> #? Error: ShouldNotReachHere() >> # >> # JRE version:? (11.0) (slowdebug build ) >> # Java VM: OpenJDK 64-Bit Server VM (slowdebug >> 11-internal+0-adhoc.aph.jdk-jdk, mixed mode, aot, sharing, tiered, >> compressed oops, g1 gc, linux-aarch64) >> # Core dump will be written. Default location: >> /local/jdk-jdk/build/linux-aarch64-normal-server-slowdebug/jdk/bin/core.31485 >> # >> # An error report file with more information is saved as: >> # >> /local/jdk-jdk/build/linux-aarch64-normal-server-slowdebug/jdk/bin/hs_err_pid31485.log >> # >> # If you would like to submit a bug report, please visit: >> #?? http://bugreport.java.com/bugreport/crash.jsp >> # >> Current thread is 31486 >> Dumping core ... >> > Ahh, sorry. Missed single existing [ab]usage of such addressing in > fastdebug mode: > http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/cpu/aarch64/assembler_aarch64.cpp#l1179 > > However, there is a confusing comment there: "// BEGIN? Generated code > -- do not edit // Generated by aarch64-asmtest.py" > What should we do about it? I don't see aarch64-asmtest.py to edit. Do > we need to edit this smoke test directly despite this comment? > > Thanks, > Dmitrij ... there is still // END Generated code comment above, but I don't know, if aarch64-asmtest.py (if any will be ever used) will append hand-written code to a generated one. In that case, where it takes this code to append? Or it is safe to edit? Thanks, Dmitrij From aph at redhat.com Wed Jun 6 17:16:23 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jun 2018 18:16:23 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly In-Reply-To: References: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> Message-ID: <9d9a49a2-bf30-5db8-8273-98162d543820@redhat.com> On 06/06/2018 05:59 PM, Dmitrij Pochepko wrote: > Ahh, sorry. Missed single existing [ab]usage of such addressing in > fastdebug mode: Mmm. It's always a really, really good idea to run tests with assertions enabled. > http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/cpu/aarch64/assembler_aarch64.cpp#l1179 > > However, there is a confusing comment there: "// BEGIN Generated code > -- do not edit // Generated by aarch64-asmtest.py" > What should we do about it? I don't see aarch64-asmtest.py to edit. Oh yes. It must not have been included when we merged into mainline. Oops. > Do we need to edit this smoke test directly despite this comment? Yes, please. The code you need to edit is *after* the line END Generated code -- do not edit I did this: address PC = __ pc(); __ ld1(v0, __ T16B, Address(r16)); // No offset __ ld1(v0, __ T16B, __ post(r16, 8)); // Post-index __ ld1(v0, __ T16B, __ post(r16, r17)); // which at least checks that we can generate the instructions, for which I get 0x000003ffa1000764: ld1 {v0.16b}, [x16] 0x000003ffa1000768: ld1 {v0.16b}, [x16], #16 0x000003ffa100076c: ld1 {v0.16b}, [x16], x17 That "#16" looks odd. Presumably there's some scaling going on there. Do you know? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Wed Jun 6 17:26:42 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 6 Jun 2018 20:26:42 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly In-Reply-To: <9d9a49a2-bf30-5db8-8273-98162d543820@redhat.com> References: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> <9d9a49a2-bf30-5db8-8273-98162d543820@redhat.com> Message-ID: On 06.06.2018 20:16, Andrew Haley wrote: > On 06/06/2018 05:59 PM, Dmitrij Pochepko wrote: >> Ahh, sorry. Missed single existing [ab]usage of such addressing in >> fastdebug mode: > Mmm. It's always a really, really good idea to run tests with > assertions enabled. Yes. My bad. >> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/cpu/aarch64/assembler_aarch64.cpp#l1179 >> >> However, there is a confusing comment there: "// BEGIN Generated code >> -- do not edit // Generated by aarch64-asmtest.py" >> What should we do about it? I don't see aarch64-asmtest.py to edit. > Oh yes. It must not have been included when we merged into mainline. > Oops. > >> Do we need to edit this smoke test directly despite this comment? > Yes, please. The code you need to edit is *after* the line > END Generated code -- do not edit Thanks. Running full test cycle now. > > I did this: > > address PC = __ pc(); > __ ld1(v0, __ T16B, Address(r16)); // No offset > __ ld1(v0, __ T16B, __ post(r16, 8)); // Post-index > __ ld1(v0, __ T16B, __ post(r16, r17)); // > > which at least checks that we can generate the instructions, for which > I get > > 0x000003ffa1000764: ld1 {v0.16b}, [x16] > 0x000003ffa1000768: ld1 {v0.16b}, [x16], #16 > 0x000003ffa100076c: ld1 {v0.16b}, [x16], x17 > > That "#16" looks odd. Presumably there's some scaling going on there. > Do you know? > Yes. I also investigated this some time ago. It is also related to ld/st addressing modes. For immediate post-index of ld/st only one immediate value per type is supported (which is size of loaded/stored data) and the instruction doesn't allow any other options for immediates (see specification, C7.2.152 LD1 (multiple structures)). So, hotspot just checks if immediate is not zero and silently generates the instruction. Thanks, Dmitrij From vladimir.kozlov at oracle.com Wed Jun 6 17:32:02 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 6 Jun 2018 10:32:02 -0700 Subject: RFR(L): 8203197: C2: consider all paths in loop body for loop predication In-Reply-To: References: <560a000a-01c1-eff8-7520-2dbb8460f041@oracle.com> <2adf40c0-6e38-e35c-c3f1-4829fca92181@oracle.com> Message-ID: Hi Roland, On 6/4/18 7:05 AM, Roland Westrelin wrote: > > Hi Vladimir, > >> SpeculativeTrapData has only one cell for Method* which should be only >> one cell, even in 32-bit VM. Change it to 2 cells is wrong I think. >> >> I think old assumption is invalid with your changes: >> >> // This code assumes an entry for a SpeculativeTrapData is 2 cells >> >> because you changed header size for 32 bit - it is now 2 cells. > > The extra data area where the speculative traps are stored is allocated > with: > > // Add some extra DataLayout cells (at least one) to track stray traps. > int extra_data_count = compute_extra_data_count(data_size, empty_bc_count, needs_speculative_traps); > object_size += extra_data_count * DataLayout::compute_size_in_bytes(0); > > // Add a cell to record information about modified arguments. > int arg_size = method->size_of_parameters(); > object_size += DataLayout::compute_size_in_bytes(arg_size+1); > > So > > 1) extra_data_count * DataLayout::compute_size_in_bytes(0) guarantees > the size of the space for traps is a multiple of the header size so a > multiple of 2 cells on 32 bits > > 2) space is reserved after the traps for entries with tag > DataLayout::arg_info_data_tag. That stuff is still inside the extra data > area. > > When MethodData::bci_to_extra_data() allocates a new trap in the extra > data area, it must make sure there's still space available. It checks > that there's room by finding the last trap in the area, moving to the > next entry and checking if: > > - it's still within the extra data area > - it's not an arg_info_data_tag, i.e. we're not overflowing in the > argument area > - if the trap is a speculative trap it also needs to check that there's > room, not only for the header, but also for the Method* > > Now if traps are either 2 (regular traps) or 3 (speculative traps) > cells, that code cannot be left as is. Let say we have 6 cells for extra > data. We allocate a regular trap and a speculative trap. Next entry is > at cell number 5 (assuming they are numbered from 0). Let's say now we > want to allocate a regular trap. We're still within the extra data area > (but don't have sufficient room), we're half way on the first arg info > but reading the tag can't be used to reliably tell us that. > > Adding the padding allows us to keep the existing logic. Got it. Please, add comment to that code explaining why it is needed in 32-bit mode: +#ifndef _LP64 + speculative_trap_padding, +#endif Also may be name it simple 'padding'. Otherwise it is confusing. I first assumed that it is needed functionality for speculative traps and not simple memory allocation layout fix. > >> It may actually cause issues (with 32-bit VM) in other places with >> similar assumption. >> >> An other issue is that header can't be allocated/set/load atomically in >> 32-bit VM as MethodData::bci_to_extra_data_helper() expecting. > > The header contains: > > bci/tag, flags and traps > > bci/tag are constant. They are set once for all when the MethodData is > built. There's an exception for traps as discussed above but then > allocation happens under a lock and once a trap is allocated the bci/tag > is constant. > > So, the only things being updated are flags and traps. It's possible we > loose an update because of concurrency but that was true before and the > change doesn't make it worse. I don't see what other problem the lack of > atomicity could cause. > > The method data is laid out statically in a way that, AFAICT, is quite > robust to a 2 cell header. Once it is built, updates mostly happen in > fields of the individual profile data. So I don't really see what else > could break. > >> Then I don't understand your changes. I thought you move out checks (as >> new predicates) which have profiling information which means you have an >> other valid path branch from dominating check. Such check can't be moved >> from loop as I remember. I don't think you can move out from loop loop >> exit checks. >> >> Please, explain which checks you moved from loop as profiling predicates >> without moving dominating checks. Thank you for showing examples. I understand it now. As you said it is loop invariant checks and the only concerns is the order of predicates execution and more frequent deoptimizations. I agree with separate "profiling" predicates to separate deoptimizations. > > Say we have: > > while() { > if (some_condition) { // both branches profiled taken > if (!null_check) unc(null_check); > if (!range_check) unc(range_check); > ... > } > } > > The existing loop predication wouldn't consider those predicates. My > change does if there's a speculated pay off. > > if (!null_check) unc(profile_predicate); > if (!range_check) unc(profile_predicate); > while() { > if (some_condition) { // both branches profiled taken > ... > } > } > > It's otherwise strictly identical to the existing loop predication: > predicates are moved only if all inputs are loop independent. > > Now: > > while() { > if (!null_check1) unc(null_check); > if (!range_check1) unc(range_check); > ... > if (some_condition) { // both branches profiled taken > if (!null_check2) unc(null_check); > if (!range_check2) unc(range_check); > ... > } > } > > becomes: > > if (!null_check1) unc(predicate); > if (!range_check1) unc(predicate); > > if (!null_check2) unc(profile_predicate); > if (!range_check2) unc(profile_predicate); > > while() { > ... > if (some_condition) { // both branches profiled taken > ... > } > } > > that's because loop predication is now more speculative, so it's more > likely to fail and I don't want a failure with profile predicates to > disable predication entirely and cause a regression. > > First, a pass over the loop body moves regular predicates out of the > loop and then a second pass moves other predicates as profile > predicates. > > There can be dependencies between predicates. Dependencies are preserved > because predicates are kept out of the loop in the order they were moved > out of loop. > > With this: > > while() { > if (!null_check1) unc(null_check); > if (!range_check1) unc(range_check); > ... > if (some_condition) { // both branches profiled taken > if (!null_check2) unc(null_check); > if (!range_check2) unc(range_check); > ... > } > if (!null_check3) unc(null_check); > if (!range_check3) unc(range_check); > } > > Let's say, the first time loop predication is applies, it finds > null_check1/range_check1 and null_check2/range_check2 to hoist but not > null_check3/range_check3 because they are not loop independent at that > point. > > if (!null_check1) unc(predicate); > if (!range_check1) unc(predicate); > > if (!null_check2) unc(profile_predicate); > if (!range_check2) unc(profile_predicate); > > while() { > ... > if (some_condition) { // both branches profiled taken > ... > } > if (!null_check3) unc(null_check); > if (!range_check3) unc(range_check); > } > > Now let's say a later loop predication pass finds > it can hoist null_check3/range_check3. To guarantee correct ordering of > predicates, they will be moved as profile_predicates even though they > are not in a branch: > > if (!null_check1) unc(predicate); > if (!range_check1) unc(predicate); > > if (!null_check2) unc(profile_predicate); > if (!range_check2) unc(profile_predicate); > if (!null_check3) unc(profile_predicate); > if (!range_check3) unc(profile_predicate); > > while() { > ... > if (some_condition) { // both branches profiled taken > ... > } > } In this example what will happen if *_check1 and *_check3 are moved from loop first (they are regular predicates). And then you found that "profiling" *_check2 can be moved. How you enforce order in such case? > > When you say loop exit are you talking about something like? > > while() { > if (some_condition) { // both branches profiled taken > break; > } > if (!null_check) unc(null_check); > if (!range_check) unc(range_check); > ... > } No I was asking about this case when you have "profiling" case: while() { if (some_condition) { // both branches profiled taken if (!null_check) unc(null_check); if (!range_check) unc(range_check); break; } ... } Should you take special care in such case because such checks only executed on exit? Thanks, Vladimir > > It would be optimized as: > > if (!null_check) unc(profile_predicate); > if (!range_check) unc(profile_predicate); > while() { > if (some_condition) { // both branches profiled taken > break; > } > } > > As long as inputs for the tests are loop independent I don't see why > that would be illegal. Worst case, they trigger a deopt and next > compilation won't apply profile predication. > > Roland. > From vladimir.x.ivanov at oracle.com Wed Jun 6 17:32:18 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 6 Jun 2018 20:32:18 +0300 Subject: [11] RFR (S): 8203480: IncompatibleClassChangeError thrown at sites linked to default interface methods In-Reply-To: <4c1d8d99-a358-7d33-7c77-5608446edcba@oracle.com> References: <77c87ad3-8ce9-1e4d-4005-f578fab06fca@oracle.com> <4c1d8d99-a358-7d33-7c77-5608446edcba@oracle.com> Message-ID: <3075a27b-5787-fe08-d558-e4db03d9e3cb@oracle.com> Thanks, Vladimir. Best regards, Vladimir Ivanov On 06/06/2018 20:01, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 6/5/18 2:42 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8203480/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8203480 >> >> JDK-8072008 enabled MethodHandle linker elimination when MemberName is >> a compile-time constant, but target method isn't inlined. It involves >> method resolution step and attached method + linker are used to >> initiate it. >> >> The problematic case is invokevirtual on a default method. As an example: >> >> ?? interface I { default m() {} } >> ?? class T implements I {} >> >> ?? invokevirtual T.m() =R=> I.m() >> ?? findVirtual(T.class, "m", ...) => DMH: MH.linkToVirtual(..., I.m()) >> >> During call site resolution, "invokevirtual I.m()" resolution is >> initiated and it fails link-time checks ending with an ICCE. >> >> The fix is to adjust invocation mode for default methods from >> invokevirtual to invokeinterface: resolution succeeds for >> "invokeinterface I.m()" and it does the right thing. >> >> Testing: hs-precheckin-comp, hs-tier1, hs-tier2 >> (-XX:+-StressMethodHandleLinkerInlining) >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov From dmitrij.pochepko at bell-sw.com Wed Jun 6 17:46:23 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 6 Jun 2018 20:46:23 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly In-Reply-To: References: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> <9d9a49a2-bf30-5db8-8273-98162d543820@redhat.com> Message-ID: <6d92e1a2-40a4-ecea-e098-2581400c2ec8@bell-sw.com> On 06.06.2018 20:26, Dmitrij Pochepko wrote: > > > On 06.06.2018 20:16, Andrew Haley wrote: >> On 06/06/2018 05:59 PM, Dmitrij Pochepko wrote: >>> Ahh, sorry. Missed single existing [ab]usage of such addressing in >>> fastdebug mode: >> Mmm.? It's always a really, really good idea to run tests with >> assertions enabled. > Yes. My bad. >>> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/cpu/aarch64/assembler_aarch64.cpp#l1179 >>> >>> >>> However, there is a confusing comment there: "// BEGIN Generated code >>> -- do not edit // Generated by aarch64-asmtest.py" >>> What should we do about it? I don't see aarch64-asmtest.py to edit. >> Oh yes.? It must not have been included when we merged into mainline. >> Oops. >> >>> Do we need to edit this smoke test directly despite this comment? >> Yes, please.? The code you need to edit is *after* the line >> END? Generated code -- do not edit > Thanks. Running full test cycle now. >> >> I did this: >> >> ?? address PC = __ pc(); >> ?? __ ld1(v0, __ T16B, Address(r16)); // No offset >> ?? __ ld1(v0, __ T16B, __ post(r16, 8)); // Post-index >> ?? __ ld1(v0, __ T16B, __ post(r16, r17)); // >> >> which at least checks that we can generate the instructions, for which >> I get >> >> ?? 0x000003ffa1000764: ld1??? {v0.16b}, [x16] >> ?? 0x000003ffa1000768: ld1??? {v0.16b}, [x16], #16 >> ?? 0x000003ffa100076c: ld1??? {v0.16b}, [x16], x17 >> >> That "#16" looks odd.? Presumably there's some scaling going on there. >> Do you know? >> > Yes. I also investigated this some time ago. It is also related to > ld/st addressing modes. > For immediate post-index of ld/st only one immediate value per type is > supported (which is size of loaded/stored data) and the instruction > doesn't allow any other options for immediates (see specification, > C7.2.152 > LD1 (multiple structures)). > So, hotspot just checks if immediate is not zero and silently > generates the instruction. > > Thanks, > Dmitrij Please take a look to webrev.02: http://cr.openjdk.java.net/~dpochepk/8204473/webrev.02/ Simple sanity with fastdebug build passed. Currently waiting for large test cycle to be finished. Thanks, Dmitrij From dmitrij.pochepko at bell-sw.com Wed Jun 6 18:33:31 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 6 Jun 2018 21:33:31 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly In-Reply-To: <6d92e1a2-40a4-ecea-e098-2581400c2ec8@bell-sw.com> References: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> <9d9a49a2-bf30-5db8-8273-98162d543820@redhat.com> <6d92e1a2-40a4-ecea-e098-2581400c2ec8@bell-sw.com> Message-ID: <69623a1a-a2ac-ed3e-ff29-7ccce0a8b9cc@bell-sw.com> On 06.06.2018 20:46, Dmitrij Pochepko wrote: > > > On 06.06.2018 20:26, Dmitrij Pochepko wrote: >> >> >> On 06.06.2018 20:16, Andrew Haley wrote: >>> On 06/06/2018 05:59 PM, Dmitrij Pochepko wrote: >>>> Ahh, sorry. Missed single existing [ab]usage of such addressing in >>>> fastdebug mode: >>> Mmm.? It's always a really, really good idea to run tests with >>> assertions enabled. >> Yes. My bad. >>>> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/cpu/aarch64/assembler_aarch64.cpp#l1179 >>>> >>>> >>>> However, there is a confusing comment there: "// BEGIN Generated code >>>> -- do not edit // Generated by aarch64-asmtest.py" >>>> What should we do about it? I don't see aarch64-asmtest.py to edit. >>> Oh yes.? It must not have been included when we merged into mainline. >>> Oops. >>> >>>> Do we need to edit this smoke test directly despite this comment? >>> Yes, please.? The code you need to edit is *after* the line >>> END? Generated code -- do not edit >> Thanks. Running full test cycle now. >>> >>> I did this: >>> >>> ?? address PC = __ pc(); >>> ?? __ ld1(v0, __ T16B, Address(r16)); // No offset >>> ?? __ ld1(v0, __ T16B, __ post(r16, 8)); // Post-index >>> ?? __ ld1(v0, __ T16B, __ post(r16, r17)); // >>> >>> which at least checks that we can generate the instructions, for which >>> I get >>> >>> ?? 0x000003ffa1000764: ld1??? {v0.16b}, [x16] >>> ?? 0x000003ffa1000768: ld1??? {v0.16b}, [x16], #16 >>> ?? 0x000003ffa100076c: ld1??? {v0.16b}, [x16], x17 >>> >>> That "#16" looks odd.? Presumably there's some scaling going on there. >>> Do you know? >>> >> Yes. I also investigated this some time ago. It is also related to >> ld/st addressing modes. >> For immediate post-index of ld/st only one immediate value per type >> is supported (which is size of loaded/stored data) and the >> instruction doesn't allow any other options for immediates (see >> specification, C7.2.152 >> LD1 (multiple structures)). >> So, hotspot just checks if immediate is not zero and silently >> generates the instruction. >> >> Thanks, >> Dmitrij > > Please take a look to webrev.02: > http://cr.openjdk.java.net/~dpochepk/8204473/webrev.02/ > Simple sanity with fastdebug build passed. Currently waiting for large > test cycle to be finished. > > Thanks, > Dmitrij large test cycle passed. no new failures(although lots of JDK-8204331 failures). From Derek.White at cavium.com Wed Jun 6 22:33:00 2018 From: Derek.White at cavium.com (White, Derek) Date: Wed, 6 Jun 2018 22:33:00 +0000 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: <5d5e6c96-239c-557d-d2f1-4be377b83935@redhat.com> References: <5d5e6c96-239c-557d-d2f1-4be377b83935@redhat.com> Message-ID: Hi Andrew, Sorry, I've been staring at the JDK 9 code for the last few weeks. This issue was fixed in JDK 10. Dmitrij, it looks like there's a similar fix possible to save_live_registers()/restore_live_registers() in c1_Runtime1_aarch64.cpp. It's used in about 24 stubs. I think this current fix is fine as is, but you might consider save_live_registers() as a separate fix when you (or someone) gets the time. Sorry for hijacking this RFR! - Derek > -----Original Message----- > On 06/05/2018 10:48 PM, White, Derek wrote: > > > The related question I've had on the back-burner for a while is WHY > > are we saving/restoring 42 registers in > > gen_write_ref_array_pre_barrier/ gen_write_ref_array_post_barrier? > > Please point me to the exact line of code you are talking about. > > We don't do that around any other calls to call_VM_leaf. > > > > No other port saves the entire register set, even the arm64 port. They > > just save a few registers that are in use. > > You don't know which registers are in use. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Jun 7 11:32:01 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Jun 2018 12:32:01 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly In-Reply-To: <69623a1a-a2ac-ed3e-ff29-7ccce0a8b9cc@bell-sw.com> References: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> <9d9a49a2-bf30-5db8-8273-98162d543820@redhat.com> <6d92e1a2-40a4-ecea-e098-2581400c2ec8@bell-sw.com> <69623a1a-a2ac-ed3e-ff29-7ccce0a8b9cc@bell-sw.com> Message-ID: On 06/06/2018 07:33 PM, Dmitrij Pochepko wrote: > large test cycle passed. no new failures(although lots of JDK-8204331 > failures). As John Rose put it, we should clean up as we go. Try this. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -------------- next part -------------- A non-text attachment was scrubbed... Name: vect_asm.diff Type: text/x-patch Size: 8218 bytes Desc: not available URL: From tobias.hartmann at oracle.com Thu Jun 7 13:39:46 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 7 Jun 2018 15:39:46 +0200 Subject: [11] RFR(M): 8203915: Induction variable of over-unrolled loop conflicts with range checks Message-ID: Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8203915 http://cr.openjdk.java.net/~thartmann/8203915/webrev.00/ The general problem is that a range check predicated loop is over-unrolled such that the type of the loop induction variable is out of the statically known bounds of the array. As a result, the CastII/ConvI2L nodes are replaced by TOP and the memory graph is corrupted because the control path to this dead code is not removed. This is because there are no range checks in the loop but only predicates before the main loop. For example, in TestOverunrolling::test5() we unroll the inner for-loop 16 times because the loop limit 'i' is not statically known. The last iArr access in the unrolled main loop body therefore has the type [6+stride-1, int] with stride = 16 which is out of the statically known array size 8. After vectorization, we crash in the matcher because the vectorized result += ... computation has a TOP memory input. Test3 and test4 trigger the same problem but fail at different stages during compilation. This is very similar to what Roland fixed with skeleton predicates in JDK-8193130 [1]. However, this fix only added checks to verify that the initial value of the induction variable is in bounds but not that init+stride-1 is in bounds as well. I've changed the skeleton predicate code to not only add a check for init References: Message-ID: <8ee8b4b3-9e4f-3a9f-638a-b17300c9e6cc@oracle.com> Hi Tobias, Can you look if PhaseIdealLoop::do_range_check() is executed for main loop in this case? If array length is known statically that code should produce check which should eliminate control flow for main loop and collapse it. Your changes seems fine but I want to understand why existing mechanism does not work. Thanks, Vladimir On 6/7/18 6:39 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8203915 > http://cr.openjdk.java.net/~thartmann/8203915/webrev.00/ > > The general problem is that a range check predicated loop is over-unrolled such that the type of the > loop induction variable is out of the statically known bounds of the array. As a result, the > CastII/ConvI2L nodes are replaced by TOP and the memory graph is corrupted because the control path > to this dead code is not removed. This is because there are no range checks in the loop but only > predicates before the main loop. > > For example, in TestOverunrolling::test5() we unroll the inner for-loop 16 times because the loop > limit 'i' is not statically known. The last iArr access in the unrolled main loop body therefore has > the type [6+stride-1, int] with stride = 16 which is out of the statically known array size 8. After > vectorization, we crash in the matcher because the vectorized result += ... computation has a TOP > memory input. Test3 and test4 trigger the same problem but fail at different stages during compilation. > > This is very similar to what Roland fixed with skeleton predicates in JDK-8193130 [1]. However, this > fix only added checks to verify that the initial value of the induction variable is in bounds but > not that init+stride-1 is in bounds as well. > > I've changed the skeleton predicate code to not only add a check for init another copy of the skeleton predicate to before the main loop. Whenever we now unroll the loop and > therefore increase the stride, this predicate copy is updated to check init+stride-1 prevent early folding of the expression, I left the Opaque1Nodes in (they are removed after loop > optimizations). > > The reason why this issue only showed up now (JDK 9 and 10 are also affected) is because > vectorization of loops with safepoints was fixed by JDK-8200477 in JDK 11. > > Thanks to Roland for discussing this! > > Best regards, > Tobias > > [1] https://bugs.openjdk.java.net/browse/JDK-8193130 > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-December/027938.html > From igor.ignatyev at oracle.com Thu Jun 7 21:17:20 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 7 Jun 2018 14:17:20 -0700 Subject: RFR(XS) : 8204577 : jittester generator doesn't kill processes on timeout Message-ID: http://cr.openjdk.java.net/~iignatyev//8204577/webrev.00 > 11 lines changed: 5 ins; 2 del; 4 mod; Hi all, could you please review this small fix for jit-tester test generator? TestsGenerator::generateGoldenOut starts a new process to get golden output, waits for a process to finish Automatic.MINUTES_TO_WAIT and destroys it afterward. however Automatic::main interrupts generatorThread (the thread which runs TestsGenerator::runProcess) after Automatic.MINUTES_TO_WAIT, so we get an interrupted exception and don't destroy the process. the patch changes wait time to default jtreg timeout (120 seconds) and also moves Process::destroyForcibly to finally block. JBS: https://bugs.openjdk.java.net/browse/JDK-8204577 webrev: http://cr.openjdk.java.net/~iignatyev//8204577/webrev.00 testing: compiled jit-tester library and generate a number of tests w/ it Thanks, -- Igor From ekaterina.pavlova at oracle.com Thu Jun 7 22:04:03 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Thu, 7 Jun 2018 15:04:03 -0700 Subject: RFR(XS) : 8204577 : jittester generator doesn't kill processes on timeout In-Reply-To: References: Message-ID: Looks good. -katya On 6/7/18 2:17 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8204577/webrev.00 >> 11 lines changed: 5 ins; 2 del; 4 mod; > > Hi all, > > could you please review this small fix for jit-tester test generator? > > TestsGenerator::generateGoldenOut starts a new process to get golden output, waits for a process to finish Automatic.MINUTES_TO_WAIT and destroys it afterward. however Automatic::main interrupts generatorThread (the thread which runs TestsGenerator::runProcess) after Automatic.MINUTES_TO_WAIT, so we get an interrupted exception and don't destroy the process. > > the patch changes wait time to default jtreg timeout (120 seconds) and also moves Process::destroyForcibly to finally block. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8204577 > webrev: http://cr.openjdk.java.net/~iignatyev//8204577/webrev.00 > testing: compiled jit-tester library and generate a number of tests w/ it > > Thanks, > -- Igor > From vivek.r.deshpande at intel.com Thu Jun 7 22:24:17 2018 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Thu, 7 Jun 2018 22:24:17 +0000 Subject: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes performance regression Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A9073FB24@ORSMSX106.amr.corp.intel.com> Hi All I have a fix for the regression caused by Subword Analysis. I tested the fix with SPECjvm2008.MPEG and I don't observe the slowdown. Could you please review the patch and sponsor it. Bug ID: https://bugs.openjdk.java.net/browse/JDK-8194740 Webrev: http://cr.openjdk.java.net/~vdeshpande/SubwordFix/webrev.00/ Regards, Vivek -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Fri Jun 8 00:11:12 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 7 Jun 2018 17:11:12 -0700 Subject: RFR(XS) : 8204577 : jittester generator doesn't kill processes on timeout In-Reply-To: References: Message-ID: +1 Vladimir K On 6/7/18 3:04 PM, Ekaterina Pavlova wrote: > Looks good. > > -katya > > On 6/7/18 2:17 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8204577/webrev.00 >>> 11 lines changed: 5 ins; 2 del; 4 mod; >> >> Hi all, >> >> could you please review this small fix for jit-tester test generator? >> >> TestsGenerator::generateGoldenOut starts a new process to get golden output, waits for a process >> to finish Automatic.MINUTES_TO_WAIT and destroys it afterward. however Automatic::main interrupts >> generatorThread (the thread which runs TestsGenerator::runProcess) after >> Automatic.MINUTES_TO_WAIT, so we get an interrupted exception and don't destroy the process. >> >> the patch changes wait time to default jtreg timeout (120 seconds) and also moves >> Process::destroyForcibly to finally block. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8204577 >> webrev: http://cr.openjdk.java.net/~iignatyev//8204577/webrev.00 >> testing: compiled jit-tester library and generate a number of tests w/ it >> >> Thanks, >> -- Igor >> > From igor.ignatyev at oracle.com Fri Jun 8 00:09:52 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 7 Jun 2018 17:09:52 -0700 Subject: RFR(XS) : 8204577 : jittester generator doesn't kill processes on timeout In-Reply-To: References: Message-ID: <9F7A9EB5-8543-416B-A11D-8FBAD886C70F@oracle.com> Vladimir, Katya, thanks for your reviews. -- Igor > On Jun 7, 2018, at 5:11 PM, Vladimir Kozlov wrote: > > +1 > > Vladimir K > > On 6/7/18 3:04 PM, Ekaterina Pavlova wrote: >> Looks good. >> -katya >> On 6/7/18 2:17 PM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8204577/webrev.00 >>>> 11 lines changed: 5 ins; 2 del; 4 mod; >>> >>> Hi all, >>> >>> could you please review this small fix for jit-tester test generator? >>> >>> TestsGenerator::generateGoldenOut starts a new process to get golden output, waits for a process to finish Automatic.MINUTES_TO_WAIT and destroys it afterward. however Automatic::main interrupts generatorThread (the thread which runs TestsGenerator::runProcess) after Automatic.MINUTES_TO_WAIT, so we get an interrupted exception and don't destroy the process. >>> >>> the patch changes wait time to default jtreg timeout (120 seconds) and also moves Process::destroyForcibly to finally block. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8204577 >>> webrev: http://cr.openjdk.java.net/~iignatyev//8204577/webrev.00 >>> testing: compiled jit-tester library and generate a number of tests w/ it >>> >>> Thanks, >>> -- Igor >>> From paul.sandoz at oracle.com Fri Jun 8 00:42:04 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 7 Jun 2018 17:42:04 -0700 Subject: RFC: Experiment in accessing/managing persistent memory from Java In-Reply-To: <02FCFB8477C4EF43A2AD8E0C60F3DA2B9EE74C14@FMSMSX126.amr.corp.intel.com> References: <02FCFB8477C4EF43A2AD8E0C60F3DA2B9EE74C14@FMSMSX126.amr.corp.intel.com> Message-ID: Hi Andrew, Jonathan, Sandhya gave an overview to a few of us Oracle folks. I agree with what Sandhya says regarding the API, a small surface, and on pursuing an unsafe intrinsic. I like it and would encourage the writing of a draft JEP, especially to give this visibility. I expect this will be beneficial for experimentation with the Panama foreign API where we can use a Pointer to reference into a byte buffer and scribble on it. Further, i hope this work may also benefit the persistent collections effort (PCJ). It intersects with https://bugs.openjdk.java.net/browse/JDK-8153111 ((bf) Allocating ByteBuffer on heterogeneous memory), which is attempting to be more generic. We might also need to increase the velocity on https://bugs.openjdk.java.net/browse/JDK-8180628 (retrofit direct buffer support for size beyond gigabyte scales), and i would be very interested your views on this, how you might be currently working around such size limitations, and what buffer enhancements would work for you. Thanks, Paul. > On May 30, 2018, at 10:21 PM, Viswanathan, Sandhya wrote: > > Hi Andrew/Jonathan, > > Thanks a lot for sharing this work. Copying hotspot-compiler-dev to get their feedback as well. > > Couple of thoughts/observations below: > * Supporting ByteBuffer on persistent memory using existing FileChannel and MappedByteBuffer mechanism sounds like a very good idea. > > * Extending FileChannel.map to take additional parameter to indicate that the ByteBuffer is backed by persistent memory is a small API change. > > * Adding MappedByteBuffer.force(int from, int to) method on smaller range is very useful in addition to the force() on entire ByteBuffer. > > * The underlying force0_mapsync() could be implemented in terms of new unsafe APIs which in turn could be intrinsified. > The advantage of this is that the unsafe APIs could then be used for other future persistent memory APIs in the JRE. > Specifically the following two unsafe APIs would be useful: > a) public native void flush(long address, long size); > b) public native void storeFence(); > storeFence() exists today but doesn?t generate any instruction for x86. > Wondering if we could have additional boolean parameter to force the sfence generation. > * DEFAULT_CACHE_LINE_SIZE is 128 in src/hotspot/cpu/x86/globalDefinitions_x86.hpp whereas actual cache line on the hardware is 64 bytes. > This could be the cause for some of performance that you saw with compiler intrinsic vs pure C native. > > Best Regards, > Sandhya > > > > RFC: Experiment in accessing/managing persistent memory from Java > Andrew Dinn adinn at redhat.com > Mon May 21 09:47:46 UTC 2018 > > I have been helping one of my Red Hat colleagues, Jonathan Halliday, to > investigate provision of a Java equivalent to Intel's libpmem suite of C > libraries [1]. This approach avoids the significant cost of using the > Intel libraries from Java via JNI (or, worse, as a virtual driver for a > persistent memory device). > > Jonathan has modified the JVM/JDK to allow a MappedByteBuffer to be > mapped over persistent memory, providing equivalent function to libpmem > itself. > > On top of this he implemented a Java journaled log class providing > equivalent functionality to one of the Intel client libs, libpmemlog, > built over libpmem. > > The modified MappedByteBuffer can be configured to use either i) a > registered native method or ii) a JIT intrinsic to perform the critical > task of cache line writeback i.e. the persistence step (the intrinsic is > my contribution). > > Jonathan's tests compare use of JNI, registered native and intrinsic > with an equivalent C program to write a large swathe of records to a > journaled log file stored in persistent memory. Performance is worse > than C when relying on JNI and significantly better with JVM/JDK > support. Indeed, as one might reasonably expect, use of the JIT > intrinsic almost completely eliminates writeback costs. > > The journaled log code, jdk dev tree patch, build instructions, test > code plus C equivalent and test results are all available from > Jonathan's git repo [2]. > > For those who do not want to look at the actual code, the README file > [3] provides background to use of persistent memory, an overview of the > design, and summary details of the test process and results. > > [1] https://pmem.io/pmdk/ > [2] https://github.com/jhalliday/pmem > [3] http://github.com://jhalliday/pmem/README.md > > n.b. Jonathan has experimented with using this same prototype to replace > the journaled log used in the Red Hat Narayana transaction manager. It > provides a significant improvement on the current disk file based log, > both for throughput and latency (the code is not yet available as > getting it to work involved some horrible hacking of the build to > migrate up to jdk11). > > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From fujie at loongson.cn Fri Jun 8 03:19:29 2018 From: fujie at loongson.cn (=?UTF-8?B?5YKF5p2w?=) Date: Fri, 8 Jun 2018 11:19:29 +0800 (GMT+08:00) Subject: C1 may generate wrong code during the phase of EdgeMoveOptimizer::optimize() Message-ID: <32aa30f3.6bfb.163dd67fada.Coremail.fujie@loongson.cn> Hi all, I'm porting OpenJDK to mips. I found that the C1 compiler may generate wrong code for mips during the phase of EdgeMoveOptimizer::optimize(). I think the reason is that EdgeMoveOptimizer::optimize_moves_at_block_begin(BlockBegin* block) doesn't consider the case of branch instructions with operands. Some platforms, such as mips, s390 and aarch64, the branch instruction may contain register operands. If the move instruction would change the branch instruction's operand after EdgeMoveOptimizer::optimize_moves_at_block_begin(...), we can't apply it. I made a patch based on http://hg.openjdk.java.net/jdk/jdk/rev/538dd69b60c0. Please see the attachment for that patch. I think s390 and aarch64 will come across the same problem if they optimize the code generation of C1 using branch instructions with operands. Thanks. Fu Jie -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: EdgeMoveOptimizer.patch Type: application/octet-stream Size: 3221 bytes Desc: not available URL: From fujie at loongson.cn Fri Jun 8 04:05:46 2018 From: fujie at loongson.cn (=?UTF-8?B?5YKF5p2w?=) Date: Fri, 8 Jun 2018 12:05:46 +0800 (GMT+08:00) Subject: C1 may generate wrong code during the phase of EdgeMoveOptimizer::optimize() Message-ID: <372fa671.6c12.163dd9259cc.Coremail.fujie@loongson.cn> Hi all, I'm sorry in my previous email, the patch is not convenient to read. I'm porting OpenJDK to mips. I found that the C1 compiler may generate wrong code for mips during the phase of EdgeMoveOptimizer::optimize(). I think the reason is that EdgeMoveOptimizer::optimize_moves_at_block_begin(BlockBegin* block) doesn't consider the case of branch instructions with operands. Some platforms, such as mips, s390 and aarch64, the branch instruction may contain register operands. If the move instruction would change the branch instruction's operand after EdgeMoveOptimizer::optimize_moves_at_block_begin(...), we can't apply it. I made a patch based on http://hg.openjdk.java.net/jdk/jdk/rev/538dd69b60c0. ------------------------------ patch begin ------------------------------------ diff -r 538dd69b60c0 src/hotspot/share/c1/c1_LIR.cpp --- a/src/hotspot/share/c1/c1_LIR.cpp Thu Jun 07 22:26:02 2018 -0400 +++ b/src/hotspot/share/c1/c1_LIR.cpp Fri Jun 08 11:41:32 2018 +0800 @@ -194,7 +194,42 @@ } } +bool LIR_OprDesc::has_common_register(LIR_Opr opr) const { +#ifdef _LP64 + return is_same_register(opr); +#else + if (!(is_register() && opr->is_register())) return false; + if (!(kind_field() == opr->kind_field())) return false; + if (is_single_cpu()) { + if (opr->is_single_cpu()) { + return as_register() == opr->as_register(); + } else { + Register dst = as_register(); + Register lo = opr->as_register_lo(); + Register hi = opr->as_register_hi(); + if (dst == lo || dst == hi) return true; + } + + } else { + Register dst_lo = as_register_lo(); + Register dst_hi = as_register_hi(); + + if (opr->is_single_cpu()) { + Register src = opr->as_register(); + if (dst_lo == src || dst_hi == src) return true; + } else { + Register src_lo = opr->as_register_lo(); + Register src_hi = opr->as_register_hi(); + if (dst_lo == src_lo || + dst_lo == src_hi || + dst_hi == src_lo || + dst_hi == src_hi) return true; + } + } + return false; +#endif +} void LIR_Op2::verify() const { #ifdef ASSERT diff -r 538dd69b60c0 src/hotspot/share/c1/c1_LIR.hpp --- a/src/hotspot/share/c1/c1_LIR.hpp Thu Jun 07 22:26:02 2018 -0400 +++ b/src/hotspot/share/c1/c1_LIR.hpp Fri Jun 08 11:41:32 2018 +0800 @@ -349,7 +349,7 @@ opr->type_field() != unknown_type, "shouldn't see unknown_type"); return type_field() == opr->type_field(); } - bool is_same_register(LIR_Opr opr) { + bool is_same_register(LIR_Opr opr) const { return (is_register() && opr->is_register() && kind_field() == opr->kind_field() && (value() & no_type_mask) == (opr->value() & no_type_mask)); @@ -368,6 +368,8 @@ bool is_float_kind() const { return is_pointer() ? pointer()->is_float_kind() : (kind_field() == fpu_register); } bool is_oop() const; + bool has_common_register(LIR_Opr opr) const; + // semantic for fpu- and xmm-registers: // * is_float and is_double return true for xmm_registers // (so is_single_fpu and is_single_xmm are true) diff -r 538dd69b60c0 src/hotspot/share/c1/c1_LinearScan.cpp --- a/src/hotspot/share/c1/c1_LinearScan.cpp Thu Jun 07 22:26:02 2018 -0400 +++ b/src/hotspot/share/c1/c1_LinearScan.cpp Fri Jun 08 11:41:32 2018 +0800 @@ -6074,6 +6074,14 @@ } } + // Some platforms, such as mips, s390 and aarch64, the branch instruction may contain register operands. + // If the move instruction would change the branch instruction's operand after the optimization, we can't apply it. + if (branch->as_Op2() != NULL) { + LIR_Op2* branch_op2 = (LIR_Op2*)branch; + if (op->result_opr()->has_common_register(branch_op2->in_opr1())) return; + if (op->result_opr()->has_common_register(branch_op2->in_opr2())) return; + } + TRACE_LINEAR_SCAN(4, tty->print("----- found instruction that is equal in all %d successors: ", num_sux); op->print()); // insert instruction at end of current block ------------------------------ patch end of her ------------------------------------ I think s390 and aarch64 will come across the same problem if they optimize the code generation of C1 using branch instructions with operands. Thanks. Best regards, Fu Jie -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Fri Jun 8 07:53:54 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 8 Jun 2018 09:53:54 +0200 Subject: [11] RFR(M): 8203915: Induction variable of over-unrolled loop conflicts with range checks In-Reply-To: <8ee8b4b3-9e4f-3a9f-638a-b17300c9e6cc@oracle.com> References: <8ee8b4b3-9e4f-3a9f-638a-b17300c9e6cc@oracle.com> Message-ID: <02410fb4-e8fb-932e-d8e8-8eadd3b313a5@oracle.com> Hi Vladimir, thanks for looking at this! On 07.06.2018 19:18, Vladimir Kozlov wrote: > Can you look if PhaseIdealLoop::do_range_check() is executed for main loop in this case? If array > length is known statically that code should produce check which should eliminate control flow for > main loop and collapse it. PhaseIdealLoop::do_range_check() is not executed because after predication, the main loop does not contain any range checks (the predicates are before the pre-loop). The tests work fine without loop predication (-XX:-UseLoopPredicate) because in this case do_range_check() is executed and the corresponding check eliminates control flow as expected. Thanks, Tobias From shade at redhat.com Fri Jun 8 07:59:03 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 8 Jun 2018 09:59:03 +0200 Subject: RFR: 8204479: Bitwise AND on byte value sometimes produces wrong result Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8204479 Fix: http://cr.openjdk.java.net/~shade/8204479/webrev.03/ The trouble with unsigned comparisons is that original code would have generate: movzbl (mem), %r cmp %r, $imm jl ... ...while the new code with compUB_mem_imm matcher generates: cmpb (mem), $imm jl ... Original code loaded non-sign-extended byte into int register and then safely did signed comparison. New code does signed byte comparison against memory, which is incorrect. It is still safe when we do proper LoadB, but not LoadUB. Vladimir thinks the second matcher (testUB_mem_imm) suffers from the same issue. I don't think it is ever exposed in our code, because comparison with zero usually conditionally jumps on ZF. But testb does set SF to the MSB of and-ed operands, so we can accidentally use (incorrect) SF for unsigned byte in conditional jump and fail? I haven't been able to reproduce that in the test though. This partially reverts JDK-8203628 change: http://hg.openjdk.java.net/jdk/jdk/rev/197ee9d8e228 Testing: regression test, failing Nashorn tests Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From tobias.hartmann at oracle.com Fri Jun 8 08:18:25 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 8 Jun 2018 10:18:25 +0200 Subject: RFR: 8204479: Bitwise AND on byte value sometimes produces wrong result In-Reply-To: References: Message-ID: <0cc0a475-3e72-e4bb-8311-3b4e411697c8@oracle.com> Hi Aleksey, this looks good to me (and I think the change is trivial because it reverts a previous one). Best regards, Tobias On 08.06.2018 09:59, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8204479 > > Fix: > http://cr.openjdk.java.net/~shade/8204479/webrev.03/ > > The trouble with unsigned comparisons is that original code would have generate: > > movzbl (mem), %r > cmp %r, $imm > jl ... > > ...while the new code with compUB_mem_imm matcher generates: > > cmpb (mem), $imm > jl ... > > Original code loaded non-sign-extended byte into int register and then safely did signed comparison. > New code does signed byte comparison against memory, which is incorrect. It is still safe when we do > proper LoadB, but not LoadUB. > > Vladimir thinks the second matcher (testUB_mem_imm) suffers from the same issue. I don't think it is > ever exposed in our code, because comparison with zero usually conditionally jumps on ZF. But testb > does set SF to the MSB of and-ed operands, so we can accidentally use (incorrect) SF for unsigned > byte in conditional jump and fail? I haven't been able to reproduce that in the test though. > > This partially reverts JDK-8203628 change: > http://hg.openjdk.java.net/jdk/jdk/rev/197ee9d8e228 > > Testing: regression test, failing Nashorn tests > > Thanks, > -Aleksey > From shade at redhat.com Fri Jun 8 10:00:32 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 8 Jun 2018 12:00:32 +0200 Subject: RFR: 8204479: Bitwise AND on byte value sometimes produces wrong result In-Reply-To: <0cc0a475-3e72-e4bb-8311-3b4e411697c8@oracle.com> References: <0cc0a475-3e72-e4bb-8311-3b4e411697c8@oracle.com> Message-ID: On 06/08/2018 10:18 AM, Tobias Hartmann wrote: > Hi Aleksey, > > this looks good to me (and I think the change is trivial because it reverts a previous one). Thank you Tobias. I pushed, adding Vladimir as second reviewer, because he came up with the same patch. I wonder separately if we could instead make matchers match rFlagsRegU cr, maybe that would help to match only "safe" conditional jumps? We can follow up with the redo later. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From nils.eliasson at oracle.com Fri Jun 8 12:05:21 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 8 Jun 2018 14:05:21 +0200 Subject: RFR(S): 8203425: assert(is_Loop()) failed: invalid node class In-Reply-To: References: Message-ID: <6290fe5f-bd33-8b8f-b0e9-b03b57e482cc@oracle.com> Hi, After much testing the patch suggested doesn't still fail in some cases. Until I have a better patch I suggest we revert JDK-8203215. The original problem only manifested itself together with barriers in ZGC, and a workaround is in place. Webrev: http://cr.openjdk.java.net/~neliasso/8203425.02/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8203425 If I can get a quick review, I will push today. Regards, Nils On 2018-05-23 14:14, Nils Eliasson wrote: > Hi, > > This is a follow up to JDK-8203215 that caused failures in testing. > > JDK-8203215 added a call to igvn.optimize after beautify_loops to > handle phi-nodes that have lost their loop edge and now produce loop > invariant data. In testing a failure came up - the igvn.optimize call > can sometimes eliminate a loop node when the phis are all invariant. > > When fixing this I observed that a loop might be removed, and that > another region that is a subset of the first is selected as new loop, > and then there might be new loop invariant phis (not observed). > > This change introduces a fix point iteration for beautify_loops, until > no more loop structure changes has been made. This might sound > expensive but In practice beautify-loops is called one additional time > at first insertion of loop-nodes. I have seen one case of cascading > loop reductions when beautify_loops is called three times. The upside > is that we reach fix point for PhaseIdealLoop faster since these > changes would guarantee to trigger a major change in next iteration > instead. > > https://bugs.openjdk.java.net/browse/JDK-8203425 > > http://cr.openjdk.java.net/~neliasso/8203425/webrev.01/ > > Regards, > > Nils Eliasson > From tobias.hartmann at oracle.com Fri Jun 8 12:49:39 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 8 Jun 2018 14:49:39 +0200 Subject: RFR(S): 8203425: assert(is_Loop()) failed: invalid node class In-Reply-To: <6290fe5f-bd33-8b8f-b0e9-b03b57e482cc@oracle.com> References: <6290fe5f-bd33-8b8f-b0e9-b03b57e482cc@oracle.com> Message-ID: Hi Nils, looks good to me. Best regards, Tobias On 08.06.2018 14:05, Nils Eliasson wrote: > Hi, > > After much testing the patch suggested doesn't still fail in some cases. Until I have a better patch > I suggest we revert JDK-8203215. The original problem only manifested itself together with barriers > in ZGC, and a workaround is in place. > > Webrev: http://cr.openjdk.java.net/~neliasso/8203425.02/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203425 > > If I can get a quick review, I will push today. > > Regards, > > Nils > > > On 2018-05-23 14:14, Nils Eliasson wrote: >> Hi, >> >> This is a follow up to JDK-8203215 that caused failures in testing. >> >> JDK-8203215 added a call to igvn.optimize after beautify_loops to handle phi-nodes that have lost >> their loop edge and now produce loop invariant data. In testing a failure came up - the >> igvn.optimize call can sometimes eliminate a loop node when the phis are all invariant. >> >> When fixing this I observed that a loop might be removed, and that another region that is a subset >> of the first is selected as new loop, and then there might be new loop invariant phis (not observed). >> >> This change introduces a fix point iteration for beautify_loops, until no more loop structure >> changes has been made. This might sound expensive but In practice beautify-loops is called one >> additional time at first insertion of loop-nodes. I have seen one case of cascading loop >> reductions when beautify_loops is called three times. The upside is that we reach fix point for >> PhaseIdealLoop faster since these changes would guarantee to trigger a major change in next >> iteration instead. >> >> https://bugs.openjdk.java.net/browse/JDK-8203425 >> >> http://cr.openjdk.java.net/~neliasso/8203425/webrev.01/ >> >> Regards, >> >> Nils Eliasson >> > From nils.eliasson at oracle.com Fri Jun 8 12:46:12 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 8 Jun 2018 14:46:12 +0200 Subject: RFR(S): 8202747: C2: assert(mode == ControlAroundStripMined && use == sfpt) failed: missed a node In-Reply-To: References: <372497b1-ef88-5e6b-0257-4e7ed17fb2f4@oracle.com> Message-ID: <67a52f8d-f727-6d73-6bdd-634f5bcab542@oracle.com> Hi, Sorry, I have to make a quick respin of testing of just this patch. The previous run had to much noice, probably unrelated. I'll get back to you in 1-2 hours. Regards, Nils On 2018-06-06 10:48, Roland Westrelin wrote: > Hi Nils, > >> I am testing this together with 8203197 now. > Any update on testing? Can I push this? > > Thanks, > Roland. From nils.eliasson at oracle.com Fri Jun 8 14:00:02 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 8 Jun 2018 16:00:02 +0200 Subject: RFR(S): 8202747: C2: assert(mode == ControlAroundStripMined && use == sfpt) failed: missed a node In-Reply-To: <67a52f8d-f727-6d73-6bdd-634f5bcab542@oracle.com> References: <372497b1-ef88-5e6b-0257-4e7ed17fb2f4@oracle.com> <67a52f8d-f727-6d73-6bdd-634f5bcab542@oracle.com> Message-ID: Linux x64 and Windows x64 have passed tier 1-3 testing. Sparc and OSX is on track, but it may take a while. Regards, Nils On 2018-06-08 14:46, Nils Eliasson wrote: > Hi, > > Sorry, I have to make a quick respin of testing of just this patch. > The previous run had to much noice, probably unrelated. I'll get back > to you in 1-2 hours. > > Regards, > > Nils > > > On 2018-06-06 10:48, Roland Westrelin wrote: >> Hi Nils, >> >>> I am testing this together with 8203197 now. >> Any update on testing? Can I push this? >> >> Thanks, >> Roland. > From vladimir.kozlov at oracle.com Fri Jun 8 17:07:21 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 8 Jun 2018 10:07:21 -0700 Subject: RFR: 8204479: Bitwise AND on byte value sometimes produces wrong result In-Reply-To: References: <0cc0a475-3e72-e4bb-8311-3b4e411697c8@oracle.com> Message-ID: <31e872af-26d0-7888-2cfb-d9103a16b1b7@oracle.com> On 6/8/18 3:00 AM, Aleksey Shipilev wrote: > On 06/08/2018 10:18 AM, Tobias Hartmann wrote: >> Hi Aleksey, >> >> this looks good to me (and I think the change is trivial because it reverts a previous one). > > Thank you Tobias. I pushed, adding Vladimir as second reviewer, because he came up with the same patch. Thank you, Aleksey for pushing the fix. > > I wonder separately if we could instead make matchers match rFlagsRegU cr, maybe that would help to > match only "safe" conditional jumps? We can follow up with the redo later. It could be more complicated change because we would need to change ideal nodes to use unsigned compare CmpUNode in case when we have LoadU and positive compared value. Otherwise as you noticed with your first experiment it will not match. Regards, Vladimir > > -Aleksey > > From vladimir.kozlov at oracle.com Fri Jun 8 17:14:36 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 8 Jun 2018 10:14:36 -0700 Subject: [11] RFR(M): 8203915: Induction variable of over-unrolled loop conflicts with range checks In-Reply-To: <02410fb4-e8fb-932e-d8e8-8eadd3b313a5@oracle.com> References: <8ee8b4b3-9e4f-3a9f-638a-b17300c9e6cc@oracle.com> <02410fb4-e8fb-932e-d8e8-8eadd3b313a5@oracle.com> Message-ID: <3338f802-b52f-d0c1-afd2-4ac2862d286f@oracle.com> Thank you, Tobias, for looking on it. Then we have to do what you are suggesting. Reviewed. It is a little frustrating that predicates code become more and more complex and bugs prone :( Thanks, Vladimir On 6/8/18 12:53 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for looking at this! > > On 07.06.2018 19:18, Vladimir Kozlov wrote: >> Can you look if PhaseIdealLoop::do_range_check() is executed for main loop in this case? If array >> length is known statically that code should produce check which should eliminate control flow for >> main loop and collapse it. > > PhaseIdealLoop::do_range_check() is not executed because after predication, the main loop does not > contain any range checks (the predicates are before the pre-loop). > > The tests work fine without loop predication (-XX:-UseLoopPredicate) because in this case > do_range_check() is executed and the corresponding check eliminates control flow as expected. > > Thanks, > Tobias > From vladimir.kozlov at oracle.com Fri Jun 8 19:22:48 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 8 Jun 2018 12:22:48 -0700 Subject: RFC: 8201193 C2 Object Initialization - Using XMM/YMM registers In-Reply-To: <3301e0ef-e43c-6c7a-5b23-e4b296c86178@oracle.com> References: <6ddfaac5-a5ad-dc27-8185-d2237a5b1695@oracle.com> <3301e0ef-e43c-6c7a-5b23-e4b296c86178@oracle.com> Message-ID: <1f664d16-9bb5-7a63-b87c-3359aec8a360@oracle.com> Hi Rohit, I found few issues with changes. I hit assert in Assembler::vpxor() when ran on machine which does not have AVX: assert(UseAVX > 0) failed: requires some form of AVX I think you can use pxor() instead of vpxor() in else case: if (UseAVX >= 2) { vpxor(xtmp, xtmp, xtmp, AVX_256bit); } else { pxor(xtmp, xtmp); } EAX zeroing - it is required for UseFastStosb case too. BTW your code is executed only when UseFastStosb is false. Is it intentional? My be add UseFastStosb check in vm_version_x86.cpp code too. You can also do UseXMMForObjInit setting in vm_version_x86.cpp similar to UseBMI1Instructions flag setting to avoid checking UseUnalignedLoadStores and other flags in all places. Here is code with my changes: http://cr.openjdk.java.net/~kvn/8201193/webrev.02/ Regards, Vladimir On 6/6/18 11:04 AM, Vladimir Kozlov wrote: > Thank you, Rohit > > This change looks reasonable. Let me test it. > > Thanks, > Vladimir > > On 5/30/18 9:55 PM, Rohit Arul Raj wrote: >> Thanks Vladimir, >> >> I made the changes as you had suggested and it works now. >> Please find attached the updated patch, relevant test case as well as >> the micro-benchmark performance data. >> Sorry for the delay. >> >> **************** P A T C H ************** >> >> diff --git a/src/hotspot/cpu/x86/globals_x86.hpp >> b/src/hotspot/cpu/x86/globals_x86.hpp >> --- a/src/hotspot/cpu/x86/globals_x86.hpp >> +++ b/src/hotspot/cpu/x86/globals_x86.hpp >> @@ -150,6 +150,9 @@ >> ??? product(bool, UseUnalignedLoadStores, false,????????????????????????????? \ >> ??????????? "Use SSE2 MOVDQU instruction for Arraycopy")????????????????????? \ >> ????????????????????????????????????????????????????????????????????????????? \ >> +? product(bool, UseXMMForObjInit, false,??????????????????????????????????? \ >> +????????? "Use XMM/YMM MOVDQU instruction for Object Initialization")?????? \ >> +??????????????????????????????????????????????????????????????????????????? \ >> ??? product(bool, UseFastStosb, false,??????????????????????????????????????? \ >> ??????????? "Use fast-string operation for zeroing: rep stosb")?????????????? \ >> ????????????????????????????????????????????????????????????????????????????? \ >> diff --git a/src/hotspot/cpu/x86/macroAssembler_x86.cpp >> b/src/hotspot/cpu/x86/macroAssembler_x86.cpp >> --- a/src/hotspot/cpu/x86/macroAssembler_x86.cpp >> +++ b/src/hotspot/cpu/x86/macroAssembler_x86.cpp >> @@ -6775,7 +6775,58 @@ >> >> ? } >> >> -void MacroAssembler::clear_mem(Register base, Register cnt, Register >> tmp, bool is_large) { >> +// clear memory of size 'cnt' qwords, starting at 'base' using >> XMM/YMM registers >> +void MacroAssembler::xmm_clear_mem(Register base, Register cnt, >> XMMRegister xtmp) { >> +? // cnt - number of qwords (8-byte words). >> +? // base - start address, qword aligned. >> +? Label L_zero_64_bytes, L_loop, L_sloop, L_tail, L_end; >> +? if (UseAVX >= 2) >> +??? vpxor(xtmp, xtmp, xtmp, AVX_256bit); >> +? else >> +??? vpxor(xtmp, xtmp, xtmp, AVX_128bit); >> +? jmp(L_zero_64_bytes); >> + >> +? BIND(L_loop); >> +? if (UseAVX >= 2) { >> +??? vmovdqu(Address(base,? 0), xtmp); >> +??? vmovdqu(Address(base, 32), xtmp); >> +? } else { >> +??? movdqu(Address(base,? 0), xtmp); >> +??? movdqu(Address(base, 16), xtmp); >> +??? movdqu(Address(base, 32), xtmp); >> +??? movdqu(Address(base, 48), xtmp); >> +? } >> +? addptr(base, 64); >> + >> +? BIND(L_zero_64_bytes); >> +? subptr(cnt, 8); >> +? jccb(Assembler::greaterEqual, L_loop); >> +? addptr(cnt, 4); >> +? jccb(Assembler::less, L_tail); >> +? // Copy trailing 32 bytes >> +? if (UseAVX >= 2) { >> +??? vmovdqu(Address(base, 0), xtmp); >> +? } else { >> +??? movdqu(Address(base,? 0), xtmp); >> +??? movdqu(Address(base, 16), xtmp); >> +? } >> +? addptr(base, 32); >> +? subptr(cnt, 4); >> + >> +? BIND(L_tail); >> +? addptr(cnt, 4); >> +? jccb(Assembler::lessEqual, L_end); >> +? decrement(cnt); >> + >> +? BIND(L_sloop); >> +? movq(Address(base, 0), xtmp); >> +? addptr(base, 8); >> +? decrement(cnt); >> +? jccb(Assembler::greaterEqual, L_sloop); >> +? BIND(L_end); >> +} >> + >> +void MacroAssembler::clear_mem(Register base, Register cnt, Register >> tmp, XMMRegister xtmp, bool is_large) { >> ??? // cnt - number of qwords (8-byte words). >> ??? // base - start address, qword aligned. >> ??? // is_large - if optimizers know cnt is larger than InitArrayShortSize >> @@ -6787,7 +6838,9 @@ >> >> ??? Label DONE; >> >> -? xorptr(tmp, tmp); >> +? if (!is_large || !(UseXMMForObjInit && UseUnalignedLoadStores)) { >> +??? xorptr(tmp, tmp); >> +? } >> >> ??? if (!is_large) { >> ????? Label LOOP, LONG; >> @@ -6813,6 +6866,9 @@ >> ??? if (UseFastStosb) { >> ????? shlptr(cnt, 3); // convert to number of bytes >> ????? rep_stosb(); >> +? } else if (UseXMMForObjInit && UseUnalignedLoadStores) { >> +??? movptr(tmp, base); >> +??? xmm_clear_mem(tmp, cnt, xtmp); >> ??? } else { >> ????? NOT_LP64(shlptr(cnt, 1);) // convert to number of 32-bit words >> for 32-bit VM >> ????? rep_stos(); >> diff --git a/src/hotspot/cpu/x86/macroAssembler_x86.hpp >> b/src/hotspot/cpu/x86/macroAssembler_x86.hpp >> --- a/src/hotspot/cpu/x86/macroAssembler_x86.hpp >> +++ b/src/hotspot/cpu/x86/macroAssembler_x86.hpp >> @@ -1578,7 +1578,10 @@ >> >> ??? // clear memory of size 'cnt' qwords, starting at 'base'; >> ??? // if 'is_large' is set, do not try to produce short loop >> -? void clear_mem(Register base, Register cnt, Register rtmp, bool is_large); >> +? void clear_mem(Register base, Register cnt, Register rtmp, >> XMMRegister xtmp, bool is_large); >> + >> +? // clear memory of size 'cnt' qwords, starting at 'base' using >> XMM/YMM registers >> +? void xmm_clear_mem(Register base, Register cnt, XMMRegister xtmp); >> >> ? #ifdef COMPILER2 >> ??? void string_indexof_char(Register str1, Register cnt1, Register ch, >> Register result, >> diff --git a/src/hotspot/cpu/x86/x86_32.ad b/src/hotspot/cpu/x86/x86_32.ad >> --- a/src/hotspot/cpu/x86/x86_32.ad >> +++ b/src/hotspot/cpu/x86/x86_32.ad >> @@ -11482,13 +11482,15 @@ >> >> ? // ======================================================================= >> ? // fast clearing of an array >> -instruct rep_stos(eCXRegI cnt, eDIRegP base, eAXRegI zero, Universe >> dummy, eFlagsReg cr) %{ >> +instruct rep_stos(eCXRegI cnt, eDIRegP base, regD tmp, eAXRegI zero, >> Universe dummy, eFlagsReg cr) %{ >> ??? predicate(!((ClearArrayNode*)n)->is_large()); >> ??? match(Set dummy (ClearArray cnt base)); >> -? effect(USE_KILL cnt, USE_KILL base, KILL zero, KILL cr); >> +? effect(USE_KILL cnt, USE_KILL base, TEMP tmp, KILL zero, KILL cr); >> >> ??? format %{ $$template >> -??? $$emit$$"XOR??? EAX,EAX\t# ClearArray:\n\t" >> +??? if (!is_large || !(UseXMMForObjInit && UseUnalignedLoadStores)) { >> +????? $$emit$$"XOR??? EAX,EAX\t# ClearArray:\n\t" >> +??? } >> ????? $$emit$$"CMP??? InitArrayShortSize,rcx\n\t" >> ????? $$emit$$"JG???? LARGE\n\t" >> ????? $$emit$$"SHL??? ECX, 1\n\t" >> @@ -11502,6 +11504,32 @@ >> ????? if (UseFastStosb) { >> ???????? $$emit$$"SHL??? ECX,3\t# Convert doublewords to bytes\n\t" >> ???????? $$emit$$"REP STOSB\t# store EAX into [EDI++] while ECX--\n\t" >> +??? } else if (UseXMMForObjInit && UseUnalignedLoadStores) { >> +?????? $$emit$$"MOV???? RDI,RAX\n\t" >> +?????? $$emit$$"VPXOR?? YMM0,YMM0,YMM0\n\t" >> +?????? $$emit$$"JMPQ??? L_zero_64_bytes\n\t" >> +?????? $$emit$$"# L_loop:\t# 64-byte LOOP\n\t" >> +?????? $$emit$$"VMOVDQU YMM0,(RAX)\n\t" >> +?????? $$emit$$"VMOVDQU YMM0,0x20(RAX)\n\t" >> +?????? $$emit$$"ADD???? 0x40,RAX\n\t" >> +?????? $$emit$$"# L_zero_64_bytes:\n\t" >> +?????? $$emit$$"SUB???? 0x8,RCX\n\t" >> +?????? $$emit$$"JGE???? L_loop\n\t" >> +?????? $$emit$$"ADD???? 0x4,RCX\n\t" >> +?????? $$emit$$"JL????? L_tail\n\t" >> +?????? $$emit$$"VMOVDQU YMM0,(RAX)\n\t" >> +?????? $$emit$$"ADD???? 0x20,RAX\n\t" >> +?????? $$emit$$"SUB???? 0x4,RCX\n\t" >> +?????? $$emit$$"# L_tail:\t# Clearing tail bytes\n\t" >> +?????? $$emit$$"ADD???? 0x4,RCX\n\t" >> +?????? $$emit$$"JLE???? L_end\n\t" >> +?????? $$emit$$"DEC???? RCX\n\t" >> +?????? $$emit$$"# L_sloop:\t# 8-byte short loop\n\t" >> +?????? $$emit$$"VMOVQ?? XMM0,(RAX)\n\t" >> +?????? $$emit$$"ADD???? 0x8,RAX\n\t" >> +?????? $$emit$$"DEC???? RCX\n\t" >> +?????? $$emit$$"JGE???? L_sloop\n\t" >> +?????? $$emit$$"# L_end:\n\t" >> ????? } else { >> ???????? $$emit$$"SHL??? ECX,1\t# Convert doublewords to words\n\t" >> ???????? $$emit$$"REP STOS\t# store EAX into [EDI++] while ECX--\n\t" >> @@ -11509,20 +11537,49 @@ >> ????? $$emit$$"# DONE" >> ??? %} >> ??? ins_encode %{ >> -??? __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, false); >> -? %} >> -? ins_pipe( pipe_slow ); >> -%} >> - >> -instruct rep_stos_large(eCXRegI cnt, eDIRegP base, eAXRegI zero, >> Universe dummy, eFlagsReg cr) %{ >> +??? __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, >> +???????????????? $tmp$$XMMRegister, false); >> +? %} >> +? ins_pipe( pipe_slow ); >> +%} >> + >> +instruct rep_stos_large(eCXRegI cnt, eDIRegP base, regD tmp, eAXRegI >> zero, Universe dummy, eFlagsReg cr) %{ >> ??? predicate(((ClearArrayNode*)n)->is_large()); >> ??? match(Set dummy (ClearArray cnt base)); >> -? effect(USE_KILL cnt, USE_KILL base, KILL zero, KILL cr); >> +? effect(USE_KILL cnt, USE_KILL base, TEMP tmp, KILL zero, KILL cr); >> ??? format %{ $$template >> -??? $$emit$$"XOR??? EAX,EAX\t# ClearArray:\n\t" >> +??? if (!is_large || !(UseXMMForObjInit && UseUnalignedLoadStores)) { >> +?????? $$emit$$"XOR??? EAX,EAX\t# ClearArray:\n\t" >> +??? } >> ????? if (UseFastStosb) { >> ???????? $$emit$$"SHL??? ECX,3\t# Convert doublewords to bytes\n\t" >> ???????? $$emit$$"REP STOSB\t# store EAX into [EDI++] while ECX--\n\t" >> +??? } else if (UseXMMForObjInit && UseUnalignedLoadStores) { >> +?????? $$emit$$"MOV???? RDI,RAX\n\t" >> +?????? $$emit$$"VPXOR?? YMM0,YMM0,YMM0\n\t" >> +?????? $$emit$$"JMPQ??? L_zero_64_bytes\n\t" >> +?????? $$emit$$"# L_loop:\t# 64-byte LOOP\n\t" >> +?????? $$emit$$"VMOVDQU YMM0,(RAX)\n\t" >> +?????? $$emit$$"VMOVDQU YMM0,0x20(RAX)\n\t" >> +?????? $$emit$$"ADD???? 0x40,RAX\n\t" >> +?????? $$emit$$"# L_zero_64_bytes:\n\t" >> +?????? $$emit$$"SUB???? 0x8,RCX\n\t" >> +?????? $$emit$$"JGE???? L_loop\n\t" >> +?????? $$emit$$"ADD???? 0x4,RCX\n\t" >> +?????? $$emit$$"JL????? L_tail\n\t" >> +?????? $$emit$$"VMOVDQU YMM0,(RAX)\n\t" >> +?????? $$emit$$"ADD???? 0x20,RAX\n\t" >> +?????? $$emit$$"SUB???? 0x4,RCX\n\t" >> +?????? $$emit$$"# L_tail:\t# Clearing tail bytes\n\t" >> +?????? $$emit$$"ADD???? 0x4,RCX\n\t" >> +?????? $$emit$$"JLE???? L_end\n\t" >> +?????? $$emit$$"DEC???? RCX\n\t" >> +?????? $$emit$$"# L_sloop:\t# 8-byte short loop\n\t" >> +?????? $$emit$$"VMOVQ?? XMM0,(RAX)\n\t" >> +?????? $$emit$$"ADD???? 0x8,RAX\n\t" >> +?????? $$emit$$"DEC???? RCX\n\t" >> +?????? $$emit$$"JGE???? L_sloop\n\t" >> +?????? $$emit$$"# L_end:\n\t" >> ????? } else { >> ???????? $$emit$$"SHL??? ECX,1\t# Convert doublewords to words\n\t" >> ???????? $$emit$$"REP STOS\t# store EAX into [EDI++] while ECX--\n\t" >> @@ -11530,7 +11587,8 @@ >> ????? $$emit$$"# DONE" >> ??? %} >> ??? ins_encode %{ >> -??? __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, true); >> +??? __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, >> +???????????????? $tmp$$XMMRegister, true); >> ??? %} >> ??? ins_pipe( pipe_slow ); >> ? %} >> diff --git a/src/hotspot/cpu/x86/x86_64.ad b/src/hotspot/cpu/x86/x86_64.ad >> --- a/src/hotspot/cpu/x86/x86_64.ad >> +++ b/src/hotspot/cpu/x86/x86_64.ad >> @@ -10625,15 +10625,17 @@ >> >> ? // ======================================================================= >> ? // fast clearing of an array >> -instruct rep_stos(rcx_RegL cnt, rdi_RegP base, rax_RegI zero, Universe dummy, >> -????????????????? rFlagsReg cr) >> +instruct rep_stos(rcx_RegL cnt, rdi_RegP base, regD tmp, rax_RegI zero, >> +????????????????? Universe dummy, rFlagsReg cr) >> ? %{ >> ??? predicate(!((ClearArrayNode*)n)->is_large()); >> ??? match(Set dummy (ClearArray cnt base)); >> -? effect(USE_KILL cnt, USE_KILL base, KILL zero, KILL cr); >> +? effect(USE_KILL cnt, USE_KILL base, TEMP tmp, KILL zero, KILL cr); >> >> ??? format %{ $$template >> -??? $$emit$$"xorq??? rax, rax\t# ClearArray:\n\t" >> +??? if (!is_large || !(UseXMMForObjInit && UseUnalignedLoadStores)) { >> +?????? $$emit$$"xorq??? rax, rax\t# ClearArray:\n\t" >> +??? } >> ????? $$emit$$"cmp???? InitArrayShortSize,rcx\n\t" >> ????? $$emit$$"jg????? LARGE\n\t" >> ????? $$emit$$"dec???? rcx\n\t" >> @@ -10646,35 +10648,91 @@ >> ????? if (UseFastStosb) { >> ???????? $$emit$$"shlq??? rcx,3\t# Convert doublewords to bytes\n\t" >> ???????? $$emit$$"rep???? stosb\t# Store rax to *rdi++ while rcx--\n\t" >> +??? } else if (UseXMMForObjInit && UseUnalignedLoadStores) { >> +?????? $$emit$$"mov???? rdi,rax\n\t" >> +?????? $$emit$$"vpxor?? ymm0,ymm0,ymm0\n\t" >> +?????? $$emit$$"jmpq??? L_zero_64_bytes\n\t" >> +?????? $$emit$$"# L_loop:\t# 64-byte LOOP\n\t" >> +?????? $$emit$$"vmovdqu ymm0,(rax)\n\t" >> +?????? $$emit$$"vmovdqu ymm0,0x20(rax)\n\t" >> +?????? $$emit$$"add???? 0x40,rax\n\t" >> +?????? $$emit$$"# L_zero_64_bytes:\n\t" >> +?????? $$emit$$"sub???? 0x8,rcx\n\t" >> +?????? $$emit$$"jge???? L_loop\n\t" >> +?????? $$emit$$"add???? 0x4,rcx\n\t" >> +?????? $$emit$$"jl????? L_tail\n\t" >> +?????? $$emit$$"vmovdqu ymm0,(rax)\n\t" >> +?????? $$emit$$"add???? 0x20,rax\n\t" >> +?????? $$emit$$"sub???? 0x4,rcx\n\t" >> +?????? $$emit$$"# L_tail:\t# Clearing tail bytes\n\t" >> +?????? $$emit$$"add???? 0x4,rcx\n\t" >> +?????? $$emit$$"jle???? L_end\n\t" >> +?????? $$emit$$"dec???? rcx\n\t" >> +?????? $$emit$$"# L_sloop:\t# 8-byte short loop\n\t" >> +?????? $$emit$$"vmovq?? xmm0,(rax)\n\t" >> +?????? $$emit$$"add???? 0x8,rax\n\t" >> +?????? $$emit$$"dec???? rcx\n\t" >> +?????? $$emit$$"jge???? L_sloop\n\t" >> +?????? $$emit$$"# L_end:\n\t" >> ????? } else { >> ???????? $$emit$$"rep???? stosq\t# Store rax to *rdi++ while rcx--\n\t" >> ????? } >> ????? $$emit$$"# DONE" >> ??? %} >> ??? ins_encode %{ >> -??? __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, false); >> +??? __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, >> +???????????????? $tmp$$XMMRegister, false); >> ??? %} >> ??? ins_pipe(pipe_slow); >> ? %} >> >> -instruct rep_stos_large(rcx_RegL cnt, rdi_RegP base, rax_RegI zero, >> Universe dummy, >> -????????????????? rFlagsReg cr) >> +instruct rep_stos_large(rcx_RegL cnt, rdi_RegP base, regD tmp, rax_RegI zero, >> +??????????????????????? Universe dummy, rFlagsReg cr) >> ? %{ >> ??? predicate(((ClearArrayNode*)n)->is_large()); >> ??? match(Set dummy (ClearArray cnt base)); >> -? effect(USE_KILL cnt, USE_KILL base, KILL zero, KILL cr); >> +? effect(USE_KILL cnt, USE_KILL base, TEMP tmp, KILL zero, KILL cr); >> >> ??? format %{ $$template >> -??? $$emit$$"xorq??? rax, rax\t# ClearArray:\n\t" >> +??? if (!is_large || !(UseXMMForObjInit && UseUnalignedLoadStores)) { >> +????? $$emit$$"xorq??? rax, rax\t# ClearArray:\n\t" >> +??? } >> ????? if (UseFastStosb) { >> ???????? $$emit$$"shlq??? rcx,3\t# Convert doublewords to bytes\n\t" >> ???????? $$emit$$"rep???? stosb\t# Store rax to *rdi++ while rcx--" >> +??? } else if (UseXMMForObjInit && UseUnalignedLoadStores) { >> +?????? $$emit$$"mov???? rdi,rax\n\t" >> +?????? $$emit$$"vpxor?? ymm0,ymm0,ymm0\n\t" >> +?????? $$emit$$"jmpq??? L_zero_64_bytes\n\t" >> +?????? $$emit$$"# L_loop:\t# 64-byte LOOP\n\t" >> +?????? $$emit$$"vmovdqu ymm0,(rax)\n\t" >> +?????? $$emit$$"vmovdqu ymm0,0x20(rax)\n\t" >> +?????? $$emit$$"add???? 0x40,rax\n\t" >> +?????? $$emit$$"# L_zero_64_bytes:\n\t" >> +?????? $$emit$$"sub???? 0x8,rcx\n\t" >> +?????? $$emit$$"jge???? L_loop\n\t" >> +?????? $$emit$$"add???? 0x4,rcx\n\t" >> +?????? $$emit$$"jl????? L_tail\n\t" >> +?????? $$emit$$"vmovdqu ymm0,(rax)\n\t" >> +?????? $$emit$$"add???? 0x20,rax\n\t" >> +?????? $$emit$$"sub???? 0x4,rcx\n\t" >> +?????? $$emit$$"# L_tail:\t# Clearing tail bytes\n\t" >> +?????? $$emit$$"add???? 0x4,rcx\n\t" >> +?????? $$emit$$"jle???? L_end\n\t" >> +?????? $$emit$$"dec???? rcx\n\t" >> +?????? $$emit$$"# L_sloop:\t# 8-byte short loop\n\t" >> +?????? $$emit$$"vmovq?? xmm0,(rax)\n\t" >> +?????? $$emit$$"add???? 0x8,rax\n\t" >> +?????? $$emit$$"dec???? rcx\n\t" >> +?????? $$emit$$"jge???? L_sloop\n\t" >> +?????? $$emit$$"# L_end:\n\t" >> ????? } else { >> ???????? $$emit$$"rep???? stosq\t# Store rax to *rdi++ while rcx--" >> ????? } >> ??? %} >> ??? ins_encode %{ >> -??? __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, true); >> +??? __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, >> +???????????????? $tmp$$XMMRegister, true); >> ??? %} >> ??? ins_pipe(pipe_slow); >> ? %} >> >> >> *********************** END of P A T C H ******************* >> >> >> Generated assembly code after change: >> ------------------------------------------------------ >> ? 0x00002b771c0016e4: mov??? %rdx,%rdi >> ? 0x00002b771c0016e7: add??? $0x10,%rdi >> ? 0x00002b771c0016eb: mov??? $0x14,%ecx >> ? 0x00002b771c0016f0: mov??? %rdi,%rax >> ? 0x00002b771c0016f3: vpxor? %ymm0,%ymm0,%ymm0 >> ? 0x00002b771c0016f7: jmpq?? 0x00002b771c001709 >> ? 0x00002b771c0016fc: vmovdqu %ymm0,(%rax) >> ? 0x00002b771c001700: vmovdqu %ymm0,0x20(%rax) >> ? 0x00002b771c001705: add??? $0x40,%rax >> ? 0x00002b771c001709: sub??? $0x8,%rcx >> ? 0x00002b771c00170d: jge??? 0x00002b771c0016fc >> ? 0x00002b771c00170f: add??? $0x4,%rcx >> ? 0x00002b771c001713: jl???? 0x00002b771c001721 >> ? 0x00002b771c001715: vmovdqu %ymm0,(%rax) >> ? 0x00002b771c001719: add??? $0x20,%rax >> ? 0x00002b771c00171d: sub??? $0x4,%rcx >> ? 0x00002b771c001721: add??? $0x4,%rcx >> ? 0x00002b771c001725: jle??? 0x00002b771c001737 >> ? 0x00002b771c001727: dec??? %rcx >> ? 0x00002b771c00172a: vmovq? %xmm0,(%rax) >> ? 0x00002b771c00172e: add??? $0x8,%rax >> ? 0x00002b771c001732: dec??? %rcx >> ? 0x00002b771c001735: jge??? 0x00002b771c00172a >> ? 0x00002b771c001737: >> >> >> I have done regression testing (changeset: >> 50250:04f9bb270ab8/24May2018) on 32-bit as well as 64-bit builds and >> didn't find any regressions. >> $make run-test TEST="tier1 tier2" JTREG="JOBS=1" >> CONF=linux-x86_64-normal-server-release >> >> Please let me know your comments. >> >> Regards, >> Rohit >> >> >> >> On Tue, Apr 24, 2018 at 12:33 AM, Vladimir Kozlov >> wrote: >>> Sorry for delay. >>> >>> In general you can't use arbitrary registers without letting know JIT >>> compilers that you use it. It will definitely cause problems. >>> You need to pass it as additional XMMRegister argument and described it as >>> TEMP in .ad files. >>> >>> See byte_array_inflate() as example. >>> >>> >>> On 4/11/18 7:25 PM, Rohit Arul Raj wrote: >>>>>> >>>>>> When I use XMM0 as a temporary register, the micro-benchmark crashes. >>>>>> Saving and Restoring the XMM0 register before and after use works >>>>>> fine. >>>>>> >>>>>> Looking at the? "hotspot/src/cpu/x86/vm/x86.ad" file, XMM0 as with >>>>>> other XMM registers has been mentioned as Save-On-Call registers and >>>>>> on Linux ABI, no register is preserved across function calls though >>>>>> XMM0-XMM7 might hold parameters. So I assumed using XMM0 without >>>>>> saving/restoring should be fine. >>>>>> >>>>>> Is it incorrect use XMM* registers without saving/restoring them? >>>>>> Using XMM10 register as temporary register works fine without having >>>>>> to save and restore it. >>>> >>>> >>>> Any comments/suggestions on the usage of XMM* registers? >>>> >>>> Thanks, >>>> Rohit >>>> >>>> On Thu, Apr 5, 2018 at 11:38 PM, Vladimir Kozlov >>>> wrote: >>>>> >>>>> Good suggestion, Rohit >>>>> >>>>> I created new RFE. Please add you suggestion and performance data there: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8201193 >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> >>>>> On 4/5/18 12:19 AM, Rohit Arul Raj wrote: >>>>>> >>>>>> >>>>>> Hi All, >>>>>> >>>>>> I was going through the C2 object initialization (zeroing) code based >>>>>> on the below bug entry: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8146801 >>>>>> >>>>>> Right now, for longer lengths we use "rep stos" instructions on x86. I >>>>>> was experimenting with using XMM/YMM registers (on AMD EPYC processor) >>>>>> and found that they do improve performance for certain lengths: >>>>>> >>>>>> For lengths > 64 bytes - 512 bytes : improvement is in the range of 8% >>>>>> to >>>>>> 44% >>>>>> For lengths > 512bytes?????????????????? : some lengths show slight >>>>>> improvement in the range of 2% to 7%, others almost same as "rep stos" >>>>>> numbers. >>>>>> >>>>>> I have attached the complete performance data (data.txt) for reference . >>>>>> Can we add this as an user option similar to UseXMMForArrayCopy? >>>>>> >>>>>> I have used the same test case as in >>>>>> (http://cr.openjdk.java.net/~shade/8146801/benchmarks.jar) with >>>>>> additional sizes. >>>>>> >>>>>> Initial Patch: >>>>>> I haven't added the check for 32-bit mode as I need some help with the >>>>>> code (description given below the patch). >>>>>> The code is similar to the one used in array copy stubs >>>>>> (copy_bytes_forward). >>>>>> >>>>>> diff --git a/src/hotspot/cpu/x86/globals_x86.hpp >>>>>> b/src/hotspot/cpu/x86/globals_x86.hpp >>>>>> --- a/src/hotspot/cpu/x86/globals_x86.hpp >>>>>> +++ b/src/hotspot/cpu/x86/globals_x86.hpp >>>>>> @@ -150,6 +150,9 @@ >>>>>> ????? product(bool, UseUnalignedLoadStores, false, >>>>>> \ >>>>>> ????????????? "Use SSE2 MOVDQU instruction for Arraycopy") >>>>>> \ >>>>>> >>>>>> \ >>>>>> +? product(bool, UseXMMForObjInit, false, >>>>>> \ >>>>>> +????????? "Use XMM/YMM MOVDQU instruction for Object Initialization") >>>>>> \ >>>>>> + >>>>>> \ >>>>>> ????? product(bool, UseFastStosb, false, >>>>>> \ >>>>>> ????????????? "Use fast-string operation for zeroing: rep stosb") >>>>>> \ >>>>>> >>>>>> \ >>>>>> diff --git a/src/hotspot/cpu/x86/macroAssembler_x86.cpp >>>>>> b/src/hotspot/cpu/x86/macroAssembler_x86.cpp >>>>>> --- a/src/hotspot/cpu/x86/macroAssembler_x86.cpp >>>>>> +++ b/src/hotspot/cpu/x86/macroAssembler_x86.cpp >>>>>> @@ -7106,6 +7106,56 @@ >>>>>> ????? if (UseFastStosb) { >>>>>> ??????? shlptr(cnt, 3); // convert to number of bytes >>>>>> ??????? rep_stosb(); >>>>>> +? } else if (UseXMMForObjInit && UseUnalignedLoadStores) { >>>>>> +??? Label L_loop, L_sloop, L_check, L_tail, L_end; >>>>>> +??? push(base); >>>>>> +??? if (UseAVX >= 2) >>>>>> +????? vpxor(xmm10, xmm10, xmm10, AVX_256bit); >>>>>> +??? else >>>>>> +????? vpxor(xmm10, xmm10, xmm10, AVX_128bit); >>>>>> + >>>>>> +??? jmp(L_check); >>>>>> + >>>>>> +??? BIND(L_loop); >>>>>> +??? if (UseAVX >= 2) { >>>>>> +????? vmovdqu(Address(base,? 0), xmm10); >>>>>> +????? vmovdqu(Address(base, 32), xmm10); >>>>>> +??? } else { >>>>>> +????? movdqu(Address(base,? 0), xmm10); >>>>>> +????? movdqu(Address(base, 16), xmm10); >>>>>> +????? movdqu(Address(base, 32), xmm10); >>>>>> +????? movdqu(Address(base, 48), xmm10); >>>>>> +??? } >>>>>> +??? addptr(base, 64); >>>>>> + >>>>>> +??? BIND(L_check); >>>>>> +??? subptr(cnt, 8); >>>>>> +??? jccb(Assembler::greaterEqual, L_loop); >>>>>> +??? addptr(cnt, 4); >>>>>> +??? jccb(Assembler::less, L_tail); >>>>>> +??? // Copy trailing 32 bytes >>>>>> +??? if (UseAVX >= 2) { >>>>>> +????? vmovdqu(Address(base, 0), xmm10); >>>>>> +??? } else { >>>>>> +????? movdqu(Address(base,? 0), xmm10); >>>>>> +????? movdqu(Address(base, 16), xmm10); >>>>>> +??? } >>>>>> +??? addptr(base, 32); >>>>>> +??? subptr(cnt, 4); >>>>>> + >>>>>> +??? BIND(L_tail); >>>>>> +??? addptr(cnt, 4); >>>>>> +??? jccb(Assembler::lessEqual, L_end); >>>>>> +??? decrement(cnt); >>>>>> + >>>>>> +??? BIND(L_sloop); >>>>>> +??? movptr(Address(base, 0), tmp); >>>>>> +??? addptr(base, 8); >>>>>> +??? decrement(cnt); >>>>>> +??? jccb(Assembler::greaterEqual, L_sloop); >>>>>> + >>>>>> +??? BIND(L_end); >>>>>> +??? pop(base); >>>>>> ????? } else { >>>>>> ??????? NOT_LP64(shlptr(cnt, 1);) // convert to number of 32-bit words >>>>>> for 32-bit VM >>>>>> ??????? rep_stos(); >>>>>> >>>>>> >>>>>> When I use XMM0 as a temporary register, the micro-benchmark crashes. >>>>>> Saving and Restoring the XMM0 register before and after use works >>>>>> fine. >>>>>> >>>>>> Looking at the? "hotspot/src/cpu/x86/vm/x86.ad" file, XMM0 as with >>>>>> other XMM registers has been mentioned as Save-On-Call registers and >>>>>> on Linux ABI, no register is preserved across function calls though >>>>>> XMM0-XMM7 might hold parameters. So I assumed using XMM0 without >>>>>> saving/restoring should be fine. >>>>>> >>>>>> Is it incorrect use XMM* registers without saving/restoring them? >>>>>> Using XMM10 register as temporary register works fine without having >>>>>> to save and restore it. >>>>>> >>>>>> Please let me know your comments. >>>>>> >>>>>> Regards, >>>>>> Rohit >>>>>> >>>>> >>> From tom.rodriguez at oracle.com Fri Jun 8 20:46:35 2018 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 8 Jun 2018 13:46:35 -0700 Subject: RFR (S): 8198909: [Graal] compiler/codecache/stress/UnexpectedDeoptimizationTest.java crashed with SIGSEGV Message-ID: <64c722cd-14e3-e0db-6a16-08ca69605205@oracle.com> The JVMCI API may read Klass* and java.lang.Class instances from locations which G1 would consider to be weakly referenced. This can result in HotSpotResolvedObjectTypeImpl instances with references to Classes that have been unloaded. In the this crash, JVMCI was reading a Klass* from the profile in an MDO and building a wrapper around it. The MDO reference is weak and was the only remaining reference to the type so it could be dropped resulting in an eventual crash. I've added an explicit G1 enqueue before we call out to create the wrapper object but is there a more recommended way of doing this? Dean had pointed out the oddly named InstanceKlass::holder_phantom which is used by the CI. Should I be using that? The G1 barrier is only really need when reading from non-Java heap memory but since the get_jvmci_type method is the main entry point for this logic it safest to always perform it in this path. https://bugs.openjdk.java.net/browse/JDK-8198909 http://cr.openjdk.java.net/~never/8198909/webrev From vladimir.kozlov at oracle.com Fri Jun 8 23:34:11 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 8 Jun 2018 16:34:11 -0700 Subject: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes performance regression In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A9073FB24@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A9073FB24@ORSMSX106.amr.corp.intel.com> Message-ID: <04aa0928-9be8-69bc-9a40-8e0a4436b176@oracle.com> Hi Vivek, Changes look good to me. Only add {} for condition in loopTransform.cpp. I asked Tobias to rerun performance testing to verify the fix. Thanks, Vladimir On 6/7/18 3:24 PM, Deshpande, Vivek R wrote: > Hi All > > I have a fix for the regression caused by Subword Analysis. I tested the fix with SPECjvm2008.MPEG > and I don?t observe the slowdown. > > Could you please review the patch and sponsor it. > > Bug ID: > > https://bugs.openjdk.java.net/browse/JDK-8194740 > > Webrev: > http://cr.openjdk.java.net/~vdeshpande/SubwordFix/webrev.00/ > > Regards, > > Vivek > From vivek.r.deshpande at intel.com Fri Jun 8 23:41:57 2018 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Fri, 8 Jun 2018 23:41:57 +0000 Subject: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes performance regression In-Reply-To: <04aa0928-9be8-69bc-9a40-8e0a4436b176@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A9073FB24@ORSMSX106.amr.corp.intel.com> <04aa0928-9be8-69bc-9a40-8e0a4436b176@oracle.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A90740968@ORSMSX106.amr.corp.intel.com> Thanks Vladimir I will take do that and resend the updated webrev. Thanks Tobias for making the runs. Regards, Vivek -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Friday, June 8, 2018 4:34 PM To: Deshpande, Vivek R ; hotspot-compiler-dev at openjdk.java.net compiler Subject: Re: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes performance regression Hi Vivek, Changes look good to me. Only add {} for condition in loopTransform.cpp. I asked Tobias to rerun performance testing to verify the fix. Thanks, Vladimir On 6/7/18 3:24 PM, Deshpande, Vivek R wrote: > Hi All > > I have a fix for the regression caused by Subword Analysis. I tested > the fix with SPECjvm2008.MPEG and I don't observe the slowdown. > > Could you please review the patch and sponsor it. > > Bug ID: > > https://bugs.openjdk.java.net/browse/JDK-8194740 > > Webrev: > http://cr.openjdk.java.net/~vdeshpande/SubwordFix/webrev.00/ > > Regards, > > Vivek > From rohitarulraj at gmail.com Sun Jun 10 05:00:59 2018 From: rohitarulraj at gmail.com (Rohit Arul Raj) Date: Sun, 10 Jun 2018 10:30:59 +0530 Subject: RFC: 8201193 C2 Object Initialization - Using XMM/YMM registers In-Reply-To: <1f664d16-9bb5-7a63-b87c-3359aec8a360@oracle.com> References: <6ddfaac5-a5ad-dc27-8185-d2237a5b1695@oracle.com> <3301e0ef-e43c-6c7a-5b23-e4b296c86178@oracle.com> <1f664d16-9bb5-7a63-b87c-3359aec8a360@oracle.com> Message-ID: Hello Vladimir, Thank you very much for the review. Please find my comments in-lined below. > I hit assert in Assembler::vpxor() when ran on machine which does not have AVX: > assert(UseAVX > 0) failed: requires some form of AVX > I think you can use pxor() instead of vpxor() in else case: > if (UseAVX >= 2) { > vpxor(xtmp, xtmp, xtmp, AVX_256bit); > } else { > pxor(xtmp, xtmp); > } Yes, this change should be fine. My patch would have worked only on processors with AVX support. > EAX zeroing - it is required for UseFastStosb case too. > > BTW your code is executed only when UseFastStosb is false. Is it intentional? My be add UseFastStosb > check in vm_version_x86.cpp code too. Our AMD processors don't have ERMS (Enhanced REP MOVSB/STOSB) support. Hence it would have always been false. Your patch has a much better generic check for this. > You can also do UseXMMForObjInit setting in vm_version_x86.cpp similar to UseBMI1Instructions flag > setting to avoid checking UseUnalignedLoadStores and other flags in all places. Yes, right. > Here is code with my changes: > http://cr.openjdk.java.net/~kvn/8201193/webrev.02/ The patch looks good. We are OK with the updated changes. Thanks, Rohit > > Thank you, Rohit > > > > This change looks reasonable. Let me test it. > > > > Thanks, > > Vladimir > > > > On 5/30/18 9:55 PM, Rohit Arul Raj wrote: > >> Thanks Vladimir, > >> > >> I made the changes as you had suggested and it works now. > >> Please find attached the updated patch, relevant test case as well as > >> the micro-benchmark performance data. > >> Sorry for the delay. > >> > >> **************** P A T C H ************** > >> > >> diff --git a/src/hotspot/cpu/x86/globals_x86.hpp > >> b/src/hotspot/cpu/x86/globals_x86.hpp > >> --- a/src/hotspot/cpu/x86/globals_x86.hpp > >> +++ b/src/hotspot/cpu/x86/globals_x86.hpp > >> @@ -150,6 +150,9 @@ > >> product(bool, UseUnalignedLoadStores, false, \ > >> "Use SSE2 MOVDQU instruction for Arraycopy") \ > >> \ > >> + product(bool, UseXMMForObjInit, false, \ > >> + "Use XMM/YMM MOVDQU instruction for Object Initialization") \ > >> + \ > >> product(bool, UseFastStosb, false, \ > >> "Use fast-string operation for zeroing: rep stosb") \ > >> \ > >> diff --git a/src/hotspot/cpu/x86/macroAssembler_x86.cpp > >> b/src/hotspot/cpu/x86/macroAssembler_x86.cpp > >> --- a/src/hotspot/cpu/x86/macroAssembler_x86.cpp > >> +++ b/src/hotspot/cpu/x86/macroAssembler_x86.cpp > >> @@ -6775,7 +6775,58 @@ > >> > >> } > >> > >> -void MacroAssembler::clear_mem(Register base, Register cnt, Register > >> tmp, bool is_large) { > >> +// clear memory of size 'cnt' qwords, starting at 'base' using > >> XMM/YMM registers > >> +void MacroAssembler::xmm_clear_mem(Register base, Register cnt, > >> XMMRegister xtmp) { > >> + // cnt - number of qwords (8-byte words). > >> + // base - start address, qword aligned. > >> + Label L_zero_64_bytes, L_loop, L_sloop, L_tail, L_end; > >> + if (UseAVX >= 2) > >> + vpxor(xtmp, xtmp, xtmp, AVX_256bit); > >> + else > >> + vpxor(xtmp, xtmp, xtmp, AVX_128bit); > >> + jmp(L_zero_64_bytes); > >> + > >> + BIND(L_loop); > >> + if (UseAVX >= 2) { > >> + vmovdqu(Address(base, 0), xtmp); > >> + vmovdqu(Address(base, 32), xtmp); > >> + } else { > >> + movdqu(Address(base, 0), xtmp); > >> + movdqu(Address(base, 16), xtmp); > >> + movdqu(Address(base, 32), xtmp); > >> + movdqu(Address(base, 48), xtmp); > >> + } > >> + addptr(base, 64); > >> + > >> + BIND(L_zero_64_bytes); > >> + subptr(cnt, 8); > >> + jccb(Assembler::greaterEqual, L_loop); > >> + addptr(cnt, 4); > >> + jccb(Assembler::less, L_tail); > >> + // Copy trailing 32 bytes > >> + if (UseAVX >= 2) { > >> + vmovdqu(Address(base, 0), xtmp); > >> + } else { > >> + movdqu(Address(base, 0), xtmp); > >> + movdqu(Address(base, 16), xtmp); > >> + } > >> + addptr(base, 32); > >> + subptr(cnt, 4); > >> + > >> + BIND(L_tail); > >> + addptr(cnt, 4); > >> + jccb(Assembler::lessEqual, L_end); > >> + decrement(cnt); > >> + > >> + BIND(L_sloop); > >> + movq(Address(base, 0), xtmp); > >> + addptr(base, 8); > >> + decrement(cnt); > >> + jccb(Assembler::greaterEqual, L_sloop); > >> + BIND(L_end); > >> +} > >> + > >> +void MacroAssembler::clear_mem(Register base, Register cnt, Register > >> tmp, XMMRegister xtmp, bool is_large) { > >> // cnt - number of qwords (8-byte words). > >> // base - start address, qword aligned. > >> // is_large - if optimizers know cnt is larger than InitArrayShortSize > >> @@ -6787,7 +6838,9 @@ > >> > >> Label DONE; > >> > >> - xorptr(tmp, tmp); > >> + if (!is_large || !(UseXMMForObjInit && UseUnalignedLoadStores)) { > >> + xorptr(tmp, tmp); > >> + } > >> > >> if (!is_large) { > >> Label LOOP, LONG; > >> @@ -6813,6 +6866,9 @@ > >> if (UseFastStosb) { > >> shlptr(cnt, 3); // convert to number of bytes > >> rep_stosb(); > >> + } else if (UseXMMForObjInit && UseUnalignedLoadStores) { > >> + movptr(tmp, base); > >> + xmm_clear_mem(tmp, cnt, xtmp); > >> } else { > >> NOT_LP64(shlptr(cnt, 1);) // convert to number of 32-bit words > >> for 32-bit VM > >> rep_stos(); > >> diff --git a/src/hotspot/cpu/x86/macroAssembler_x86.hpp > >> b/src/hotspot/cpu/x86/macroAssembler_x86.hpp > >> --- a/src/hotspot/cpu/x86/macroAssembler_x86.hpp > >> +++ b/src/hotspot/cpu/x86/macroAssembler_x86.hpp > >> @@ -1578,7 +1578,10 @@ > >> > >> // clear memory of size 'cnt' qwords, starting at 'base'; > >> // if 'is_large' is set, do not try to produce short loop > >> - void clear_mem(Register base, Register cnt, Register rtmp, bool is_large); > >> + void clear_mem(Register base, Register cnt, Register rtmp, > >> XMMRegister xtmp, bool is_large); > >> + > >> + // clear memory of size 'cnt' qwords, starting at 'base' using > >> XMM/YMM registers > >> + void xmm_clear_mem(Register base, Register cnt, XMMRegister xtmp); > >> > >> #ifdef COMPILER2 > >> void string_indexof_char(Register str1, Register cnt1, Register ch, > >> Register result, > >> diff --git a/src/hotspot/cpu/x86/x86_32.ad b/src/hotspot/cpu/x86/x86_32.ad > >> --- a/src/hotspot/cpu/x86/x86_32.ad > >> +++ b/src/hotspot/cpu/x86/x86_32.ad > >> @@ -11482,13 +11482,15 @@ > >> > >> // ======================================================================= > >> // fast clearing of an array > >> -instruct rep_stos(eCXRegI cnt, eDIRegP base, eAXRegI zero, Universe > >> dummy, eFlagsReg cr) %{ > >> +instruct rep_stos(eCXRegI cnt, eDIRegP base, regD tmp, eAXRegI zero, > >> Universe dummy, eFlagsReg cr) %{ > >> predicate(!((ClearArrayNode*)n)->is_large()); > >> match(Set dummy (ClearArray cnt base)); > >> - effect(USE_KILL cnt, USE_KILL base, KILL zero, KILL cr); > >> + effect(USE_KILL cnt, USE_KILL base, TEMP tmp, KILL zero, KILL cr); > >> > >> format %{ $$template > >> - $$emit$$"XOR EAX,EAX\t# ClearArray:\n\t" > >> + if (!is_large || !(UseXMMForObjInit && UseUnalignedLoadStores)) { > >> + $$emit$$"XOR EAX,EAX\t# ClearArray:\n\t" > >> + } > >> $$emit$$"CMP InitArrayShortSize,rcx\n\t" > >> $$emit$$"JG LARGE\n\t" > >> $$emit$$"SHL ECX, 1\n\t" > >> @@ -11502,6 +11504,32 @@ > >> if (UseFastStosb) { > >> $$emit$$"SHL ECX,3\t# Convert doublewords to bytes\n\t" > >> $$emit$$"REP STOSB\t# store EAX into [EDI++] while ECX--\n\t" > >> + } else if (UseXMMForObjInit && UseUnalignedLoadStores) { > >> + $$emit$$"MOV RDI,RAX\n\t" > >> + $$emit$$"VPXOR YMM0,YMM0,YMM0\n\t" > >> + $$emit$$"JMPQ L_zero_64_bytes\n\t" > >> + $$emit$$"# L_loop:\t# 64-byte LOOP\n\t" > >> + $$emit$$"VMOVDQU YMM0,(RAX)\n\t" > >> + $$emit$$"VMOVDQU YMM0,0x20(RAX)\n\t" > >> + $$emit$$"ADD 0x40,RAX\n\t" > >> + $$emit$$"# L_zero_64_bytes:\n\t" > >> + $$emit$$"SUB 0x8,RCX\n\t" > >> + $$emit$$"JGE L_loop\n\t" > >> + $$emit$$"ADD 0x4,RCX\n\t" > >> + $$emit$$"JL L_tail\n\t" > >> + $$emit$$"VMOVDQU YMM0,(RAX)\n\t" > >> + $$emit$$"ADD 0x20,RAX\n\t" > >> + $$emit$$"SUB 0x4,RCX\n\t" > >> + $$emit$$"# L_tail:\t# Clearing tail bytes\n\t" > >> + $$emit$$"ADD 0x4,RCX\n\t" > >> + $$emit$$"JLE L_end\n\t" > >> + $$emit$$"DEC RCX\n\t" > >> + $$emit$$"# L_sloop:\t# 8-byte short loop\n\t" > >> + $$emit$$"VMOVQ XMM0,(RAX)\n\t" > >> + $$emit$$"ADD 0x8,RAX\n\t" > >> + $$emit$$"DEC RCX\n\t" > >> + $$emit$$"JGE L_sloop\n\t" > >> + $$emit$$"# L_end:\n\t" > >> } else { > >> $$emit$$"SHL ECX,1\t# Convert doublewords to words\n\t" > >> $$emit$$"REP STOS\t# store EAX into [EDI++] while ECX--\n\t" > >> @@ -11509,20 +11537,49 @@ > >> $$emit$$"# DONE" > >> %} > >> ins_encode %{ > >> - __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, false); > >> - %} > >> - ins_pipe( pipe_slow ); > >> -%} > >> - > >> -instruct rep_stos_large(eCXRegI cnt, eDIRegP base, eAXRegI zero, > >> Universe dummy, eFlagsReg cr) %{ > >> + __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, > >> + $tmp$$XMMRegister, false); > >> + %} > >> + ins_pipe( pipe_slow ); > >> +%} > >> + > >> +instruct rep_stos_large(eCXRegI cnt, eDIRegP base, regD tmp, eAXRegI > >> zero, Universe dummy, eFlagsReg cr) %{ > >> predicate(((ClearArrayNode*)n)->is_large()); > >> match(Set dummy (ClearArray cnt base)); > >> - effect(USE_KILL cnt, USE_KILL base, KILL zero, KILL cr); > >> + effect(USE_KILL cnt, USE_KILL base, TEMP tmp, KILL zero, KILL cr); > >> format %{ $$template > >> - $$emit$$"XOR EAX,EAX\t# ClearArray:\n\t" > >> + if (!is_large || !(UseXMMForObjInit && UseUnalignedLoadStores)) { > >> + $$emit$$"XOR EAX,EAX\t# ClearArray:\n\t" > >> + } > >> if (UseFastStosb) { > >> $$emit$$"SHL ECX,3\t# Convert doublewords to bytes\n\t" > >> $$emit$$"REP STOSB\t# store EAX into [EDI++] while ECX--\n\t" > >> + } else if (UseXMMForObjInit && UseUnalignedLoadStores) { > >> + $$emit$$"MOV RDI,RAX\n\t" > >> + $$emit$$"VPXOR YMM0,YMM0,YMM0\n\t" > >> + $$emit$$"JMPQ L_zero_64_bytes\n\t" > >> + $$emit$$"# L_loop:\t# 64-byte LOOP\n\t" > >> + $$emit$$"VMOVDQU YMM0,(RAX)\n\t" > >> + $$emit$$"VMOVDQU YMM0,0x20(RAX)\n\t" > >> + $$emit$$"ADD 0x40,RAX\n\t" > >> + $$emit$$"# L_zero_64_bytes:\n\t" > >> + $$emit$$"SUB 0x8,RCX\n\t" > >> + $$emit$$"JGE L_loop\n\t" > >> + $$emit$$"ADD 0x4,RCX\n\t" > >> + $$emit$$"JL L_tail\n\t" > >> + $$emit$$"VMOVDQU YMM0,(RAX)\n\t" > >> + $$emit$$"ADD 0x20,RAX\n\t" > >> + $$emit$$"SUB 0x4,RCX\n\t" > >> + $$emit$$"# L_tail:\t# Clearing tail bytes\n\t" > >> + $$emit$$"ADD 0x4,RCX\n\t" > >> + $$emit$$"JLE L_end\n\t" > >> + $$emit$$"DEC RCX\n\t" > >> + $$emit$$"# L_sloop:\t# 8-byte short loop\n\t" > >> + $$emit$$"VMOVQ XMM0,(RAX)\n\t" > >> + $$emit$$"ADD 0x8,RAX\n\t" > >> + $$emit$$"DEC RCX\n\t" > >> + $$emit$$"JGE L_sloop\n\t" > >> + $$emit$$"# L_end:\n\t" > >> } else { > >> $$emit$$"SHL ECX,1\t# Convert doublewords to words\n\t" > >> $$emit$$"REP STOS\t# store EAX into [EDI++] while ECX--\n\t" > >> @@ -11530,7 +11587,8 @@ > >> $$emit$$"# DONE" > >> %} > >> ins_encode %{ > >> - __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, true); > >> + __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, > >> + $tmp$$XMMRegister, true); > >> %} > >> ins_pipe( pipe_slow ); > >> %} > >> diff --git a/src/hotspot/cpu/x86/x86_64.ad b/src/hotspot/cpu/x86/x86_64.ad > >> --- a/src/hotspot/cpu/x86/x86_64.ad > >> +++ b/src/hotspot/cpu/x86/x86_64.ad > >> @@ -10625,15 +10625,17 @@ > >> > >> // ======================================================================= > >> // fast clearing of an array > >> -instruct rep_stos(rcx_RegL cnt, rdi_RegP base, rax_RegI zero, Universe dummy, > >> - rFlagsReg cr) > >> +instruct rep_stos(rcx_RegL cnt, rdi_RegP base, regD tmp, rax_RegI zero, > >> + Universe dummy, rFlagsReg cr) > >> %{ > >> predicate(!((ClearArrayNode*)n)->is_large()); > >> match(Set dummy (ClearArray cnt base)); > >> - effect(USE_KILL cnt, USE_KILL base, KILL zero, KILL cr); > >> + effect(USE_KILL cnt, USE_KILL base, TEMP tmp, KILL zero, KILL cr); > >> > >> format %{ $$template > >> - $$emit$$"xorq rax, rax\t# ClearArray:\n\t" > >> + if (!is_large || !(UseXMMForObjInit && UseUnalignedLoadStores)) { > >> + $$emit$$"xorq rax, rax\t# ClearArray:\n\t" > >> + } > >> $$emit$$"cmp InitArrayShortSize,rcx\n\t" > >> $$emit$$"jg LARGE\n\t" > >> $$emit$$"dec rcx\n\t" > >> @@ -10646,35 +10648,91 @@ > >> if (UseFastStosb) { > >> $$emit$$"shlq rcx,3\t# Convert doublewords to bytes\n\t" > >> $$emit$$"rep stosb\t# Store rax to *rdi++ while rcx--\n\t" > >> + } else if (UseXMMForObjInit && UseUnalignedLoadStores) { > >> + $$emit$$"mov rdi,rax\n\t" > >> + $$emit$$"vpxor ymm0,ymm0,ymm0\n\t" > >> + $$emit$$"jmpq L_zero_64_bytes\n\t" > >> + $$emit$$"# L_loop:\t# 64-byte LOOP\n\t" > >> + $$emit$$"vmovdqu ymm0,(rax)\n\t" > >> + $$emit$$"vmovdqu ymm0,0x20(rax)\n\t" > >> + $$emit$$"add 0x40,rax\n\t" > >> + $$emit$$"# L_zero_64_bytes:\n\t" > >> + $$emit$$"sub 0x8,rcx\n\t" > >> + $$emit$$"jge L_loop\n\t" > >> + $$emit$$"add 0x4,rcx\n\t" > >> + $$emit$$"jl L_tail\n\t" > >> + $$emit$$"vmovdqu ymm0,(rax)\n\t" > >> + $$emit$$"add 0x20,rax\n\t" > >> + $$emit$$"sub 0x4,rcx\n\t" > >> + $$emit$$"# L_tail:\t# Clearing tail bytes\n\t" > >> + $$emit$$"add 0x4,rcx\n\t" > >> + $$emit$$"jle L_end\n\t" > >> + $$emit$$"dec rcx\n\t" > >> + $$emit$$"# L_sloop:\t# 8-byte short loop\n\t" > >> + $$emit$$"vmovq xmm0,(rax)\n\t" > >> + $$emit$$"add 0x8,rax\n\t" > >> + $$emit$$"dec rcx\n\t" > >> + $$emit$$"jge L_sloop\n\t" > >> + $$emit$$"# L_end:\n\t" > >> } else { > >> $$emit$$"rep stosq\t# Store rax to *rdi++ while rcx--\n\t" > >> } > >> $$emit$$"# DONE" > >> %} > >> ins_encode %{ > >> - __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, false); > >> + __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, > >> + $tmp$$XMMRegister, false); > >> %} > >> ins_pipe(pipe_slow); > >> %} > >> > >> -instruct rep_stos_large(rcx_RegL cnt, rdi_RegP base, rax_RegI zero, > >> Universe dummy, > >> - rFlagsReg cr) > >> +instruct rep_stos_large(rcx_RegL cnt, rdi_RegP base, regD tmp, rax_RegI zero, > >> + Universe dummy, rFlagsReg cr) > >> %{ > >> predicate(((ClearArrayNode*)n)->is_large()); > >> match(Set dummy (ClearArray cnt base)); > >> - effect(USE_KILL cnt, USE_KILL base, KILL zero, KILL cr); > >> + effect(USE_KILL cnt, USE_KILL base, TEMP tmp, KILL zero, KILL cr); > >> > >> format %{ $$template > >> - $$emit$$"xorq rax, rax\t# ClearArray:\n\t" > >> + if (!is_large || !(UseXMMForObjInit && UseUnalignedLoadStores)) { > >> + $$emit$$"xorq rax, rax\t# ClearArray:\n\t" > >> + } > >> if (UseFastStosb) { > >> $$emit$$"shlq rcx,3\t# Convert doublewords to bytes\n\t" > >> $$emit$$"rep stosb\t# Store rax to *rdi++ while rcx--" > >> + } else if (UseXMMForObjInit && UseUnalignedLoadStores) { > >> + $$emit$$"mov rdi,rax\n\t" > >> + $$emit$$"vpxor ymm0,ymm0,ymm0\n\t" > >> + $$emit$$"jmpq L_zero_64_bytes\n\t" > >> + $$emit$$"# L_loop:\t# 64-byte LOOP\n\t" > >> + $$emit$$"vmovdqu ymm0,(rax)\n\t" > >> + $$emit$$"vmovdqu ymm0,0x20(rax)\n\t" > >> + $$emit$$"add 0x40,rax\n\t" > >> + $$emit$$"# L_zero_64_bytes:\n\t" > >> + $$emit$$"sub 0x8,rcx\n\t" > >> + $$emit$$"jge L_loop\n\t" > >> + $$emit$$"add 0x4,rcx\n\t" > >> + $$emit$$"jl L_tail\n\t" > >> + $$emit$$"vmovdqu ymm0,(rax)\n\t" > >> + $$emit$$"add 0x20,rax\n\t" > >> + $$emit$$"sub 0x4,rcx\n\t" > >> + $$emit$$"# L_tail:\t# Clearing tail bytes\n\t" > >> + $$emit$$"add 0x4,rcx\n\t" > >> + $$emit$$"jle L_end\n\t" > >> + $$emit$$"dec rcx\n\t" > >> + $$emit$$"# L_sloop:\t# 8-byte short loop\n\t" > >> + $$emit$$"vmovq xmm0,(rax)\n\t" > >> + $$emit$$"add 0x8,rax\n\t" > >> + $$emit$$"dec rcx\n\t" > >> + $$emit$$"jge L_sloop\n\t" > >> + $$emit$$"# L_end:\n\t" > >> } else { > >> $$emit$$"rep stosq\t# Store rax to *rdi++ while rcx--" > >> } > >> %} > >> ins_encode %{ > >> - __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, true); > >> + __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, > >> + $tmp$$XMMRegister, true); > >> %} > >> ins_pipe(pipe_slow); > >> %} > >> > >> > >> *********************** END of P A T C H ******************* > >> > >> > >> Generated assembly code after change: > >> ------------------------------------------------------ > >> 0x00002b771c0016e4: mov %rdx,%rdi > >> 0x00002b771c0016e7: add $0x10,%rdi > >> 0x00002b771c0016eb: mov $0x14,%ecx > >> 0x00002b771c0016f0: mov %rdi,%rax > >> 0x00002b771c0016f3: vpxor %ymm0,%ymm0,%ymm0 > >> 0x00002b771c0016f7: jmpq 0x00002b771c001709 > >> 0x00002b771c0016fc: vmovdqu %ymm0,(%rax) > >> 0x00002b771c001700: vmovdqu %ymm0,0x20(%rax) > >> 0x00002b771c001705: add $0x40,%rax > >> 0x00002b771c001709: sub $0x8,%rcx > >> 0x00002b771c00170d: jge 0x00002b771c0016fc > >> 0x00002b771c00170f: add $0x4,%rcx > >> 0x00002b771c001713: jl 0x00002b771c001721 > >> 0x00002b771c001715: vmovdqu %ymm0,(%rax) > >> 0x00002b771c001719: add $0x20,%rax > >> 0x00002b771c00171d: sub $0x4,%rcx > >> 0x00002b771c001721: add $0x4,%rcx > >> 0x00002b771c001725: jle 0x00002b771c001737 > >> 0x00002b771c001727: dec %rcx > >> 0x00002b771c00172a: vmovq %xmm0,(%rax) > >> 0x00002b771c00172e: add $0x8,%rax > >> 0x00002b771c001732: dec %rcx > >> 0x00002b771c001735: jge 0x00002b771c00172a > >> 0x00002b771c001737: > >> > >> > >> I have done regression testing (changeset: > >> 50250:04f9bb270ab8/24May2018) on 32-bit as well as 64-bit builds and > >> didn't find any regressions. > >> $make run-test TEST="tier1 tier2" JTREG="JOBS=1" > >> CONF=linux-x86_64-normal-server-release > >> > >> Please let me know your comments. > >> > >> Regards, > >> Rohit > >> > >> > >> > >> On Tue, Apr 24, 2018 at 12:33 AM, Vladimir Kozlov > >> wrote: > >>> Sorry for delay. > >>> > >>> In general you can't use arbitrary registers without letting know JIT > >>> compilers that you use it. It will definitely cause problems. > >>> You need to pass it as additional XMMRegister argument and described it as > >>> TEMP in .ad files. > >>> > >>> See byte_array_inflate() as example. > >>> > >>> > >>> On 4/11/18 7:25 PM, Rohit Arul Raj wrote: > >>>>>> > >>>>>> When I use XMM0 as a temporary register, the micro-benchmark crashes. > >>>>>> Saving and Restoring the XMM0 register before and after use works > >>>>>> fine. > >>>>>> > >>>>>> Looking at the "hotspot/src/cpu/x86/vm/x86.ad" file, XMM0 as with > >>>>>> other XMM registers has been mentioned as Save-On-Call registers and > >>>>>> on Linux ABI, no register is preserved across function calls though > >>>>>> XMM0-XMM7 might hold parameters. So I assumed using XMM0 without > >>>>>> saving/restoring should be fine. > >>>>>> > >>>>>> Is it incorrect use XMM* registers without saving/restoring them? > >>>>>> Using XMM10 register as temporary register works fine without having > >>>>>> to save and restore it. > >>>> > >>>> > >>>> Any comments/suggestions on the usage of XMM* registers? > >>>> > >>>> Thanks, > >>>> Rohit > >>>> > >>>> On Thu, Apr 5, 2018 at 11:38 PM, Vladimir Kozlov > >>>> wrote: > >>>>> > >>>>> Good suggestion, Rohit > >>>>> > >>>>> I created new RFE. Please add you suggestion and performance data there: > >>>>> > >>>>> https://bugs.openjdk.java.net/browse/JDK-8201193 > >>>>> > >>>>> Thanks, > >>>>> Vladimir > >>>>> > >>>>> > >>>>> On 4/5/18 12:19 AM, Rohit Arul Raj wrote: > >>>>>> > >>>>>> > >>>>>> Hi All, > >>>>>> > >>>>>> I was going through the C2 object initialization (zeroing) code based > >>>>>> on the below bug entry: > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8146801 > >>>>>> > >>>>>> Right now, for longer lengths we use "rep stos" instructions on x86. I > >>>>>> was experimenting with using XMM/YMM registers (on AMD EPYC processor) > >>>>>> and found that they do improve performance for certain lengths: > >>>>>> > >>>>>> For lengths > 64 bytes - 512 bytes : improvement is in the range of 8% > >>>>>> to > >>>>>> 44% > >>>>>> For lengths > 512bytes : some lengths show slight > >>>>>> improvement in the range of 2% to 7%, others almost same as "rep stos" > >>>>>> numbers. > >>>>>> > >>>>>> I have attached the complete performance data (data.txt) for reference . > >>>>>> Can we add this as an user option similar to UseXMMForArrayCopy? > >>>>>> > >>>>>> I have used the same test case as in > >>>>>> (http://cr.openjdk.java.net/~shade/8146801/benchmarks.jar) with > >>>>>> additional sizes. > >>>>>> > >>>>>> Initial Patch: > >>>>>> I haven't added the check for 32-bit mode as I need some help with the > >>>>>> code (description given below the patch). > >>>>>> The code is similar to the one used in array copy stubs > >>>>>> (copy_bytes_forward). > >>>>>> > >>>>>> diff --git a/src/hotspot/cpu/x86/globals_x86.hpp > >>>>>> b/src/hotspot/cpu/x86/globals_x86.hpp > >>>>>> --- a/src/hotspot/cpu/x86/globals_x86.hpp > >>>>>> +++ b/src/hotspot/cpu/x86/globals_x86.hpp > >>>>>> @@ -150,6 +150,9 @@ > >>>>>> product(bool, UseUnalignedLoadStores, false, > >>>>>> \ > >>>>>> "Use SSE2 MOVDQU instruction for Arraycopy") > >>>>>> \ > >>>>>> > >>>>>> \ > >>>>>> + product(bool, UseXMMForObjInit, false, > >>>>>> \ > >>>>>> + "Use XMM/YMM MOVDQU instruction for Object Initialization") > >>>>>> \ > >>>>>> + > >>>>>> \ > >>>>>> product(bool, UseFastStosb, false, > >>>>>> \ > >>>>>> "Use fast-string operation for zeroing: rep stosb") > >>>>>> \ > >>>>>> > >>>>>> \ > >>>>>> diff --git a/src/hotspot/cpu/x86/macroAssembler_x86.cpp > >>>>>> b/src/hotspot/cpu/x86/macroAssembler_x86.cpp > >>>>>> --- a/src/hotspot/cpu/x86/macroAssembler_x86.cpp > >>>>>> +++ b/src/hotspot/cpu/x86/macroAssembler_x86.cpp > >>>>>> @@ -7106,6 +7106,56 @@ > >>>>>> if (UseFastStosb) { > >>>>>> shlptr(cnt, 3); // convert to number of bytes > >>>>>> rep_stosb(); > >>>>>> + } else if (UseXMMForObjInit && UseUnalignedLoadStores) { > >>>>>> + Label L_loop, L_sloop, L_check, L_tail, L_end; > >>>>>> + push(base); > >>>>>> + if (UseAVX >= 2) > >>>>>> + vpxor(xmm10, xmm10, xmm10, AVX_256bit); > >>>>>> + else > >>>>>> + vpxor(xmm10, xmm10, xmm10, AVX_128bit); > >>>>>> + > >>>>>> + jmp(L_check); > >>>>>> + > >>>>>> + BIND(L_loop); > >>>>>> + if (UseAVX >= 2) { > >>>>>> + vmovdqu(Address(base, 0), xmm10); > >>>>>> + vmovdqu(Address(base, 32), xmm10); > >>>>>> + } else { > >>>>>> + movdqu(Address(base, 0), xmm10); > >>>>>> + movdqu(Address(base, 16), xmm10); > >>>>>> + movdqu(Address(base, 32), xmm10); > >>>>>> + movdqu(Address(base, 48), xmm10); > >>>>>> + } > >>>>>> + addptr(base, 64); > >>>>>> + > >>>>>> + BIND(L_check); > >>>>>> + subptr(cnt, 8); > >>>>>> + jccb(Assembler::greaterEqual, L_loop); > >>>>>> + addptr(cnt, 4); > >>>>>> + jccb(Assembler::less, L_tail); > >>>>>> + // Copy trailing 32 bytes > >>>>>> + if (UseAVX >= 2) { > >>>>>> + vmovdqu(Address(base, 0), xmm10); > >>>>>> + } else { > >>>>>> + movdqu(Address(base, 0), xmm10); > >>>>>> + movdqu(Address(base, 16), xmm10); > >>>>>> + } > >>>>>> + addptr(base, 32); > >>>>>> + subptr(cnt, 4); > >>>>>> + > >>>>>> + BIND(L_tail); > >>>>>> + addptr(cnt, 4); > >>>>>> + jccb(Assembler::lessEqual, L_end); > >>>>>> + decrement(cnt); > >>>>>> + > >>>>>> + BIND(L_sloop); > >>>>>> + movptr(Address(base, 0), tmp); > >>>>>> + addptr(base, 8); > >>>>>> + decrement(cnt); > >>>>>> + jccb(Assembler::greaterEqual, L_sloop); > >>>>>> + > >>>>>> + BIND(L_end); > >>>>>> + pop(base); > >>>>>> } else { > >>>>>> NOT_LP64(shlptr(cnt, 1);) // convert to number of 32-bit words > >>>>>> for 32-bit VM > >>>>>> rep_stos(); > >>>>>> > >>>>>> > >>>>>> When I use XMM0 as a temporary register, the micro-benchmark crashes. > >>>>>> Saving and Restoring the XMM0 register before and after use works > >>>>>> fine. > >>>>>> > >>>>>> Looking at the "hotspot/src/cpu/x86/vm/x86.ad" file, XMM0 as with > >>>>>> other XMM registers has been mentioned as Save-On-Call registers and > >>>>>> on Linux ABI, no register is preserved across function calls though > >>>>>> XMM0-XMM7 might hold parameters. So I assumed using XMM0 without > >>>>>> saving/restoring should be fine. > >>>>>> > >>>>>> Is it incorrect use XMM* registers without saving/restoring them? > >>>>>> Using XMM10 register as temporary register works fine without having > >>>>>> to save and restore it. > >>>>>> > >>>>>> Please let me know your comments. > >>>>>> > >>>>>> Regards, > >>>>>> Rohit > >>>>>> > >>>>> > >>> From nils.eliasson at oracle.com Mon Jun 11 08:23:39 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 11 Jun 2018 10:23:39 +0200 Subject: RFR(S): 8202747: C2: assert(mode == ControlAroundStripMined && use == sfpt) failed: missed a node In-Reply-To: References: <372497b1-ef88-5e6b-0257-4e7ed17fb2f4@oracle.com> <67a52f8d-f727-6d73-6bdd-634f5bcab542@oracle.com> Message-ID: <8c81e3e6-35c1-07bd-c702-96059e70092d@oracle.com> All passed. Regards, Nils On 2018-06-08 16:00, Nils Eliasson wrote: > Linux x64 and Windows x64 have passed tier 1-3 testing. Sparc and OSX > is on track, but it may take a while. > > Regards, > > Nils > > > > On 2018-06-08 14:46, Nils Eliasson wrote: >> Hi, >> >> Sorry, I have to make a quick respin of testing of just this patch. >> The previous run had to much noice, probably unrelated. I'll get back >> to you in 1-2 hours. >> >> Regards, >> >> Nils >> >> >> On 2018-06-06 10:48, Roland Westrelin wrote: >>> Hi Nils, >>> >>>> I am testing this together with 8203197 now. >>> Any update on testing? Can I push this? >>> >>> Thanks, >>> Roland. >> > From erik.osterlund at oracle.com Mon Jun 11 09:09:09 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 11 Jun 2018 11:09:09 +0200 Subject: RFR (S): 8198909: [Graal] compiler/codecache/stress/UnexpectedDeoptimizationTest.java crashed with SIGSEGV In-Reply-To: <64c722cd-14e3-e0db-6a16-08ca69605205@oracle.com> References: <64c722cd-14e3-e0db-6a16-08ca69605205@oracle.com> Message-ID: <5B1E3C35.3090506@oracle.com> Hi Tom, Could you please call InstanceKlass::holder_phantom() instead to keep the class alive? That is the more general mechanism that is also used by ciInstanceKlass. We don't want to use explicit G1 enqueue calls anymore. Also, you must not perform any thread transition between loading the weak klass from the MDO until you call holder_phantom, otherwise it might have been unloaded before you get to call holder_phantom(). Is this guaranteed somehow in this scenario? I looked through all callsites and could not find where the Klass pointer is read in the MDO and subsequently passed into the CompilerToVM::get_jvmci_type API, and therefore I do not know if this is guaranteed. Thanks, /Erik On 2018-06-08 22:46, Tom Rodriguez wrote: > The JVMCI API may read Klass* and java.lang.Class instances from > locations which G1 would consider to be weakly referenced. This can > result in HotSpotResolvedObjectTypeImpl instances with references to > Classes that have been unloaded. In the this crash, JVMCI was reading > a Klass* from the profile in an MDO and building a wrapper around it. > The MDO reference is weak and was the only remaining reference to the > type so it could be dropped resulting in an eventual crash. > > I've added an explicit G1 enqueue before we call out to create the > wrapper object but is there a more recommended way of doing this? Dean > had pointed out the oddly named InstanceKlass::holder_phantom which is > used by the CI. Should I be using that? The G1 barrier is only > really need when reading from non-Java heap memory but since the > get_jvmci_type method is the main entry point for this logic it safest > to always perform it in this path. > > https://bugs.openjdk.java.net/browse/JDK-8198909 > http://cr.openjdk.java.net/~never/8198909/webrev From stuart.monteith at linaro.org Mon Jun 11 12:49:12 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Mon, 11 Jun 2018 13:49:12 +0100 Subject: RFR(S): 8204606 - [Aarch64] SIGSEGVs caused by C1 because of improper register usage Message-ID: Hello, Here is Andrew's patch to correct a poor choice of registers in JDK-8201593. http://cr.openjdk.java.net/~smonteith/8204606/webrev/ CR: https://bugs.openjdk.java.net/browse/JDK-8204606 Retested with C1 on tier1 tests. Thanks, Stuart From rwestrel at redhat.com Mon Jun 11 13:03:23 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 11 Jun 2018 15:03:23 +0200 Subject: RFR(L): 8203197: C2: consider all paths in loop body for loop predication In-Reply-To: References: <560a000a-01c1-eff8-7520-2dbb8460f041@oracle.com> <2adf40c0-6e38-e35c-c3f1-4829fca92181@oracle.com> Message-ID: Hi Vladimir, >> With this: >> >> while() { >> if (!null_check1) unc(null_check); >> if (!range_check1) unc(range_check); >> ... >> if (some_condition) { // both branches profiled taken >> if (!null_check2) unc(null_check); >> if (!range_check2) unc(range_check); >> ... >> } >> if (!null_check3) unc(null_check); >> if (!range_check3) unc(range_check); >> } > > In this example what will happen if *_check1 and *_check3 are moved from > loop first (they are regular predicates). And then you found that > "profiling" *_check2 can be moved. How you enforce order in such case? Predicates *_check1 and *_check3 are executed first because they are part of the regular predicates block. Then only *_check2 are executed because they're part of the profiling predicates block which is after. My understanding is that it doesn't matter whether predicates are executed in the same order they would be in the loop body because they have no side effect anyway. Order of predicates matter in cases like: while() { if (object == null) unc(null_check); value = object.field; if (value == null) unc(null_check); result += value.field; } Once they are out of loop, if (object == null) .. must be before if (value == null) .. because the first check causes the object.field load to be becomes loop independent and the second check depends on the object.field load. So order matters, because there's a data dependence between the 2 checks. > No I was asking about this case when you have "profiling" case: > > while() { > if (some_condition) { // both branches profiled taken > if (!null_check) unc(null_check); > if (!range_check) unc(range_check); > break; > } > ... > } > > Should you take special care in such case because such checks only > executed on exit? Both checks are not in the loop. If we walk through the loop body from the tail to the head we shouldn't encounter them, right? Roland. From tobias.hartmann at oracle.com Mon Jun 11 13:30:22 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 11 Jun 2018 15:30:22 +0200 Subject: [11] RFR(M): 8203915: Induction variable of over-unrolled loop conflicts with range checks In-Reply-To: <3338f802-b52f-d0c1-afd2-4ac2862d286f@oracle.com> References: <8ee8b4b3-9e4f-3a9f-638a-b17300c9e6cc@oracle.com> <02410fb4-e8fb-932e-d8e8-8eadd3b313a5@oracle.com> <3338f802-b52f-d0c1-afd2-4ac2862d286f@oracle.com> Message-ID: <09064711-ca97-3444-3d5f-4fa9efaa5f35@oracle.com> Thanks, Vladimir! Best regards, Tobias On 08.06.2018 19:14, Vladimir Kozlov wrote: > Thank you, Tobias, for looking on it. > > Then we have to do what you are suggesting. Reviewed. > > It is a little frustrating that predicates code become more and more complex and bugs prone :( > > Thanks, > Vladimir > > On 6/8/18 12:53 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for looking at this! >> >> On 07.06.2018 19:18, Vladimir Kozlov wrote: >>> Can you look if PhaseIdealLoop::do_range_check() is executed for main loop in this case? If array >>> length is known statically that code should produce check which should eliminate control flow for >>> main loop and collapse it. >> >> PhaseIdealLoop::do_range_check() is not executed because after predication, the main loop does not >> contain any range checks (the predicates are before the pre-loop). >> >> The tests work fine without loop predication (-XX:-UseLoopPredicate) because in this case >> do_range_check() is executed and the corresponding check eliminates control flow as expected. >> >> Thanks, >> Tobias >> From jonathan.halliday at redhat.com Fri Jun 8 10:59:58 2018 From: jonathan.halliday at redhat.com (Jonathan Halliday) Date: Fri, 8 Jun 2018 11:59:58 +0100 Subject: RFC: Experiment in accessing/managing persistent memory from Java In-Reply-To: References: <02FCFB8477C4EF43A2AD8E0C60F3DA2B9EE74C14@FMSMSX126.amr.corp.intel.com> Message-ID: Hi Paul Looks like we're all on the same page regarding the basic approach of using a small API and making the critical bits intrinsic. We perhaps have some way to go on exactly what that API looks like in terms of the classes and methods, but iterating on it by discussion of a JEP seems like the best way forward. The important thing from my perspective is that so far nobody has come forward with a use case that is not covered by the proposed primitives. So it's a small API, but not too small. As far a tweaks go, we have considered making the low level primitive method / intrinsic just a flushCacheline(base_address), since the arithmetic and loop for writing flush(from,to) in terms of that low level op is something that can be optimized fine by the JIT already. Though that does mean exposing the cache line size to the Java layer, whereas currently it's only visible in the C code. My own background and focus is transactions systems, so I'm more about the speed and fault tolerance than the capacity, but I can see long vs. int being of interest to our Infinispan data grid team and likewise for e.g. Oracle Coherence or databases like Cassandra. OTOH it's not uncommon to prefer moderately sized files and shard over them, which sidesteps the issue. Utility code to assist with fine-grained memory management within the buffer/file may be more useful than support for really large buffers, since they tend to be used with some form of internal block/heap structure anyhow, rather than to hold very large objects. Providing that may be the role of a 3rd party pure Java library like PCJ though, rather than something we want in the JDK itself at this early stage. The researcher in me is kinda interested in how much of the memory allocation and GC code can be re-purposed here though... What's the intended timeline on long buffer indexing at present? My feeling is a pmem API JEP is probably targeting around JDK 13, but we're flexible on that. We may also want to look at related enhancements like unmapping buffers. I think those pieces are sufficient decoupled that they won't be dependencies for the pmem API though, unlike other factors such as the availability of test hardware. Regards Jonathan. On 08/06/18 01:42, Paul Sandoz wrote: > Hi Andrew, Jonathan, > > Sandhya gave an overview to a few of us Oracle folks. I agree with what Sandhya says regarding the API, a small surface, and on pursuing an unsafe intrinsic. I like it and would encourage the writing of a draft JEP, especially to give this visibility. > > I expect this will be beneficial for experimentation with the Panama foreign API where we can use a Pointer to reference into a byte buffer and scribble on it. Further, i hope this work may also benefit the persistent collections effort (PCJ). > > > It intersects with https://bugs.openjdk.java.net/browse/JDK-8153111 ((bf) Allocating ByteBuffer on heterogeneous memory), which is attempting to be more generic. > > We might also need to increase the velocity on https://bugs.openjdk.java.net/browse/JDK-8180628 (retrofit direct buffer support for size beyond gigabyte scales), and i would be very interested your views on this, how you might be currently working around such size limitations, and what buffer enhancements would work for you. > > Thanks, > Paul. > > >> On May 30, 2018, at 10:21 PM, Viswanathan, Sandhya wrote: >> >> Hi Andrew/Jonathan, >> >> Thanks a lot for sharing this work. Copying hotspot-compiler-dev to get their feedback as well. >> >> Couple of thoughts/observations below: >> * Supporting ByteBuffer on persistent memory using existing FileChannel and MappedByteBuffer mechanism sounds like a very good idea. >> >> * Extending FileChannel.map to take additional parameter to indicate that the ByteBuffer is backed by persistent memory is a small API change. >> >> * Adding MappedByteBuffer.force(int from, int to) method on smaller range is very useful in addition to the force() on entire ByteBuffer. >> >> * The underlying force0_mapsync() could be implemented in terms of new unsafe APIs which in turn could be intrinsified. >> The advantage of this is that the unsafe APIs could then be used for other future persistent memory APIs in the JRE. >> Specifically the following two unsafe APIs would be useful: >> a) public native void flush(long address, long size); >> b) public native void storeFence(); >> storeFence() exists today but doesn?t generate any instruction for x86. >> Wondering if we could have additional boolean parameter to force the sfence generation. >> * DEFAULT_CACHE_LINE_SIZE is 128 in src/hotspot/cpu/x86/globalDefinitions_x86.hpp whereas actual cache line on the hardware is 64 bytes. >> This could be the cause for some of performance that you saw with compiler intrinsic vs pure C native. >> >> Best Regards, >> Sandhya >> >> >> >> RFC: Experiment in accessing/managing persistent memory from Java >> Andrew Dinn adinn at redhat.com >> Mon May 21 09:47:46 UTC 2018 >> >> I have been helping one of my Red Hat colleagues, Jonathan Halliday, to >> investigate provision of a Java equivalent to Intel's libpmem suite of C >> libraries [1]. This approach avoids the significant cost of using the >> Intel libraries from Java via JNI (or, worse, as a virtual driver for a >> persistent memory device). >> >> Jonathan has modified the JVM/JDK to allow a MappedByteBuffer to be >> mapped over persistent memory, providing equivalent function to libpmem >> itself. >> >> On top of this he implemented a Java journaled log class providing >> equivalent functionality to one of the Intel client libs, libpmemlog, >> built over libpmem. >> >> The modified MappedByteBuffer can be configured to use either i) a >> registered native method or ii) a JIT intrinsic to perform the critical >> task of cache line writeback i.e. the persistence step (the intrinsic is >> my contribution). >> >> Jonathan's tests compare use of JNI, registered native and intrinsic >> with an equivalent C program to write a large swathe of records to a >> journaled log file stored in persistent memory. Performance is worse >> than C when relying on JNI and significantly better with JVM/JDK >> support. Indeed, as one might reasonably expect, use of the JIT >> intrinsic almost completely eliminates writeback costs. >> >> The journaled log code, jdk dev tree patch, build instructions, test >> code plus C equivalent and test results are all available from >> Jonathan's git repo [2]. >> >> For those who do not want to look at the actual code, the README file >> [3] provides background to use of persistent memory, an overview of the >> design, and summary details of the test process and results. >> >> [1] https://pmem.io/pmdk/ >> [2] https://github.com/jhalliday/pmem >> [3] http://github.com://jhalliday/pmem/README.md >> >> n.b. Jonathan has experimented with using this same prototype to replace >> the journaled log used in the Red Hat Narayana transaction manager. It >> provides a significant improvement on the current disk file based log, >> both for throughput and latency (the code is not yet available as >> getting it to work involved some horrible hacking of the build to >> migrate up to jdk11). >> >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Senior Principal Software Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > -- Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Mon Jun 11 15:07:16 2018 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 11 Jun 2018 16:07:16 +0100 Subject: RFR: 8189105: AARCH64: create intrinsic for sin and cos In-Reply-To: References: <4de41b0c-e318-c70f-a864-4f6c8bd14297@redhat.com> <5B12CAEF.8050105@bell-sw.com> <2bd89c11-d234-ceae-3b04-4c547ef5836c@redhat.com> Message-ID: Hi Dimitrij, Apologies for not responding -- I have only just returned from holiday. On 04/06/18 16:50, Dmitrij Pochepko wrote: > On 04.06.2018 13:59, Andrew Haley wrote: >>> . . . >>> > I don't really know how to review this. It's a lot of hand-carved >>> > assembly code and it's very hard to read. It'd need to be very >>> > thoroughly tested. >>> >>> It is a vectorized version of existing C code algorithm, >> Which existing C code algorithm? > this is a hotspot copy of fdlibm trigonometric functions in > hotspot/src/share/runtime/sharedRuntimeTrig.cpp > I added respective comment in intrinsic. Thanks for providing this code and the additional comments. However, I don't think this approaches anywhere near the requirements Andrew set out in his initial review, requirements which I agree are absolutely necessary. I can only repeat his recommendation that you look at the Montgomery multiply code in stubGenerator_aarch64.cpp to get an idea of the sort of detail that is needed to satisfactorily document an implementation this complex. The two most important goals are to be able to 1) review the current code with a high degree of confidence that it is correct 2) maintain this code without imposing an intolerable burden on developers who might need to check it months from now Review will only be possible if the code is written in a way that makes what it is doing clear enough to be able to judge that it is correct. That is far from being the case as it stands. Saying it is the same as the C code modulo a few optimizations is nothing like enough. Visibly identifying how the various register values and insns/blocks correspond to their original C source lines would be a big improvement. Explaining what these values represent as they are updated and what each insn/block achieves would be even better. Better still would be to define macro instructions in the assembler so that the generation can be viewed at the level of more abstract operations that reflect the numerical and mathematical transformations being performed. Finally, relating the whole to the underlying mathematical theory would be the cherry on the cake. Note that the original C code has comments with this level of detail and that code is far easier to follow than this assembler. So, all the more reason for the same or more commentary here. Maintenance is an issue *whether or not* the current code is correct. Someone will inevitably at some point be faced with the following dilemma: possibly, locate a bug in the current implementation; or, more likely, reassure yourself that the code is correct before proceeding to diagnose the real problem elsewhere. The current code is a fly-trap and a piece of software as large and mature as OpenJDK has more than enough complexity without adding fly-traps into the mix. Note that neither of these goals are going to be met by testing, no matter how exhaustive. Also, don't feel singled out by these reviews. Andrew and I are not suggesting this as a matter of form. We know how important this is because we have tested and reviewed*** an immense amount of much less complex code in getting this port to where it is now and learned a great deal from that experience. We have only been able to identify and fix the many bugs that have turned up /after/ extensive review because we tried very hard to keep the code as clear and well documented as possible (n.b. we also added lots of asserts to validate assumptions). That is not something specific that we did off our own bat. It is actually the expected standard for JVM code, shared or cpu-specific. That standard has not always been lived up to but it is steadily improving. The Intel versions of these intrinsics in the x86 are indeed a notable lapse (I believe they were culled from Intel's C compiler output). However, their failings do not excuse repeating the same mistake for AArch64. *** n.b contrary to assumptions expressed in some recent threads Andrew is not the only reviewer for AArch64 code. In particular, every line of his code has been reviewed by me and/or a handful of other reviewers from the day we started this port. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From tom.rodriguez at oracle.com Mon Jun 11 17:04:39 2018 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 11 Jun 2018 10:04:39 -0700 Subject: RFR (S): 8198909: [Graal] compiler/codecache/stress/UnexpectedDeoptimizationTest.java crashed with SIGSEGV In-Reply-To: <5B1E3C35.3090506@oracle.com> References: <64c722cd-14e3-e0db-6a16-08ca69605205@oracle.com> <5B1E3C35.3090506@oracle.com> Message-ID: Erik ?sterlund wrote on 6/11/18 2:09 AM: > Hi Tom, > > Could you please call InstanceKlass::holder_phantom() instead to keep > the class alive? That is the more general mechanism that is also used by > ciInstanceKlass. We don't want to use explicit G1 enqueue calls anymore. Ok. I guess the same fix in JDK8 will have the use the explicit enqueue though or is it not required in JDK8? > Also, you must not perform any thread transition between loading the > weak klass from the MDO until you call holder_phantom, otherwise it > might have been unloaded before you get to call holder_phantom(). Is > this guaranteed somehow in this scenario? I looked through all callsites > and could not find where the Klass pointer is read in the MDO and > subsequently passed into the CompilerToVM::get_jvmci_type API, and > therefore I do not know if this is guaranteed. The obviously problematic path is at http://hg.openjdk.java.net/jdk/jdk/file/50469fb301c4/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp#l334 when either base_address is a Klass* or base_object is NULL which is where we are reading from non-heap memory. There are other paths which are reading Klasses through more standard APIs from the ConstantPool for instance. There isn't an easy way to ensure no safepoint occurs in between so maybe we require the caller of get_jvmci_type to pass in the phantom_holder() as a way of forcing the caller to call holder_phantom() at the appropriate places? Or is it the case that getResolvedType is the only place where special effort is required? All the other paths are fairly normal HotSpot code but though place that uses klass->implementor() for instance seems like it could be considered to be weak by G1. http://hg.openjdk.java.net/jdk/jdk/file/50469fb301c4/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp#l368 The lack of a properly working KlassHandle seems like an oversight in the API to me. tom > > Thanks, > /Erik > > On 2018-06-08 22:46, Tom Rodriguez wrote: >> The JVMCI API may read Klass* and java.lang.Class instances from >> locations which G1 would consider to be weakly referenced. This can >> result in HotSpotResolvedObjectTypeImpl instances with references to >> Classes that have been unloaded. In the this crash, JVMCI was reading >> a Klass* from the profile in an MDO and building a wrapper around it. >> The MDO reference is weak and was the only remaining reference to the >> type so it could be dropped resulting in an eventual crash. >> >> I've added an explicit G1 enqueue before we call out to create the >> wrapper object but is there a more recommended way of doing this? Dean >> had pointed out the oddly named InstanceKlass::holder_phantom which is >> used by the CI. Should I be using that? The G1 barrier is only >> really need when reading from non-Java heap memory but since the >> get_jvmci_type method is the main entry point for this logic it safest >> to always perform it in this path. >> >> https://bugs.openjdk.java.net/browse/JDK-8198909 >> http://cr.openjdk.java.net/~never/8198909/webrev > From vladimir.kozlov at oracle.com Mon Jun 11 17:26:40 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Jun 2018 10:26:40 -0700 Subject: Updated: [11] RFR(M) 8184349: There should be some verification that EnableJVMCI is disabled if a GC not supporting JVMCI is selected In-Reply-To: <8b33f96f-48c5-6df3-5efe-f77dd19961c5@oracle.com> References: <8b33f96f-48c5-6df3-5efe-f77dd19961c5@oracle.com> Message-ID: http://cr.openjdk.java.net/~kvn/8184349/webrev.04/ I updated changes made back in May. I pushed CMS tests changes in separate fix 8202611. The main fix is for JVMCI to check if GC is supported and exit VM with error if not [1]. It is called from Arguments::apply_ergo() after GC is selected in GCConfig::initialize(). In Arguments::check_vm_args_consistency() I added compiler flags reset in -Xint case when Interpreter only used. ScavengeRootsInCode code for JVMCI is removed because the same code is executed already always in Arguments::parse() [2]. Added new Arguments::set_compiler_flags() called from apply_ergo() to combine all compiler flags ergo settings. One test CheckCompileThresholdScaling.java was modified because scaling compiler threshold is skipped in Interpreter mode (-Xint). Tested tier1,tier2,tier3-graal Thanks, Vladimir [1] http://cr.openjdk.java.net/~kvn/8184349/webrev.04/src/hotspot/share/jvmci/jvmci_globals.cpp.udiff.html [2] http://hg.openjdk.java.net/jdk/jdk/file/54fcaffa8fac/src/hotspot/share/runtime/arguments.cpp#l4111 From vivek.r.deshpande at intel.com Mon Jun 11 18:48:19 2018 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Mon, 11 Jun 2018 18:48:19 +0000 Subject: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes performance regression In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A90740968@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A9073FB24@ORSMSX106.amr.corp.intel.com> <04aa0928-9be8-69bc-9a40-8e0a4436b176@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A90740968@ORSMSX106.amr.corp.intel.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A907415AB@ORSMSX106.amr.corp.intel.com> Hi Vladimir I have updated the webrev with suggested {} for if(). Regards, Vivek -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Deshpande, Vivek R Sent: Friday, June 8, 2018 4:42 PM To: Vladimir Kozlov ; hotspot-compiler-dev at openjdk.java.net compiler Subject: RE: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes performance regression Thanks Vladimir I will take do that and resend the updated webrev. Thanks Tobias for making the runs. Regards, Vivek -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Friday, June 8, 2018 4:34 PM To: Deshpande, Vivek R ; hotspot-compiler-dev at openjdk.java.net compiler Subject: Re: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes performance regression Hi Vivek, Changes look good to me. Only add {} for condition in loopTransform.cpp. I asked Tobias to rerun performance testing to verify the fix. Thanks, Vladimir On 6/7/18 3:24 PM, Deshpande, Vivek R wrote: > Hi All > > I have a fix for the regression caused by Subword Analysis. I tested > the fix with SPECjvm2008.MPEG and I don't observe the slowdown. > > Could you please review the patch and sponsor it. > > Bug ID: > > https://bugs.openjdk.java.net/browse/JDK-8194740 > > Webrev: > http://cr.openjdk.java.net/~vdeshpande/SubwordFix/webrev.00/ > > Regards, > > Vivek > From vladimir.kozlov at oracle.com Mon Jun 11 18:50:01 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Jun 2018 11:50:01 -0700 Subject: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes performance regression In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A907415AB@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A9073FB24@ORSMSX106.amr.corp.intel.com> <04aa0928-9be8-69bc-9a40-8e0a4436b176@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A90740968@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A907415AB@ORSMSX106.amr.corp.intel.com> Message-ID: http://cr.openjdk.java.net/~vdeshpande/SubwordFix/webrev.01/ Good. Now we have to wait performance results. Thanks, Vladimir On 6/11/18 11:48 AM, Deshpande, Vivek R wrote: > Hi Vladimir > > I have updated the webrev with suggested {} for if(). > > Regards, > Vivek > > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Deshpande, Vivek R > Sent: Friday, June 8, 2018 4:42 PM > To: Vladimir Kozlov ; hotspot-compiler-dev at openjdk.java.net compiler > Subject: RE: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes performance regression > > Thanks Vladimir > > I will take do that and resend the updated webrev. > Thanks Tobias for making the runs. > > Regards, > Vivek > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Friday, June 8, 2018 4:34 PM > To: Deshpande, Vivek R ; hotspot-compiler-dev at openjdk.java.net compiler > Subject: Re: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes performance regression > > Hi Vivek, > > Changes look good to me. Only add {} for condition in loopTransform.cpp. > I asked Tobias to rerun performance testing to verify the fix. > > Thanks, > Vladimir > > On 6/7/18 3:24 PM, Deshpande, Vivek R wrote: >> Hi All >> >> I have a fix for the regression caused by Subword Analysis. I tested >> the fix with SPECjvm2008.MPEG and I don't observe the slowdown. >> >> Could you please review the patch and sponsor it. >> >> Bug ID: >> >> https://bugs.openjdk.java.net/browse/JDK-8194740 >> >> Webrev: >> http://cr.openjdk.java.net/~vdeshpande/SubwordFix/webrev.00/ >> >> Regards, >> >> Vivek >> From vivek.r.deshpande at intel.com Mon Jun 11 18:51:44 2018 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Mon, 11 Jun 2018 18:51:44 +0000 Subject: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes performance regression In-Reply-To: References: <53E8E64DB2403849AFD89B7D4DAC8B2A9073FB24@ORSMSX106.amr.corp.intel.com> <04aa0928-9be8-69bc-9a40-8e0a4436b176@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A90740968@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A907415AB@ORSMSX106.amr.corp.intel.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A907415DC@ORSMSX106.amr.corp.intel.com> Thanks Vladimir, that is the right link. http://cr.openjdk.java.net/~vdeshpande/SubwordFix/webrev.01/ Regards, Vivek -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Monday, June 11, 2018 11:50 AM To: Deshpande, Vivek R ; hotspot-compiler-dev at openjdk.java.net compiler Cc: Tobias Hartmann Subject: Re: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes performance regression http://cr.openjdk.java.net/~vdeshpande/SubwordFix/webrev.01/ Good. Now we have to wait performance results. Thanks, Vladimir On 6/11/18 11:48 AM, Deshpande, Vivek R wrote: > Hi Vladimir > > I have updated the webrev with suggested {} for if(). > > Regards, > Vivek > > -----Original Message----- > From: hotspot-compiler-dev > [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of > Deshpande, Vivek R > Sent: Friday, June 8, 2018 4:42 PM > To: Vladimir Kozlov ; > hotspot-compiler-dev at openjdk.java.net compiler > > Subject: RE: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes > performance regression > > Thanks Vladimir > > I will take do that and resend the updated webrev. > Thanks Tobias for making the runs. > > Regards, > Vivek > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Friday, June 8, 2018 4:34 PM > To: Deshpande, Vivek R ; > hotspot-compiler-dev at openjdk.java.net compiler > > Subject: Re: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes > performance regression > > Hi Vivek, > > Changes look good to me. Only add {} for condition in loopTransform.cpp. > I asked Tobias to rerun performance testing to verify the fix. > > Thanks, > Vladimir > > On 6/7/18 3:24 PM, Deshpande, Vivek R wrote: >> Hi All >> >> I have a fix for the regression caused by Subword Analysis. I tested >> the fix with SPECjvm2008.MPEG and I don't observe the slowdown. >> >> Could you please review the patch and sponsor it. >> >> Bug ID: >> >> https://bugs.openjdk.java.net/browse/JDK-8194740 >> >> Webrev: >> http://cr.openjdk.java.net/~vdeshpande/SubwordFix/webrev.00/ >> >> Regards, >> >> Vivek >> From ekaterina.pavlova at oracle.com Mon Jun 11 20:31:57 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Mon, 11 Jun 2018 13:31:57 -0700 Subject: RFR (XXS): 8204694: Add failed compiler/stable tests into ProblemList-graal.txt Message-ID: <562eec59-add7-d9d2-c5c5-7d419010755b@oracle.com> Hi all, please review this tiny change which adds recently failed tests into test/hotspot/jtreg/ProblemList-graal.txt. JBS: https://bugs.openjdk.java.net/browse/JDK-8204694 webrev: http://cr.openjdk.java.net/~epavlova//8204694/webrev.00/index.html Thanks, -katya p.s. Igor Ignatyev volunteered to sponsor this change. From vladimir.kozlov at oracle.com Mon Jun 11 20:35:51 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Jun 2018 13:35:51 -0700 Subject: RFR (XXS): 8204694: Add failed compiler/stable tests into ProblemList-graal.txt In-Reply-To: <562eec59-add7-d9d2-c5c5-7d419010755b@oracle.com> References: <562eec59-add7-d9d2-c5c5-7d419010755b@oracle.com> Message-ID: <817a317b-92c8-e11e-a903-8de0f5d262d2@oracle.com> Looks good. Thanks, Vladimir On 6/11/18 1:31 PM, Ekaterina Pavlova wrote: > Hi all, > > please review this tiny change which adds recently failed tests > into test/hotspot/jtreg/ProblemList-graal.txt. > > ?JBS:???? https://bugs.openjdk.java.net/browse/JDK-8204694 > ?webrev: > http://cr.openjdk.java.net/~epavlova//8204694/webrev.00/index.html > > Thanks, > -katya > > p.s. > ?Igor Ignatyev volunteered to sponsor this change. From vladimir.kozlov at oracle.com Mon Jun 11 20:41:04 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Jun 2018 13:41:04 -0700 Subject: RFC: 8201193 C2 Object Initialization - Using XMM/YMM registers In-Reply-To: References: <6ddfaac5-a5ad-dc27-8185-d2237a5b1695@oracle.com> <3301e0ef-e43c-6c7a-5b23-e4b296c86178@oracle.com> <1f664d16-9bb5-7a63-b87c-3359aec8a360@oracle.com> Message-ID: Okay, I will send official RFR. Thanks, Vladimir On 6/9/18 10:00 PM, Rohit Arul Raj wrote: > Hello Vladimir, > > Thank you very much for the review. > > Please find my comments in-lined below. > >> I hit assert in Assembler::vpxor() when ran on machine which does not have AVX: >> assert(UseAVX > 0) failed: requires some form of AVX >> I think you can use pxor() instead of vpxor() in else case: >> if (UseAVX >= 2) { >> vpxor(xtmp, xtmp, xtmp, AVX_256bit); >> } else { >> pxor(xtmp, xtmp); >> } > > Yes, this change should be fine. My patch would have worked only on > processors with AVX support. > >> EAX zeroing - it is required for UseFastStosb case too. >> >> BTW your code is executed only when UseFastStosb is false. Is it intentional? My be add UseFastStosb >> check in vm_version_x86.cpp code too. > > Our AMD processors don't have ERMS (Enhanced REP MOVSB/STOSB) support. > Hence it would have always been false. > Your patch has a much better generic check for this. > >> You can also do UseXMMForObjInit setting in vm_version_x86.cpp similar to UseBMI1Instructions flag >> setting to avoid checking UseUnalignedLoadStores and other flags in all places. > > Yes, right. > >> Here is code with my changes: >> http://cr.openjdk.java.net/~kvn/8201193/webrev.02/ > > The patch looks good. We are OK with the updated changes. > > Thanks, > Rohit > >>> Thank you, Rohit >>> >>> This change looks reasonable. Let me test it. >>> >>> Thanks, >>> Vladimir >>> >>> On 5/30/18 9:55 PM, Rohit Arul Raj wrote: >>>> Thanks Vladimir, >>>> >>>> I made the changes as you had suggested and it works now. >>>> Please find attached the updated patch, relevant test case as well as >>>> the micro-benchmark performance data. >>>> Sorry for the delay. >>>> >>>> **************** P A T C H ************** >>>> >>>> diff --git a/src/hotspot/cpu/x86/globals_x86.hpp >>>> b/src/hotspot/cpu/x86/globals_x86.hpp >>>> --- a/src/hotspot/cpu/x86/globals_x86.hpp >>>> +++ b/src/hotspot/cpu/x86/globals_x86.hpp >>>> @@ -150,6 +150,9 @@ >>>> product(bool, UseUnalignedLoadStores, false, \ >>>> "Use SSE2 MOVDQU instruction for Arraycopy") \ >>>> \ >>>> + product(bool, UseXMMForObjInit, false, \ >>>> + "Use XMM/YMM MOVDQU instruction for Object Initialization") \ >>>> + \ >>>> product(bool, UseFastStosb, false, \ >>>> "Use fast-string operation for zeroing: rep stosb") \ >>>> \ >>>> diff --git a/src/hotspot/cpu/x86/macroAssembler_x86.cpp >>>> b/src/hotspot/cpu/x86/macroAssembler_x86.cpp >>>> --- a/src/hotspot/cpu/x86/macroAssembler_x86.cpp >>>> +++ b/src/hotspot/cpu/x86/macroAssembler_x86.cpp >>>> @@ -6775,7 +6775,58 @@ >>>> >>>> } >>>> >>>> -void MacroAssembler::clear_mem(Register base, Register cnt, Register >>>> tmp, bool is_large) { >>>> +// clear memory of size 'cnt' qwords, starting at 'base' using >>>> XMM/YMM registers >>>> +void MacroAssembler::xmm_clear_mem(Register base, Register cnt, >>>> XMMRegister xtmp) { >>>> + // cnt - number of qwords (8-byte words). >>>> + // base - start address, qword aligned. >>>> + Label L_zero_64_bytes, L_loop, L_sloop, L_tail, L_end; >>>> + if (UseAVX >= 2) >>>> + vpxor(xtmp, xtmp, xtmp, AVX_256bit); >>>> + else >>>> + vpxor(xtmp, xtmp, xtmp, AVX_128bit); >>>> + jmp(L_zero_64_bytes); >>>> + >>>> + BIND(L_loop); >>>> + if (UseAVX >= 2) { >>>> + vmovdqu(Address(base, 0), xtmp); >>>> + vmovdqu(Address(base, 32), xtmp); >>>> + } else { >>>> + movdqu(Address(base, 0), xtmp); >>>> + movdqu(Address(base, 16), xtmp); >>>> + movdqu(Address(base, 32), xtmp); >>>> + movdqu(Address(base, 48), xtmp); >>>> + } >>>> + addptr(base, 64); >>>> + >>>> + BIND(L_zero_64_bytes); >>>> + subptr(cnt, 8); >>>> + jccb(Assembler::greaterEqual, L_loop); >>>> + addptr(cnt, 4); >>>> + jccb(Assembler::less, L_tail); >>>> + // Copy trailing 32 bytes >>>> + if (UseAVX >= 2) { >>>> + vmovdqu(Address(base, 0), xtmp); >>>> + } else { >>>> + movdqu(Address(base, 0), xtmp); >>>> + movdqu(Address(base, 16), xtmp); >>>> + } >>>> + addptr(base, 32); >>>> + subptr(cnt, 4); >>>> + >>>> + BIND(L_tail); >>>> + addptr(cnt, 4); >>>> + jccb(Assembler::lessEqual, L_end); >>>> + decrement(cnt); >>>> + >>>> + BIND(L_sloop); >>>> + movq(Address(base, 0), xtmp); >>>> + addptr(base, 8); >>>> + decrement(cnt); >>>> + jccb(Assembler::greaterEqual, L_sloop); >>>> + BIND(L_end); >>>> +} >>>> + >>>> +void MacroAssembler::clear_mem(Register base, Register cnt, Register >>>> tmp, XMMRegister xtmp, bool is_large) { >>>> // cnt - number of qwords (8-byte words). >>>> // base - start address, qword aligned. >>>> // is_large - if optimizers know cnt is larger than InitArrayShortSize >>>> @@ -6787,7 +6838,9 @@ >>>> >>>> Label DONE; >>>> >>>> - xorptr(tmp, tmp); >>>> + if (!is_large || !(UseXMMForObjInit && UseUnalignedLoadStores)) { >>>> + xorptr(tmp, tmp); >>>> + } >>>> >>>> if (!is_large) { >>>> Label LOOP, LONG; >>>> @@ -6813,6 +6866,9 @@ >>>> if (UseFastStosb) { >>>> shlptr(cnt, 3); // convert to number of bytes >>>> rep_stosb(); >>>> + } else if (UseXMMForObjInit && UseUnalignedLoadStores) { >>>> + movptr(tmp, base); >>>> + xmm_clear_mem(tmp, cnt, xtmp); >>>> } else { >>>> NOT_LP64(shlptr(cnt, 1);) // convert to number of 32-bit words >>>> for 32-bit VM >>>> rep_stos(); >>>> diff --git a/src/hotspot/cpu/x86/macroAssembler_x86.hpp >>>> b/src/hotspot/cpu/x86/macroAssembler_x86.hpp >>>> --- a/src/hotspot/cpu/x86/macroAssembler_x86.hpp >>>> +++ b/src/hotspot/cpu/x86/macroAssembler_x86.hpp >>>> @@ -1578,7 +1578,10 @@ >>>> >>>> // clear memory of size 'cnt' qwords, starting at 'base'; >>>> // if 'is_large' is set, do not try to produce short loop >>>> - void clear_mem(Register base, Register cnt, Register rtmp, bool is_large); >>>> + void clear_mem(Register base, Register cnt, Register rtmp, >>>> XMMRegister xtmp, bool is_large); >>>> + >>>> + // clear memory of size 'cnt' qwords, starting at 'base' using >>>> XMM/YMM registers >>>> + void xmm_clear_mem(Register base, Register cnt, XMMRegister xtmp); >>>> >>>> #ifdef COMPILER2 >>>> void string_indexof_char(Register str1, Register cnt1, Register ch, >>>> Register result, >>>> diff --git a/src/hotspot/cpu/x86/x86_32.ad b/src/hotspot/cpu/x86/x86_32.ad >>>> --- a/src/hotspot/cpu/x86/x86_32.ad >>>> +++ b/src/hotspot/cpu/x86/x86_32.ad >>>> @@ -11482,13 +11482,15 @@ >>>> >>>> // ======================================================================= >>>> // fast clearing of an array >>>> -instruct rep_stos(eCXRegI cnt, eDIRegP base, eAXRegI zero, Universe >>>> dummy, eFlagsReg cr) %{ >>>> +instruct rep_stos(eCXRegI cnt, eDIRegP base, regD tmp, eAXRegI zero, >>>> Universe dummy, eFlagsReg cr) %{ >>>> predicate(!((ClearArrayNode*)n)->is_large()); >>>> match(Set dummy (ClearArray cnt base)); >>>> - effect(USE_KILL cnt, USE_KILL base, KILL zero, KILL cr); >>>> + effect(USE_KILL cnt, USE_KILL base, TEMP tmp, KILL zero, KILL cr); >>>> >>>> format %{ $$template >>>> - $$emit$$"XOR EAX,EAX\t# ClearArray:\n\t" >>>> + if (!is_large || !(UseXMMForObjInit && UseUnalignedLoadStores)) { >>>> + $$emit$$"XOR EAX,EAX\t# ClearArray:\n\t" >>>> + } >>>> $$emit$$"CMP InitArrayShortSize,rcx\n\t" >>>> $$emit$$"JG LARGE\n\t" >>>> $$emit$$"SHL ECX, 1\n\t" >>>> @@ -11502,6 +11504,32 @@ >>>> if (UseFastStosb) { >>>> $$emit$$"SHL ECX,3\t# Convert doublewords to bytes\n\t" >>>> $$emit$$"REP STOSB\t# store EAX into [EDI++] while ECX--\n\t" >>>> + } else if (UseXMMForObjInit && UseUnalignedLoadStores) { >>>> + $$emit$$"MOV RDI,RAX\n\t" >>>> + $$emit$$"VPXOR YMM0,YMM0,YMM0\n\t" >>>> + $$emit$$"JMPQ L_zero_64_bytes\n\t" >>>> + $$emit$$"# L_loop:\t# 64-byte LOOP\n\t" >>>> + $$emit$$"VMOVDQU YMM0,(RAX)\n\t" >>>> + $$emit$$"VMOVDQU YMM0,0x20(RAX)\n\t" >>>> + $$emit$$"ADD 0x40,RAX\n\t" >>>> + $$emit$$"# L_zero_64_bytes:\n\t" >>>> + $$emit$$"SUB 0x8,RCX\n\t" >>>> + $$emit$$"JGE L_loop\n\t" >>>> + $$emit$$"ADD 0x4,RCX\n\t" >>>> + $$emit$$"JL L_tail\n\t" >>>> + $$emit$$"VMOVDQU YMM0,(RAX)\n\t" >>>> + $$emit$$"ADD 0x20,RAX\n\t" >>>> + $$emit$$"SUB 0x4,RCX\n\t" >>>> + $$emit$$"# L_tail:\t# Clearing tail bytes\n\t" >>>> + $$emit$$"ADD 0x4,RCX\n\t" >>>> + $$emit$$"JLE L_end\n\t" >>>> + $$emit$$"DEC RCX\n\t" >>>> + $$emit$$"# L_sloop:\t# 8-byte short loop\n\t" >>>> + $$emit$$"VMOVQ XMM0,(RAX)\n\t" >>>> + $$emit$$"ADD 0x8,RAX\n\t" >>>> + $$emit$$"DEC RCX\n\t" >>>> + $$emit$$"JGE L_sloop\n\t" >>>> + $$emit$$"# L_end:\n\t" >>>> } else { >>>> $$emit$$"SHL ECX,1\t# Convert doublewords to words\n\t" >>>> $$emit$$"REP STOS\t# store EAX into [EDI++] while ECX--\n\t" >>>> @@ -11509,20 +11537,49 @@ >>>> $$emit$$"# DONE" >>>> %} >>>> ins_encode %{ >>>> - __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, false); >>>> - %} >>>> - ins_pipe( pipe_slow ); >>>> -%} >>>> - >>>> -instruct rep_stos_large(eCXRegI cnt, eDIRegP base, eAXRegI zero, >>>> Universe dummy, eFlagsReg cr) %{ >>>> + __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, >>>> + $tmp$$XMMRegister, false); >>>> + %} >>>> + ins_pipe( pipe_slow ); >>>> +%} >>>> + >>>> +instruct rep_stos_large(eCXRegI cnt, eDIRegP base, regD tmp, eAXRegI >>>> zero, Universe dummy, eFlagsReg cr) %{ >>>> predicate(((ClearArrayNode*)n)->is_large()); >>>> match(Set dummy (ClearArray cnt base)); >>>> - effect(USE_KILL cnt, USE_KILL base, KILL zero, KILL cr); >>>> + effect(USE_KILL cnt, USE_KILL base, TEMP tmp, KILL zero, KILL cr); >>>> format %{ $$template >>>> - $$emit$$"XOR EAX,EAX\t# ClearArray:\n\t" >>>> + if (!is_large || !(UseXMMForObjInit && UseUnalignedLoadStores)) { >>>> + $$emit$$"XOR EAX,EAX\t# ClearArray:\n\t" >>>> + } >>>> if (UseFastStosb) { >>>> $$emit$$"SHL ECX,3\t# Convert doublewords to bytes\n\t" >>>> $$emit$$"REP STOSB\t# store EAX into [EDI++] while ECX--\n\t" >>>> + } else if (UseXMMForObjInit && UseUnalignedLoadStores) { >>>> + $$emit$$"MOV RDI,RAX\n\t" >>>> + $$emit$$"VPXOR YMM0,YMM0,YMM0\n\t" >>>> + $$emit$$"JMPQ L_zero_64_bytes\n\t" >>>> + $$emit$$"# L_loop:\t# 64-byte LOOP\n\t" >>>> + $$emit$$"VMOVDQU YMM0,(RAX)\n\t" >>>> + $$emit$$"VMOVDQU YMM0,0x20(RAX)\n\t" >>>> + $$emit$$"ADD 0x40,RAX\n\t" >>>> + $$emit$$"# L_zero_64_bytes:\n\t" >>>> + $$emit$$"SUB 0x8,RCX\n\t" >>>> + $$emit$$"JGE L_loop\n\t" >>>> + $$emit$$"ADD 0x4,RCX\n\t" >>>> + $$emit$$"JL L_tail\n\t" >>>> + $$emit$$"VMOVDQU YMM0,(RAX)\n\t" >>>> + $$emit$$"ADD 0x20,RAX\n\t" >>>> + $$emit$$"SUB 0x4,RCX\n\t" >>>> + $$emit$$"# L_tail:\t# Clearing tail bytes\n\t" >>>> + $$emit$$"ADD 0x4,RCX\n\t" >>>> + $$emit$$"JLE L_end\n\t" >>>> + $$emit$$"DEC RCX\n\t" >>>> + $$emit$$"# L_sloop:\t# 8-byte short loop\n\t" >>>> + $$emit$$"VMOVQ XMM0,(RAX)\n\t" >>>> + $$emit$$"ADD 0x8,RAX\n\t" >>>> + $$emit$$"DEC RCX\n\t" >>>> + $$emit$$"JGE L_sloop\n\t" >>>> + $$emit$$"# L_end:\n\t" >>>> } else { >>>> $$emit$$"SHL ECX,1\t# Convert doublewords to words\n\t" >>>> $$emit$$"REP STOS\t# store EAX into [EDI++] while ECX--\n\t" >>>> @@ -11530,7 +11587,8 @@ >>>> $$emit$$"# DONE" >>>> %} >>>> ins_encode %{ >>>> - __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, true); >>>> + __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, >>>> + $tmp$$XMMRegister, true); >>>> %} >>>> ins_pipe( pipe_slow ); >>>> %} >>>> diff --git a/src/hotspot/cpu/x86/x86_64.ad b/src/hotspot/cpu/x86/x86_64.ad >>>> --- a/src/hotspot/cpu/x86/x86_64.ad >>>> +++ b/src/hotspot/cpu/x86/x86_64.ad >>>> @@ -10625,15 +10625,17 @@ >>>> >>>> // ======================================================================= >>>> // fast clearing of an array >>>> -instruct rep_stos(rcx_RegL cnt, rdi_RegP base, rax_RegI zero, Universe dummy, >>>> - rFlagsReg cr) >>>> +instruct rep_stos(rcx_RegL cnt, rdi_RegP base, regD tmp, rax_RegI zero, >>>> + Universe dummy, rFlagsReg cr) >>>> %{ >>>> predicate(!((ClearArrayNode*)n)->is_large()); >>>> match(Set dummy (ClearArray cnt base)); >>>> - effect(USE_KILL cnt, USE_KILL base, KILL zero, KILL cr); >>>> + effect(USE_KILL cnt, USE_KILL base, TEMP tmp, KILL zero, KILL cr); >>>> >>>> format %{ $$template >>>> - $$emit$$"xorq rax, rax\t# ClearArray:\n\t" >>>> + if (!is_large || !(UseXMMForObjInit && UseUnalignedLoadStores)) { >>>> + $$emit$$"xorq rax, rax\t# ClearArray:\n\t" >>>> + } >>>> $$emit$$"cmp InitArrayShortSize,rcx\n\t" >>>> $$emit$$"jg LARGE\n\t" >>>> $$emit$$"dec rcx\n\t" >>>> @@ -10646,35 +10648,91 @@ >>>> if (UseFastStosb) { >>>> $$emit$$"shlq rcx,3\t# Convert doublewords to bytes\n\t" >>>> $$emit$$"rep stosb\t# Store rax to *rdi++ while rcx--\n\t" >>>> + } else if (UseXMMForObjInit && UseUnalignedLoadStores) { >>>> + $$emit$$"mov rdi,rax\n\t" >>>> + $$emit$$"vpxor ymm0,ymm0,ymm0\n\t" >>>> + $$emit$$"jmpq L_zero_64_bytes\n\t" >>>> + $$emit$$"# L_loop:\t# 64-byte LOOP\n\t" >>>> + $$emit$$"vmovdqu ymm0,(rax)\n\t" >>>> + $$emit$$"vmovdqu ymm0,0x20(rax)\n\t" >>>> + $$emit$$"add 0x40,rax\n\t" >>>> + $$emit$$"# L_zero_64_bytes:\n\t" >>>> + $$emit$$"sub 0x8,rcx\n\t" >>>> + $$emit$$"jge L_loop\n\t" >>>> + $$emit$$"add 0x4,rcx\n\t" >>>> + $$emit$$"jl L_tail\n\t" >>>> + $$emit$$"vmovdqu ymm0,(rax)\n\t" >>>> + $$emit$$"add 0x20,rax\n\t" >>>> + $$emit$$"sub 0x4,rcx\n\t" >>>> + $$emit$$"# L_tail:\t# Clearing tail bytes\n\t" >>>> + $$emit$$"add 0x4,rcx\n\t" >>>> + $$emit$$"jle L_end\n\t" >>>> + $$emit$$"dec rcx\n\t" >>>> + $$emit$$"# L_sloop:\t# 8-byte short loop\n\t" >>>> + $$emit$$"vmovq xmm0,(rax)\n\t" >>>> + $$emit$$"add 0x8,rax\n\t" >>>> + $$emit$$"dec rcx\n\t" >>>> + $$emit$$"jge L_sloop\n\t" >>>> + $$emit$$"# L_end:\n\t" >>>> } else { >>>> $$emit$$"rep stosq\t# Store rax to *rdi++ while rcx--\n\t" >>>> } >>>> $$emit$$"# DONE" >>>> %} >>>> ins_encode %{ >>>> - __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, false); >>>> + __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, >>>> + $tmp$$XMMRegister, false); >>>> %} >>>> ins_pipe(pipe_slow); >>>> %} >>>> >>>> -instruct rep_stos_large(rcx_RegL cnt, rdi_RegP base, rax_RegI zero, >>>> Universe dummy, >>>> - rFlagsReg cr) >>>> +instruct rep_stos_large(rcx_RegL cnt, rdi_RegP base, regD tmp, rax_RegI zero, >>>> + Universe dummy, rFlagsReg cr) >>>> %{ >>>> predicate(((ClearArrayNode*)n)->is_large()); >>>> match(Set dummy (ClearArray cnt base)); >>>> - effect(USE_KILL cnt, USE_KILL base, KILL zero, KILL cr); >>>> + effect(USE_KILL cnt, USE_KILL base, TEMP tmp, KILL zero, KILL cr); >>>> >>>> format %{ $$template >>>> - $$emit$$"xorq rax, rax\t# ClearArray:\n\t" >>>> + if (!is_large || !(UseXMMForObjInit && UseUnalignedLoadStores)) { >>>> + $$emit$$"xorq rax, rax\t# ClearArray:\n\t" >>>> + } >>>> if (UseFastStosb) { >>>> $$emit$$"shlq rcx,3\t# Convert doublewords to bytes\n\t" >>>> $$emit$$"rep stosb\t# Store rax to *rdi++ while rcx--" >>>> + } else if (UseXMMForObjInit && UseUnalignedLoadStores) { >>>> + $$emit$$"mov rdi,rax\n\t" >>>> + $$emit$$"vpxor ymm0,ymm0,ymm0\n\t" >>>> + $$emit$$"jmpq L_zero_64_bytes\n\t" >>>> + $$emit$$"# L_loop:\t# 64-byte LOOP\n\t" >>>> + $$emit$$"vmovdqu ymm0,(rax)\n\t" >>>> + $$emit$$"vmovdqu ymm0,0x20(rax)\n\t" >>>> + $$emit$$"add 0x40,rax\n\t" >>>> + $$emit$$"# L_zero_64_bytes:\n\t" >>>> + $$emit$$"sub 0x8,rcx\n\t" >>>> + $$emit$$"jge L_loop\n\t" >>>> + $$emit$$"add 0x4,rcx\n\t" >>>> + $$emit$$"jl L_tail\n\t" >>>> + $$emit$$"vmovdqu ymm0,(rax)\n\t" >>>> + $$emit$$"add 0x20,rax\n\t" >>>> + $$emit$$"sub 0x4,rcx\n\t" >>>> + $$emit$$"# L_tail:\t# Clearing tail bytes\n\t" >>>> + $$emit$$"add 0x4,rcx\n\t" >>>> + $$emit$$"jle L_end\n\t" >>>> + $$emit$$"dec rcx\n\t" >>>> + $$emit$$"# L_sloop:\t# 8-byte short loop\n\t" >>>> + $$emit$$"vmovq xmm0,(rax)\n\t" >>>> + $$emit$$"add 0x8,rax\n\t" >>>> + $$emit$$"dec rcx\n\t" >>>> + $$emit$$"jge L_sloop\n\t" >>>> + $$emit$$"# L_end:\n\t" >>>> } else { >>>> $$emit$$"rep stosq\t# Store rax to *rdi++ while rcx--" >>>> } >>>> %} >>>> ins_encode %{ >>>> - __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, true); >>>> + __ clear_mem($base$$Register, $cnt$$Register, $zero$$Register, >>>> + $tmp$$XMMRegister, true); >>>> %} >>>> ins_pipe(pipe_slow); >>>> %} >>>> >>>> >>>> *********************** END of P A T C H ******************* >>>> >>>> >>>> Generated assembly code after change: >>>> ------------------------------------------------------ >>>> 0x00002b771c0016e4: mov %rdx,%rdi >>>> 0x00002b771c0016e7: add $0x10,%rdi >>>> 0x00002b771c0016eb: mov $0x14,%ecx >>>> 0x00002b771c0016f0: mov %rdi,%rax >>>> 0x00002b771c0016f3: vpxor %ymm0,%ymm0,%ymm0 >>>> 0x00002b771c0016f7: jmpq 0x00002b771c001709 >>>> 0x00002b771c0016fc: vmovdqu %ymm0,(%rax) >>>> 0x00002b771c001700: vmovdqu %ymm0,0x20(%rax) >>>> 0x00002b771c001705: add $0x40,%rax >>>> 0x00002b771c001709: sub $0x8,%rcx >>>> 0x00002b771c00170d: jge 0x00002b771c0016fc >>>> 0x00002b771c00170f: add $0x4,%rcx >>>> 0x00002b771c001713: jl 0x00002b771c001721 >>>> 0x00002b771c001715: vmovdqu %ymm0,(%rax) >>>> 0x00002b771c001719: add $0x20,%rax >>>> 0x00002b771c00171d: sub $0x4,%rcx >>>> 0x00002b771c001721: add $0x4,%rcx >>>> 0x00002b771c001725: jle 0x00002b771c001737 >>>> 0x00002b771c001727: dec %rcx >>>> 0x00002b771c00172a: vmovq %xmm0,(%rax) >>>> 0x00002b771c00172e: add $0x8,%rax >>>> 0x00002b771c001732: dec %rcx >>>> 0x00002b771c001735: jge 0x00002b771c00172a >>>> 0x00002b771c001737: >>>> >>>> >>>> I have done regression testing (changeset: >>>> 50250:04f9bb270ab8/24May2018) on 32-bit as well as 64-bit builds and >>>> didn't find any regressions. >>>> $make run-test TEST="tier1 tier2" JTREG="JOBS=1" >>>> CONF=linux-x86_64-normal-server-release >>>> >>>> Please let me know your comments. >>>> >>>> Regards, >>>> Rohit >>>> >>>> >>>> >>>> On Tue, Apr 24, 2018 at 12:33 AM, Vladimir Kozlov >>>> wrote: >>>>> Sorry for delay. >>>>> >>>>> In general you can't use arbitrary registers without letting know JIT >>>>> compilers that you use it. It will definitely cause problems. >>>>> You need to pass it as additional XMMRegister argument and described it as >>>>> TEMP in .ad files. >>>>> >>>>> See byte_array_inflate() as example. >>>>> >>>>> >>>>> On 4/11/18 7:25 PM, Rohit Arul Raj wrote: >>>>>>>> >>>>>>>> When I use XMM0 as a temporary register, the micro-benchmark crashes. >>>>>>>> Saving and Restoring the XMM0 register before and after use works >>>>>>>> fine. >>>>>>>> >>>>>>>> Looking at the "hotspot/src/cpu/x86/vm/x86.ad" file, XMM0 as with >>>>>>>> other XMM registers has been mentioned as Save-On-Call registers and >>>>>>>> on Linux ABI, no register is preserved across function calls though >>>>>>>> XMM0-XMM7 might hold parameters. So I assumed using XMM0 without >>>>>>>> saving/restoring should be fine. >>>>>>>> >>>>>>>> Is it incorrect use XMM* registers without saving/restoring them? >>>>>>>> Using XMM10 register as temporary register works fine without having >>>>>>>> to save and restore it. >>>>>> >>>>>> >>>>>> Any comments/suggestions on the usage of XMM* registers? >>>>>> >>>>>> Thanks, >>>>>> Rohit >>>>>> >>>>>> On Thu, Apr 5, 2018 at 11:38 PM, Vladimir Kozlov >>>>>> wrote: >>>>>>> >>>>>>> Good suggestion, Rohit >>>>>>> >>>>>>> I created new RFE. Please add you suggestion and performance data there: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201193 >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> >>>>>>> On 4/5/18 12:19 AM, Rohit Arul Raj wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> I was going through the C2 object initialization (zeroing) code based >>>>>>>> on the below bug entry: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146801 >>>>>>>> >>>>>>>> Right now, for longer lengths we use "rep stos" instructions on x86. I >>>>>>>> was experimenting with using XMM/YMM registers (on AMD EPYC processor) >>>>>>>> and found that they do improve performance for certain lengths: >>>>>>>> >>>>>>>> For lengths > 64 bytes - 512 bytes : improvement is in the range of 8% >>>>>>>> to >>>>>>>> 44% >>>>>>>> For lengths > 512bytes : some lengths show slight >>>>>>>> improvement in the range of 2% to 7%, others almost same as "rep stos" >>>>>>>> numbers. >>>>>>>> >>>>>>>> I have attached the complete performance data (data.txt) for reference . >>>>>>>> Can we add this as an user option similar to UseXMMForArrayCopy? >>>>>>>> >>>>>>>> I have used the same test case as in >>>>>>>> (http://cr.openjdk.java.net/~shade/8146801/benchmarks.jar) with >>>>>>>> additional sizes. >>>>>>>> >>>>>>>> Initial Patch: >>>>>>>> I haven't added the check for 32-bit mode as I need some help with the >>>>>>>> code (description given below the patch). >>>>>>>> The code is similar to the one used in array copy stubs >>>>>>>> (copy_bytes_forward). >>>>>>>> >>>>>>>> diff --git a/src/hotspot/cpu/x86/globals_x86.hpp >>>>>>>> b/src/hotspot/cpu/x86/globals_x86.hpp >>>>>>>> --- a/src/hotspot/cpu/x86/globals_x86.hpp >>>>>>>> +++ b/src/hotspot/cpu/x86/globals_x86.hpp >>>>>>>> @@ -150,6 +150,9 @@ >>>>>>>> product(bool, UseUnalignedLoadStores, false, >>>>>>>> \ >>>>>>>> "Use SSE2 MOVDQU instruction for Arraycopy") >>>>>>>> \ >>>>>>>> >>>>>>>> \ >>>>>>>> + product(bool, UseXMMForObjInit, false, >>>>>>>> \ >>>>>>>> + "Use XMM/YMM MOVDQU instruction for Object Initialization") >>>>>>>> \ >>>>>>>> + >>>>>>>> \ >>>>>>>> product(bool, UseFastStosb, false, >>>>>>>> \ >>>>>>>> "Use fast-string operation for zeroing: rep stosb") >>>>>>>> \ >>>>>>>> >>>>>>>> \ >>>>>>>> diff --git a/src/hotspot/cpu/x86/macroAssembler_x86.cpp >>>>>>>> b/src/hotspot/cpu/x86/macroAssembler_x86.cpp >>>>>>>> --- a/src/hotspot/cpu/x86/macroAssembler_x86.cpp >>>>>>>> +++ b/src/hotspot/cpu/x86/macroAssembler_x86.cpp >>>>>>>> @@ -7106,6 +7106,56 @@ >>>>>>>> if (UseFastStosb) { >>>>>>>> shlptr(cnt, 3); // convert to number of bytes >>>>>>>> rep_stosb(); >>>>>>>> + } else if (UseXMMForObjInit && UseUnalignedLoadStores) { >>>>>>>> + Label L_loop, L_sloop, L_check, L_tail, L_end; >>>>>>>> + push(base); >>>>>>>> + if (UseAVX >= 2) >>>>>>>> + vpxor(xmm10, xmm10, xmm10, AVX_256bit); >>>>>>>> + else >>>>>>>> + vpxor(xmm10, xmm10, xmm10, AVX_128bit); >>>>>>>> + >>>>>>>> + jmp(L_check); >>>>>>>> + >>>>>>>> + BIND(L_loop); >>>>>>>> + if (UseAVX >= 2) { >>>>>>>> + vmovdqu(Address(base, 0), xmm10); >>>>>>>> + vmovdqu(Address(base, 32), xmm10); >>>>>>>> + } else { >>>>>>>> + movdqu(Address(base, 0), xmm10); >>>>>>>> + movdqu(Address(base, 16), xmm10); >>>>>>>> + movdqu(Address(base, 32), xmm10); >>>>>>>> + movdqu(Address(base, 48), xmm10); >>>>>>>> + } >>>>>>>> + addptr(base, 64); >>>>>>>> + >>>>>>>> + BIND(L_check); >>>>>>>> + subptr(cnt, 8); >>>>>>>> + jccb(Assembler::greaterEqual, L_loop); >>>>>>>> + addptr(cnt, 4); >>>>>>>> + jccb(Assembler::less, L_tail); >>>>>>>> + // Copy trailing 32 bytes >>>>>>>> + if (UseAVX >= 2) { >>>>>>>> + vmovdqu(Address(base, 0), xmm10); >>>>>>>> + } else { >>>>>>>> + movdqu(Address(base, 0), xmm10); >>>>>>>> + movdqu(Address(base, 16), xmm10); >>>>>>>> + } >>>>>>>> + addptr(base, 32); >>>>>>>> + subptr(cnt, 4); >>>>>>>> + >>>>>>>> + BIND(L_tail); >>>>>>>> + addptr(cnt, 4); >>>>>>>> + jccb(Assembler::lessEqual, L_end); >>>>>>>> + decrement(cnt); >>>>>>>> + >>>>>>>> + BIND(L_sloop); >>>>>>>> + movptr(Address(base, 0), tmp); >>>>>>>> + addptr(base, 8); >>>>>>>> + decrement(cnt); >>>>>>>> + jccb(Assembler::greaterEqual, L_sloop); >>>>>>>> + >>>>>>>> + BIND(L_end); >>>>>>>> + pop(base); >>>>>>>> } else { >>>>>>>> NOT_LP64(shlptr(cnt, 1);) // convert to number of 32-bit words >>>>>>>> for 32-bit VM >>>>>>>> rep_stos(); >>>>>>>> >>>>>>>> >>>>>>>> When I use XMM0 as a temporary register, the micro-benchmark crashes. >>>>>>>> Saving and Restoring the XMM0 register before and after use works >>>>>>>> fine. >>>>>>>> >>>>>>>> Looking at the "hotspot/src/cpu/x86/vm/x86.ad" file, XMM0 as with >>>>>>>> other XMM registers has been mentioned as Save-On-Call registers and >>>>>>>> on Linux ABI, no register is preserved across function calls though >>>>>>>> XMM0-XMM7 might hold parameters. So I assumed using XMM0 without >>>>>>>> saving/restoring should be fine. >>>>>>>> >>>>>>>> Is it incorrect use XMM* registers without saving/restoring them? >>>>>>>> Using XMM10 register as temporary register works fine without having >>>>>>>> to save and restore it. >>>>>>>> >>>>>>>> Please let me know your comments. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Rohit >>>>>>>> >>>>>>> >>>>> From vladimir.kozlov at oracle.com Mon Jun 11 20:57:00 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Jun 2018 13:57:00 -0700 Subject: [11] RFR(M) 8201193: Use XMM/YMM for objects initialization Message-ID: http://cr.openjdk.java.net/~kvn/8201193/webrev.02/ https://bugs.openjdk.java.net/browse/JDK-8201193 Changes are contributed by Rohit from AMD. For new allocated java object on x86 C2 generates simple loop with a general (EAX) register store for small objects (< InitArrayShortSize) or 'rep stosq' instructions for big one. 'rep stosq' is not the best for initialization arrays because it has setup latency but it is only one instruction (very compact). Modern Intel processors have enhanced 'rep stosb' which addressed this issue and show very good performance. AMD processors don't have ERMS (Enhanced REP MOVSB/STOSB) support. To have good performance it is suggested to use SSE/AVX wide registers stores instead of 'rep stosq'. It shows better performance on AMD cpus. Tested with jdk-tier1, hs-tier1, hs-tier2, hs-precheckin-comp (-Xcomp), hs-graal on all x86 OSs. And using '-XX:-UseFastStosb -XX:+UseXMMForObjInit' flags combination to force new code generation. -- Thanks, Vladimir From vladimir.kozlov at oracle.com Mon Jun 11 21:05:10 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Jun 2018 14:05:10 -0700 Subject: RFR(L): 8203197: C2: consider all paths in loop body for loop predication In-Reply-To: References: <560a000a-01c1-eff8-7520-2dbb8460f041@oracle.com> <2adf40c0-6e38-e35c-c3f1-4829fca92181@oracle.com> Message-ID: <90f56743-cc89-fc20-1e4b-0181c377582d@oracle.com> On 6/11/18 6:03 AM, Roland Westrelin wrote: > > Hi Vladimir, > >>> With this: >>> >>> while() { >>> if (!null_check1) unc(null_check); >>> if (!range_check1) unc(range_check); >>> ... >>> if (some_condition) { // both branches profiled taken >>> if (!null_check2) unc(null_check); >>> if (!range_check2) unc(range_check); >>> ... >>> } >>> if (!null_check3) unc(null_check); >>> if (!range_check3) unc(range_check); >>> } >> >> In this example what will happen if *_check1 and *_check3 are moved from >> loop first (they are regular predicates). And then you found that >> "profiling" *_check2 can be moved. How you enforce order in such case? > > Predicates *_check1 and *_check3 are executed first because they are > part of the regular predicates block. Then only *_check2 are executed > because they're part of the profiling predicates block which is > after. My understanding is that it doesn't matter whether predicates are > executed in the same order they would be in the loop body because they > have no side effect anyway. Got it. > > Order of predicates matter in cases like: > > while() { > if (object == null) unc(null_check); > value = object.field; > if (value == null) unc(null_check); > result += value.field; > } > > Once they are out of loop, if (object == null) .. must be before if > (value == null) .. because the first check causes the object.field load > to be becomes loop independent and the second check depends on the > object.field load. So order matters, because there's a data dependence > between the 2 checks. So if there is dependency like this, the second check will stay in loop because it depends on values in loop. Okay. > >> No I was asking about this case when you have "profiling" case: >> >> while() { >> if (some_condition) { // both branches profiled taken >> if (!null_check) unc(null_check); >> if (!range_check) unc(range_check); >> break; >> } >> ... >> } >> >> Should you take special care in such case because such checks only >> executed on exit? > > Both checks are not in the loop. If we walk through the loop body from > the tail to the head we shouldn't encounter them, right? Right. I forgot that you scan checks from loop exit up. Thanks you for answering all my questions. Reviewed. Vladimir > > Roland. > From john.r.rose at oracle.com Mon Jun 11 21:09:04 2018 From: john.r.rose at oracle.com (John Rose) Date: Mon, 11 Jun 2018 14:09:04 -0700 Subject: [11] RFR(M) 8201193: Use XMM/YMM for objects initialization In-Reply-To: References: Message-ID: <3094A82F-0A9C-4D2F-BD11-2174EAAD282B@oracle.com> On Jun 11, 2018, at 1:57 PM, Vladimir Kozlov wrote: > > AMD processors don't have ERMS (Enhanced REP MOVSB/STOSB) support. To have good performance it is suggested to use SSE/AVX wide registers stores instead of 'rep stosq'. It shows better performance on AMD cpus. > > Tested with jdk-tier1, hs-tier1, hs-tier2, hs-precheckin-comp (-Xcomp), hs-graal on all x86 OSs. And using '-XX:-UseFastStosb -XX:+UseXMMForObjInit' flags combination to force new code generation. Good stuff. I have one suggestion: If possible, let's use macroassembler to generate the code from the AD files. It is a maintainability problem to have three copies of the same algorithm. I notice in particular that the AD file versions don't support UseAVX==1 while the assembler does. That's going to give some maintainer nightmares in a few years. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Mon Jun 11 22:04:25 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Jun 2018 15:04:25 -0700 Subject: [11] RFR(M) 8201193: Use XMM/YMM for objects initialization In-Reply-To: <3094A82F-0A9C-4D2F-BD11-2174EAAD282B@oracle.com> References: <3094A82F-0A9C-4D2F-BD11-2174EAAD282B@oracle.com> Message-ID: Hi John, thank you for looking on it. AD files have only 'format' code which produce output for PrintOptoAssembly flag. $$emit$$ is a new way to produce format %{ %} when you have conditions (global flags checks). All AD files calls the same one method MacroAssembler::clear_mem(). Yes, 'format' (PrintOptoAssembly) output will be different from generated assembly. But I thought that it is pseudo-assembly anyway (we never promised it will match assembly) and we can have slightly different output but make it simple in AD file. Regards, Vladimir On 6/11/18 2:09 PM, John Rose wrote: > On Jun 11, 2018, at 1:57 PM, Vladimir Kozlov > wrote: >> >> AMD processors don't have ERMS (Enhanced REP MOVSB/STOSB) support. To >> have good performance it is suggested to use SSE/AVX wide registers >> stores instead of 'rep stosq'. It shows better performance on AMD cpus. >> >> Tested with jdk-tier1, hs-tier1, hs-tier2, hs-precheckin-comp >> (-Xcomp), hs-graal on all x86 OSs. And using '-XX:-UseFastStosb >> -XX:+UseXMMForObjInit' flags combination to force new code generation. > > Good stuff. ?I have one suggestion: ?If possible, let's use > macroassembler to generate the code from the AD files. > It is a maintainability problem to have three copies of > the same algorithm. ?I notice in particular that the AD > file versions don't support UseAVX==1 while the assembler > does. ?That's going to give some maintainer nightmares > in a few years. > > ? John From vladimir.kozlov at oracle.com Tue Jun 12 01:15:15 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Jun 2018 18:15:15 -0700 Subject: [11] RFR(S) 8204113: Upgrade linker used in AOT tests to be same version as build toolchain Message-ID: http://cr.openjdk.java.net/~kvn/8204113/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8204113 AOT tests need a local linker to generate AOT libraries. They load devkits from our infrastructure when there is no local linker on testing machine. The names of devkits are hardcoded in AotCompiler.java (java wrapper which launches 'jaotc' tool). We recently updated compilers for JDK 11. As result devkit names in AotCompiler.java should be updated too. Tested by running AOT tests on all our supported platforms. -- Thanks, Vladimir From igor.ignatyev at oracle.com Tue Jun 12 01:21:16 2018 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Mon, 11 Jun 2018 18:21:16 -0700 Subject: [11] RFR(S) 8204113: Upgrade linker used in AOT tests to be same version as build toolchain In-Reply-To: References: Message-ID: Hi Vladimir, The fix looks good to me. ? Igor > On Jun 11, 2018, at 6:15 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/8204113/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8204113 > > AOT tests need a local linker to generate AOT libraries. They load devkits from our infrastructure when there is no local linker on testing machine. The names of devkits are hardcoded in AotCompiler.java (java wrapper which launches 'jaotc' tool). > > We recently updated compilers for JDK 11. As result devkit names in AotCompiler.java should be updated too. > > Tested by running AOT tests on all our supported platforms. > > -- > Thanks, > Vladimir From vladimir.kozlov at oracle.com Tue Jun 12 01:35:07 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Jun 2018 18:35:07 -0700 Subject: [11] RFR(S) 8204113: Upgrade linker used in AOT tests to be same version as build toolchain In-Reply-To: References: Message-ID: <6c0f5c04-4209-8e5e-89e3-7844c699397e@oracle.com> Thank you, Igor Vladimir On 6/11/18 6:21 PM, Igor Ignatev wrote: > Hi Vladimir, > > The fix looks good to me. > > ? Igor > >> On Jun 11, 2018, at 6:15 PM, Vladimir Kozlov wrote: >> >> http://cr.openjdk.java.net/~kvn/8204113/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8204113 >> >> AOT tests need a local linker to generate AOT libraries. They load devkits from our infrastructure when there is no local linker on testing machine. The names of devkits are hardcoded in AotCompiler.java (java wrapper which launches 'jaotc' tool). >> >> We recently updated compilers for JDK 11. As result devkit names in AotCompiler.java should be updated too. >> >> Tested by running AOT tests on all our supported platforms. >> >> -- >> Thanks, >> Vladimir > From adinn at redhat.com Tue Jun 12 09:02:29 2018 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 12 Jun 2018 10:02:29 +0100 Subject: RFR(S): 8204606 - [Aarch64] SIGSEGVs caused by C1 because of improper register usage In-Reply-To: References: Message-ID: <50bc753c-ffbd-3a1a-e2dc-aca85d7db408@redhat.com> On 11/06/18 13:49, Stuart Monteith wrote: > Here is Andrew's patch to correct a poor choice of registers in JDK-8201593. > > http://cr.openjdk.java.net/~smonteith/8204606/webrev/ > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8204606 > > Retested with C1 on tier1 tests. Yes, that looks good. Thanks. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From stuart.monteith at linaro.org Tue Jun 12 09:09:43 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Tue, 12 Jun 2018 10:09:43 +0100 Subject: RFR(S): 8204606 - [Aarch64] SIGSEGVs caused by C1 because of improper register usage In-Reply-To: <50bc753c-ffbd-3a1a-e2dc-aca85d7db408@redhat.com> References: <50bc753c-ffbd-3a1a-e2dc-aca85d7db408@redhat.com> Message-ID: Thanks Andrew. Shall I push a nice patch with "reviewed-by", etc? It should include "Contributed-by: aph at redhat.com" On 12 June 2018 at 10:02, Andrew Dinn wrote: > On 11/06/18 13:49, Stuart Monteith wrote: >> Here is Andrew's patch to correct a poor choice of registers in JDK-8201593. >> >> http://cr.openjdk.java.net/~smonteith/8204606/webrev/ >> >> CR: >> >> https://bugs.openjdk.java.net/browse/JDK-8204606 >> >> Retested with C1 on tier1 tests. > Yes, that looks good. Thanks. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Tue Jun 12 09:18:04 2018 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 12 Jun 2018 10:18:04 +0100 Subject: RFR(S): 8204606 - [Aarch64] SIGSEGVs caused by C1 because of improper register usage In-Reply-To: References: <50bc753c-ffbd-3a1a-e2dc-aca85d7db408@redhat.com> Message-ID: <16c36afe-bfcd-5825-8210-12d36480e831@redhat.com> On 12/06/18 10:09, Stuart Monteith wrote: > Shall I push a nice patch with "reviewed-by", etc? It should include > "Contributed-by: aph at redhat.com" I'll commit the patch from the webrev with Andrew Haley as the patch author and the two of us as reviewers -- you did the testing so that counts as an unofficial review and we don't need a second official reviewer since this is AArch64-specific. I think that would be more appropriate than adding a contributed-by for Andrew. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From stuart.monteith at linaro.org Tue Jun 12 09:23:30 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Tue, 12 Jun 2018 10:23:30 +0100 Subject: RFR(S): 8204606 - [Aarch64] SIGSEGVs caused by C1 because of improper register usage In-Reply-To: <16c36afe-bfcd-5825-8210-12d36480e831@redhat.com> References: <50bc753c-ffbd-3a1a-e2dc-aca85d7db408@redhat.com> <16c36afe-bfcd-5825-8210-12d36480e831@redhat.com> Message-ID: That's even better, thanks. I assumed that mercurial wouldn't allow you to do what you suggested. On 12 June 2018 at 10:18, Andrew Dinn wrote: > On 12/06/18 10:09, Stuart Monteith wrote: >> Shall I push a nice patch with "reviewed-by", etc? It should include >> "Contributed-by: aph at redhat.com" > > I'll commit the patch from the webrev with Andrew Haley as the patch > author and the two of us as reviewers -- you did the testing so that > counts as an unofficial review and we don't need a second official > reviewer since this is AArch64-specific. > > I think that would be more appropriate than adding a contributed-by for > Andrew. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From tobias.hartmann at oracle.com Tue Jun 12 09:36:11 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 12 Jun 2018 11:36:11 +0200 Subject: RFR: 8203344: Make C1 leal patchable on SPARC In-Reply-To: <5AFD3F9F.8020202@oracle.com> References: <5AFD3F9F.8020202@oracle.com> Message-ID: Hi Erik, looks good to me as well. Thanks, Tobias On 17.05.2018 10:38, Erik ?sterlund wrote: > Hi, > > In C1, address resolution of an accessed field is not always possible, because the offset of the > class of the object being accessed, has not yet been loaded. In ZGC, we use lea to resolve the > address of fields. Therefore, the lea instruction needs to be patchable for ZGC. This enhancement > aims to add support for such patching on SPARC. > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8203344/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8203344 > > Thanks, > /Erik From erik.osterlund at oracle.com Tue Jun 12 09:42:22 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 12 Jun 2018 11:42:22 +0200 Subject: RFR: 8203344: Make C1 leal patchable on SPARC In-Reply-To: References: <5AFD3F9F.8020202@oracle.com> Message-ID: <5B1F957E.5060406@oracle.com> Hi Tobias, Thank you for the review. Thanks, /Erik On 2018-06-12 11:36, Tobias Hartmann wrote: > Hi Erik, > > looks good to me as well. > > Thanks, > Tobias > > On 17.05.2018 10:38, Erik ?sterlund wrote: >> Hi, >> >> In C1, address resolution of an accessed field is not always possible, because the offset of the >> class of the object being accessed, has not yet been loaded. In ZGC, we use lea to resolve the >> address of fields. Therefore, the lea instruction needs to be patchable for ZGC. This enhancement >> aims to add support for such patching on SPARC. >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8203344/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8203344 >> >> Thanks, >> /Erik From tobias.hartmann at oracle.com Tue Jun 12 09:47:33 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 12 Jun 2018 11:47:33 +0200 Subject: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes performance regression In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A907415DC@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A9073FB24@ORSMSX106.amr.corp.intel.com> <04aa0928-9be8-69bc-9a40-8e0a4436b176@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A90740968@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A907415AB@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A907415DC@ORSMSX106.amr.corp.intel.com> Message-ID: Hi Vivek, On 11.06.2018 20:51, Deshpande, Vivek R wrote: > http://cr.openjdk.java.net/~vdeshpande/SubwordFix/webrev.01/ This looks good to me as well. I've just submitted performance testing and premature results look great (+3.17% on SpecJVM2008 MPEG). I'll let you know once the runs are completed. Please set the status of the bug to "In Progress". Best regards, Tobias From rwestrel at redhat.com Tue Jun 12 12:28:11 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 12 Jun 2018 14:28:11 +0200 Subject: [11] RFR(M): 8203915: Induction variable of over-unrolled loop conflicts with range checks In-Reply-To: References: Message-ID: Hi Tobias, > To prevent early folding of the expression, I left the Opaque1Nodes in > (they are removed after loop optimizations). What Opaque1 nodes do you leave in? Roland. From tobias.hartmann at oracle.com Tue Jun 12 12:52:31 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 12 Jun 2018 14:52:31 +0200 Subject: [11] RFR(M): 8203915: Induction variable of over-unrolled loop conflicts with range checks In-Reply-To: References: Message-ID: <8b6f1b09-8a1f-b29a-d0a5-a67a3635f95c@oracle.com> Hi Roland, On 12.06.2018 14:28, Roland Westrelin wrote: > What Opaque1 nodes do you leave in? I should have added that I'm not copying the skeleton predicate from the pre-loop because the pre-loop might not longer exist when we perform unrolling of the main loop. Instead, I'm copying a skeleton predicate which still has the Opaque1Node once to before the main loop that is then updated during loop unrolling according to the new stride. When updating the init+stride predicate during loop unrolling, I leave the Opaque1Node that guards this expression in because otherwise the constant expression might be folded and we cannot update it during the next iteration of unrolling. Thanks, Tobias From rwestrel at redhat.com Tue Jun 12 13:05:13 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 12 Jun 2018 15:05:13 +0200 Subject: [11] RFR(M): 8203915: Induction variable of over-unrolled loop conflicts with range checks In-Reply-To: <8b6f1b09-8a1f-b29a-d0a5-a67a3635f95c@oracle.com> References: <8b6f1b09-8a1f-b29a-d0a5-a67a3635f95c@oracle.com> Message-ID: > I should have added that I'm not copying the skeleton predicate from the pre-loop because the > pre-loop might not longer exist when we perform unrolling of the main loop. Instead, I'm copying a > skeleton predicate which still has the Opaque1Node once to before the main loop that is then updated > during loop unrolling according to the new stride. > > When updating the init+stride predicate during loop unrolling, I leave the Opaque1Node that guards > this expression in because otherwise the constant expression might be folded and we cannot update it > during the next iteration of unrolling. Thanks. Change looks good to me. Roland. From rwestrel at redhat.com Tue Jun 12 13:20:44 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 12 Jun 2018 15:20:44 +0200 Subject: RFR(M): 8204240: Extend MDO to allow more reasons to be recorded per bci Message-ID: http://cr.openjdk.java.net/~roland/8204240/webrev.00/ The number of traps that can be recorded per bci is currently limited to 8. This patch changes the layout of the DataLayout header so more traps can be recorded per bci. This change was part of 8203197: "C2: consider all paths in loop body for loop predication" but I was asked to integrate separately. That review thread has some discussion about that change. Note this patch modifies platform specific code. I verified x86 (32 and 64 bits), aarch64. Sparc is ok AFAICT but I couldn't verify it. For PPC and arm32 I will need someone to take a closer look. Roland. From tobias.hartmann at oracle.com Tue Jun 12 13:26:16 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 12 Jun 2018 15:26:16 +0200 Subject: [11] RFR(M): 8203915: Induction variable of over-unrolled loop conflicts with range checks In-Reply-To: References: <8b6f1b09-8a1f-b29a-d0a5-a67a3635f95c@oracle.com> Message-ID: <07818d84-c6dd-ec1e-2694-5b7365c1f6b1@oracle.com> On 12.06.2018 15:05, Roland Westrelin wrote: > Thanks. Change looks good to me. Thanks Roland! Best regards, Tobias From erik.joelsson at oracle.com Tue Jun 12 13:41:00 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 12 Jun 2018 06:41:00 -0700 Subject: [11] RFR(S) 8204113: Upgrade linker used in AOT tests to be same version as build toolchain In-Reply-To: References: Message-ID: <8e132944-f7df-708d-1b84-8bd68385217e@oracle.com> Looks good. /Erik On 2018-06-11 18:15, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8204113/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8204113 > > AOT tests need a local linker to generate AOT libraries. They load > devkits from our infrastructure when there is no local linker on > testing machine. The names of devkits are hardcoded in > AotCompiler.java (java wrapper which launches 'jaotc' tool). > > We recently updated compilers for JDK 11. As result devkit names in > AotCompiler.java should be updated too. > > Tested by running AOT tests on all our supported platforms. > From vladimir.kozlov at oracle.com Tue Jun 12 14:26:48 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Jun 2018 07:26:48 -0700 Subject: [11] RFR(S) 8204113: Upgrade linker used in AOT tests to be same version as build toolchain In-Reply-To: <8e132944-f7df-708d-1b84-8bd68385217e@oracle.com> References: <8e132944-f7df-708d-1b84-8bd68385217e@oracle.com> Message-ID: <128f99fd-cdc2-fc0d-56d6-2eac213a7ae2@oracle.com> Thank you, Erik Vladimir On 6/12/18 6:41 AM, Erik Joelsson wrote: > Looks good. > > /Erik > > > On 2018-06-11 18:15, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8204113/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8204113 >> >> AOT tests need a local linker to generate AOT libraries. They load >> devkits from our infrastructure when there is no local linker on >> testing machine. The names of devkits are hardcoded in >> AotCompiler.java (java wrapper which launches 'jaotc' tool). >> >> We recently updated compilers for JDK 11. As result devkit names in >> AotCompiler.java should be updated too. >> >> Tested by running AOT tests on all our supported platforms. >> > From vivek.r.deshpande at intel.com Tue Jun 12 16:51:55 2018 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Tue, 12 Jun 2018 16:51:55 +0000 Subject: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes performance regression In-Reply-To: References: <53E8E64DB2403849AFD89B7D4DAC8B2A9073FB24@ORSMSX106.amr.corp.intel.com> <04aa0928-9be8-69bc-9a40-8e0a4436b176@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A90740968@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A907415AB@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A907415DC@ORSMSX106.amr.corp.intel.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A90742C0C@ORSMSX106.amr.corp.intel.com> Hi Tobias Thanks for testing it. I have changed the status to - In Progress. Regards, Vivek -----Original Message----- From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] Sent: Tuesday, June 12, 2018 2:48 AM To: Deshpande, Vivek R ; Vladimir Kozlov ; hotspot-compiler-dev at openjdk.java.net compiler Subject: Re: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes performance regression Hi Vivek, On 11.06.2018 20:51, Deshpande, Vivek R wrote: > http://cr.openjdk.java.net/~vdeshpande/SubwordFix/webrev.01/ This looks good to me as well. I've just submitted performance testing and premature results look great (+3.17% on SpecJVM2008 MPEG). I'll let you know once the runs are completed. Please set the status of the bug to "In Progress". Best regards, Tobias From paul.sandoz at oracle.com Tue Jun 12 17:12:39 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 12 Jun 2018 10:12:39 -0700 Subject: RFC: Experiment in accessing/managing persistent memory from Java In-Reply-To: References: <02FCFB8477C4EF43A2AD8E0C60F3DA2B9EE74C14@FMSMSX126.amr.corp.intel.com> Message-ID: <382F6C6B-D097-4DF2-A8AB-FBCB60C5D3F5@oracle.com> Hi Jonathan, > On Jun 8, 2018, at 3:59 AM, Jonathan Halliday wrote: > > > Hi Paul > > Looks like we're all on the same page regarding the basic approach of using a small API and making the critical bits intrinsic. We perhaps have some way to go on exactly what that API looks like in terms of the classes and methods, but iterating on it by discussion of a JEP seems like the best way forward. The important thing from my perspective is that so far nobody has come forward with a use case that is not covered by the proposed primitives. So it's a small API, but not too small. Yes, a smallish API we can iterate on. > > As far a tweaks go, we have considered making the low level primitive method / intrinsic just a flushCacheline(base_address), since the arithmetic and loop for writing flush(from,to) in terms of that low level op is something that can be optimized fine by the JIT already. Though that does mean exposing the cache line size to the Java layer, whereas currently it's only visible in the C code. > That?s ok. The simpler the intrinsics while relying on Java code + JIT would be my generally preferred pattern. > > My own background and focus is transactions systems, so I'm more about the speed and fault tolerance than the capacity, but I can see long vs. int being of interest to our Infinispan data grid team and likewise for e.g. Oracle Coherence or databases like Cassandra. OTOH it's not uncommon to prefer moderately sized files and shard over them, which sidesteps the issue. > Ok, which is conveniently how developers currently work around the issue of mapping large files :-) > Utility code to assist with fine-grained memory management within the buffer/file may be more useful than support for really large buffers, since they tend to be used with some form of internal block/heap structure anyhow, rather than to hold very large objects. Providing that may be the role of a 3rd party pure Java library like PCJ though, rather than something we want in the JDK itself at this early stage. The researcher in me is kinda interested in how much of the memory allocation and GC code can be re-purposed here though... > > What's the intended timeline on long buffer indexing at present? Unsure, but it's probably something we want to solve soonish. > My feeling is a pmem API JEP is probably targeting around JDK 13, but we're flexible on that. Note that the JEP process can be started before then and JEPs are not targeted to a release until ready, if its ready sooner great! otherwise later. Keeping such a JEP focused on the mapping/flushing of BBs for NVM would be my recommendation rather than expanding its scope. > We may also want to look at related enhancements like unmapping buffers. I think those pieces are sufficient decoupled that they won't be dependencies for the pmem API though, unlike other factors such as the availability of test hardware. > That?s tricky! We have been through many discussions over the years on how to achieve this without much resolution. Andrew Haley came up with an interesting solution which IIRC requires the deallocating/unmapping thread to effectively reach safe point and wait for all other threads to pass through a check point. Project Panama is looking at the explicit scoping of resources, perhaps also resources that are thread confined or owned. My sense is Project Panama will eventually push strongly on this area and that?s where we should focus our efforts. Thanks, Paul. From aph at redhat.com Tue Jun 12 17:58:00 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 12 Jun 2018 18:58:00 +0100 Subject: RFC: Experiment in accessing/managing persistent memory from Java In-Reply-To: <382F6C6B-D097-4DF2-A8AB-FBCB60C5D3F5@oracle.com> References: <02FCFB8477C4EF43A2AD8E0C60F3DA2B9EE74C14@FMSMSX126.amr.corp.intel.com> <382F6C6B-D097-4DF2-A8AB-FBCB60C5D3F5@oracle.com> Message-ID: <7defb48e-c77a-4ca5-119e-bacd7cf9aa93@redhat.com> On 06/12/2018 06:12 PM, Paul Sandoz wrote: > >> We may also want to look at related enhancements like unmapping >> buffers. I think those pieces are sufficient decoupled that they >> won't be dependencies for the pmem API though, unlike other factors >> such as the availability of test hardware. >> > That?s tricky! We have been through many discussions over the years > on how to achieve this without much resolution. Andrew Haley came up > with an interesting solution which IIRC requires the > deallocating/unmapping thread to effectively reach safe point and > wait for all other threads to pass through a check point. Project > Panama is looking at the explicit scoping of resources, perhaps also > resources that are thread confined or owned. My sense is Project > Panama will eventually push strongly on this area and that?s where > we should focus our efforts. Yeah, perhaps so. I've been waiting to come up for air to have enough time to handle the ByteBuffer.unmap() bug. I can see the advantage of handling it at a static language level, but the solutions aren't necessarily exclusive. -- 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 13 01:51:22 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Jun 2018 18:51:22 -0700 Subject: RFR(M): 8204240: Extend MDO to allow more reasons to be recorded per bci In-Reply-To: References: Message-ID: Looks good. I will testing on our platforms and let you know. Thanks, Vladimir On 6/12/18 6:20 AM, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8204240/webrev.00/ > > The number of traps that can be recorded per bci is currently limited to > 8. This patch changes the layout of the DataLayout header so more traps > can be recorded per bci. > > This change was part of 8203197: "C2: consider all paths in loop body > for loop predication" but I was asked to integrate separately. That > review thread has some discussion about that change. > > Note this patch modifies platform specific code. I verified x86 (32 and > 64 bits), aarch64. Sparc is ok AFAICT but I couldn't verify it. For PPC > and arm32 I will need someone to take a closer look. > > Roland. > From tobias.hartmann at oracle.com Wed Jun 13 06:56:29 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 13 Jun 2018 08:56:29 +0200 Subject: [11] RFR(M): 8203915: Induction variable of over-unrolled loop conflicts with range checks In-Reply-To: References: Message-ID: <485521e2-d490-1efa-2e57-ca90eb0b8099@oracle.com> Hi, final testing revealed a problem with my patch: if the stride is negative, we need check "2 * stride + 1" instead of "2 * stride - 1". Here's the incremental webrev: http://cr.openjdk.java.net/~thartmann/8203915/webrev.inc/ All tests pass and benchmarking shows no regressions. Thanks, Tobias On 07.06.2018 15:39, Tobias Hartmann wrote: > Hi, > > please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8203915 > http://cr.openjdk.java.net/~thartmann/8203915/webrev.00/ > > The general problem is that a range check predicated loop is over-unrolled such that the type of the > loop induction variable is out of the statically known bounds of the array. As a result, the > CastII/ConvI2L nodes are replaced by TOP and the memory graph is corrupted because the control path > to this dead code is not removed. This is because there are no range checks in the loop but only > predicates before the main loop. > > For example, in TestOverunrolling::test5() we unroll the inner for-loop 16 times because the loop > limit 'i' is not statically known. The last iArr access in the unrolled main loop body therefore has > the type [6+stride-1, int] with stride = 16 which is out of the statically known array size 8. After > vectorization, we crash in the matcher because the vectorized result += ... computation has a TOP > memory input. Test3 and test4 trigger the same problem but fail at different stages during compilation. > > This is very similar to what Roland fixed with skeleton predicates in JDK-8193130 [1]. However, this > fix only added checks to verify that the initial value of the induction variable is in bounds but > not that init+stride-1 is in bounds as well. > > I've changed the skeleton predicate code to not only add a check for init another copy of the skeleton predicate to before the main loop. Whenever we now unroll the loop and > therefore increase the stride, this predicate copy is updated to check init+stride-1 prevent early folding of the expression, I left the Opaque1Nodes in (they are removed after loop > optimizations). > > The reason why this issue only showed up now (JDK 9 and 10 are also affected) is because > vectorization of loops with safepoints was fixed by JDK-8200477 in JDK 11. > > Thanks to Roland for discussing this! > > Best regards, > Tobias > > [1] https://bugs.openjdk.java.net/browse/JDK-8193130 > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-December/027938.html > From rwestrel at redhat.com Wed Jun 13 09:03:35 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 13 Jun 2018 11:03:35 +0200 Subject: RFR(M): 8204240: Extend MDO to allow more reasons to be recorded per bci In-Reply-To: References: Message-ID: > Looks good. I will testing on our platforms and let you know. Thanks for the review and testing. Roland. From rwestrel at redhat.com Wed Jun 13 12:57:32 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 13 Jun 2018 14:57:32 +0200 Subject: [11] RFR(M): 8203915: Induction variable of over-unrolled loop conflicts with range checks In-Reply-To: <485521e2-d490-1efa-2e57-ca90eb0b8099@oracle.com> References: <485521e2-d490-1efa-2e57-ca90eb0b8099@oracle.com> Message-ID: > final testing revealed a problem with my patch: if the stride is negative, we need check "2 * stride > + 1" instead of "2 * stride - 1". Here's the incremental webrev: > http://cr.openjdk.java.net/~thartmann/8203915/webrev.inc/ Looks ok to me. Roland. From tobias.hartmann at oracle.com Wed Jun 13 13:07:50 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 13 Jun 2018 15:07:50 +0200 Subject: [11] RFR(M): 8203915: Induction variable of over-unrolled loop conflicts with range checks In-Reply-To: References: <485521e2-d490-1efa-2e57-ca90eb0b8099@oracle.com> Message-ID: <53c0f184-b9b1-f203-d9f4-d8664f0a5905@oracle.com> Thanks again, Roland. Best regards, Tobias On 13.06.2018 14:57, Roland Westrelin wrote: > >> final testing revealed a problem with my patch: if the stride is negative, we need check "2 * stride >> + 1" instead of "2 * stride - 1". Here's the incremental webrev: >> http://cr.openjdk.java.net/~thartmann/8203915/webrev.inc/ > > Looks ok to me. > > Roland. > From vladimir.kozlov at oracle.com Wed Jun 13 17:03:07 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Jun 2018 10:03:07 -0700 Subject: [11] RFR(M): 8203915: Induction variable of over-unrolled loop conflicts with range checks In-Reply-To: References: <485521e2-d490-1efa-2e57-ca90eb0b8099@oracle.com> Message-ID: <2c07a6c5-18a9-108e-bcf9-6b2fb544104f@oracle.com> On 6/13/18 5:57 AM, Roland Westrelin wrote: > >> final testing revealed a problem with my patch: if the stride is negative, we need check "2 * stride >> + 1" instead of "2 * stride - 1". Here's the incremental webrev: >> http://cr.openjdk.java.net/~thartmann/8203915/webrev.inc/ > > Looks ok to me. +1 Vladimir > > Roland. > From vladimir.kozlov at oracle.com Wed Jun 13 17:14:52 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Jun 2018 10:14:52 -0700 Subject: [11] RFR(XS) 8202948: C2: assert(init_offset >= 0) failed: positive offset from object start Message-ID: <30d6bc63-cdc7-7f71-ef1a-e3b6e45244fb@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8202948 Predicates and Range checks before main loop will not help since they are runtime checks and limit is not constant. The problem happens during compilation because vectorization is attempted for over-unrolling loop which will not be executed in runtime (dead loop). Stride is negative (-3) value and initial is 2 - loop will be executed at least once (or never) because of other conditions in code. C2 did not recognize this because the test fails only with -Xcomp when profiling data is no available (it passed without -Xcomp). Simplest fix is to convert the assert into compilation check which will skip superword optimization in such case. diff -r 0d47e89382ed src/hotspot/share/opto/superword.cpp --- a/src/hotspot/share/opto/superword.cpp +++ b/src/hotspot/share/opto/superword.cpp @@ -887,7 +887,9 @@ if (init_nd->is_Con() && p.invar() == NULL) { int init = init_nd->bottom_type()->is_int()->get_con(); int init_offset = init * p.scale_in_bytes() + offset; - assert(init_offset >= 0, "positive offset from object start"); + if (init_offset < 0) { // negative offset from object start? + return false; // may happen in dead loop + } if (vw % span == 0) { // If vm is a multiple of span, we use formula (1). if (span > 0) { Test passed with and without Predicates with this fix. Tested with tier1, tier2, precheckin-xcomp -- Thanks, Vladimir From dmitrij.pochepko at bell-sw.com Wed Jun 13 17:44:30 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 13 Jun 2018 20:44:30 +0300 Subject: RFR: 8189105: AARCH64: create intrinsic for sin and cos In-Reply-To: References: <4de41b0c-e318-c70f-a864-4f6c8bd14297@redhat.com> <5B12CAEF.8050105@bell-sw.com> <2bd89c11-d234-ceae-3b04-4c547ef5836c@redhat.com> Message-ID: Andrew, thank you for a detailed outline of the necessary changes. I'll get back to you in a few days with an updated version. Thanks, Dmitrij On 11.06.2018 18:07, Andrew Dinn wrote: > Hi Dimitrij, > > Apologies for not responding -- I have only just returned from holiday. > > On 04/06/18 16:50, Dmitrij Pochepko wrote: >> On 04.06.2018 13:59, Andrew Haley wrote: >>>> . . . >>>> > I don't really know how to review this. It's a lot of hand-carved >>>> > assembly code and it's very hard to read. It'd need to be very >>>> > thoroughly tested. >>>> >>>> It is a vectorized version of existing C code algorithm, >>> Which existing C code algorithm? >> this is a hotspot copy of fdlibm trigonometric functions in >> hotspot/src/share/runtime/sharedRuntimeTrig.cpp >> I added respective comment in intrinsic. > Thanks for providing this code and the additional comments. However, I > don't think this approaches anywhere near the requirements Andrew set > out in his initial review, requirements which I agree are absolutely > necessary. I can only repeat his recommendation that you look at the > Montgomery multiply code in stubGenerator_aarch64.cpp to get an idea of > the sort of detail that is needed to satisfactorily document an > implementation this complex. > > The two most important goals are to be able to > > 1) review the current code with a high degree of confidence that it is > correct > > 2) maintain this code without imposing an intolerable burden on > developers who might need to check it months from now > > Review will only be possible if the code is written in a way that makes > what it is doing clear enough to be able to judge that it is correct. > That is far from being the case as it stands. Saying it is the same as > the C code modulo a few optimizations is nothing like enough. Visibly > identifying how the various register values and insns/blocks correspond > to their original C source lines would be a big improvement. Explaining > what these values represent as they are updated and what each insn/block > achieves would be even better. Better still would be to define macro > instructions in the assembler so that the generation can be viewed at > the level of more abstract operations that reflect the numerical and > mathematical transformations being performed. Finally, relating the > whole to the underlying mathematical theory would be the cherry on the > cake. Note that the original C code has comments with this level of > detail and that code is far easier to follow than this assembler. So, > all the more reason for the same or more commentary here. > > Maintenance is an issue *whether or not* the current code is correct. > Someone will inevitably at some point be faced with the following > dilemma: possibly, locate a bug in the current implementation; or, more > likely, reassure yourself that the code is correct before proceeding to > diagnose the real problem elsewhere. The current code is a fly-trap and > a piece of software as large and mature as OpenJDK has more than enough > complexity without adding fly-traps into the mix. > > Note that neither of these goals are going to be met by testing, no > matter how exhaustive. Also, don't feel singled out by these reviews. > Andrew and I are not suggesting this as a matter of form. We know how > important this is because we have tested and reviewed*** an immense > amount of much less complex code in getting this port to where it is now > and learned a great deal from that experience. We have only been able to > identify and fix the many bugs that have turned up /after/ extensive > review because we tried very hard to keep the code as clear and well > documented as possible (n.b. we also added lots of asserts to validate > assumptions). > > That is not something specific that we did off our own bat. It is > actually the expected standard for JVM code, shared or cpu-specific. > That standard has not always been lived up to but it is steadily > improving. The Intel versions of these intrinsics in the x86 are indeed > a notable lapse (I believe they were culled from Intel's C compiler > output). However, their failings do not excuse repeating the same > mistake for AArch64. > > *** n.b contrary to assumptions expressed in some recent threads Andrew > is not the only reviewer for AArch64 code. In particular, every line of > his code has been reviewed by me and/or a handful of other reviewers > from the day we started this port. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From vladimir.kozlov at oracle.com Wed Jun 13 19:31:46 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Jun 2018 12:31:46 -0700 Subject: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes performance regression In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A90742C0C@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A9073FB24@ORSMSX106.amr.corp.intel.com> <04aa0928-9be8-69bc-9a40-8e0a4436b176@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A90740968@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A907415AB@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A907415DC@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A90742C0C@ORSMSX106.amr.corp.intel.com> Message-ID: <12e43222-4cb8-a5a0-83b6-8790a74f326c@oracle.com> Hi Vivek, Performance testing is finished and we see regressions. SPECjvm2008-SOR.small with Parallel GC - 5-7% on all platfroms. There is also 3-5% regression in MonteCarlo with G1 (we did not test with Praallel GC - it may also regress). Please investigate it. Thanks, Vladimir On 6/12/18 9:51 AM, Deshpande, Vivek R wrote: > Hi Tobias > > Thanks for testing it. I have changed the status to - In Progress. > > Regards, > Vivek > > -----Original Message----- > From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] > Sent: Tuesday, June 12, 2018 2:48 AM > To: Deshpande, Vivek R ; Vladimir Kozlov ; hotspot-compiler-dev at openjdk.java.net compiler > Subject: Re: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes performance regression > > Hi Vivek, > > On 11.06.2018 20:51, Deshpande, Vivek R wrote: >> http://cr.openjdk.java.net/~vdeshpande/SubwordFix/webrev.01/ > > This looks good to me as well. I've just submitted performance testing and premature results look great (+3.17% on SpecJVM2008 MPEG). > > I'll let you know once the runs are completed. Please set the status of the bug to "In Progress". > > Best regards, > Tobias > From ekaterina.pavlova at oracle.com Thu Jun 14 01:07:53 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Wed, 13 Jun 2018 18:07:53 -0700 Subject: RFR(XS) : 8204978: Disable Epsilon GC tests from running with Graal Message-ID: Hello, Graal does not support Epsilon GC and gc/epsilon tests need to be excluded from execution with Graal. Please review the fix which adds "@requires !vm.graal.enabled" to disable Epsilon GC tests from running with Graal. JDK-8184349 is going to address jvm issue to exit gracefully in case GC does not support JVMCI. Right now Epsilon GC will crash with Graal. JBS: https://bugs.openjdk.java.net/browse/JDK-8204978 webrev: http://cr.openjdk.java.net/~epavlova//8204978/webrev.00/index.html testing: tested by running GC tests with Graal and checked that all gc/epsilon were excluded. Thanks, -katya p.s. Igor Ignatyev volunteered to sponsor this change. From vladimir.kozlov at oracle.com Thu Jun 14 01:18:43 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Jun 2018 18:18:43 -0700 Subject: RFR(XS) : 8204978: Disable Epsilon GC tests from running with Graal In-Reply-To: References: Message-ID: Looks good. Thanks, Vladimir On 6/13/18 6:07 PM, Ekaterina Pavlova wrote: > Hello, > > Graal does not support Epsilon GC and gc/epsilon tests need to be > excluded from execution with Graal. > Please review the fix which adds "@requires !vm.graal.enabled" to > disable Epsilon GC tests from running with Graal. > > JDK-8184349 is going to address jvm issue to exit gracefully in case GC > does not support JVMCI. > Right now Epsilon GC will crash with Graal. > > ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8204978 > ?webrev: > http://cr.openjdk.java.net/~epavlova//8204978/webrev.00/index.html > testing: tested by running GC tests with Graal and checked that all > gc/epsilon were excluded. > > Thanks, > -katya > > p.s. > ?Igor Ignatyev volunteered to sponsor this change. From tobias.hartmann at oracle.com Thu Jun 14 06:47:43 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 14 Jun 2018 08:47:43 +0200 Subject: [11] RFR(M): 8203915: Induction variable of over-unrolled loop conflicts with range checks In-Reply-To: <2c07a6c5-18a9-108e-bcf9-6b2fb544104f@oracle.com> References: <485521e2-d490-1efa-2e57-ca90eb0b8099@oracle.com> <2c07a6c5-18a9-108e-bcf9-6b2fb544104f@oracle.com> Message-ID: Thanks, Vladimir. Best regards, Tobias On 13.06.2018 19:03, Vladimir Kozlov wrote: > On 6/13/18 5:57 AM, Roland Westrelin wrote: >> >>> final testing revealed a problem with my patch: if the stride is negative, we need check "2 * stride >>> + 1" instead of "2 * stride - 1". Here's the incremental webrev: >>> http://cr.openjdk.java.net/~thartmann/8203915/webrev.inc/ >> >> Looks ok to me. > > +1 > > Vladimir > >> >> Roland. >> From tobias.hartmann at oracle.com Thu Jun 14 07:07:44 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 14 Jun 2018 09:07:44 +0200 Subject: [11] RFR(XS) 8202948: C2: assert(init_offset >= 0) failed: positive offset from object start In-Reply-To: <30d6bc63-cdc7-7f71-ef1a-e3b6e45244fb@oracle.com> References: <30d6bc63-cdc7-7f71-ef1a-e3b6e45244fb@oracle.com> Message-ID: Hi Vladimir, looks good to me but shouldn't we add the test (looks like you came up with a very simple version)? Thanks, Tobias On 13.06.2018 19:14, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8202948 > > Predicates and Range checks before main loop will not help since they are runtime checks and limit > is not constant. The problem happens during compilation because vectorization is attempted for > over-unrolling loop which will not be executed in runtime (dead loop). Stride is negative (-3) value > and initial is 2 - loop will be executed at least once (or never) because of other conditions in > code. C2 did not recognize this because the test fails only with -Xcomp when profiling data is no > available (it passed without -Xcomp). > > Simplest fix is to convert the assert into compilation check which will skip superword optimization > in such case. > > diff -r 0d47e89382ed src/hotspot/share/opto/superword.cpp > --- a/src/hotspot/share/opto/superword.cpp > +++ b/src/hotspot/share/opto/superword.cpp > @@ -887,7 +887,9 @@ > ?? if (init_nd->is_Con() && p.invar() == NULL) { > ???? int init = init_nd->bottom_type()->is_int()->get_con(); > ???? int init_offset = init * p.scale_in_bytes() + offset; > -??? assert(init_offset >= 0, "positive offset from object start"); > +??? if (init_offset < 0) { // negative offset from object start? > +????? return false;??????? // may happen in dead loop > +??? } > ???? if (vw % span == 0) { > ?????? // If vm is a multiple of span, we use formula (1). > ?????? if (span > 0) { > > Test passed with and without Predicates with this fix. > > Tested with tier1, tier2, precheckin-xcomp > From shade at redhat.com Thu Jun 14 07:57:54 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Jun 2018 09:57:54 +0200 Subject: RFR(XS) : 8204978: Disable Epsilon GC tests from running with Graal In-Reply-To: References: Message-ID: On 06/14/2018 03:07 AM, Ekaterina Pavlova wrote: > ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8204978 > ?webrev: http://cr.openjdk.java.net/~epavlova//8204978/webrev.00/index.html Looks good. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From doug.simon at oracle.com Thu Jun 14 08:09:38 2018 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 14 Jun 2018 10:09:38 +0200 Subject: RFR(XS): 8205025: [AOT] make jdk.aot module upgradeable Message-ID: <77DF5B8E-F7C2-43EB-B02B-C40CB958D081@oracle.com> In the context of JDK-8202762, we to need to make the jdk.aot module upgradeable. Otherwise, it is impossible to run or test the version of jdk.aot under development in a Graal repo: java --module-path=../sdk/mxbuild/modules/org.graalvm.graal_sdk.jar:../truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar:mxbuild/modules/jdk.internal.vm.compiler.jar --upgrade-module-path=mxbuild/modules/jdk.internal.vm.compiler.jar:mxbuild/modules/jdk.internal.vm.compiler.management.jar:mxbuild/modules/jdk.aot.jar -m jdk.aot/jdk.tools.jaotc.Main Error occurred during initialization of boot layer java.lang.module.FindException: Hash of jdk.aot (55cfefcfb0ca2a8b12403c47848d2bbd54416149cfe75f5051ad77628a2764b4) differs to expected hash (e6882d3461a21ea46c52da87ef52b5850a7b1f5ae0cfd650b7f784c970aaa0ee) recorded in java.base https://bugs.openjdk.java.net/browse/JDK-8205025 http://cr.openjdk.java.net/~dnsimon/8205025/ -Doug From tobias.hartmann at oracle.com Thu Jun 14 09:16:13 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 14 Jun 2018 11:16:13 +0200 Subject: [Urgent] RFR(M): 8205034: [BACKOUT] Induction variable of over-unrolled loop conflicts with range checks Message-ID: <7773f1e5-28b3-ee47-a479-ad3a21647b3e@oracle.com> Hi, please review the following patch that backs out the fix for JDK-8203915 which causes SIGILL failures in testing: http://cr.openjdk.java.net/~thartmann/8205034/webrev.00/ Thanks, Tobias From shade at redhat.com Thu Jun 14 09:19:04 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Jun 2018 11:19:04 +0200 Subject: [Urgent] RFR(M): 8205034: [BACKOUT] Induction variable of over-unrolled loop conflicts with range checks In-Reply-To: <7773f1e5-28b3-ee47-a479-ad3a21647b3e@oracle.com> References: <7773f1e5-28b3-ee47-a479-ad3a21647b3e@oracle.com> Message-ID: <01b39363-0bb9-3d08-df7b-ecaa173712b4@redhat.com> On 06/14/2018 11:16 AM, Tobias Hartmann wrote: > please review the following patch that backs out the fix for JDK-8203915 which causes SIGILL > failures in testing: > http://cr.openjdk.java.net/~thartmann/8205034/webrev.00/ Looks OK. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From tobias.hartmann at oracle.com Thu Jun 14 09:20:00 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 14 Jun 2018 11:20:00 +0200 Subject: [Urgent] RFR(M): 8205034: [BACKOUT] Induction variable of over-unrolled loop conflicts with range checks In-Reply-To: <01b39363-0bb9-3d08-df7b-ecaa173712b4@redhat.com> References: <7773f1e5-28b3-ee47-a479-ad3a21647b3e@oracle.com> <01b39363-0bb9-3d08-df7b-ecaa173712b4@redhat.com> Message-ID: <66e804f0-9ccb-905c-3966-1bc9a7215e69@oracle.com> Thanks for the quick review, Aleksey! Will push this trivial fix immediately. Best regards, Tobias On 14.06.2018 11:19, Aleksey Shipilev wrote: > On 06/14/2018 11:16 AM, Tobias Hartmann wrote: >> please review the following patch that backs out the fix for JDK-8203915 which causes SIGILL >> failures in testing: >> http://cr.openjdk.java.net/~thartmann/8205034/webrev.00/ > > Looks OK. > > -Aleksey > From thomas.schatzl at oracle.com Thu Jun 14 09:22:57 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 14 Jun 2018 11:22:57 +0200 Subject: [Urgent] RFR(M): 8205034: [BACKOUT] Induction variable of over-unrolled loop conflicts with range checks In-Reply-To: <7773f1e5-28b3-ee47-a479-ad3a21647b3e@oracle.com> References: <7773f1e5-28b3-ee47-a479-ad3a21647b3e@oracle.com> Message-ID: <6a8bbb9b2488487778387466c075ac9f6b3aafc3.camel@oracle.com> Hi, On Thu, 2018-06-14 at 11:16 +0200, Tobias Hartmann wrote: > Hi, > > please review the following patch that backs out the fix for JDK- > 8203915 which causes SIGILL > failures in testing: > http://cr.openjdk.java.net/~thartmann/8205034/webrev.00/ > > Thanks, > Tobias looks like a valid anti-diff. Ship it. Thomas From Alan.Bateman at oracle.com Thu Jun 14 10:03:42 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Jun 2018 11:03:42 +0100 Subject: RFR(XS): 8205025: [AOT] make jdk.aot module upgradeable In-Reply-To: <77DF5B8E-F7C2-43EB-B02B-C40CB958D081@oracle.com> References: <77DF5B8E-F7C2-43EB-B02B-C40CB958D081@oracle.com> Message-ID: On 14/06/2018 09:09, Doug Simon wrote: > In the context of JDK-8202762, we to need to make the jdk.aot module upgradeable. Otherwise, it is impossible to run or test the version of jdk.aot under development in a Graal repo: > > java --module-path=../sdk/mxbuild/modules/org.graalvm.graal_sdk.jar:../truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar:mxbuild/modules/jdk.internal.vm.compiler.jar --upgrade-module-path=mxbuild/modules/jdk.internal.vm.compiler.jar:mxbuild/modules/jdk.internal.vm.compiler.management.jar:mxbuild/modules/jdk.aot.jar -m jdk.aot/jdk.tools.jaotc.Main > Error occurred during initialization of boot layer > java.lang.module.FindException: Hash of jdk.aot (55cfefcfb0ca2a8b12403c47848d2bbd54416149cfe75f5051ad77628a2764b4) differs to expected hash (e6882d3461a21ea46c52da87ef52b5850a7b1f5ae0cfd650b7f784c970aaa0ee) recorded in java.base > > https://bugs.openjdk.java.net/browse/JDK-8205025 > http://cr.openjdk.java.net/~dnsimon/8205025/ > This looks okay except that there has been an attempt to keep the list of modules in alphabetic order in these make files. Do all tests pass with this change? There is at least one test in test/jdk/jdk/modules/etc that is sensitive to the list of upgradeable modules. -Alan. From tobias.hartmann at oracle.com Thu Jun 14 10:06:44 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 14 Jun 2018 12:06:44 +0200 Subject: [Urgent] RFR(M): 8205034: [BACKOUT] Induction variable of over-unrolled loop conflicts with range checks In-Reply-To: <6a8bbb9b2488487778387466c075ac9f6b3aafc3.camel@oracle.com> References: <7773f1e5-28b3-ee47-a479-ad3a21647b3e@oracle.com> <6a8bbb9b2488487778387466c075ac9f6b3aafc3.camel@oracle.com> Message-ID: <91d506c6-c2e7-8156-7b66-9625b40ede08@oracle.com> On 14.06.2018 11:22, Thomas Schatzl wrote: > looks like a valid anti-diff. > > Ship it. Thanks, Thomas. I've already pushed it. Best regards, Tobias From rwestrel at redhat.com Thu Jun 14 12:37:33 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 14 Jun 2018 14:37:33 +0200 Subject: RFR(M): 8204240: Extend MDO to allow more reasons to be recorded per bci In-Reply-To: References: Message-ID: > Note this patch modifies platform specific code. I verified x86 (32 and > 64 bits), aarch64. Sparc is ok AFAICT but I couldn't verify it. For PPC > and arm32 I will need someone to take a closer look. Both Andrews took a look at aarch64. Martin confirmed PPC64 and s390 are ok. I looked at the arm32 code and I think no change is needed. I now need another review so I can push this. Nils, do you still intend to review it? Roland. From mandy.chung at oracle.com Thu Jun 14 14:17:48 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 14 Jun 2018 07:17:48 -0700 Subject: RFR(XS): 8205025: [AOT] make jdk.aot module upgradeable In-Reply-To: <77DF5B8E-F7C2-43EB-B02B-C40CB958D081@oracle.com> References: <77DF5B8E-F7C2-43EB-B02B-C40CB958D081@oracle.com> Message-ID: <68e2be81-ce59-197a-b1ce-bea4230e2f44@oracle.com> test/jdk/jdk/modules/etc/UpgradeableModules.java needs to be updated as it keeps the list of upgradeable modules as well to verify the hashes in java.base. Mandy On 6/14/18 1:09 AM, Doug Simon wrote: > In the context of JDK-8202762, we to need to make the jdk.aot module upgradeable. Otherwise, it is impossible to run or test the version of jdk.aot under development in a Graal repo: > > java --module-path=../sdk/mxbuild/modules/org.graalvm.graal_sdk.jar:../truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar:mxbuild/modules/jdk.internal.vm.compiler.jar --upgrade-module-path=mxbuild/modules/jdk.internal.vm.compiler.jar:mxbuild/modules/jdk.internal.vm.compiler.management.jar:mxbuild/modules/jdk.aot.jar -m jdk.aot/jdk.tools.jaotc.Main > Error occurred during initialization of boot layer > java.lang.module.FindException: Hash of jdk.aot (55cfefcfb0ca2a8b12403c47848d2bbd54416149cfe75f5051ad77628a2764b4) differs to expected hash (e6882d3461a21ea46c52da87ef52b5850a7b1f5ae0cfd650b7f784c970aaa0ee) recorded in java.base > > https://bugs.openjdk.java.net/browse/JDK-8205025 > http://cr.openjdk.java.net/~dnsimon/8205025/ > > -Doug > From vladimir.kozlov at oracle.com Thu Jun 14 15:41:34 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Jun 2018 08:41:34 -0700 Subject: [11] RFR(XS) 8202948: C2: assert(init_offset >= 0) failed: positive offset from object start In-Reply-To: References: <30d6bc63-cdc7-7f71-ef1a-e3b6e45244fb@oracle.com> Message-ID: <856048b9-5736-300d-ed9b-e2b0b4da7a63@oracle.com> Thank you, Tobias Yes, I need to add test. Thanks, Vladimir On 6/14/18 12:07 AM, Tobias Hartmann wrote: > Hi Vladimir, > > looks good to me but shouldn't we add the test (looks like you came up with a very simple version)? > > Thanks, > Tobias > > On 13.06.2018 19:14, Vladimir Kozlov wrote: >> https://bugs.openjdk.java.net/browse/JDK-8202948 >> >> Predicates and Range checks before main loop will not help since they are runtime checks and limit >> is not constant. The problem happens during compilation because vectorization is attempted for >> over-unrolling loop which will not be executed in runtime (dead loop). Stride is negative (-3) value >> and initial is 2 - loop will be executed at least once (or never) because of other conditions in >> code. C2 did not recognize this because the test fails only with -Xcomp when profiling data is no >> available (it passed without -Xcomp). >> >> Simplest fix is to convert the assert into compilation check which will skip superword optimization >> in such case. >> >> diff -r 0d47e89382ed src/hotspot/share/opto/superword.cpp >> --- a/src/hotspot/share/opto/superword.cpp >> +++ b/src/hotspot/share/opto/superword.cpp >> @@ -887,7 +887,9 @@ >> ?? if (init_nd->is_Con() && p.invar() == NULL) { >> ???? int init = init_nd->bottom_type()->is_int()->get_con(); >> ???? int init_offset = init * p.scale_in_bytes() + offset; >> -??? assert(init_offset >= 0, "positive offset from object start"); >> +??? if (init_offset < 0) { // negative offset from object start? >> +????? return false;??????? // may happen in dead loop >> +??? } >> ???? if (vw % span == 0) { >> ?????? // If vm is a multiple of span, we use formula (1). >> ?????? if (span > 0) { >> >> Test passed with and without Predicates with this fix. >> >> Tested with tier1, tier2, precheckin-xcomp >> From doug.simon at oracle.com Thu Jun 14 16:35:00 2018 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 14 Jun 2018 18:35:00 +0200 Subject: RFR(XS): 8205025: [AOT] make jdk.aot module upgradeable In-Reply-To: References: <77DF5B8E-F7C2-43EB-B02B-C40CB958D081@oracle.com> Message-ID: > On 14 Jun 2018, at 12:03, Alan Bateman wrote: > > > > On 14/06/2018 09:09, Doug Simon wrote: >> In the context of JDK-8202762, we to need to make the jdk.aot module upgradeable. Otherwise, it is impossible to run or test the version of jdk.aot under development in a Graal repo: >> >> java --module-path=../sdk/mxbuild/modules/org.graalvm.graal_sdk.jar:../truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar:mxbuild/modules/jdk.internal.vm.compiler.jar --upgrade-module-path=mxbuild/modules/jdk.internal.vm.compiler.jar:mxbuild/modules/jdk.internal.vm.compiler.management.jar:mxbuild/modules/jdk.aot.jar -m jdk.aot/jdk.tools.jaotc.Main >> Error occurred during initialization of boot layer >> java.lang.module.FindException: Hash of jdk.aot (55cfefcfb0ca2a8b12403c47848d2bbd54416149cfe75f5051ad77628a2764b4) differs to expected hash (e6882d3461a21ea46c52da87ef52b5850a7b1f5ae0cfd650b7f784c970aaa0ee) recorded in java.base >> >> https://bugs.openjdk.java.net/browse/JDK-8205025 >> http://cr.openjdk.java.net/~dnsimon/8205025/ >> > This looks okay except that there has been an attempt to keep the list of modules in alphabetic order in these make files. > > Do all tests pass with this change? There is at least one test in test/jdk/jdk/modules/etc that is sensitive to the list of upgradeable modules. I changed the test (thanks Mandy for pointing out exactly which one), fixed the alphabetic ordering of the list and am running tests now. -Doug From Alan.Bateman at oracle.com Thu Jun 14 17:01:37 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Jun 2018 18:01:37 +0100 Subject: RFR(XS): 8205025: [AOT] make jdk.aot module upgradeable In-Reply-To: References: <77DF5B8E-F7C2-43EB-B02B-C40CB958D081@oracle.com> Message-ID: <5378b058-f6f6-499b-4858-b16204714919@oracle.com> On 14/06/2018 17:35, Doug Simon wrote: > : > >> This looks okay except that there has been an attempt to keep the list of modules in alphabetic order in these make files. >> >> Do all tests pass with this change? There is at least one test in test/jdk/jdk/modules/etc that is sensitive to the list of upgradeable modules. > I changed the test (thanks Mandy for pointing out exactly which one), fixed the alphabetic ordering of the list and am running tests now. > The updated webrev looks good to me. -Alan From vladimir.kozlov at oracle.com Thu Jun 14 17:26:02 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Jun 2018 10:26:02 -0700 Subject: RFR(XS): 8205025: [AOT] make jdk.aot module upgradeable In-Reply-To: References: <77DF5B8E-F7C2-43EB-B02B-C40CB958D081@oracle.com> Message-ID: Good. Thanks, Vladimir On 6/14/18 9:35 AM, Doug Simon wrote: > > >> On 14 Jun 2018, at 12:03, Alan Bateman wrote: >> >> >> >> On 14/06/2018 09:09, Doug Simon wrote: >>> In the context of JDK-8202762, we to need to make the jdk.aot module upgradeable. Otherwise, it is impossible to run or test the version of jdk.aot under development in a Graal repo: >>> >>> java --module-path=../sdk/mxbuild/modules/org.graalvm.graal_sdk.jar:../truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar:mxbuild/modules/jdk.internal.vm.compiler.jar --upgrade-module-path=mxbuild/modules/jdk.internal.vm.compiler.jar:mxbuild/modules/jdk.internal.vm.compiler.management.jar:mxbuild/modules/jdk.aot.jar -m jdk.aot/jdk.tools.jaotc.Main >>> Error occurred during initialization of boot layer >>> java.lang.module.FindException: Hash of jdk.aot (55cfefcfb0ca2a8b12403c47848d2bbd54416149cfe75f5051ad77628a2764b4) differs to expected hash (e6882d3461a21ea46c52da87ef52b5850a7b1f5ae0cfd650b7f784c970aaa0ee) recorded in java.base >>> >>> https://bugs.openjdk.java.net/browse/JDK-8205025 >>> http://cr.openjdk.java.net/~dnsimon/8205025/ >>> >> This looks okay except that there has been an attempt to keep the list of modules in alphabetic order in these make files. >> >> Do all tests pass with this change? There is at least one test in test/jdk/jdk/modules/etc that is sensitive to the list of upgradeable modules. > > I changed the test (thanks Mandy for pointing out exactly which one), fixed the alphabetic ordering of the list and am running tests now. > > -Doug > From mandy.chung at oracle.com Thu Jun 14 17:28:35 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 14 Jun 2018 10:28:35 -0700 Subject: RFR(XS): 8205025: [AOT] make jdk.aot module upgradeable In-Reply-To: References: <77DF5B8E-F7C2-43EB-B02B-C40CB958D081@oracle.com> Message-ID: <0196949e-0249-06ce-0807-eb0d5e0e3b58@oracle.com> On 6/14/18 9:35 AM, Doug Simon wrote: > I changed the test (thanks Mandy for pointing out exactly which one), > fixed the alphabetic ordering of the list and am running tests now. I reviewed http://cr.openjdk.java.net/~dnsimon/8205025/. Looks good. Mandy From nils.eliasson at oracle.com Thu Jun 14 18:54:08 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 14 Jun 2018 20:54:08 +0200 Subject: RFR(M): 8204240: Extend MDO to allow more reasons to be recorded per bci In-Reply-To: References: Message-ID: <9a4cb0ad-1062-3738-bfc0-fb2177c5627c@oracle.com> Hi Roland, Looks great! // Nils On 2018-06-14 14:37, Roland Westrelin wrote: >> Note this patch modifies platform specific code. I verified x86 (32 and >> 64 bits), aarch64. Sparc is ok AFAICT but I couldn't verify it. For PPC >> and arm32 I will need someone to take a closer look. > Both Andrews took a look at aarch64. Martin confirmed PPC64 and s390 are > ok. I looked at the arm32 code and I think no change is needed. > > I now need another review so I can push this. Nils, do you still intend > to review it? > > Roland. From vladimir.kozlov at oracle.com Thu Jun 14 20:51:12 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Jun 2018 13:51:12 -0700 Subject: [11] RFR(XS) 8202948: C2: assert(init_offset >= 0) failed: positive offset from object start In-Reply-To: <856048b9-5736-300d-ed9b-e2b0b4da7a63@oracle.com> References: <30d6bc63-cdc7-7f71-ef1a-e3b6e45244fb@oracle.com> <856048b9-5736-300d-ed9b-e2b0b4da7a63@oracle.com> Message-ID: I added test and ran it on all platforms: http://cr.openjdk.java.net/~kvn/8202948/webrev.01/ Thanks, Vladimir On 6/14/18 8:41 AM, Vladimir Kozlov wrote: > Thank you, Tobias > > Yes, I need to add test. > > Thanks, > Vladimir > > On 6/14/18 12:07 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> looks good to me but shouldn't we add the test (looks like you came up >> with a very simple version)? >> >> Thanks, >> Tobias >> >> On 13.06.2018 19:14, Vladimir Kozlov wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8202948 >>> >>> Predicates and Range checks before main loop will not help since they >>> are runtime checks and limit >>> is not constant. The problem happens during compilation because >>> vectorization is attempted for >>> over-unrolling loop which will not be executed in runtime (dead >>> loop). Stride is negative (-3) value >>> and initial is 2 - loop will be executed at least once (or never) >>> because of other conditions in >>> code. C2 did not recognize this because the test fails only with >>> -Xcomp when profiling data is no >>> available (it passed without -Xcomp). >>> >>> Simplest fix is to convert the assert into compilation check which >>> will skip superword optimization >>> in such case. >>> >>> diff -r 0d47e89382ed src/hotspot/share/opto/superword.cpp >>> --- a/src/hotspot/share/opto/superword.cpp >>> +++ b/src/hotspot/share/opto/superword.cpp >>> @@ -887,7 +887,9 @@ >>> ??? if (init_nd->is_Con() && p.invar() == NULL) { >>> ????? int init = init_nd->bottom_type()->is_int()->get_con(); >>> ????? int init_offset = init * p.scale_in_bytes() + offset; >>> -??? assert(init_offset >= 0, "positive offset from object start"); >>> +??? if (init_offset < 0) { // negative offset from object start? >>> +????? return false;??????? // may happen in dead loop >>> +??? } >>> ????? if (vw % span == 0) { >>> ??????? // If vm is a multiple of span, we use formula (1). >>> ??????? if (span > 0) { >>> >>> Test passed with and without Predicates with this fix. >>> >>> Tested with tier1, tier2, precheckin-xcomp >>> 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 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekaterina.pavlova at oracle.com Thu Jun 14 22:07:05 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Thu, 14 Jun 2018 15:07:05 -0700 Subject: RFR (XXS): 8205074: [Graal] Add rest of compiler/stable tests into ProblemList-graal.txt Message-ID: Hi All, compiler/stable/TestStableObject.java also failed recently because of 8204347. As pointed by Tobias it has sense to exclude all compiler/stable tests from execution in Graal mode till 8204347 is fixed. JBS: https://bugs.openjdk.java.net/browse/JDK-8205074 webrev: http://cr.openjdk.java.net/~epavlova//8205074/webrev.00/index.html thanks, -katya p.s. Igor Ignatyev volunteered to sponsor this change. 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 vladimir.kozlov at oracle.com Thu Jun 14 22:13:16 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Jun 2018 15:13:16 -0700 Subject: RFR (XXS): 8205074: [Graal] Add rest of compiler/stable tests into ProblemList-graal.txt In-Reply-To: References: Message-ID: <8d2894df-9aee-3a51-0b10-b8c435e43343@oracle.com> Looks good. Thanks, Vladimir On 6/14/18 3:07 PM, Ekaterina Pavlova wrote: > Hi All, > > compiler/stable/TestStableObject.java also failed recently because of > 8204347. > As pointed by Tobias it has sense to exclude all compiler/stable tests > from execution in Graal mode till 8204347 is fixed. > > ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8205074 > webrev: http://cr.openjdk.java.net/~epavlova//8205074/webrev.00/index.html > > thanks, > -katya > > p.s. > ?Igor Ignatyev volunteered to sponsor this change. From ekaterina.pavlova at oracle.com Thu Jun 14 22:21:17 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Thu, 14 Jun 2018 15:21:17 -0700 Subject: RFR (XXS): 8205074: [Graal] Add rest of compiler/stable tests into ProblemList-graal.txt In-Reply-To: <8d2894df-9aee-3a51-0b10-b8c435e43343@oracle.com> References: <8d2894df-9aee-3a51-0b10-b8c435e43343@oracle.com> Message-ID: <73707dc9-4afe-6dc1-47eb-dc01fe08f881@oracle.com> Thanks Vladimir. -katya On 6/14/18 3:13 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 6/14/18 3:07 PM, Ekaterina Pavlova wrote: >> Hi All, >> >> compiler/stable/TestStableObject.java also failed recently because of 8204347. >> As pointed by Tobias it has sense to exclude all compiler/stable tests from execution in Graal mode till 8204347 is fixed. >> >> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8205074 >> webrev: http://cr.openjdk.java.net/~epavlova//8205074/webrev.00/index.html >> >> thanks, >> -katya >> >> p.s. >> ??Igor Ignatyev volunteered to sponsor this change. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: 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 tobias.hartmann at oracle.com Fri Jun 15 06:35:49 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 15 Jun 2018 08:35:49 +0200 Subject: [11] RFR(XS) 8202948: C2: assert(init_offset >= 0) failed: positive offset from object start In-Reply-To: References: <30d6bc63-cdc7-7f71-ef1a-e3b6e45244fb@oracle.com> <856048b9-5736-300d-ed9b-e2b0b4da7a63@oracle.com> Message-ID: Hi Vladimir, looks good, thanks for adding the test. Best regards, Tobias On 14.06.2018 22:51, Vladimir Kozlov wrote: > I added test and ran it on all platforms: > > http://cr.openjdk.java.net/~kvn/8202948/webrev.01/ > > Thanks, > Vladimir > > On 6/14/18 8:41 AM, Vladimir Kozlov wrote: >> Thank you, Tobias >> >> Yes, I need to add test. >> >> Thanks, >> Vladimir >> >> On 6/14/18 12:07 AM, Tobias Hartmann wrote: >>> Hi Vladimir, >>> >>> looks good to me but shouldn't we add the test (looks like you came up with a very simple version)? >>> >>> Thanks, >>> Tobias >>> >>> On 13.06.2018 19:14, Vladimir Kozlov wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8202948 >>>> >>>> Predicates and Range checks before main loop will not help since they are runtime checks and limit >>>> is not constant. The problem happens during compilation because vectorization is attempted for >>>> over-unrolling loop which will not be executed in runtime (dead loop). Stride is negative (-3) >>>> value >>>> and initial is 2 - loop will be executed at least once (or never) because of other conditions in >>>> code. C2 did not recognize this because the test fails only with -Xcomp when profiling data is no >>>> available (it passed without -Xcomp). >>>> >>>> Simplest fix is to convert the assert into compilation check which will skip superword optimization >>>> in such case. >>>> >>>> diff -r 0d47e89382ed src/hotspot/share/opto/superword.cpp >>>> --- a/src/hotspot/share/opto/superword.cpp >>>> +++ b/src/hotspot/share/opto/superword.cpp >>>> @@ -887,7 +887,9 @@ >>>> ??? if (init_nd->is_Con() && p.invar() == NULL) { >>>> ????? int init = init_nd->bottom_type()->is_int()->get_con(); >>>> ????? int init_offset = init * p.scale_in_bytes() + offset; >>>> -??? assert(init_offset >= 0, "positive offset from object start"); >>>> +??? if (init_offset < 0) { // negative offset from object start? >>>> +????? return false;??????? // may happen in dead loop >>>> +??? } >>>> ????? if (vw % span == 0) { >>>> ??????? // If vm is a multiple of span, we use formula (1). >>>> ??????? if (span > 0) { >>>> >>>> Test passed with and without Predicates with this fix. >>>> >>>> Tested with tier1, tier2, precheckin-xcomp >>>> From rwestrel at redhat.com Fri Jun 15 06:52:26 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 15 Jun 2018 08:52:26 +0200 Subject: RFR(M): 8204240: Extend MDO to allow more reasons to be recorded per bci In-Reply-To: <9a4cb0ad-1062-3738-bfc0-fb2177c5627c@oracle.com> References: <9a4cb0ad-1062-3738-bfc0-fb2177c5627c@oracle.com> Message-ID: Hi Nils, Thanks for the review. Roland. From rwestrel at redhat.com Fri Jun 15 07:27:28 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 15 Jun 2018 09:27:28 +0200 Subject: [11] RFR(XS) 8202948: C2: assert(init_offset >= 0) failed: positive offset from object start In-Reply-To: References: <30d6bc63-cdc7-7f71-ef1a-e3b6e45244fb@oracle.com> <856048b9-5736-300d-ed9b-e2b0b4da7a63@oracle.com> Message-ID: > http://cr.openjdk.java.net/~kvn/8202948/webrev.01/ That looks good to me. Roland. From nils.eliasson at oracle.com Fri Jun 15 09:38:06 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 15 Jun 2018 11:38:06 +0200 Subject: 8205097: RFR(S): zBarrierSetC2::split_barrier_thru_phi need to update idom Message-ID: Hi, This patch fixes missing updates of the idom when splitting barrier thru phis. Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8205097 Webrev: http://cr.openjdk.java.net/~neliasso/8205097/webrev.01/ Regards, Nils Eliasson From rwestrel at redhat.com Fri Jun 15 10:10:13 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 15 Jun 2018 12:10:13 +0200 Subject: 8205097: RFR(S): zBarrierSetC2::split_barrier_thru_phi need to update idom In-Reply-To: References: Message-ID: > Webrev: http://cr.openjdk.java.net/~neliasso/8205097/webrev.01/ That looks good to me. Roland. From per.liden at oracle.com Fri Jun 15 11:58:18 2018 From: per.liden at oracle.com (Per Liden) Date: Fri, 15 Jun 2018 13:58:18 +0200 Subject: 8205097: RFR(S): zBarrierSetC2::split_barrier_thru_phi need to update idom In-Reply-To: References: Message-ID: <0e8f5b54-2f65-6c6f-981e-44f764e95e8c@oracle.com> I ran this through tier{1,2,3,4,5} over night without running into the assert we occasionally saw before. So the change seems good. /Per On 06/15/2018 11:38 AM, Nils Eliasson wrote: > Hi, > > This patch fixes missing updates of the idom when splitting barrier thru > phis. > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205097 > > Webrev: http://cr.openjdk.java.net/~neliasso/8205097/webrev.01/ > > Regards, > > Nils Eliasson > From tobias.hartmann at oracle.com Fri Jun 15 12:07:41 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 15 Jun 2018 14:07:41 +0200 Subject: [11] RFR(M): 8205033: [REDO] Induction variable of over-unrolled loop conflicts with range checks Message-ID: <42367890-a5eb-1413-6a1d-1a383953d5a1@oracle.com> Hi, my initial patch for JDK-8203915 [1] failed because the computation of the value of the loop induction variable at the end of the first iteration of the unrolled loop was wrong. As a result, the predicate was incorrectly found to always fail and we hit a HaltNode (SIGILL) in compiled code. The problem is very easy to reproduce with the jdk/sun/security/tools/keytool/ tests, I therefore did not add an additional regression test. The problematic loop looks like this: for (int i = 20; i > 0; i -= 4) { array[i-1] = ... array[i-2] = ... array[i-3] = ... array[i-4] = ... } To make sure that the last array access is in bounds, we add a skeleton predicate of the form max_i - 4 = (init + stride + 1) - 4 References: Message-ID: <5cb41113-98dc-e635-bb6c-d092cc9249c3@oracle.com> I mixed up the bug numbers. This will be submitted as JDK-8204927 and JDK-8205097 will be closed as a dup. I will update the webrev accordingly before pushing. Regards, Nils On 2018-06-15 11:38, Nils Eliasson wrote: > Hi, > > This patch fixes missing updates of the idom when splitting barrier > thru phis. > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205097 > > Webrev: http://cr.openjdk.java.net/~neliasso/8205097/webrev.01/ > > Regards, > > Nils Eliasson > From nils.eliasson at oracle.com Fri Jun 15 12:34:14 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 15 Jun 2018 14:34:14 +0200 Subject: RFR(S): 8205107: assert(c->Opcode() == Op_SafePoint) failed: broken outer loop Message-ID: Hi, This patch fixes a problem where we eliminate the safepoint of a strip mined loop, and later hit an assert. I add a check in SafepointNode::Identity to not remove the safepoint node if it belongs to a OuterStripMinedLoopEndNode. If the loop is eliminated, the safepoint will be removed together with the OuterStripMinedLoop and OuterStripMinedLoopEnd, maintaining a consistent shape until it is gone. http://cr.openjdk.java.net/~neliasso/8205107/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8205107 Regards, Nils Eliasson From nils.eliasson at oracle.com Fri Jun 15 12:35:11 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 15 Jun 2018 14:35:11 +0200 Subject: 8205097: RFR(S): zBarrierSetC2::split_barrier_thru_phi need to update idom In-Reply-To: <5cb41113-98dc-e635-bb6c-d092cc9249c3@oracle.com> References: <5cb41113-98dc-e635-bb6c-d092cc9249c3@oracle.com> Message-ID: <3ca06902-e4d0-7aaa-c996-b219871efce5@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8204927 http://cr.openjdk.java.net/~neliasso/8204927/webrev.01/ // Nils On 2018-06-15 13:53, Nils Eliasson wrote: > I mixed up the bug numbers. > > This will be submitted as JDK-8204927 and JDK-8205097 will be closed > as a dup. I will update the webrev accordingly before pushing. > > Regards, > > Nils > > > > On 2018-06-15 11:38, Nils Eliasson wrote: >> Hi, >> >> This patch fixes missing updates of the idom when splitting barrier >> thru phis. >> >> Please review. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8205097 >> >> Webrev: http://cr.openjdk.java.net/~neliasso/8205097/webrev.01/ >> >> Regards, >> >> Nils Eliasson >> > From rwestrel at redhat.com Fri Jun 15 12:53:10 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 15 Jun 2018 14:53:10 +0200 Subject: RFR(S): 8205107: assert(c->Opcode() == Op_SafePoint) failed: broken outer loop In-Reply-To: References: Message-ID: Hi Nils, > http://cr.openjdk.java.net/~neliasso/8205107/webrev.01/ Looks like the webrev for the wrong bug. Roland. From nils.eliasson at oracle.com Fri Jun 15 12:49:42 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 15 Jun 2018 14:49:42 +0200 Subject: RFR(S): 8205107: assert(c->Opcode() == Op_SafePoint) failed: broken outer loop In-Reply-To: References: Message-ID: Hi, Here is the correct one: http://cr.openjdk.java.net/~neliasso/8205107/webrev.02/ Thanks, Nils On 2018-06-15 14:53, Roland Westrelin wrote: > Hi Nils, > >> http://cr.openjdk.java.net/~neliasso/8205107/webrev.01/ > Looks like the webrev for the wrong bug. > > Roland. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwestrel at redhat.com Fri Jun 15 13:12:56 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 15 Jun 2018 15:12:56 +0200 Subject: RFR(S): 8205107: assert(c->Opcode() == Op_SafePoint) failed: broken outer loop In-Reply-To: References: Message-ID: > Here is the correct one: > http://cr.openjdk.java.net/~neliasso/8205107/webrev.02/ Looks ok to me. Roland. From goetz.lindenmaier at sap.com Fri Jun 15 13:12:25 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 15 Jun 2018 13:12:25 +0000 Subject: RFR(XS): 8204135: jtreg: Fix failing RTM test TestUseRTMXendForLockBusy In-Reply-To: <798cdc2a-ad0a-423f-351b-a8fc9eefc942@linux.vnet.ibm.com> References: <798cdc2a-ad0a-423f-351b-a8fc9eefc942@linux.vnet.ibm.com> Message-ID: <9cfd785a819e4b4e93660e8644304cff@sap.com> Hi Gustavo, I had a look at your fix. As I understand the test it's just what was intended to do. Also, it fixed the test in our runs. Reviewed. I would volunteer to sponsor this. Best regards, Goetz. > -----Original Message----- > From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] > Sent: Donnerstag, 31. Mai 2018 04:05 > To: hotspot-compiler-dev at openjdk.java.net; igor.ignatyev at oracle.com > Cc: Lindenmaier, Goetz ; Doerr, Martin > > Subject: RFR(XS): 8204135: jtreg: Fix failing RTM test > TestUseRTMXendForLockBusy > > Hi, > > Could the following change be reviewed please? > > webrev: http://cr.openjdk.java.net/~gromero/8204135/v1 > bug : https://bugs.openjdk.java.net/browse/JDK-8204135 > > It fixes currently failing RTM test "TestUseRTMXendForLockBusy" by > changing > in which cases UseRTMForStackLocks flags must be enabled/disabled. > > I could not track down on the timeline when exactly that test stopped to > pass, however my understanding is that if inflateMonitor is 'false' that > should /not/ imply that UseRTMForStackLocks is also 'false'. Thus I > understand that for this particular test if inflated monitors are used, > then UseRTMForStackLocks has to be disabled, i.e. 'false'. On the other > hand, if inflated monitors are /not/ used, then UseRTMForStackLocks must > be > enabled. > > Currently the test is failing for the following cases where inflateMonitor > is 'false', because it implies that UseRTMForStackLocks is disabled and so > no abort statistics is generated (which is correct from the JVM's > perspective): > > // stack lock, xabort on lock busy > verifyXendForLockBusy(false, false); > // stack lock, xend on lock busy > verifyXendForLockBusy(false, true); > > In other words, "stack lock" case should imply UseRTMForStackLocks = 'true', > not 'false'. > > Cases: > // inflated lock, xabort on lock busy > verifyXendForLockBusy(true, false); > // inflated lock, xend on lock busy > verifyXendForLockBusy(true, true); > > are not failing because UseRTMForStackLocks = 'true' and they will generate > proper abort statistics when +UseRTMXendForLockBusy ('xend' is used to > finish the transaction) or when -UseRTMXendForLockBusy ('xabort' is used > to finish the transaction). > > So, in summing up: (a) inflated lock cases are not being tested correctly > (since UseRTMForStackLocks is always enabled) and (b) stack lock cases are > failing because UseRTMForStackLocks is always disabled. > > @Igor, it's a long time ago, but maybe you recall some details on that > test... :-) > > > Thank you. > > Best regards, > Gustavo From nils.eliasson at oracle.com Fri Jun 15 13:20:39 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 15 Jun 2018 15:20:39 +0200 Subject: RFR(S): 8205107: assert(c->Opcode() == Op_SafePoint) failed: broken outer loop In-Reply-To: References: Message-ID: Thank you! // N On 2018-06-15 15:12, Roland Westrelin wrote: >> Here is the correct one: >> http://cr.openjdk.java.net/~neliasso/8205107/webrev.02/ > Looks ok to me. > > Roland. From gromero at linux.vnet.ibm.com Fri Jun 15 13:54:22 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 15 Jun 2018 10:54:22 -0300 Subject: RFR(XS): 8204135: jtreg: Fix failing RTM test TestUseRTMXendForLockBusy In-Reply-To: <9cfd785a819e4b4e93660e8644304cff@sap.com> References: <798cdc2a-ad0a-423f-351b-a8fc9eefc942@linux.vnet.ibm.com> <9cfd785a819e4b4e93660e8644304cff@sap.com> Message-ID: <42f56da6-ee70-9034-12b5-158d7e465f97@linux.vnet.ibm.com> Hi Goetz, On 06/15/2018 10:12 AM, Lindenmaier, Goetz wrote: > Hi Gustavo, > > I had a look at your fix. As I understand the test it's just > what was intended to do. Also, it fixed the test in our runs. > > Reviewed. > > I would volunteer to sponsor this. Thank you so much. Best regards, Gustavo > Best regards, > Goetz. > >> -----Original Message----- >> From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] >> Sent: Donnerstag, 31. Mai 2018 04:05 >> To: hotspot-compiler-dev at openjdk.java.net; igor.ignatyev at oracle.com >> Cc: Lindenmaier, Goetz ; Doerr, Martin >> >> Subject: RFR(XS): 8204135: jtreg: Fix failing RTM test >> TestUseRTMXendForLockBusy >> >> Hi, >> >> Could the following change be reviewed please? >> >> webrev: http://cr.openjdk.java.net/~gromero/8204135/v1 >> bug : https://bugs.openjdk.java.net/browse/JDK-8204135 >> >> It fixes currently failing RTM test "TestUseRTMXendForLockBusy" by >> changing >> in which cases UseRTMForStackLocks flags must be enabled/disabled. >> >> I could not track down on the timeline when exactly that test stopped to >> pass, however my understanding is that if inflateMonitor is 'false' that >> should /not/ imply that UseRTMForStackLocks is also 'false'. Thus I >> understand that for this particular test if inflated monitors are used, >> then UseRTMForStackLocks has to be disabled, i.e. 'false'. On the other >> hand, if inflated monitors are /not/ used, then UseRTMForStackLocks must >> be >> enabled. >> >> Currently the test is failing for the following cases where inflateMonitor >> is 'false', because it implies that UseRTMForStackLocks is disabled and so >> no abort statistics is generated (which is correct from the JVM's >> perspective): >> >> // stack lock, xabort on lock busy >> verifyXendForLockBusy(false, false); >> // stack lock, xend on lock busy >> verifyXendForLockBusy(false, true); >> >> In other words, "stack lock" case should imply UseRTMForStackLocks = 'true', >> not 'false'. >> >> Cases: >> // inflated lock, xabort on lock busy >> verifyXendForLockBusy(true, false); >> // inflated lock, xend on lock busy >> verifyXendForLockBusy(true, true); >> >> are not failing because UseRTMForStackLocks = 'true' and they will generate >> proper abort statistics when +UseRTMXendForLockBusy ('xend' is used to >> finish the transaction) or when -UseRTMXendForLockBusy ('xabort' is used >> to finish the transaction). >> >> So, in summing up: (a) inflated lock cases are not being tested correctly >> (since UseRTMForStackLocks is always enabled) and (b) stack lock cases are >> failing because UseRTMForStackLocks is always disabled. >> >> @Igor, it's a long time ago, but maybe you recall some details on that >> test... :-) >> >> >> Thank you. >> >> Best regards, >> Gustavo > From vladimir.kozlov at oracle.com Fri Jun 15 14:41:54 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 15 Jun 2018 07:41:54 -0700 Subject: [11] RFR(XS) 8202948: C2: assert(init_offset >= 0) failed: positive offset from object start In-Reply-To: References: <30d6bc63-cdc7-7f71-ef1a-e3b6e45244fb@oracle.com> <856048b9-5736-300d-ed9b-e2b0b4da7a63@oracle.com> Message-ID: Thank you, Tobias Vladimir On 6/14/18 11:35 PM, Tobias Hartmann wrote: > Hi Vladimir, > > looks good, thanks for adding the test. > > Best regards, > Tobias > > On 14.06.2018 22:51, Vladimir Kozlov wrote: >> I added test and ran it on all platforms: >> >> http://cr.openjdk.java.net/~kvn/8202948/webrev.01/ >> >> Thanks, >> Vladimir >> >> On 6/14/18 8:41 AM, Vladimir Kozlov wrote: >>> Thank you, Tobias >>> >>> Yes, I need to add test. >>> >>> Thanks, >>> Vladimir >>> >>> On 6/14/18 12:07 AM, Tobias Hartmann wrote: >>>> Hi Vladimir, >>>> >>>> looks good to me but shouldn't we add the test (looks like you came up with a very simple version)? >>>> >>>> Thanks, >>>> Tobias >>>> >>>> On 13.06.2018 19:14, Vladimir Kozlov wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8202948 >>>>> >>>>> Predicates and Range checks before main loop will not help since they are runtime checks and limit >>>>> is not constant. The problem happens during compilation because vectorization is attempted for >>>>> over-unrolling loop which will not be executed in runtime (dead loop). Stride is negative (-3) >>>>> value >>>>> and initial is 2 - loop will be executed at least once (or never) because of other conditions in >>>>> code. C2 did not recognize this because the test fails only with -Xcomp when profiling data is no >>>>> available (it passed without -Xcomp). >>>>> >>>>> Simplest fix is to convert the assert into compilation check which will skip superword optimization >>>>> in such case. >>>>> >>>>> diff -r 0d47e89382ed src/hotspot/share/opto/superword.cpp >>>>> --- a/src/hotspot/share/opto/superword.cpp >>>>> +++ b/src/hotspot/share/opto/superword.cpp >>>>> @@ -887,7 +887,9 @@ >>>>> ??? if (init_nd->is_Con() && p.invar() == NULL) { >>>>> ????? int init = init_nd->bottom_type()->is_int()->get_con(); >>>>> ????? int init_offset = init * p.scale_in_bytes() + offset; >>>>> -??? assert(init_offset >= 0, "positive offset from object start"); >>>>> +??? if (init_offset < 0) { // negative offset from object start? >>>>> +????? return false;??????? // may happen in dead loop >>>>> +??? } >>>>> ????? if (vw % span == 0) { >>>>> ??????? // If vm is a multiple of span, we use formula (1). >>>>> ??????? if (span > 0) { >>>>> >>>>> Test passed with and without Predicates with this fix. >>>>> >>>>> Tested with tier1, tier2, precheckin-xcomp >>>>> From vladimir.kozlov at oracle.com Fri Jun 15 15:20:37 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 15 Jun 2018 08:20:37 -0700 Subject: [11] RFR(XS) 8202948: C2: assert(init_offset >= 0) failed: positive offset from object start In-Reply-To: References: <30d6bc63-cdc7-7f71-ef1a-e3b6e45244fb@oracle.com> <856048b9-5736-300d-ed9b-e2b0b4da7a63@oracle.com> Message-ID: <168f63a1-8824-c61b-53ee-35a757199c18@oracle.com> Thank you, Roland Vladimir On 6/15/18 12:27 AM, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~kvn/8202948/webrev.01/ > > That looks good to me. > > Roland. > From vladimir.kozlov at oracle.com Fri Jun 15 15:46:05 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 15 Jun 2018 08:46:05 -0700 Subject: RFR(S): 8205107: assert(c->Opcode() == Op_SafePoint) failed: broken outer loop In-Reply-To: References: Message-ID: Hi Nils, I don't see link to testing in bug report. Roland, why we need to keep Safepoint in Outer loop if we have call? Why we even do strip mining if we have a call in a loop? Thanks, Vladimir On 6/15/18 5:49 AM, Nils Eliasson wrote: > Hi, > > Here is the correct one: > http://cr.openjdk.java.net/~neliasso/8205107/webrev.02/ > > Thanks, > > Nils > > > On 2018-06-15 14:53, Roland Westrelin wrote: >> Hi Nils, >> >>> http://cr.openjdk.java.net/~neliasso/8205107/webrev.01/ >> Looks like the webrev for the wrong bug. >> >> Roland. > From dmitrij.pochepko at bell-sw.com Fri Jun 15 17:04:02 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 15 Jun 2018 20:04:02 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly In-Reply-To: References: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> <9d9a49a2-bf30-5db8-8273-98162d543820@redhat.com> <6d92e1a2-40a4-ecea-e098-2581400c2ec8@bell-sw.com> <69623a1a-a2ac-ed3e-ff29-7ccce0a8b9cc@bell-sw.com> Message-ID: Hi Andrew, Thank you for your suggestion. It does look better this way. The change you suggested also passed all jtreg tests in fastdebug mode. New webrev: http://cr.openjdk.java.net/~dpochepk/8204473/webrev.03/ Thanks, Dmitrij On 07.06.2018 14:32, Andrew Haley wrote: > On 06/06/2018 07:33 PM, Dmitrij Pochepko wrote: >> large test cycle passed. no new failures(although lots of JDK-8204331 >> failures). >> hg import > As John Rose put it, we should clean up as we go. Try this. > From aph at redhat.com Fri Jun 15 17:19:14 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 15 Jun 2018 18:19:14 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly In-Reply-To: References: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> <9d9a49a2-bf30-5db8-8273-98162d543820@redhat.com> <6d92e1a2-40a4-ecea-e098-2581400c2ec8@bell-sw.com> <69623a1a-a2ac-ed3e-ff29-7ccce0a8b9cc@bell-sw.com> Message-ID: Hi, On 06/15/2018 06:04 PM, Dmitrij Pochepko wrote: > Thank you for your suggestion. It does look better this way. > > The change you suggested also passed all jtreg tests in fastdebug mode. > > New webrev: http://cr.openjdk.java.net/~dpochepk/8204473/webrev.03/ OK, cool. That looks like a maintainability improvement, thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitry.chuyko at bell-sw.com Fri Jun 15 17:20:29 2018 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Fri, 15 Jun 2018 20:20:29 +0300 Subject: [11] RFR(XXS): 8198719: MethodHandleHelper.linkToStatic should drop MH arg Message-ID: Hello, Please review a small fix in InvokerSignatureMismatch MH test. Unnecessary parameter was removed from linkToStatic helper method. The test still passes. bug: https://bugs.openjdk.java.net/browse/JDK-8198719 webrev: http://cr.openjdk.java.net/~dchuyko/8198719/webrev.00/ -Dmitry From vladimir.x.ivanov at oracle.com Fri Jun 15 17:24:20 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 15 Jun 2018 20:24:20 +0300 Subject: [11] RFR(XXS): 8198719: MethodHandleHelper.linkToStatic should drop MH arg In-Reply-To: References: Message-ID: <10514543-e770-ae13-015c-e6b6fe2cf894@oracle.com> Looks good. Best regards, Vladimir Ivanov On 15/06/2018 20:20, Dmitry Chuyko wrote: > Hello, > > Please review a small fix in InvokerSignatureMismatch MH test. > Unnecessary parameter was removed from linkToStatic helper method. The > test still passes. > > bug: https://bugs.openjdk.java.net/browse/JDK-8198719 > webrev: http://cr.openjdk.java.net/~dchuyko/8198719/webrev.00/ > > -Dmitry > From dmitrij.pochepko at bell-sw.com Fri Jun 15 17:54:12 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 15 Jun 2018 20:54:12 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly In-Reply-To: References: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> <9d9a49a2-bf30-5db8-8273-98162d543820@redhat.com> <6d92e1a2-40a4-ecea-e098-2581400c2ec8@bell-sw.com> <69623a1a-a2ac-ed3e-ff29-7ccce0a8b9cc@bell-sw.com> Message-ID: Thank you for review! On 15.06.2018 20:19, Andrew Haley wrote: > Hi, > > On 06/15/2018 06:04 PM, Dmitrij Pochepko wrote: > >> Thank you for your suggestion. It does look better this way. >> >> The change you suggested also passed all jtreg tests in fastdebug mode. >> >> New webrev: http://cr.openjdk.java.net/~dpochepk/8204473/webrev.03/ > OK, cool. That looks like a maintainability improvement, thanks. > From dmitrij.pochepko at bell-sw.com Fri Jun 15 17:54:19 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 15 Jun 2018 20:54:19 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: References: <56064140-2348-acb5-1859-5ac4c9e6ee30@redhat.com> <5B17C282.6030009@bell-sw.com> Message-ID: Now that dependency of this patch is done(8204473 - AARCH64: register post-index addressing mode is not supported directly), is it a good time to review this one? Thanks, Dmitrij On 06.06.2018 16:43, Dmitrij Pochepko wrote: > > On 06.06.2018 15:37, Andrew Haley wrote: >> On 06/06/2018 01:30 PM, Dmitrij Pochepko wrote: >>> You can take a look here: >>> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/cpu/aarch64/assembler_aarch64.hpp#l2068 >>> >>> As you can see, switch by a.getMode() has 3 cases: >>> >>> 1) "base_plus_offset" (expecting only 0 offset. This is for "base >>> register, no offset" ld/st addressing mode >>> 2) "post"- this if for immediate post-index mode >>> 3) "base_plus_offset_reg" which is treated further as register >>> post-index mode. >> Well, yes, but I can't see that being [ab]used anywhere in the existing >> source. >> >>> I'll create separate issue and patch, which will add new address mode >>> (something like: "post_reg"). And final syntax for such mode usage will >>> be ... Address(post(, )), which makes it more readable. >> Yes.? And please disallow the use of Address(reg, reg) while you're >> doing >> that. >> >>> After that I'll update this fpu ld/st optimization patch accordingly. >> OK. >> > > Please take a look at webrev.02: > http://cr.openjdk.java.net/~dpochepk/8204353/webrev.02/ > > The only change is to match changes in JDK-8204473 -? AARCH64: > register post-index addressing mode is not supported directly > > 2 entries of "Address(sp, rscratch1)" is now "Address(post(sp, > rscratch1))" > > > I relaunched hotspot jtreg compiler tests as sanity with both patches. > No new failures found. > > > Thanks, > > Dmitrij > From dean.long at oracle.com Fri Jun 15 18:37:05 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 15 Jun 2018 11:37:05 -0700 Subject: [11] RFR(XXS): 8198719: MethodHandleHelper.linkToStatic should drop MH arg In-Reply-To: <10514543-e770-ae13-015c-e6b6fe2cf894@oracle.com> References: <10514543-e770-ae13-015c-e6b6fe2cf894@oracle.com> Message-ID: <75fe5351-3da2-f253-4939-6eda8f999ef3@oracle.com> +1 dl On 6/15/18 10:24 AM, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 15/06/2018 20:20, Dmitry Chuyko wrote: >> Hello, >> >> Please review a small fix in InvokerSignatureMismatch MH test. >> Unnecessary parameter was removed from linkToStatic helper method. >> The test still passes. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8198719 >> webrev: http://cr.openjdk.java.net/~dchuyko/8198719/webrev.00/ >> >> -Dmitry >> From aph at redhat.com Mon Jun 18 08:57:13 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Jun 2018 09:57:13 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: References: <56064140-2348-acb5-1859-5ac4c9e6ee30@redhat.com> <5B17C282.6030009@bell-sw.com> Message-ID: On 06/06/2018 02:43 PM, Dmitrij Pochepko wrote: > Please take a look at webrev.02: > http://cr.openjdk.java.net/~dpochepk/8204353/webrev.02/ > > The only change is to match changes in JDK-8204473 -? AARCH64: register > post-index addressing mode is not supported directly OK, thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rwestrel at redhat.com Mon Jun 18 09:00:54 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 18 Jun 2018 11:00:54 +0200 Subject: RFR(L): 8203197: C2: consider all paths in loop body for loop predication In-Reply-To: References: Message-ID: http://cr.openjdk.java.net/~roland/8203197/webrev.01/ Incremental change: http://cr.openjdk.java.net/~roland/8203197/webrev.00-01/ The new webrev doesn't include the MDO change anymore as it was pushed under a separate CR. I fixed the issues that Nils reported as well. Also, to properly leverage the MDO change, I realized that the previous patch was not sufficient: ideally we would want a profile_predicate trap to be recorded in the header of an existing profile data entry but there might not be one where the predicates are added (in the loop header). To work around that problem, the new patch tries to add the predicates at a if that dominates the loop header. Roland. From martin.doerr at sap.com Mon Jun 18 09:22:36 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 18 Jun 2018 09:22:36 +0000 Subject: RFR(M): 8204240: Extend MDO to allow more reasons to be recorded per bci In-Reply-To: References: <9a4cb0ad-1062-3738-bfc0-fb2177c5627c@oracle.com> Message-ID: <3d174004374f4d119fe52186de6c0017@sap.com> Hi Roland, we just noticed that this change causes a build warning on Windows 32 bit: jdk\src\hotspot\share\oops/methodData.hpp(142) : warning C4293: '<<' : shift count negative or too big, undefined behavior I think trap_mask is incorrect for 32 bit and should get fixed. Best regards, Martin From dmitrij.pochepko at bell-sw.com Mon Jun 18 11:34:44 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Mon, 18 Jun 2018 14:34:44 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: References: <56064140-2348-acb5-1859-5ac4c9e6ee30@redhat.com> <5B17C282.6030009@bell-sw.com> Message-ID: Thank you for review! On 18.06.2018 11:57, Andrew Haley wrote: > On 06/06/2018 02:43 PM, Dmitrij Pochepko wrote: >> Please take a look at webrev.02: >> http://cr.openjdk.java.net/~dpochepk/8204353/webrev.02/ >> >> The only change is to match changes in JDK-8204473 -? AARCH64: register >> post-index addressing mode is not supported directly > OK, thanks. > From rwestrel at redhat.com Mon Jun 18 12:22:13 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 18 Jun 2018 14:22:13 +0200 Subject: [11] RFR(M): 8205033: [REDO] Induction variable of over-unrolled loop conflicts with range checks In-Reply-To: <42367890-a5eb-1413-6a1d-1a383953d5a1@oracle.com> References: <42367890-a5eb-1413-6a1d-1a383953d5a1@oracle.com> Message-ID: > Incremental changes: > http://cr.openjdk.java.net/~thartmann/8205033/webrev.inc/ > > Full webrev: > http://cr.openjdk.java.net/~thartmann/8205033/webrev.00/ That looks good to me. Roland. From rwestrel at redhat.com Mon Jun 18 12:26:48 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 18 Jun 2018 14:26:48 +0200 Subject: RFR(M): 8204240: Extend MDO to allow more reasons to be recorded per bci In-Reply-To: <3d174004374f4d119fe52186de6c0017@sap.com> References: <9a4cb0ad-1062-3738-bfc0-fb2177c5627c@oracle.com> <3d174004374f4d119fe52186de6c0017@sap.com> Message-ID: Hi Martin, > we just noticed that this change causes a build warning on Windows 32 bit: > jdk\src\hotspot\share\oops/methodData.hpp(142) : warning C4293: '<<' : shift count negative or too big, undefined behavior > > I think trap_mask is incorrect for 32 bit and should get fixed. Thanks for reporting that issue. What about the patch below? Roland. diff --git a/src/hotspot/share/oops/methodData.hpp b/src/hotspot/share/oops/methodData.hpp --- a/src/hotspot/share/oops/methodData.hpp +++ b/src/hotspot/share/oops/methodData.hpp @@ -139,7 +139,7 @@ // // The trap_state is collected only if ProfileTraps is true. trap_bits = 1+31, // 31: enough to distinguish [0..Reason_RECORDED_LIMIT]. - trap_mask = right_n_bits(trap_bits), + trap_mask = -1, first_flag = 0 }; From tobias.hartmann at oracle.com Mon Jun 18 12:29:50 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 18 Jun 2018 14:29:50 +0200 Subject: [11] RFR(M): 8205033: [REDO] Induction variable of over-unrolled loop conflicts with range checks In-Reply-To: References: <42367890-a5eb-1413-6a1d-1a383953d5a1@oracle.com> Message-ID: <1f6eeb04-3a5c-07c7-0898-7708fbdc239d@oracle.com> Hi Roland, thanks for the review! Best regards, Tobias On 18.06.2018 14:22, Roland Westrelin wrote: > >> Incremental changes: >> http://cr.openjdk.java.net/~thartmann/8205033/webrev.inc/ >> >> Full webrev: >> http://cr.openjdk.java.net/~thartmann/8205033/webrev.00/ > > That looks good to me. > > Roland. > From rwestrel at redhat.com Mon Jun 18 13:41:24 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 18 Jun 2018 15:41:24 +0200 Subject: RFR(S): 8205107: assert(c->Opcode() == Op_SafePoint) failed: broken outer loop In-Reply-To: References: Message-ID: > Roland, why we need to keep Safepoint in Outer loop if we have call? I double checked with a simple test case and we don't keep the safepoint if there's a call so it's indeed strange that we would need Nils' patch. Roland. From martin.doerr at sap.com Mon Jun 18 13:43:47 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 18 Jun 2018 13:43:47 +0000 Subject: RFR(M): 8204240: Extend MDO to allow more reasons to be recorded per bci In-Reply-To: References: <9a4cb0ad-1062-3738-bfc0-fb2177c5627c@oracle.com> <3d174004374f4d119fe52186de6c0017@sap.com> Message-ID: <38b6b58039a94bddb86e62a01591184c@sap.com> Hi Roland, that helps. Unfortunately, there's a second place which breaks 32 bit: jdk/src/hotspot/share/runtime/threadHeapSampler.cpp(50) : warning C4293: '<<' : shift count negative or too big, undefined behavior I'll open a bug and fix both ones. Best regards, Martin -----Original Message----- From: Roland Westrelin [mailto:rwestrel at redhat.com] Sent: Montag, 18. Juni 2018 14:27 To: Doerr, Martin ; hotspot-compiler-dev at openjdk.java.net Subject: RE: RFR(M): 8204240: Extend MDO to allow more reasons to be recorded per bci Hi Martin, > we just noticed that this change causes a build warning on Windows 32 bit: > jdk\src\hotspot\share\oops/methodData.hpp(142) : warning C4293: '<<' : shift count negative or too big, undefined behavior > > I think trap_mask is incorrect for 32 bit and should get fixed. Thanks for reporting that issue. What about the patch below? Roland. diff --git a/src/hotspot/share/oops/methodData.hpp b/src/hotspot/share/oops/methodData.hpp --- a/src/hotspot/share/oops/methodData.hpp +++ b/src/hotspot/share/oops/methodData.hpp @@ -139,7 +139,7 @@ // // The trap_state is collected only if ProfileTraps is true. trap_bits = 1+31, // 31: enough to distinguish [0..Reason_RECORDED_LIMIT]. - trap_mask = right_n_bits(trap_bits), + trap_mask = -1, first_flag = 0 }; From nils.eliasson at oracle.com Mon Jun 18 14:26:07 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 18 Jun 2018 16:26:07 +0200 Subject: RFR(L): 8203197: C2: consider all paths in loop body for loop predication In-Reply-To: References: Message-ID: <7d4ea167-3a96-7d18-65f1-668e25cf00ed@oracle.com> Looks good! The split of the webrev made it much easier to digest. Thanks! // Nils On 2018-06-18 11:00, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8203197/webrev.01/ > > Incremental change: > > http://cr.openjdk.java.net/~roland/8203197/webrev.00-01/ > > The new webrev doesn't include the MDO change anymore as it was pushed > under a separate CR. I fixed the issues that Nils reported as well. > > Also, to properly leverage the MDO change, I realized that the previous > patch was not sufficient: ideally we would want a profile_predicate trap > to be recorded in the header of an existing profile data entry but there > might not be one where the predicates are added (in the loop > header). To work around that problem, the new patch tries to add the > predicates at a if that dominates the loop header. > > Roland. From rwestrel at redhat.com Mon Jun 18 15:21:23 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 18 Jun 2018 17:21:23 +0200 Subject: RFR(L): 8203197: C2: consider all paths in loop body for loop predication In-Reply-To: <7d4ea167-3a96-7d18-65f1-668e25cf00ed@oracle.com> References: <7d4ea167-3a96-7d18-65f1-668e25cf00ed@oracle.com> Message-ID: Thanks for the review, Nils. Roland. From kevin.walls at oracle.com Mon Jun 18 16:06:01 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Mon, 18 Jun 2018 17:06:01 +0100 Subject: [8u] RFR 8160748: Inconsistent types for ideal_reg Message-ID: <152cf995-e19d-7ed2-ed59-3dc1c818878d@oracle.com> Hi, I'd like to get a review of this backport from 10 to 8u: 8160748: Inconsistent types for ideal_reg JBS: https://bugs.openjdk.java.net/browse/JDK-8160748 Backporting this fixes a compile time error when testing a later compiler on Windows (e.g. VS2017). 10 changeset: http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/d0f9cd0ff128 10 review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-July/023705.html This largely imports. Various copyright dates don't import, also these files don't exist in the jdk8u-dev repo: src/cpu/aarch64/vm/aarch64.ad src/cpu/arm/vm/arm.ad src/cpu/s390/vm/s390.ad Also: src/share/vm/opto/reg_split.cpp: get_spillcopy_wide is different (assert) so didn't patch automatically src/share/vm/opto/coalesce.cpp: In 8u we don't have the same calls to m->ideal_reg() which use the result in an assert message, so they don't apply. Proposed 8u change: http://cr.openjdk.java.net/~kevinw/8160748/webrev.00/ Many thanks Kevin From dmitrij.pochepko at bell-sw.com Mon Jun 18 18:53:07 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Mon, 18 Jun 2018 21:53:07 +0300 Subject: RFR: 8189105: AARCH64: create intrinsic for sin and cos In-Reply-To: References: <4de41b0c-e318-c70f-a864-4f6c8bd14297@redhat.com> <5B12CAEF.8050105@bell-sw.com> <2bd89c11-d234-ceae-3b04-4c547ef5836c@redhat.com> Message-ID: Andrew, here is an updated webrev which addresses your suggestions: > Visibly identifying how the various register values and insns/blocks correspond to their original C source lines would be a big improvement. Explaining what these values represent as they are updated and what each insn/block achieves would be even better. Better still would be to define macro instructions in the assembler so that the generation can be viewed at the level of more abstract operations that reflect the numerical and mathematical transformations being performed. Finally, relating the whole to the underlying mathematical theory would be the cherry on the cake. Note that the original C code has comments with this level of detail and that code is far easier to follow than this assembler. I made the following changes: 1. Provided a high-level description of the algorithm and links to the literature I found useful when writing this 2. Each function is now accompanied with algorithm description and C pseudo code. 3. For each function? assumptions on registers and input are provided 4. The names for variables used in assembly is the same as that in pseudo code 5. Each function is split into blocks which correspond to pseudo-code. 6. Register reuse is marked with comments in assembly which helps link it to pseudo code. If you have any other ideas how to make the code easier to read and maintain I?m happy to improve it. updated webrev: http://cr.openjdk.java.net/~dpochepk/8189105/webrev.03/ Thanks, Dmitrij On 11.06.2018 18:07, Andrew Dinn wrote: > Hi Dimitrij, > > Apologies for not responding -- I have only just returned from holiday. > > On 04/06/18 16:50, Dmitrij Pochepko wrote: >> On 04.06.2018 13:59, Andrew Haley wrote: >>>> . . . >>>> > I don't really know how to review this. It's a lot of hand-carved >>>> > assembly code and it's very hard to read. It'd need to be very >>>> > thoroughly tested. >>>> >>>> It is a vectorized version of existing C code algorithm, >>> Which existing C code algorithm? >> this is a hotspot copy of fdlibm trigonometric functions in >> hotspot/src/share/runtime/sharedRuntimeTrig.cpp >> I added respective comment in intrinsic. > Thanks for providing this code and the additional comments. However, I > don't think this approaches anywhere near the requirements Andrew set > out in his initial review, requirements which I agree are absolutely > necessary. I can only repeat his recommendation that you look at the > Montgomery multiply code in stubGenerator_aarch64.cpp to get an idea of > the sort of detail that is needed to satisfactorily document an > implementation this complex. > > The two most important goals are to be able to > > 1) review the current code with a high degree of confidence that it is > correct > > 2) maintain this code without imposing an intolerable burden on > developers who might need to check it months from now > > Review will only be possible if the code is written in a way that makes > what it is doing clear enough to be able to judge that it is correct. > That is far from being the case as it stands. Saying it is the same as > the C code modulo a few optimizations is nothing like enough. Visibly > identifying how the various register values and insns/blocks correspond > to their original C source lines would be a big improvement. Explaining > what these values represent as they are updated and what each insn/block > achieves would be even better. Better still would be to define macro > instructions in the assembler so that the generation can be viewed at > the level of more abstract operations that reflect the numerical and > mathematical transformations being performed. Finally, relating the > whole to the underlying mathematical theory would be the cherry on the > cake. Note that the original C code has comments with this level of > detail and that code is far easier to follow than this assembler. So, > all the more reason for the same or more commentary here. > > Maintenance is an issue *whether or not* the current code is correct. > Someone will inevitably at some point be faced with the following > dilemma: possibly, locate a bug in the current implementation; or, more > likely, reassure yourself that the code is correct before proceeding to > diagnose the real problem elsewhere. The current code is a fly-trap and > a piece of software as large and mature as OpenJDK has more than enough > complexity without adding fly-traps into the mix. > > Note that neither of these goals are going to be met by testing, no > matter how exhaustive. Also, don't feel singled out by these reviews. > Andrew and I are not suggesting this as a matter of form. We know how > important this is because we have tested and reviewed*** an immense > amount of much less complex code in getting this port to where it is now > and learned a great deal from that experience. We have only been able to > identify and fix the many bugs that have turned up /after/ extensive > review because we tried very hard to keep the code as clear and well > documented as possible (n.b. we also added lots of asserts to validate > assumptions). > > That is not something specific that we did off our own bat. It is > actually the expected standard for JVM code, shared or cpu-specific. > That standard has not always been lived up to but it is steadily > improving. The Intel versions of these intrinsics in the x86 are indeed > a notable lapse (I believe they were culled from Intel's C compiler > output). However, their failings do not excuse repeating the same > mistake for AArch64. > > *** n.b contrary to assumptions expressed in some recent threads Andrew > is not the only reviewer for AArch64 code. In particular, every line of > his code has been reviewed by me and/or a handful of other reviewers > from the day we started this port. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From vladimir.kozlov at oracle.com Mon Jun 18 19:10:26 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 18 Jun 2018 12:10:26 -0700 Subject: [8u] RFR 8160748: Inconsistent types for ideal_reg In-Reply-To: <152cf995-e19d-7ed2-ed59-3dc1c818878d@oracle.com> References: <152cf995-e19d-7ed2-ed59-3dc1c818878d@oracle.com> Message-ID: <1ffe2157-50c1-7a5a-5ec9-92074af51d29@oracle.com> Looks good. Thanks, Vladimir On 6/18/18 9:06 AM, Kevin Walls wrote: > Hi, > > I'd like to get a review of this backport from 10 to 8u: > > 8160748: Inconsistent types for ideal_reg > JBS: https://bugs.openjdk.java.net/browse/JDK-8160748 > > Backporting this fixes a compile time error when testing a later > compiler on Windows (e.g. VS2017). > > 10 changeset: > http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/d0f9cd0ff128 > > 10 review thread: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-July/023705.html > > > This largely imports.? Various copyright dates don't import, also these > files don't exist in the jdk8u-dev repo: > src/cpu/aarch64/vm/aarch64.ad > src/cpu/arm/vm/arm.ad > src/cpu/s390/vm/s390.ad > > Also: > src/share/vm/opto/reg_split.cpp: > get_spillcopy_wide is different (assert) so didn't patch automatically > > src/share/vm/opto/coalesce.cpp: > In 8u we don't have the same calls to m->ideal_reg() which use the > result in an assert message, so they don't apply. > > Proposed 8u change: http://cr.openjdk.java.net/~kevinw/8160748/webrev.00/ > > Many thanks > Kevin > From vladimir.kozlov at oracle.com Mon Jun 18 19:18:16 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 18 Jun 2018 12:18:16 -0700 Subject: RFR(L): 8203197: C2: consider all paths in loop body for loop predication In-Reply-To: References: Message-ID: Good. I will submit testing with this patch. Thanks, Vladimir On 6/18/18 2:00 AM, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8203197/webrev.01/ > > Incremental change: > > http://cr.openjdk.java.net/~roland/8203197/webrev.00-01/ > > The new webrev doesn't include the MDO change anymore as it was pushed > under a separate CR. I fixed the issues that Nils reported as well. > > Also, to properly leverage the MDO change, I realized that the previous > patch was not sufficient: ideally we would want a profile_predicate trap > to be recorded in the header of an existing profile data entry but there > might not be one where the predicates are added (in the loop > header). To work around that problem, the new patch tries to add the > predicates at a if that dominates the loop header. > > Roland. > From vladimir.kozlov at oracle.com Mon Jun 18 19:29:28 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 18 Jun 2018 12:29:28 -0700 Subject: [11] RFR(M): 8205033: [REDO] Induction variable of over-unrolled loop conflicts with range checks In-Reply-To: References: <42367890-a5eb-1413-6a1d-1a383953d5a1@oracle.com> Message-ID: <86d765fa-99b2-0d87-c683-4cf660ff6b66@oracle.com> +1 Vladimri On 6/18/18 5:22 AM, Roland Westrelin wrote: > >> Incremental changes: >> http://cr.openjdk.java.net/~thartmann/8205033/webrev.inc/ >> >> Full webrev: >> http://cr.openjdk.java.net/~thartmann/8205033/webrev.00/ > > That looks good to me. > > Roland. > From igor.veresov at oracle.com Tue Jun 19 01:28:11 2018 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 18 Jun 2018 18:28:11 -0700 Subject: RFR(S) 8204209: [Graal] Compilation fails during nmethod printing with "assert(bci == 0 || 0 <= bci && bci < code_size()) failed: illegal bci" Message-ID: Make hotspot tolerate negative placeholder BCIs that are produced by Graal. Should this fix be deemed acceptable I?ll backport it to graal-jvmci-8. JBS: https://bugs.openjdk.java.net/browse/JDK-8204209 Webrev: http://cr.openjdk.java.net/~iveresov/8204209/webrev/ Thanks, igor From vladimir.kozlov at oracle.com Tue Jun 19 05:12:28 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 18 Jun 2018 22:12:28 -0700 Subject: RFR(S) 8204209: [Graal] Compilation fails during nmethod printing with "assert(bci == 0 || 0 <= bci && bci < code_size()) failed: illegal bci" In-Reply-To: References: Message-ID: <489e17d8-c87e-2b78-37af-aee874821b04@oracle.com> CCing to runtime group. Seems fine to me. Thanks, Vladimir On 6/18/18 6:28 PM, Igor Veresov wrote: > Make hotspot tolerate negative placeholder BCIs that are produced by Graal. > > Should this fix be deemed acceptable I?ll backport it to graal-jvmci-8. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8204209 > Webrev: http://cr.openjdk.java.net/~iveresov/8204209/webrev/ > > Thanks, > igor > From ekaterina.pavlova at oracle.com Tue Jun 19 05:26:36 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Mon, 18 Jun 2018 22:26:36 -0700 Subject: RFR(M): 8205207: Port Graal unit tests under jtreg Message-ID: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com> Hi All, please review porting of Graal unit tests under jtreg. The main idea of this porting is to keep Graal unit tests as is (located in src/jdk.internal.vm.compiler/share/classes/*.test) and run them similar way they are run in Graal project. To achieve this test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java helper class has been written which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to run specified set of Graal unit tests. The groups of Graal unit tests to run are defined in auto-generated test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests. New make/test/JtregGraalUnit.gmk is used to build Graal unit tests into jdk.vm.compiler.tests.jar and then install it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/. make/Main.gmk adds proper dependencies for build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal. test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg knows where to find Graal tests and libs. test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file defines "testName -> testPrefix [requiresStatement]" mapping which is used by test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to generate jtreg tests. test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was ported from mx project without any changes. JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html testing: new tests were executed as part of automatic HS testing for several months. thanks, -katya p.s. Igor Ignatyev volunteered to sponsor this change. From tobias.hartmann at oracle.com Tue Jun 19 07:21:04 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 19 Jun 2018 09:21:04 +0200 Subject: [11] RFR(M): 8205033: [REDO] Induction variable of over-unrolled loop conflicts with range checks In-Reply-To: <86d765fa-99b2-0d87-c683-4cf660ff6b66@oracle.com> References: <42367890-a5eb-1413-6a1d-1a383953d5a1@oracle.com> <86d765fa-99b2-0d87-c683-4cf660ff6b66@oracle.com> Message-ID: <648878ef-6c6e-06a4-60f3-3c7ef900cde7@oracle.com> Thanks, Vladimir! Best regards, Tobias On 18.06.2018 21:29, Vladimir Kozlov wrote: > +1 > > Vladimri > > On 6/18/18 5:22 AM, Roland Westrelin wrote: >> >>> Incremental changes: >>> http://cr.openjdk.java.net/~thartmann/8205033/webrev.inc/ >>> >>> Full webrev: >>> http://cr.openjdk.java.net/~thartmann/8205033/webrev.00/ >> >> That looks good to me. >> >> Roland. >> From rwestrel at redhat.com Tue Jun 19 07:45:54 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 19 Jun 2018 09:45:54 +0200 Subject: RFR(L): 8203197: C2: consider all paths in loop body for loop predication In-Reply-To: References: Message-ID: > Good. I will submit testing with this patch. Thank you! Roland. From tobias.hartmann at oracle.com Tue Jun 19 08:20:44 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 19 Jun 2018 10:20:44 +0200 Subject: [11] RFR(M): 8205033: [REDO] Induction variable of over-unrolled loop conflicts with range checks In-Reply-To: <42367890-a5eb-1413-6a1d-1a383953d5a1@oracle.com> References: <42367890-a5eb-1413-6a1d-1a383953d5a1@oracle.com> Message-ID: Hi, since JDK-8203197 was just pushed, I had to merge my changes again: http://cr.openjdk.java.net/~thartmann/8205033/webrev.01/ I will run some sanity testing and then push this. Thanks, Tobias On 15.06.2018 14:07, Tobias Hartmann wrote: > Hi, > > my initial patch for JDK-8203915 [1] failed because the computation of the value of the loop > induction variable at the end of the first iteration of the unrolled loop was wrong. As a result, > the predicate was incorrectly found to always fail and we hit a HaltNode (SIGILL) in compiled code. > > The problem is very easy to reproduce with the jdk/sun/security/tools/keytool/ tests, I therefore > did not add an additional regression test. The problematic loop looks like this: > > for (int i = 20; i > 0; i -= 4) { > array[i-1] = ... > array[i-2] = ... > array[i-3] = ... > array[i-4] = ... > } > > To make sure that the last array access is in bounds, we add a skeleton predicate of the form > > max_i - 4 = (init + stride + 1) - 4 > before the main loop and update the stride during unrolling. After unrolling 4 times, we know that > init <= 16 (because the pre-loop is executed at least once) and the stride is 4*-4 = -16. The > predicate is updated to: > > ( (int,16] - 16 + 1) - 4 = (int,-3] > which is always false. The computation of max_i is incorrect because the (fully) unrolled loop looks > like this: > > // i <= 16 > array[i-1] = ... > array[i-2] = ... > array[i-3] = ... > array[i-4] = ... > i -= 4; > array[i-1] = ... > array[i-2] = ... > array[i-3] = ... > array[i-4] = ... > i -= 4; > array[i-1] = ... > array[i-2] = ... > array[i-3] = ... > array[i-4] = ... > i -= 4; > array[i-1] = ... > array[i-2] = ... > array[i-3] = ... > array[i-4] = ... > // i <= 4 > > And therefore the value of i at the end of the iteration is max_i = init + stride - init_inc (where > 'init_inc' is the initial loop increment). The correct predicate looks like this: > > max_i - 4 = (init + stride - init_inc) - 4 = (16 - 16 + 4) -4 = 0 > Incremental changes: > http://cr.openjdk.java.net/~thartmann/8205033/webrev.inc/ > > Full webrev: > http://cr.openjdk.java.net/~thartmann/8205033/webrev.00/ > > The failing tests pass. I'm now testing with hs-tier1-3, jdk-tier1-3 and hs-precheckin-comp. I will > also rerun the benchmarks. > > Thanks, > Tobias > > [1] > https://bugs.openjdk.java.net/browse/JDK-8203915 > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-June/029250.html > From aph at redhat.com Tue Jun 19 09:46:02 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Jun 2018 10:46:02 +0100 Subject: TestFrames.java deoptimization Message-ID: <6a241492-65ba-6927-60dd-e3fd36cde976@redhat.com> Someone posted a question about inlining and deoptimization, but I can't find the original email. I have an answer, if you want to know. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rwestrel at redhat.com Tue Jun 19 09:53:48 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 19 Jun 2018 11:53:48 +0200 Subject: TestFrames.java deoptimization In-Reply-To: <6a241492-65ba-6927-60dd-e3fd36cde976@redhat.com> References: <6a241492-65ba-6927-60dd-e3fd36cde976@redhat.com> Message-ID: > Someone posted a question about inlining and deoptimization, but I can't > find the original email. I have an answer, if you want to know. It's: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-June/033060.html Roland. From aph at redhat.com Tue Jun 19 12:54:12 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Jun 2018 13:54:12 +0100 Subject: TestFrames.java deoptimization In-Reply-To: References: <6a241492-65ba-6927-60dd-e3fd36cde976@redhat.com> Message-ID: <0dc99298-e8c3-ae09-4ca8-586edd38400d@redhat.com> On 06/19/2018 10:53 AM, Roland Westrelin wrote: > It's: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-June/033060.html Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nils.eliasson at oracle.com Tue Jun 19 14:22:27 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 19 Jun 2018 16:22:27 +0200 Subject: RFR(S): 8205107: assert(c->Opcode() == Op_SafePoint) failed: broken outer loop In-Reply-To: References: Message-ID: <06ce5035-4eb9-d56f-0a46-7188c3e74b6c@oracle.com> I looked at it in a bit more detail. The call is a java/lang/Integer::valueOf that is considered a macro node so it is kept around until macro expansion which happens after the place where we hit the assert. So the call will go away. However SafepointNode::Identity does check: if( n0->is_Call() && n0->as_Call()->guaranteed_safepoint() ) { // Useless Safepoint, so remove it And CallNode::guaranteed_safepoint() is: // Are we guaranteed that this node is a safepoint? Not true for leaf calls and // for some macro nodes whose expansion does not have a safepoint on the fast path. virtual bool guaranteed_safepoint() { return true; } No check for call/macro-nodes is implemeted despite the comment! If I fix this the problem goes away. // Nils On 2018-06-18 15:41, Roland Westrelin wrote: >> Roland, why we need to keep Safepoint in Outer loop if we have call? > I double checked with a simple test case and we don't keep the safepoint > if there's a call so it's indeed strange that we would need Nils' patch. > > Roland. From dmitry.chuyko at bell-sw.com Tue Jun 19 14:40:29 2018 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Tue, 19 Jun 2018 17:40:29 +0300 Subject: [11] RFR(XS): 8205341: AARCH64: Clean up duplicate uzp1 & uzp2 instruction definition Message-ID: Hello, Please review a small fix for aarch64 instructions encoding. The fix removes duplicate definition of two instructions from assembler_aarch64.hpp. The only usage of that variant was in MacroAssembler::kernel_crc32 in case of -UseCRC32 +UseNeon. I changed it to use another definition and made testing comparing checksums for that case. rfe: https://bugs.openjdk.java.net/browse/JDK-8205341 webrev: http://cr.openjdk.java.net/~dchuyko/8205341/webrev.00/ -Dmitry From vladimir.kozlov at oracle.com Tue Jun 19 15:23:29 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Jun 2018 08:23:29 -0700 Subject: RFR(M): 8205207: Port Graal unit tests under jtreg In-Reply-To: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com> References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com> Message-ID: <2abe6529-cc0a-0221-fb37-6dbd177fa042@oracle.com> Hi Katya, Please, fix Copyright year in new files: test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit/com/oracle/mxtool/junit/* Thanks, Vladimir On 6/18/18 10:26 PM, Ekaterina Pavlova wrote: > Hi All, > > please review porting of Graal unit tests under jtreg. The main idea of > this porting is to keep Graal unit tests as is > (located in src/jdk.internal.vm.compiler/share/classes/*.test) and run > them similar way they are run in Graal project. > To achieve this > test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java > helper class has been written > which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to run > specified set of Graal unit tests. The groups of > Graal unit tests to run are defined in auto-generated > test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests. > > New make/test/JtregGraalUnit.gmk is used to build Graal unit tests into > jdk.vm.compiler.tests.jar and then install > it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/. > > make/Main.gmk adds proper dependencies for > build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal. > > test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg knows > where to find Graal tests and libs. > > test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file defines > "testName -> testPrefix [requiresStatement]" mapping > which is used by test/hotspot/jtreg/compiler/graalunit/generateTests.sh > script to generate jtreg tests. > > test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was ported > from mx project without any changes. > > > ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 > ?webrev: > http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html > testing: new tests were executed as part of automatic HS testing for > several months. > > > thanks, > -katya > > p.s. > ?Igor Ignatyev volunteered to sponsor this change. From vladimir.kozlov at oracle.com Tue Jun 19 16:01:27 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Jun 2018 09:01:27 -0700 Subject: RFR(S): 8205107: assert(c->Opcode() == Op_SafePoint) failed: broken outer loop In-Reply-To: <06ce5035-4eb9-d56f-0a46-7188c3e74b6c@oracle.com> References: <06ce5035-4eb9-d56f-0a46-7188c3e74b6c@oracle.com> Message-ID: <26c32258-1e42-01cd-fb64-0ff4cd4ff0b8@oracle.com> On 6/19/18 7:22 AM, Nils Eliasson wrote: > I looked at it in a bit more detail. > > The call is a java/lang/Integer::valueOf that is considered a macro node > so it is kept around until macro expansion which happens after the place > where we hit the assert. So the call will go away. I assume you are talking about eliminate_boxing_node() in macro expansion. > > However SafepointNode::Identity does check: > > if( n0->is_Call() && n0->as_Call()->guaranteed_safepoint() ) { > ????? // Useless Safepoint, so remove it > > And CallNode::guaranteed_safepoint() is: > > ? // Are we guaranteed that this node is a safepoint?? Not true for > leaf calls and > ? // for some macro nodes whose expansion does not have a safepoint on > the fast path. > ? virtual bool??????? guaranteed_safepoint()? { return true; } > > No check for call/macro-nodes is implemeted despite the comment! If I > fix this the problem goes away. It returns false for Allocate nodes which are macro nodes. That is what comment says. In case of boxing node I think we should add to CallStaticJavaNode class // Boxing call which is not used and will be removed. virtual bool guaranteed_safepoint() { return C->eliminate_boxing() && is_boxing_method() && (proj_out_or_null(TypeFunc::Parms) == NULL); } Vladimir > > // Nils > > > > On 2018-06-18 15:41, Roland Westrelin wrote: >>> Roland, why we need to keep Safepoint in Outer loop if we have call? >> I double checked with a simple test case and we don't keep the safepoint >> if there's a call so it's indeed strange that we would need Nils' patch. >> >> Roland. > From aph at redhat.com Tue Jun 19 16:15:22 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Jun 2018 17:15:22 +0100 Subject: [aarch64-port-dev ] [11] RFR(XS): 8205341: AARCH64: Clean up duplicate uzp1 & uzp2 instruction definition In-Reply-To: References: Message-ID: <372c7fc7-3434-e1ee-29ca-b77052235e77@redhat.com> On 06/19/2018 03:40 PM, Dmitry Chuyko wrote: > rfe: https://bugs.openjdk.java.net/browse/JDK-8205341 > webrev: http://cr.openjdk.java.net/~dchuyko/8205341/webrev.00/ That looks right. Thanks. -- 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 Tue Jun 19 17:18:00 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Jun 2018 10:18:00 -0700 Subject: RFR(S): 8205107: assert(c->Opcode() == Op_SafePoint) failed: broken outer loop In-Reply-To: <26c32258-1e42-01cd-fb64-0ff4cd4ff0b8@oracle.com> References: <06ce5035-4eb9-d56f-0a46-7188c3e74b6c@oracle.com> <26c32258-1e42-01cd-fb64-0ff4cd4ff0b8@oracle.com> Message-ID: On 6/19/18 9:01 AM, Vladimir Kozlov wrote: > On 6/19/18 7:22 AM, Nils Eliasson wrote: >> I looked at it in a bit more detail. >> >> The call is a java/lang/Integer::valueOf that is considered a macro >> node so it is kept around until macro expansion which happens after >> the place where we hit the assert. So the call will go away. > > I assume you are talking about eliminate_boxing_node() in macro expansion. > >> >> However SafepointNode::Identity does check: >> >> if( n0->is_Call() && n0->as_Call()->guaranteed_safepoint() ) { >> ?????? // Useless Safepoint, so remove it >> >> And CallNode::guaranteed_safepoint() is: >> >> ?? // Are we guaranteed that this node is a safepoint?? Not true for >> leaf calls and >> ?? // for some macro nodes whose expansion does not have a safepoint >> on the fast path. >> ?? virtual bool??????? guaranteed_safepoint()? { return true; } >> >> No check for call/macro-nodes is implemeted despite the comment! If I >> fix this the problem goes away. > > It returns false for Allocate nodes which are macro nodes. That is what > comment says. > > In case of boxing node I think we should add to CallStaticJavaNode class > > ? // Boxing call which is not used and will be removed. > ? virtual bool??????? guaranteed_safepoint()? { return > C->eliminate_boxing() && is_boxing_method() && > (proj_out_or_null(TypeFunc::Parms) == NULL); } Sorry, test should be reversed because it guarantee SP if call is *not* removed: virtual bool guaranteed_safepoint() { return !(C->eliminate_boxing() && is_boxing_method() && (proj_out_or_null(TypeFunc::Parms) == NULL)); } Vladimir > > Vladimir > >> >> // Nils >> >> >> >> On 2018-06-18 15:41, Roland Westrelin wrote: >>>> Roland, why we need to keep Safepoint in Outer loop if we have call? >>> I double checked with a simple test case and we don't keep the safepoint >>> if there's a call so it's indeed strange that we would need Nils' patch. >>> >>> Roland. >> From aph at redhat.com Tue Jun 19 17:46:00 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Jun 2018 18:46:00 +0100 Subject: RFR: 8189105: AARCH64: create intrinsic for sin and cos In-Reply-To: References: <4de41b0c-e318-c70f-a864-4f6c8bd14297@redhat.com> <5B12CAEF.8050105@bell-sw.com> <2bd89c11-d234-ceae-3b04-4c547ef5836c@redhat.com> Message-ID: <752dd93c-7a95-c674-08df-3e054f178196@redhat.com> On 06/18/2018 07:53 PM, Dmitrij Pochepko wrote: > If you have any other ideas how to make the code easier to read and > maintain I?m happy to improve it. That's great! Really, that's a vast improvement. Excellent work. One or two relatively minor things: Why do you say the polynomial in kernel_sin/kernel_cos is a Taylor series? There's no such comment in sharedRuntimeTrig.cpp, and I doubt it. I would have thought it was a least-maximum polynomial approximation, not a Taylor series. What's the point of keeping the doubles in tables in hex form? sharedRuntimeTrig.cpp doesn't do that, and it looks like obfuscation. Even if you must keep them as hex, at least move the comment which shows their true values next to their declaration, but I really can't see the point. It'd make the code much more readable if you lined up the comments, like so: fmovd(v28, v3); // t = r fmuld(v29, v2, v6); // w = v29 = fn * pio2_2 fsubd(v3, v28, v29); // r = t - w fsubd(v31, v28, v3); // v31 = (t - r) fsubd(v31, v29, v31); // v31 = w - (t - r) = - ((t - r) - w) fmaddd(v26, v2, v7, v31); // v26 = w = fn*pio2_2t - ((t - r) - w) fsubd(v4, v3, v26); // y[0] = r - w fmovd(jx, v4); lsl(jx, jx, 1); sub(tmp3, tmp5, jx, LSR, 32 + 20 + 1); // r7 = j-(((*(i0+(int*)&y[0]))>>20)&0x7ff); But it's probably not a great idea to make the code-super wide with the comments so you have to open a huge editor window. So, don't go crazy, but a little bit of white space like this makes it much easier to read. Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From erik.joelsson at oracle.com Tue Jun 19 21:00:14 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 19 Jun 2018 14:00:14 -0700 Subject: RFR(M): 8205207: Port Graal unit tests under jtreg In-Reply-To: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com> References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com> Message-ID: <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com> Hello, Please always include build-dev when reviewing build changes. In general this looks pretty good but there are some details that need fixing. (Aside from this particular review, I must state my reservation against all the special treatment graal is enjoying from a source and test layout and build perspective. My understanding here is that someone will have to regularly update the wrapper jtreg tests manually using the script. This in addition to having to implement this very convoluted redirection logic because the tests are in the wrong place. Wouldn't it make a lot more sense to put the complicated logic in the import procedure for graal source so that it would fit nicely into the OpenJDK source/build/test model, instead of adding more and more complicated workarounds in the OpenJDK build and test procedures?) On 2018-06-18 22:26, Ekaterina Pavlova wrote: > Hi All, > > please review porting of Graal unit tests under jtreg. The main idea > of this porting is to keep Graal unit tests as is > (located in src/jdk.internal.vm.compiler/share/classes/*.test) and run > them similar way they are run in Graal project. > To achieve this > test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java > helper class has been written > which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to run > specified set of Graal unit tests. The groups of > Graal unit tests to run are defined in auto-generated > test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests. > > New make/test/JtregGraalUnit.gmk is used to build Graal unit tests > into jdk.vm.compiler.tests.jar and then install > it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/. > GRAALUNIT_LIB is never defined (in the open). Since this is used in open makefiles, we need an open configure option to set it. To make things clearer, I would rename LIB_DIR to something like LIB_OUTPUTDIR to signal that this is a location to put files in, rather than read them from. FLATTEN has no effect in the SetupCopyFiles call since all the jar files found by wildcard can only be in one directory anyway. BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. Tests classes and jars should be built into $(SUPPORT_OUTPUTDIR)/test/... Please create a suitable sub directory there for the output from this makefile. The all and test-image targets are never called so no need to declare them. There are some style issues too. (Please see http://openjdk.java.net/groups/build/doc/code-conventions.html for details.) * 43 logic indent 2 spaces * 52 we like to put the ending )) on a new line with ', \' at the end of the line before * 58 continuation indent 4 spaces * 88, 89 please break long lines * 90 continuation indent 4 spaces * 99 continuation indent 4 spaces * 120 break before )) > make/Main.gmk adds proper dependencies for > build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal. > The target build-test-hotspot-jtreg-graal only needs to depend on exploded-image-optimize. The new graal specific targets should be guarded by INCLUDE_GRAAL in Main.gmk. Otherwise those targets will silently do nothing if invoked without graal. That means adding them to JVM_TEST_IMAGE_TARGETS needs to be conditional too. > test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg > knows where to find Graal tests and libs. > This needs to be duplicated for make/RunTest.gmk so that these tests work with "make run-test" as well. /Erik > test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file defines > "testName -> testPrefix [requiresStatement]" mapping > which is used by > test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to > generate jtreg tests. > > test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was > ported from mx project without any changes. > > > ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 > ?webrev: > http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html > testing: new tests were executed as part of automatic HS testing for > several months. > > > thanks, > -katya > > p.s. > ?Igor Ignatyev volunteered to sponsor this change. From doug.simon at oracle.com Tue Jun 19 21:10:11 2018 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 19 Jun 2018 23:10:11 +0200 Subject: RFR(M): 8205207: Port Graal unit tests under jtreg In-Reply-To: <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com> References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com> <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com> Message-ID: > On 19 Jun 2018, at 23:00, Erik Joelsson wrote: > > Hello, > > Please always include build-dev when reviewing build changes. > > In general this looks pretty good but there are some details that need fixing. > > (Aside from this particular review, I must state my reservation against all the special treatment graal is enjoying from a source and test layout and build perspective. My understanding here is that someone will have to regularly update the wrapper jtreg tests manually using the script. This in addition to having to implement this very convoluted redirection logic because the tests are in the wrong place. Wouldn't it make a lot more sense to put the complicated logic in the import procedure for graal source so that it would fit nicely into the OpenJDK source/build/test model, instead of adding more and more complicated workarounds in the OpenJDK build and test procedures?) Yes, the updategraalinopenjdk command[1] can be modified in anyway seen fit to make Graal a better citizen when copied to JDK. It would also be ok to add the jtreg commands in test source headers. -Doug [1] https://github.com/oracle/graal/blob/27288e546392f44ebf8107795647e0db155faf38/compiler/mx.compiler/mx_compiler.py#L1161 > > On 2018-06-18 22:26, Ekaterina Pavlova wrote: >> Hi All, >> >> please review porting of Graal unit tests under jtreg. The main idea of this porting is to keep Graal unit tests as is >> (located in src/jdk.internal.vm.compiler/share/classes/*.test) and run them similar way they are run in Graal project. >> To achieve this test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java helper class has been written >> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to run specified set of Graal unit tests. The groups of >> Graal unit tests to run are defined in auto-generated test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests. >> >> New make/test/JtregGraalUnit.gmk is used to build Graal unit tests into jdk.vm.compiler.tests.jar and then install >> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/. >> > GRAALUNIT_LIB is never defined (in the open). Since this is used in open makefiles, we need an open configure option to set it. > > To make things clearer, I would rename LIB_DIR to something like LIB_OUTPUTDIR to signal that this is a location to put files in, rather than read them from. > > FLATTEN has no effect in the SetupCopyFiles call since all the jar files found by wildcard can only be in one directory anyway. > > BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. Tests classes and jars should be built into $(SUPPORT_OUTPUTDIR)/test/... Please create a suitable sub directory there for the output from this makefile. > > The all and test-image targets are never called so no need to declare them. > > There are some style issues too. (Please see http://openjdk.java.net/groups/build/doc/code-conventions.html for details.) > * 43 logic indent 2 spaces > * 52 we like to put the ending )) on a new line with ', \' at the end of the line before > * 58 continuation indent 4 spaces > * 88, 89 please break long lines > * 90 continuation indent 4 spaces > * 99 continuation indent 4 spaces > * 120 break before )) >> make/Main.gmk adds proper dependencies for build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal. >> > The target build-test-hotspot-jtreg-graal only needs to depend on exploded-image-optimize. > > The new graal specific targets should be guarded by INCLUDE_GRAAL in Main.gmk. Otherwise those targets will silently do nothing if invoked without graal. That means adding them to JVM_TEST_IMAGE_TARGETS needs to be conditional too. >> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg knows where to find Graal tests and libs. >> > This needs to be duplicated for make/RunTest.gmk so that these tests work with "make run-test" as well. > > /Erik >> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file defines "testName -> testPrefix [requiresStatement]" mapping >> which is used by test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to generate jtreg tests. >> >> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was ported from mx project without any changes. >> >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 >> webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html >> testing: new tests were executed as part of automatic HS testing for several months. >> >> >> thanks, >> -katya >> >> p.s. >> Igor Ignatyev volunteered to sponsor this change. > From tom.rodriguez at oracle.com Tue Jun 19 21:34:46 2018 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 19 Jun 2018 14:34:46 -0700 Subject: RFR (S): 8198909: [Graal] compiler/codecache/stress/UnexpectedDeoptimizationTest.java crashed with SIGSEGV In-Reply-To: References: <64c722cd-14e3-e0db-6a16-08ca69605205@oracle.com> <5B1E3C35.3090506@oracle.com> Message-ID: <7809c59d-5f2f-30aa-44e6-7cf4db03df05@oracle.com> I've generated a webrev with a new KlassRefHandle protecting questionable uses in JVMCI. http://cr.openjdk.java.net/~never/8198909.1/webrev One outstanding question is whether ObjArrayKlass also needs a working holder_phantom method. It would seem so to me but maybe there's some reason not? tom Tom Rodriguez wrote on 6/11/18 10:04 AM: > > > Erik ?sterlund wrote on 6/11/18 2:09 AM: >> Hi Tom, >> >> Could you please call InstanceKlass::holder_phantom() instead to keep >> the class alive? That is the more general mechanism that is also used >> by ciInstanceKlass. We don't want to use explicit G1 enqueue calls >> anymore. > > Ok. I guess the same fix in JDK8 will have the use the explicit enqueue > though or is it not required in JDK8? > >> Also, you must not perform any thread transition between loading the >> weak klass from the MDO until you call holder_phantom, otherwise it >> might have been unloaded before you get to call holder_phantom(). Is >> this guaranteed somehow in this scenario? I looked through all >> callsites and could not find where the Klass pointer is read in the >> MDO and subsequently passed into the CompilerToVM::get_jvmci_type API, >> and therefore I do not know if this is guaranteed. > > The obviously problematic path is at > http://hg.openjdk.java.net/jdk/jdk/file/50469fb301c4/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp#l334 > when either base_address is a Klass* or base_object is NULL which is > where we are reading from non-heap memory. There are other paths which > are reading Klasses through more standard APIs from the ConstantPool for > instance. > > There isn't an easy way to ensure no safepoint occurs in between so > maybe we require the caller of get_jvmci_type to pass in the > phantom_holder() as a way of forcing the caller to call holder_phantom() > at the appropriate places? Or is it the case that getResolvedType is > the only place where special effort is required? All the other paths > are fairly normal HotSpot code but though place that uses > klass->implementor() for instance seems like it could be considered to > be weak by G1. > > http://hg.openjdk.java.net/jdk/jdk/file/50469fb301c4/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp#l368 > > > The lack of a properly working KlassHandle seems like an oversight in > the API to me. > > tom > >> >> Thanks, >> /Erik >> >> On 2018-06-08 22:46, Tom Rodriguez wrote: >>> The JVMCI API may read Klass* and java.lang.Class instances from >>> locations which G1 would consider to be weakly referenced. This can >>> result in HotSpotResolvedObjectTypeImpl instances with references to >>> Classes that have been unloaded. In the this crash, JVMCI was >>> reading a Klass* from the profile in an MDO and building a wrapper >>> around it. The MDO reference is weak and was the only remaining >>> reference to the type so it could be dropped resulting in an eventual >>> crash. >>> >>> I've added an explicit G1 enqueue before we call out to create the >>> wrapper object but is there a more recommended way of doing this? >>> Dean had pointed out the oddly named InstanceKlass::holder_phantom >>> which is used by the CI. Should I be using that? The G1 barrier is >>> only really need when reading from non-Java heap memory but since the >>> get_jvmci_type method is the main entry point for this logic it >>> safest to always perform it in this path. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8198909 >>> http://cr.openjdk.java.net/~never/8198909/webrev >> From gromero at linux.vnet.ibm.com Wed Jun 20 01:13:02 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 19 Jun 2018 22:13:02 -0300 Subject: RFC: Add new JCA provider to support hardware RNGs In-Reply-To: <993c258a-57ae-d29d-2368-faac5b4d3cb1@linux.vnet.ibm.com> References: <993c258a-57ae-d29d-2368-faac5b4d3cb1@linux.vnet.ibm.com> Message-ID: Sorry for resending it. I missed a few MLs. -- Hi, Please, could I get comments on the following change? Since it's related to security, I would be glad if security experts could also comment on that. webrev: http://cr.openjdk.java.net/~gromero/POWER9/darn/v6_rebased/ It introduces a way to get benefits from hardware instructions in userspace that can delivery a random number and so be used to speed up and avoid blocking in some SecureRandom methods, notably generateSeed() and nextBytes(), without loosing the random number quality. Particularly on Power, the new POWER9 CPUs introduced a hardware instruction called 'darn' that can be used for that purpose. The main idea is to add a new JCA provider called "HWTRNG" (if no better name is suggested), adding new helper methods that can then be intrinsified and that will be used by generateSeed() and nextBytes(). In that sense, this change also adds the proper mechanisms in the Interpreter, C1 Compiler, and C2 compiler (for PPC64, but also paving the way for other platforms) to intrinsify these helper methods that will be used in the end by generateSeed() and nextBytes() methods. The added helpers are: byte[] getRandomSequence0(int) byte[] getRandomSequence1(byte[]) long validRandomLong(void) long randomLong(void) The helpers also take care of checking if the returned random number is valid and attempt 10 times (as recommended by ISA) get a valid random number before falling back to a software alternative (HWTRNG is based mostly on JCA provider NativePRNG and so the fall back mechanism will use the exactly same methods found in NativePRNG and hence behave similarly. Nonetheless, in my experience such a hardware failures (which are the main cause of a returned invalid random number) are quite rare: in my tests I was never able to exhaust the HW RNG and force it to generate an invalid random number). The user, besides having to specify explicitly the use of a non-default provider (HWTRNG), will have to unlock the VM experimental options to effectively use the hardware RNG as an unique random source by passing options "-XX:+UnlockExperimentalVMOptions -XX:+UseRANDOMIntrinsics". On Power, for the Interpreter and C1 Compiler, besides avoiding the blocking effect of a low entropy on /dev/random, I was able to get about 126 Mbps (3x higher than the version without 'darn') on generaSeed() and nextBytes(). The maximum theoretical value on a POWER9 machine is usually 128 Mbps. I'll address the details about the file headers (Copyright, dates, authors, versions, etc) after I get some feedback about this change. Thanks in advance. Best regards, Gustavo From nils.eliasson at oracle.com Wed Jun 20 09:01:03 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 20 Jun 2018 11:01:03 +0200 Subject: RFR(S): 8205107: assert(c->Opcode() == Op_SafePoint) failed: broken outer loop In-Reply-To: References: <06ce5035-4eb9-d56f-0a46-7188c3e74b6c@oracle.com> <26c32258-1e42-01cd-fb64-0ff4cd4ff0b8@oracle.com> Message-ID: <185a0fd0-6876-a6e4-d647-9bde5a7f89cf@oracle.com> I simplified it to: virtual bool guaranteed_safepoint() { // Calls to boxing methods will be expanded, and safepoints aren't guaranteed return !is_boxing_method(); } is_boxing_method() checks is_macro() that checks the Flag_is_macro which is only set when C->eliminate_boxing() is true. "(proj_out_or_null(TypeFunc::Parms) == NULL));" seems redundant too me. What would that guard against? New webrev here: http://cr.openjdk.java.net/~neliasso/8205107/webrev.03/ Thanks for the help! Nils On 2018-06-19 19:18, Vladimir Kozlov wrote: > On 6/19/18 9:01 AM, Vladimir Kozlov wrote: >> On 6/19/18 7:22 AM, Nils Eliasson wrote: >>> I looked at it in a bit more detail. >>> >>> The call is a java/lang/Integer::valueOf that is considered a macro >>> node so it is kept around until macro expansion which happens after >>> the place where we hit the assert. So the call will go away. >> >> I assume you are talking about eliminate_boxing_node() in macro >> expansion. >> >>> >>> However SafepointNode::Identity does check: >>> >>> if( n0->is_Call() && n0->as_Call()->guaranteed_safepoint() ) { >>> // Useless Safepoint, so remove it >>> >>> And CallNode::guaranteed_safepoint() is: >>> >>> // Are we guaranteed that this node is a safepoint? Not true for >>> leaf calls and >>> // for some macro nodes whose expansion does not have a safepoint >>> on the fast path. >>> virtual bool guaranteed_safepoint() { return true; } >>> >>> No check for call/macro-nodes is implemeted despite the comment! If >>> I fix this the problem goes away. >> >> It returns false for Allocate nodes which are macro nodes. That is >> what comment says. >> >> In case of boxing node I think we should add to CallStaticJavaNode class >> >> // Boxing call which is not used and will be removed. >> virtual bool guaranteed_safepoint() { return >> C->eliminate_boxing() && is_boxing_method() && >> (proj_out_or_null(TypeFunc::Parms) == NULL); } > > Sorry, test should be reversed because it guarantee SP if call is > *not* removed: > > virtual bool guaranteed_safepoint() { return > !(C->eliminate_boxing() && is_boxing_method() && > (proj_out_or_null(TypeFunc::Parms) == NULL)); } > > Vladimir > >> >> Vladimir >> >>> >>> // Nils >>> >>> >>> >>> On 2018-06-18 15:41, Roland Westrelin wrote: >>>>> Roland, why we need to keep Safepoint in Outer loop if we have call? >>>> I double checked with a simple test case and we don't keep the >>>> safepoint >>>> if there's a call so it's indeed strange that we would need Nils' >>>> patch. >>>> >>>> Roland. >>> From gromero at linux.vnet.ibm.com Wed Jun 20 12:17:58 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 20 Jun 2018 09:17:58 -0300 Subject: RFR(XS): 8204135: jtreg: Fix failing RTM test TestUseRTMXendForLockBusy In-Reply-To: <9cfd785a819e4b4e93660e8644304cff@sap.com> References: <798cdc2a-ad0a-423f-351b-a8fc9eefc942@linux.vnet.ibm.com> <9cfd785a819e4b4e93660e8644304cff@sap.com> Message-ID: <4737a4fa-40b6-3eba-8ffa-4f39e0a55c68@linux.vnet.ibm.com> Hi Igor, On 06/15/2018 10:12 AM, Lindenmaier, Goetz wrote: > I had a look at your fix. As I understand the test it's just > what was intended to do. Also, it fixed the test in our runs. > > Reviewed. > > I would volunteer to sponsor this. Goetz reviewed the change. Is it OK to be pushed? Thanks. Best regards, Gustavo > Best regards, > Goetz. > >> -----Original Message----- >> From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] >> Sent: Donnerstag, 31. Mai 2018 04:05 >> To: hotspot-compiler-dev at openjdk.java.net; igor.ignatyev at oracle.com >> Cc: Lindenmaier, Goetz ; Doerr, Martin >> >> Subject: RFR(XS): 8204135: jtreg: Fix failing RTM test >> TestUseRTMXendForLockBusy >> >> Hi, >> >> Could the following change be reviewed please? >> >> webrev: http://cr.openjdk.java.net/~gromero/8204135/v1 >> bug : https://bugs.openjdk.java.net/browse/JDK-8204135 >> >> It fixes currently failing RTM test "TestUseRTMXendForLockBusy" by >> changing >> in which cases UseRTMForStackLocks flags must be enabled/disabled. >> >> I could not track down on the timeline when exactly that test stopped to >> pass, however my understanding is that if inflateMonitor is 'false' that >> should /not/ imply that UseRTMForStackLocks is also 'false'. Thus I >> understand that for this particular test if inflated monitors are used, >> then UseRTMForStackLocks has to be disabled, i.e. 'false'. On the other >> hand, if inflated monitors are /not/ used, then UseRTMForStackLocks must >> be >> enabled. >> >> Currently the test is failing for the following cases where inflateMonitor >> is 'false', because it implies that UseRTMForStackLocks is disabled and so >> no abort statistics is generated (which is correct from the JVM's >> perspective): >> >> // stack lock, xabort on lock busy >> verifyXendForLockBusy(false, false); >> // stack lock, xend on lock busy >> verifyXendForLockBusy(false, true); >> >> In other words, "stack lock" case should imply UseRTMForStackLocks = 'true', >> not 'false'. >> >> Cases: >> // inflated lock, xabort on lock busy >> verifyXendForLockBusy(true, false); >> // inflated lock, xend on lock busy >> verifyXendForLockBusy(true, true); >> >> are not failing because UseRTMForStackLocks = 'true' and they will generate >> proper abort statistics when +UseRTMXendForLockBusy ('xend' is used to >> finish the transaction) or when -UseRTMXendForLockBusy ('xabort' is used >> to finish the transaction). >> >> So, in summing up: (a) inflated lock cases are not being tested correctly >> (since UseRTMForStackLocks is always enabled) and (b) stack lock cases are >> failing because UseRTMForStackLocks is always disabled. >> >> @Igor, it's a long time ago, but maybe you recall some details on that >> test... :-) >> >> >> Thank you. >> >> Best regards, >> Gustavo > From dmitrij.pochepko at bell-sw.com Wed Jun 20 14:26:23 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 20 Jun 2018 17:26:23 +0300 Subject: RFR: 8189105: AARCH64: create intrinsic for sin and cos In-Reply-To: <752dd93c-7a95-c674-08df-3e054f178196@redhat.com> References: <4de41b0c-e318-c70f-a864-4f6c8bd14297@redhat.com> <5B12CAEF.8050105@bell-sw.com> <2bd89c11-d234-ceae-3b04-4c547ef5836c@redhat.com> <752dd93c-7a95-c674-08df-3e054f178196@redhat.com> Message-ID: On 19.06.2018 20:46, Andrew Haley wrote: > On 06/18/2018 07:53 PM, Dmitrij Pochepko wrote: >> If you have any other ideas how to make the code easier to read and >> maintain I?m happy to improve it. > That's great! Really, that's a vast improvement. Excellent work. > > One or two relatively minor things: > > Why do you say the polynomial in kernel_sin/kernel_cos is a Taylor > series? There's no such comment in sharedRuntimeTrig.cpp, and I doubt > it. I would have thought it was a > least-maximum polynomial > approximation, not a Taylor series. Taylor series for cos(x) = 1 - x^2/2! + x^4/4! - x^6/6! + ... = 1 - 0.5*x^2 + 4.16666666666666019037e-02 * x^4 - 1.38888888888741095749e-03 * x^6 ... so, if you take a look at kernel_cos function description you'll see exactly same polynomial calculation with exactly same coefficients. > > What's the point of keeping the doubles in tables in hex form? > sharedRuntimeTrig.cpp doesn't do that, and it looks like obfuscation. > Even if you must keep them as hex, at least move the comment which > shows their true values next to their declaration, but I really can't > see the point. It was easier for me while debugging to use hex form. I changed representation to double with hex form added in comment where applicable. > > It'd make the code much more readable if you lined up the comments, > like so: > > fmovd(v28, v3); // t = r > fmuld(v29, v2, v6); // w = v29 = fn * pio2_2 > fsubd(v3, v28, v29); // r = t - w > fsubd(v31, v28, v3); // v31 = (t - r) > fsubd(v31, v29, v31); // v31 = w - (t - r) = - ((t - r) - w) > fmaddd(v26, v2, v7, v31); // v26 = w = fn*pio2_2t - ((t - r) - w) > fsubd(v4, v3, v26); // y[0] = r - w > fmovd(jx, v4); > lsl(jx, jx, 1); > sub(tmp3, tmp5, jx, LSR, 32 + 20 + 1); // r7 = j-(((*(i0+(int*)&y[0]))>>20)&0x7ff); > > But it's probably not a great idea to make the code-super wide with > the comments so you have to open a huge editor window. So, don't > go crazy, but a little bit of white space like this makes it much > easier to read. done > > Thanks. > Please take a look at updated version: http://cr.openjdk.java.net/~dpochepk/8189105/webrev.04/ Thanks, Dmitrij From dmitrij.pochepko at bell-sw.com Wed Jun 20 14:45:12 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 20 Jun 2018 17:45:12 +0300 Subject: RFR: 8204289: AARCH64: enable math intrinsics usage in interpreter and C1 In-Reply-To: <6bd4bccb-befb-0523-d75e-2c5a99c4ee34@bell-sw.com> References: <6bd4bccb-befb-0523-d75e-2c5a99c4ee34@bell-sw.com> Message-ID: <6e1457db-9b5c-3bbd-65fc-ebd2a9e99558@bell-sw.com> Hi, can somebody take a look? Thanks, Dmitrij On 04.06.2018 18:50, Dmitrij Pochepko wrote: > Hi all, > > please review patch for JDK-8204289: AARCH64: enable math intrinsics > usage in interpreter and C1 > > This patch enables usage of math intrinsics for interpreter and C1 in > case intrinsics are implemented. Code follows that of x86 port. > > > Testing: I've merged this patch with implemented intrinsic and > launched jtreg tests and benchmark in 2 more modes: -Xint and > -XX:TieredStopAtLevel=3 > > Benchmark scores were improved as expected of intrinsic. All tests > passed. > > > webrev: http://cr.openjdk.java.net/~dpochepk/8204289/webrev.01/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8204289 > > > Thanks, > > Dmitrij > From dmitrij.pochepko at bell-sw.com Wed Jun 20 15:01:34 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 20 Jun 2018 18:01:34 +0300 Subject: RFR(S): 8205421 - AARCH64: StubCodeMark should be placed after alignment Message-ID: <38c69205-bce9-aa31-8d0f-6ddf3a1a8cf6@bell-sw.com> Hi, please review small patch for 8205421 - AARCH64: StubCodeMark should be placed after alignment This patch moves few StubCodeMark declarations after alignment code to have no alignment "nop" instructions in stub listing (like -XX:+PrintStubCode) CR: https://bugs.openjdk.java.net/browse/JDK-8205421 webrev: http://cr.openjdk.java.net/~dpochepk/8205421/webrev.01/ Testing: I checked patched build output via -XX:+PrintStubCode. Thanks, Dmitrij From aph at redhat.com Wed Jun 20 16:28:34 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 20 Jun 2018 17:28:34 +0100 Subject: RFR: 8189105: AARCH64: create intrinsic for sin and cos In-Reply-To: References: <4de41b0c-e318-c70f-a864-4f6c8bd14297@redhat.com> <5B12CAEF.8050105@bell-sw.com> <2bd89c11-d234-ceae-3b04-4c547ef5836c@redhat.com> <752dd93c-7a95-c674-08df-3e054f178196@redhat.com> Message-ID: <9a8968ee-4432-19a2-f4f2-08a1fb4b4034@redhat.com> On 06/20/2018 03:26 PM, Dmitrij Pochepko wrote: > > > On 19.06.2018 20:46, Andrew Haley wrote: >> On 06/18/2018 07:53 PM, Dmitrij Pochepko wrote: >>> If you have any other ideas how to make the code easier to read and >>> maintain I?m happy to improve it. >> That's great! Really, that's a vast improvement. Excellent work. >> >> One or two relatively minor things: >> >> Why do you say the polynomial in kernel_sin/kernel_cos is a Taylor >> series? There's no such comment in sharedRuntimeTrig.cpp, and I doubt >> it. I would have thought it was a >> least-maximum polynomial >> approximation, not a Taylor series. > Taylor series for cos(x) = 1 - x^2/2! + x^4/4! - x^6/6! + ... = 1 - > 0.5*x^2 + 4.16666666666666019037e-02 * x^4 - 1.38888888888741095749e-03 > * x^6 ... > so, if you take a look at kernel_cos function description you'll see > exactly same polynomial calculation with exactly same coefficients. I don't think so. I think the program uses 4.16666666666666019037e-02, // c0x3FA555555555554C -1.38888888888741095749e-03, // 0xBF56C16C16C15177 2.48015872894767294178e-05, // 0x3EFA01A019CB1590 -2.75573143513906633035e-07, // 0xBE927E4F809C52AD 2.08757232129817482790e-09, // 0x3E21EE9EBDB4B1C4 -1.13596475577881948265e-11 // 0xBDA8FAE9BE8838D4 and unless I am mistaken the coefficients of the Taylor series for cos are approximately 4.16666666666666643537e-02, -1.38888888888888894189e-03, 2.48015873015873015658e-05, -2.75573192239858882758e-07, 2.08767569878681001866e-09, -7.81894280887451282427e-10, >> What's the point of keeping the doubles in tables in hex form? >> sharedRuntimeTrig.cpp doesn't do that, and it looks like obfuscation. >> Even if you must keep them as hex, at least move the comment which >> shows their true values next to their declaration, but I really can't >> see the point. > It was easier for me while debugging to use hex form. I changed > representation to double with hex form added in comment where applicable. Excellent. -- 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 20 16:32:53 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 20 Jun 2018 09:32:53 -0700 Subject: RFR(S): 8205107: assert(c->Opcode() == Op_SafePoint) failed: broken outer loop In-Reply-To: <185a0fd0-6876-a6e4-d647-9bde5a7f89cf@oracle.com> References: <06ce5035-4eb9-d56f-0a46-7188c3e74b6c@oracle.com> <26c32258-1e42-01cd-fb64-0ff4cd4ff0b8@oracle.com> <185a0fd0-6876-a6e4-d647-9bde5a7f89cf@oracle.com> Message-ID: <5521318c-ed90-9d04-5cc2-2dbd964dcf63@oracle.com> On 6/20/18 2:01 AM, Nils Eliasson wrote: > I simplified it to: > > ? virtual bool guaranteed_safepoint() { > ????? // Calls to boxing methods will be expanded, and safepoints > aren't guaranteed > ????? return !is_boxing_method(); > ? } > > is_boxing_method() checks is_macro() that checks the Flag_is_macro which > is only set when C->eliminate_boxing() is true. Okay. > > "(proj_out_or_null(TypeFunc::Parms) == NULL));" seems redundant too me. > What would that guard against? It checks that result of the call is not used (Box object is eliminated by EA). It is needed otherwise you will get bad graph. Thanks, Vladimir > > New webrev here: http://cr.openjdk.java.net/~neliasso/8205107/webrev.03/ > > Thanks for the help! > > Nils > > > > On 2018-06-19 19:18, Vladimir Kozlov wrote: >> On 6/19/18 9:01 AM, Vladimir Kozlov wrote: >>> On 6/19/18 7:22 AM, Nils Eliasson wrote: >>>> I looked at it in a bit more detail. >>>> >>>> The call is a java/lang/Integer::valueOf that is considered a macro >>>> node so it is kept around until macro expansion which happens after >>>> the place where we hit the assert. So the call will go away. >>> >>> I assume you are talking about eliminate_boxing_node() in macro >>> expansion. >>> >>>> >>>> However SafepointNode::Identity does check: >>>> >>>> if( n0->is_Call() && n0->as_Call()->guaranteed_safepoint() ) { >>>> ?????? // Useless Safepoint, so remove it >>>> >>>> And CallNode::guaranteed_safepoint() is: >>>> >>>> ?? // Are we guaranteed that this node is a safepoint?? Not true for >>>> leaf calls and >>>> ?? // for some macro nodes whose expansion does not have a safepoint >>>> on the fast path. >>>> ?? virtual bool??????? guaranteed_safepoint()? { return true; } >>>> >>>> No check for call/macro-nodes is implemeted despite the comment! If >>>> I fix this the problem goes away. >>> >>> It returns false for Allocate nodes which are macro nodes. That is >>> what comment says. >>> >>> In case of boxing node I think we should add to CallStaticJavaNode class >>> >>> ?? // Boxing call which is not used and will be removed. >>> ?? virtual bool??????? guaranteed_safepoint()? { return >>> C->eliminate_boxing() && is_boxing_method() && >>> (proj_out_or_null(TypeFunc::Parms) == NULL); } >> >> Sorry, test should be reversed because it guarantee SP if call is >> *not* removed: >> >> virtual bool??????? guaranteed_safepoint()? { return >> !(C->eliminate_boxing() && is_boxing_method() && >> (proj_out_or_null(TypeFunc::Parms) == NULL)); } >> >> Vladimir >> >>> >>> Vladimir >>> >>>> >>>> // Nils >>>> >>>> >>>> >>>> On 2018-06-18 15:41, Roland Westrelin wrote: >>>>>> Roland, why we need to keep Safepoint in Outer loop if we have call? >>>>> I double checked with a simple test case and we don't keep the >>>>> safepoint >>>>> if there's a call so it's indeed strange that we would need Nils' >>>>> patch. >>>>> >>>>> Roland. >>>> > From igor.ignatyev at oracle.com Wed Jun 20 18:23:29 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 20 Jun 2018 11:23:29 -0700 Subject: RFR(XS): 8204135: jtreg: Fix failing RTM test TestUseRTMXendForLockBusy In-Reply-To: <4737a4fa-40b6-3eba-8ffa-4f39e0a55c68@linux.vnet.ibm.com> References: <798cdc2a-ad0a-423f-351b-a8fc9eefc942@linux.vnet.ibm.com> <9cfd785a819e4b4e93660e8644304cff@sap.com> <4737a4fa-40b6-3eba-8ffa-4f39e0a55c68@linux.vnet.ibm.com> Message-ID: Hi Gustavo, as your patch has been reviewed by two reviewers, it is fine to be pushed. -- Igor > On Jun 20, 2018, at 5:17 AM, Gustavo Romero wrote: > > Hi Igor, > > On 06/15/2018 10:12 AM, Lindenmaier, Goetz wrote: >> I had a look at your fix. As I understand the test it's just >> what was intended to do. Also, it fixed the test in our runs. >> Reviewed. >> I would volunteer to sponsor this. > > Goetz reviewed the change. Is it OK to be pushed? > > > Thanks. > > Best regards, > Gustavo > >> Best regards, >> Goetz. >>> -----Original Message----- >>> From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] >>> Sent: Donnerstag, 31. Mai 2018 04:05 >>> To: hotspot-compiler-dev at openjdk.java.net; igor.ignatyev at oracle.com >>> Cc: Lindenmaier, Goetz ; Doerr, Martin >>> >>> Subject: RFR(XS): 8204135: jtreg: Fix failing RTM test >>> TestUseRTMXendForLockBusy >>> >>> Hi, >>> >>> Could the following change be reviewed please? >>> >>> webrev: http://cr.openjdk.java.net/~gromero/8204135/v1 >>> bug : https://bugs.openjdk.java.net/browse/JDK-8204135 >>> >>> It fixes currently failing RTM test "TestUseRTMXendForLockBusy" by >>> changing >>> in which cases UseRTMForStackLocks flags must be enabled/disabled. >>> >>> I could not track down on the timeline when exactly that test stopped to >>> pass, however my understanding is that if inflateMonitor is 'false' that >>> should /not/ imply that UseRTMForStackLocks is also 'false'. Thus I >>> understand that for this particular test if inflated monitors are used, >>> then UseRTMForStackLocks has to be disabled, i.e. 'false'. On the other >>> hand, if inflated monitors are /not/ used, then UseRTMForStackLocks must >>> be >>> enabled. >>> >>> Currently the test is failing for the following cases where inflateMonitor >>> is 'false', because it implies that UseRTMForStackLocks is disabled and so >>> no abort statistics is generated (which is correct from the JVM's >>> perspective): >>> >>> // stack lock, xabort on lock busy >>> verifyXendForLockBusy(false, false); >>> // stack lock, xend on lock busy >>> verifyXendForLockBusy(false, true); >>> >>> In other words, "stack lock" case should imply UseRTMForStackLocks = 'true', >>> not 'false'. >>> >>> Cases: >>> // inflated lock, xabort on lock busy >>> verifyXendForLockBusy(true, false); >>> // inflated lock, xend on lock busy >>> verifyXendForLockBusy(true, true); >>> >>> are not failing because UseRTMForStackLocks = 'true' and they will generate >>> proper abort statistics when +UseRTMXendForLockBusy ('xend' is used to >>> finish the transaction) or when -UseRTMXendForLockBusy ('xabort' is used >>> to finish the transaction). >>> >>> So, in summing up: (a) inflated lock cases are not being tested correctly >>> (since UseRTMForStackLocks is always enabled) and (b) stack lock cases are >>> failing because UseRTMForStackLocks is always disabled. >>> >>> @Igor, it's a long time ago, but maybe you recall some details on that >>> test... :-) >>> >>> >>> Thank you. >>> >>> Best regards, >>> Gustavo > From dmitrij.pochepko at bell-sw.com Wed Jun 20 18:40:47 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 20 Jun 2018 21:40:47 +0300 Subject: RFR: 8189105: AARCH64: create intrinsic for sin and cos In-Reply-To: <9a8968ee-4432-19a2-f4f2-08a1fb4b4034@redhat.com> References: <4de41b0c-e318-c70f-a864-4f6c8bd14297@redhat.com> <5B12CAEF.8050105@bell-sw.com> <2bd89c11-d234-ceae-3b04-4c547ef5836c@redhat.com> <752dd93c-7a95-c674-08df-3e054f178196@redhat.com> <9a8968ee-4432-19a2-f4f2-08a1fb4b4034@redhat.com> Message-ID: On 20.06.2018 19:28, Andrew Haley wrote: > On 06/20/2018 03:26 PM, Dmitrij Pochepko wrote: >> >> On 19.06.2018 20:46, Andrew Haley wrote: >>> On 06/18/2018 07:53 PM, Dmitrij Pochepko wrote: >>>> If you have any other ideas how to make the code easier to read and >>>> maintain I?m happy to improve it. >>> That's great! Really, that's a vast improvement. Excellent work. >>> >>> One or two relatively minor things: >>> >>> Why do you say the polynomial in kernel_sin/kernel_cos is a Taylor >>> series? There's no such comment in sharedRuntimeTrig.cpp, and I doubt >>> it. I would have thought it was a >>> least-maximum polynomial >>> approximation, not a Taylor series. >> Taylor series for cos(x) = 1 - x^2/2! + x^4/4! - x^6/6! + ... = 1 - >> 0.5*x^2 + 4.16666666666666019037e-02 * x^4 - 1.38888888888741095749e-03 >> * x^6 ... >> so, if you take a look at kernel_cos function description you'll see >> exactly same polynomial calculation with exactly same coefficients. > I don't think so. I think the program uses > > 4.16666666666666019037e-02, // c0x3FA555555555554C > -1.38888888888741095749e-03, // 0xBF56C16C16C15177 > 2.48015872894767294178e-05, // 0x3EFA01A019CB1590 > -2.75573143513906633035e-07, // 0xBE927E4F809C52AD > 2.08757232129817482790e-09, // 0x3E21EE9EBDB4B1C4 > -1.13596475577881948265e-11 // 0xBDA8FAE9BE8838D4 > > and unless I am mistaken the coefficients of the Taylor series for cos > are approximately > > 4.16666666666666643537e-02, > -1.38888888888888894189e-03, > 2.48015873015873015658e-05, > -2.75573192239858882758e-07, > 2.08767569878681001866e-09, > -7.81894280887451282427e-10, > Though your calculation of Taylor series coefficient is imprecise, you are right in your assessment this is not Taylor series. It's a polynomial coefficients derived by using Remez approximation algorithm, which typically use Taylor series coefficients as initial approximation. I updated webrev by removing Taylor mentioning: http://cr.openjdk.java.net/~dpochepk/8189105/webrev.05/ > >>> What's the point of keeping the doubles in tables in hex form? >>> sharedRuntimeTrig.cpp doesn't do that, and it looks like obfuscation. >>> Even if you must keep them as hex, at least move the comment which >>> shows their true values next to their declaration, but I really can't >>> see the point. >> It was easier for me while debugging to use hex form. I changed >> representation to double with hex form added in comment where applicable. > Excellent. > From nils.eliasson at oracle.com Wed Jun 20 19:22:20 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 20 Jun 2018 21:22:20 +0200 Subject: RFR(S): 8205107: assert(c->Opcode() == Op_SafePoint) failed: broken outer loop In-Reply-To: <5521318c-ed90-9d04-5cc2-2dbd964dcf63@oracle.com> References: <06ce5035-4eb9-d56f-0a46-7188c3e74b6c@oracle.com> <26c32258-1e42-01cd-fb64-0ff4cd4ff0b8@oracle.com> <185a0fd0-6876-a6e4-d647-9bde5a7f89cf@oracle.com> <5521318c-ed90-9d04-5cc2-2dbd964dcf63@oracle.com> Message-ID: <1e09c221-7c6e-093c-6dc8-53759eb162ea@oracle.com> On 2018-06-20 18:32, Vladimir Kozlov wrote: > On 6/20/18 2:01 AM, Nils Eliasson wrote: >> I simplified it to: >> >> ?? virtual bool guaranteed_safepoint() { >> ?????? // Calls to boxing methods will be expanded, and safepoints >> aren't guaranteed >> ?????? return !is_boxing_method(); >> ?? } >> >> is_boxing_method() checks is_macro() that checks the Flag_is_macro >> which is only set when C->eliminate_boxing() is true. > > Okay. > >> >> "(proj_out_or_null(TypeFunc::Parms) == NULL));" seems redundant too >> me. What would that guard against? > > It checks that result of the call is not used (Box object is > eliminated by EA). It is needed otherwise you will get bad graph. We don't need that check since we prevent an optimization for happening. The graph is kept as it is. This is the graph: Integer.valueOf ??? | CatchProj ??? | SafePoint ??? | OuterCountedLoopEnd The original problem is that the SafePoint was removed because the Integer.valueOf reported that it guarantees a safepoint. With the change - guaranteed_safepoint() returns false for boxes - no safepoint removal is done, the graph is kept intact. Regards, Nils > > Thanks, > Vladimir > >> >> New webrev here: http://cr.openjdk.java.net/~neliasso/8205107/webrev.03/ >> >> Thanks for the help! >> >> Nils >> >> >> >> On 2018-06-19 19:18, Vladimir Kozlov wrote: >>> On 6/19/18 9:01 AM, Vladimir Kozlov wrote: >>>> On 6/19/18 7:22 AM, Nils Eliasson wrote: >>>>> I looked at it in a bit more detail. >>>>> >>>>> The call is a java/lang/Integer::valueOf that is considered a >>>>> macro node so it is kept around until macro expansion which >>>>> happens after the place where we hit the assert. So the call will >>>>> go away. >>>> >>>> I assume you are talking about eliminate_boxing_node() in macro >>>> expansion. >>>> >>>>> >>>>> However SafepointNode::Identity does check: >>>>> >>>>> if( n0->is_Call() && n0->as_Call()->guaranteed_safepoint() ) { >>>>> ?????? // Useless Safepoint, so remove it >>>>> >>>>> And CallNode::guaranteed_safepoint() is: >>>>> >>>>> ?? // Are we guaranteed that this node is a safepoint? Not true >>>>> for leaf calls and >>>>> ?? // for some macro nodes whose expansion does not have a >>>>> safepoint on the fast path. >>>>> ?? virtual bool??????? guaranteed_safepoint()? { return true; } >>>>> >>>>> No check for call/macro-nodes is implemeted despite the comment! >>>>> If I fix this the problem goes away. >>>> >>>> It returns false for Allocate nodes which are macro nodes. That is >>>> what comment says. >>>> >>>> In case of boxing node I think we should add to CallStaticJavaNode >>>> class >>>> >>>> ?? // Boxing call which is not used and will be removed. >>>> ?? virtual bool??????? guaranteed_safepoint()? { return >>>> C->eliminate_boxing() && is_boxing_method() && >>>> (proj_out_or_null(TypeFunc::Parms) == NULL); } >>> >>> Sorry, test should be reversed because it guarantee SP if call is >>> *not* removed: >>> >>> virtual bool??????? guaranteed_safepoint()? { return >>> !(C->eliminate_boxing() && is_boxing_method() && >>> (proj_out_or_null(TypeFunc::Parms) == NULL)); } >>> >>> Vladimir >>> >>>> >>>> Vladimir >>>> >>>>> >>>>> // Nils >>>>> >>>>> >>>>> >>>>> On 2018-06-18 15:41, Roland Westrelin wrote: >>>>>>> Roland, why we need to keep Safepoint in Outer loop if we have >>>>>>> call? >>>>>> I double checked with a simple test case and we don't keep the >>>>>> safepoint >>>>>> if there's a call so it's indeed strange that we would need Nils' >>>>>> patch. >>>>>> >>>>>> Roland. >>>>> >> From vladimir.kozlov at oracle.com Wed Jun 20 19:33:19 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 20 Jun 2018 12:33:19 -0700 Subject: RFR(S): 8205107: assert(c->Opcode() == Op_SafePoint) failed: broken outer loop In-Reply-To: <1e09c221-7c6e-093c-6dc8-53759eb162ea@oracle.com> References: <06ce5035-4eb9-d56f-0a46-7188c3e74b6c@oracle.com> <26c32258-1e42-01cd-fb64-0ff4cd4ff0b8@oracle.com> <185a0fd0-6876-a6e4-d647-9bde5a7f89cf@oracle.com> <5521318c-ed90-9d04-5cc2-2dbd964dcf63@oracle.com> <1e09c221-7c6e-093c-6dc8-53759eb162ea@oracle.com> Message-ID: <0c2b7c85-71ec-3bd5-ac31-6715f32a5c90@oracle.com> On 6/20/18 12:22 PM, Nils Eliasson wrote: > > > On 2018-06-20 18:32, Vladimir Kozlov wrote: >> On 6/20/18 2:01 AM, Nils Eliasson wrote: >>> I simplified it to: >>> >>> ?? virtual bool guaranteed_safepoint() { >>> ?????? // Calls to boxing methods will be expanded, and safepoints >>> aren't guaranteed >>> ?????? return !is_boxing_method(); >>> ?? } >>> >>> is_boxing_method() checks is_macro() that checks the Flag_is_macro >>> which is only set when C->eliminate_boxing() is true. >> >> Okay. >> >>> >>> "(proj_out_or_null(TypeFunc::Parms) == NULL));" seems redundant too >>> me. What would that guard against? >> >> It checks that result of the call is not used (Box object is >> eliminated by EA). It is needed otherwise you will get bad graph. > > We don't need that check since we prevent an optimization for happening. > The graph is kept as it is. So the result is only used by Safepoint? Then how it is eliminated later? Hmm, may be check _is_scalar_replaceable instead. Vladimir > > This is the graph: > > Integer.valueOf > ??? | > CatchProj > ??? | > SafePoint > ??? | > OuterCountedLoopEnd > > The original problem is that the SafePoint was removed because the > Integer.valueOf reported that it guarantees a safepoint. With the change > - guaranteed_safepoint() returns false for boxes - no safepoint removal > is done, the graph is kept intact. > > Regards, > > Nils >> >> Thanks, >> Vladimir >> >>> >>> New webrev here: http://cr.openjdk.java.net/~neliasso/8205107/webrev.03/ >>> >>> Thanks for the help! >>> >>> Nils >>> >>> >>> >>> On 2018-06-19 19:18, Vladimir Kozlov wrote: >>>> On 6/19/18 9:01 AM, Vladimir Kozlov wrote: >>>>> On 6/19/18 7:22 AM, Nils Eliasson wrote: >>>>>> I looked at it in a bit more detail. >>>>>> >>>>>> The call is a java/lang/Integer::valueOf that is considered a >>>>>> macro node so it is kept around until macro expansion which >>>>>> happens after the place where we hit the assert. So the call will >>>>>> go away. >>>>> >>>>> I assume you are talking about eliminate_boxing_node() in macro >>>>> expansion. >>>>> >>>>>> >>>>>> However SafepointNode::Identity does check: >>>>>> >>>>>> if( n0->is_Call() && n0->as_Call()->guaranteed_safepoint() ) { >>>>>> ?????? // Useless Safepoint, so remove it >>>>>> >>>>>> And CallNode::guaranteed_safepoint() is: >>>>>> >>>>>> ?? // Are we guaranteed that this node is a safepoint? Not true >>>>>> for leaf calls and >>>>>> ?? // for some macro nodes whose expansion does not have a >>>>>> safepoint on the fast path. >>>>>> ?? virtual bool??????? guaranteed_safepoint()? { return true; } >>>>>> >>>>>> No check for call/macro-nodes is implemeted despite the comment! >>>>>> If I fix this the problem goes away. >>>>> >>>>> It returns false for Allocate nodes which are macro nodes. That is >>>>> what comment says. >>>>> >>>>> In case of boxing node I think we should add to CallStaticJavaNode >>>>> class >>>>> >>>>> ?? // Boxing call which is not used and will be removed. >>>>> ?? virtual bool??????? guaranteed_safepoint()? { return >>>>> C->eliminate_boxing() && is_boxing_method() && >>>>> (proj_out_or_null(TypeFunc::Parms) == NULL); } >>>> >>>> Sorry, test should be reversed because it guarantee SP if call is >>>> *not* removed: >>>> >>>> virtual bool??????? guaranteed_safepoint()? { return >>>> !(C->eliminate_boxing() && is_boxing_method() && >>>> (proj_out_or_null(TypeFunc::Parms) == NULL)); } >>>> >>>> Vladimir >>>> >>>>> >>>>> Vladimir >>>>> >>>>>> >>>>>> // Nils >>>>>> >>>>>> >>>>>> >>>>>> On 2018-06-18 15:41, Roland Westrelin wrote: >>>>>>>> Roland, why we need to keep Safepoint in Outer loop if we have >>>>>>>> call? >>>>>>> I double checked with a simple test case and we don't keep the >>>>>>> safepoint >>>>>>> if there's a call so it's indeed strange that we would need Nils' >>>>>>> patch. >>>>>>> >>>>>>> Roland. >>>>>> >>> > From igor.ignatyev at oracle.com Wed Jun 20 19:33:39 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 20 Jun 2018 12:33:39 -0700 Subject: RFR(XXS) : 8205433 : clean up hotspot ProblemList Message-ID: http://cr.openjdk.java.net/~iignatyev//8205433/webrev.00/index.html > 10 lines changed: 1 ins; 8 del; 1 mod; Hi all, could you please review this tiny clean up of ProblemList.txt? compiler/c2/Test8007294.java hasn't been removed from the problem list when JDK-8192992 was fixed. the same test s also marked as failing due to JDK-8194310 (Java EE modules removal), but this test doesn't depend on any java ee modules. testing: compiler/c2/Test8007294.java on linux-x64,windows-x64,solaris-sparcv9,macos-x64 x {product,fastdebug} webrev: http://cr.openjdk.java.net/~iignatyev//8205433/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8205433 Thanks, -- Igor From vladimir.kozlov at oracle.com Wed Jun 20 19:38:56 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 20 Jun 2018 12:38:56 -0700 Subject: RFR(XXS) : 8205433 : clean up hotspot ProblemList In-Reply-To: References: Message-ID: <36ed5b48-cfee-9377-6522-203f7f76c62c@oracle.com> Looks good. Thanks, Vladimir On 6/20/18 12:33 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8205433/webrev.00/index.html >> 10 lines changed: 1 ins; 8 del; 1 mod; > > Hi all, > > could you please review this tiny clean up of ProblemList.txt? > > compiler/c2/Test8007294.java hasn't been removed from the problem list when JDK-8192992 was fixed. the same test s also marked as failing due to JDK-8194310 (Java EE modules removal), but this test doesn't depend on any java ee modules. > > testing: compiler/c2/Test8007294.java on linux-x64,windows-x64,solaris-sparcv9,macos-x64 x {product,fastdebug} > webrev: http://cr.openjdk.java.net/~iignatyev//8205433/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8205433 > > Thanks, > -- Igor > From gromero at linux.vnet.ibm.com Wed Jun 20 19:39:41 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 20 Jun 2018 16:39:41 -0300 Subject: RFR(XS): 8204135: jtreg: Fix failing RTM test TestUseRTMXendForLockBusy In-Reply-To: References: <798cdc2a-ad0a-423f-351b-a8fc9eefc942@linux.vnet.ibm.com> <9cfd785a819e4b4e93660e8644304cff@sap.com> <4737a4fa-40b6-3eba-8ffa-4f39e0a55c68@linux.vnet.ibm.com> Message-ID: <1ceba2cc-31da-ebf5-1736-9a70c01cbc19@linux.vnet.ibm.com> Hi Igor, On 06/20/2018 03:23 PM, Igor Ignatyev wrote: > as your patch has been reviewed by two reviewers, it is fine to be pushed. Thanks for reviewing it. Goetz, could you please sponsor the change? Regards, Gustavo > -- Igor > >> On Jun 20, 2018, at 5:17 AM, Gustavo Romero wrote: >> >> Hi Igor, >> >> On 06/15/2018 10:12 AM, Lindenmaier, Goetz wrote: >>> I had a look at your fix. As I understand the test it's just >>> what was intended to do. Also, it fixed the test in our runs. >>> Reviewed. >>> I would volunteer to sponsor this. >> >> Goetz reviewed the change. Is it OK to be pushed? >> >> >> Thanks. >> >> Best regards, >> Gustavo >> >>> Best regards, >>> Goetz. >>>> -----Original Message----- >>>> From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] >>>> Sent: Donnerstag, 31. Mai 2018 04:05 >>>> To: hotspot-compiler-dev at openjdk.java.net; igor.ignatyev at oracle.com >>>> Cc: Lindenmaier, Goetz ; Doerr, Martin >>>> >>>> Subject: RFR(XS): 8204135: jtreg: Fix failing RTM test >>>> TestUseRTMXendForLockBusy >>>> >>>> Hi, >>>> >>>> Could the following change be reviewed please? >>>> >>>> webrev: http://cr.openjdk.java.net/~gromero/8204135/v1 >>>> bug : https://bugs.openjdk.java.net/browse/JDK-8204135 >>>> >>>> It fixes currently failing RTM test "TestUseRTMXendForLockBusy" by >>>> changing >>>> in which cases UseRTMForStackLocks flags must be enabled/disabled. >>>> >>>> I could not track down on the timeline when exactly that test stopped to >>>> pass, however my understanding is that if inflateMonitor is 'false' that >>>> should /not/ imply that UseRTMForStackLocks is also 'false'. Thus I >>>> understand that for this particular test if inflated monitors are used, >>>> then UseRTMForStackLocks has to be disabled, i.e. 'false'. On the other >>>> hand, if inflated monitors are /not/ used, then UseRTMForStackLocks must >>>> be >>>> enabled. >>>> >>>> Currently the test is failing for the following cases where inflateMonitor >>>> is 'false', because it implies that UseRTMForStackLocks is disabled and so >>>> no abort statistics is generated (which is correct from the JVM's >>>> perspective): >>>> >>>> // stack lock, xabort on lock busy >>>> verifyXendForLockBusy(false, false); >>>> // stack lock, xend on lock busy >>>> verifyXendForLockBusy(false, true); >>>> >>>> In other words, "stack lock" case should imply UseRTMForStackLocks = 'true', >>>> not 'false'. >>>> >>>> Cases: >>>> // inflated lock, xabort on lock busy >>>> verifyXendForLockBusy(true, false); >>>> // inflated lock, xend on lock busy >>>> verifyXendForLockBusy(true, true); >>>> >>>> are not failing because UseRTMForStackLocks = 'true' and they will generate >>>> proper abort statistics when +UseRTMXendForLockBusy ('xend' is used to >>>> finish the transaction) or when -UseRTMXendForLockBusy ('xabort' is used >>>> to finish the transaction). >>>> >>>> So, in summing up: (a) inflated lock cases are not being tested correctly >>>> (since UseRTMForStackLocks is always enabled) and (b) stack lock cases are >>>> failing because UseRTMForStackLocks is always disabled. >>>> >>>> @Igor, it's a long time ago, but maybe you recall some details on that >>>> test... :-) >>>> >>>> >>>> Thank you. >>>> >>>> Best regards, >>>> Gustavo >> > From igor.ignatyev at oracle.com Wed Jun 20 19:39:56 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 20 Jun 2018 12:39:56 -0700 Subject: RFR(XXS) : 8205433 : clean up hotspot ProblemList In-Reply-To: <36ed5b48-cfee-9377-6522-203f7f76c62c@oracle.com> References: <36ed5b48-cfee-9377-6522-203f7f76c62c@oracle.com> Message-ID: <6627A300-16CE-4D9B-93E7-20BFB4ED349D@oracle.com> Thanks Vladimir! -- Igor > On Jun 20, 2018, at 12:38 PM, Vladimir Kozlov wrote: > > Looks good. > > Thanks, > Vladimir > > On 6/20/18 12:33 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8205433/webrev.00/index.html >>> 10 lines changed: 1 ins; 8 del; 1 mod; >> Hi all, >> could you please review this tiny clean up of ProblemList.txt? >> compiler/c2/Test8007294.java hasn't been removed from the problem list when JDK-8192992 was fixed. the same test s also marked as failing due to JDK-8194310 (Java EE modules removal), but this test doesn't depend on any java ee modules. >> testing: compiler/c2/Test8007294.java on linux-x64,windows-x64,solaris-sparcv9,macos-x64 x {product,fastdebug} >> webrev: http://cr.openjdk.java.net/~iignatyev//8205433/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8205433 >> Thanks, >> -- Igor From goetz.lindenmaier at sap.com Wed Jun 20 20:08:59 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 20 Jun 2018 20:08:59 +0000 Subject: RFR(XS): 8204135: jtreg: Fix failing RTM test TestUseRTMXendForLockBusy In-Reply-To: <1ceba2cc-31da-ebf5-1736-9a70c01cbc19@linux.vnet.ibm.com> References: <798cdc2a-ad0a-423f-351b-a8fc9eefc942@linux.vnet.ibm.com> <9cfd785a819e4b4e93660e8644304cff@sap.com> <4737a4fa-40b6-3eba-8ffa-4f39e0a55c68@linux.vnet.ibm.com> <1ceba2cc-31da-ebf5-1736-9a70c01cbc19@linux.vnet.ibm.com> Message-ID: <86702fb588dc42faad205c1e3bacfe80@sap.com> Done ?? Best regards, Goetz. > -----Original Message----- > From: Gustavo Romero > Sent: Wednesday, June 20, 2018 9:40 PM > To: Lindenmaier, Goetz > Cc: Igor Ignatyev ; hotspot-compiler- > dev at openjdk.java.net; Doerr, Martin > Subject: Re: RFR(XS): 8204135: jtreg: Fix failing RTM test > TestUseRTMXendForLockBusy > > Hi Igor, > > On 06/20/2018 03:23 PM, Igor Ignatyev wrote: > > as your patch has been reviewed by two reviewers, it is fine to be pushed. > > Thanks for reviewing it. > > Goetz, could you please sponsor the change? > > > Regards, > Gustavo > > > -- Igor > > > >> On Jun 20, 2018, at 5:17 AM, Gustavo Romero > wrote: > >> > >> Hi Igor, > >> > >> On 06/15/2018 10:12 AM, Lindenmaier, Goetz wrote: > >>> I had a look at your fix. As I understand the test it's just > >>> what was intended to do. Also, it fixed the test in our runs. > >>> Reviewed. > >>> I would volunteer to sponsor this. > >> > >> Goetz reviewed the change. Is it OK to be pushed? > >> > >> > >> Thanks. > >> > >> Best regards, > >> Gustavo > >> > >>> Best regards, > >>> Goetz. > >>>> -----Original Message----- > >>>> From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] > >>>> Sent: Donnerstag, 31. Mai 2018 04:05 > >>>> To: hotspot-compiler-dev at openjdk.java.net; > igor.ignatyev at oracle.com > >>>> Cc: Lindenmaier, Goetz ; Doerr, Martin > >>>> > >>>> Subject: RFR(XS): 8204135: jtreg: Fix failing RTM test > >>>> TestUseRTMXendForLockBusy > >>>> > >>>> Hi, > >>>> > >>>> Could the following change be reviewed please? > >>>> > >>>> webrev: http://cr.openjdk.java.net/~gromero/8204135/v1 > >>>> bug : https://bugs.openjdk.java.net/browse/JDK-8204135 > >>>> > >>>> It fixes currently failing RTM test "TestUseRTMXendForLockBusy" by > >>>> changing > >>>> in which cases UseRTMForStackLocks flags must be enabled/disabled. > >>>> > >>>> I could not track down on the timeline when exactly that test stopped > to > >>>> pass, however my understanding is that if inflateMonitor is 'false' that > >>>> should /not/ imply that UseRTMForStackLocks is also 'false'. Thus I > >>>> understand that for this particular test if inflated monitors are used, > >>>> then UseRTMForStackLocks has to be disabled, i.e. 'false'. On the other > >>>> hand, if inflated monitors are /not/ used, then UseRTMForStackLocks > must > >>>> be > >>>> enabled. > >>>> > >>>> Currently the test is failing for the following cases where inflateMonitor > >>>> is 'false', because it implies that UseRTMForStackLocks is disabled and > so > >>>> no abort statistics is generated (which is correct from the JVM's > >>>> perspective): > >>>> > >>>> // stack lock, xabort on lock busy > >>>> verifyXendForLockBusy(false, false); > >>>> // stack lock, xend on lock busy > >>>> verifyXendForLockBusy(false, true); > >>>> > >>>> In other words, "stack lock" case should imply UseRTMForStackLocks = > 'true', > >>>> not 'false'. > >>>> > >>>> Cases: > >>>> // inflated lock, xabort on lock busy > >>>> verifyXendForLockBusy(true, false); > >>>> // inflated lock, xend on lock busy > >>>> verifyXendForLockBusy(true, true); > >>>> > >>>> are not failing because UseRTMForStackLocks = 'true' and they will > generate > >>>> proper abort statistics when +UseRTMXendForLockBusy ('xend' is used > to > >>>> finish the transaction) or when -UseRTMXendForLockBusy ('xabort' is > used > >>>> to finish the transaction). > >>>> > >>>> So, in summing up: (a) inflated lock cases are not being tested correctly > >>>> (since UseRTMForStackLocks is always enabled) and (b) stack lock cases > are > >>>> failing because UseRTMForStackLocks is always disabled. > >>>> > >>>> @Igor, it's a long time ago, but maybe you recall some details on that > >>>> test... :-) > >>>> > >>>> > >>>> Thank you. > >>>> > >>>> Best regards, > >>>> Gustavo > >> > > From gromero at linux.vnet.ibm.com Wed Jun 20 20:10:48 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 20 Jun 2018 17:10:48 -0300 Subject: RFR(XS): 8204135: jtreg: Fix failing RTM test TestUseRTMXendForLockBusy In-Reply-To: <86702fb588dc42faad205c1e3bacfe80@sap.com> References: <798cdc2a-ad0a-423f-351b-a8fc9eefc942@linux.vnet.ibm.com> <9cfd785a819e4b4e93660e8644304cff@sap.com> <4737a4fa-40b6-3eba-8ffa-4f39e0a55c68@linux.vnet.ibm.com> <1ceba2cc-31da-ebf5-1736-9a70c01cbc19@linux.vnet.ibm.com> <86702fb588dc42faad205c1e3bacfe80@sap.com> Message-ID: Thanks! :) On 06/20/2018 05:08 PM, Lindenmaier, Goetz wrote: > Done ?? > > Best regards, > Goetz. > >> -----Original Message----- >> From: Gustavo Romero >> Sent: Wednesday, June 20, 2018 9:40 PM >> To: Lindenmaier, Goetz >> Cc: Igor Ignatyev ; hotspot-compiler- >> dev at openjdk.java.net; Doerr, Martin >> Subject: Re: RFR(XS): 8204135: jtreg: Fix failing RTM test >> TestUseRTMXendForLockBusy >> >> Hi Igor, >> >> On 06/20/2018 03:23 PM, Igor Ignatyev wrote: >>> as your patch has been reviewed by two reviewers, it is fine to be pushed. >> >> Thanks for reviewing it. >> >> Goetz, could you please sponsor the change? >> >> >> Regards, >> Gustavo >> >>> -- Igor >>> >>>> On Jun 20, 2018, at 5:17 AM, Gustavo Romero >> wrote: >>>> >>>> Hi Igor, >>>> >>>> On 06/15/2018 10:12 AM, Lindenmaier, Goetz wrote: >>>>> I had a look at your fix. As I understand the test it's just >>>>> what was intended to do. Also, it fixed the test in our runs. >>>>> Reviewed. >>>>> I would volunteer to sponsor this. >>>> >>>> Goetz reviewed the change. Is it OK to be pushed? >>>> >>>> >>>> Thanks. >>>> >>>> Best regards, >>>> Gustavo >>>> >>>>> Best regards, >>>>> Goetz. >>>>>> -----Original Message----- >>>>>> From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] >>>>>> Sent: Donnerstag, 31. Mai 2018 04:05 >>>>>> To: hotspot-compiler-dev at openjdk.java.net; >> igor.ignatyev at oracle.com >>>>>> Cc: Lindenmaier, Goetz ; Doerr, Martin >>>>>> >>>>>> Subject: RFR(XS): 8204135: jtreg: Fix failing RTM test >>>>>> TestUseRTMXendForLockBusy >>>>>> >>>>>> Hi, >>>>>> >>>>>> Could the following change be reviewed please? >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~gromero/8204135/v1 >>>>>> bug : https://bugs.openjdk.java.net/browse/JDK-8204135 >>>>>> >>>>>> It fixes currently failing RTM test "TestUseRTMXendForLockBusy" by >>>>>> changing >>>>>> in which cases UseRTMForStackLocks flags must be enabled/disabled. >>>>>> >>>>>> I could not track down on the timeline when exactly that test stopped >> to >>>>>> pass, however my understanding is that if inflateMonitor is 'false' that >>>>>> should /not/ imply that UseRTMForStackLocks is also 'false'. Thus I >>>>>> understand that for this particular test if inflated monitors are used, >>>>>> then UseRTMForStackLocks has to be disabled, i.e. 'false'. On the other >>>>>> hand, if inflated monitors are /not/ used, then UseRTMForStackLocks >> must >>>>>> be >>>>>> enabled. >>>>>> >>>>>> Currently the test is failing for the following cases where inflateMonitor >>>>>> is 'false', because it implies that UseRTMForStackLocks is disabled and >> so >>>>>> no abort statistics is generated (which is correct from the JVM's >>>>>> perspective): >>>>>> >>>>>> // stack lock, xabort on lock busy >>>>>> verifyXendForLockBusy(false, false); >>>>>> // stack lock, xend on lock busy >>>>>> verifyXendForLockBusy(false, true); >>>>>> >>>>>> In other words, "stack lock" case should imply UseRTMForStackLocks = >> 'true', >>>>>> not 'false'. >>>>>> >>>>>> Cases: >>>>>> // inflated lock, xabort on lock busy >>>>>> verifyXendForLockBusy(true, false); >>>>>> // inflated lock, xend on lock busy >>>>>> verifyXendForLockBusy(true, true); >>>>>> >>>>>> are not failing because UseRTMForStackLocks = 'true' and they will >> generate >>>>>> proper abort statistics when +UseRTMXendForLockBusy ('xend' is used >> to >>>>>> finish the transaction) or when -UseRTMXendForLockBusy ('xabort' is >> used >>>>>> to finish the transaction). >>>>>> >>>>>> So, in summing up: (a) inflated lock cases are not being tested correctly >>>>>> (since UseRTMForStackLocks is always enabled) and (b) stack lock cases >> are >>>>>> failing because UseRTMForStackLocks is always disabled. >>>>>> >>>>>> @Igor, it's a long time ago, but maybe you recall some details on that >>>>>> test... :-) >>>>>> >>>>>> >>>>>> Thank you. >>>>>> >>>>>> Best regards, >>>>>> Gustavo >>>> >>> > From smita.kamath at intel.com Wed Jun 20 20:50:13 2018 From: smita.kamath at intel.com (Kamath, Smita) Date: Wed, 20 Jun 2018 20:50:13 +0000 Subject: RFR(S) 8205398: AES-CBC decryption algorithm using AVX512 instructions Message-ID: <6563F381B547594081EF9DE181D0791277AABEA0@FMSMSX119.amr.corp.intel.com> Hi Vladimir, As per "Intel Architecture Instruction Set Extensions and Future Features Programming Reference" manual [1], vector aes decrypt (vaesdec and vaesdeclast) instructions will be supported in future Intel ISA. I have updated AES-CBC decryption algorithm to take advantage of these instructions. Shravya(cc'ed) and I are co-contributors. Shay Gueron and Regev Shemy (regev.shemy at intel.com) are the authors of the algorithm. I have tested the algorithm with Intel SDE [2] to confirm encoding and semantics are correctly implemented. Please take a look and let me know if you have any questions or comments. http://cr.openjdk.java.net/~vdeshpande/AES_CBC_AVX512/webrev.00/ [1] https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf [2] https://software.intel.com/en-us/articles/intel-software-development-emulator [3] https://bugs.openjdk.java.net/browse/JDK-8205398 Thanks, Smita -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Wed Jun 20 21:47:00 2018 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 20 Jun 2018 14:47:00 -0700 Subject: RFR(S) 8205105: VM crashes with "assert(Universe::heap()->is_in_reserved(start + words - 1)) failed: not in heap Message-ID: <198397B5-FB87-4B4A-8761-3D5191880D01@oracle.com> Low-Overhead Heap Profiling is not compatible with fast TLAB refill. It needs to be disabled. Webrev: http://cr.openjdk.java.net/~iveresov/8205105/webrev/ Thanks, igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed Jun 20 21:50:47 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 20 Jun 2018 14:50:47 -0700 Subject: RFR(S) 8205398: AES-CBC decryption algorithm using AVX512 instructions In-Reply-To: <6563F381B547594081EF9DE181D0791277AABEA0@FMSMSX119.amr.corp.intel.com> References: <6563F381B547594081EF9DE181D0791277AABEA0@FMSMSX119.amr.corp.intel.com> Message-ID: <174162ef-15a4-22e1-8852-ceb06bee2f89@oracle.com> Hi, Smita Changes looks fine to me. Can you run set of tests defined in test/hotspot/jtreg/compiler/codegen/aes/TestAESMain.java on Intel SDE to make sure new code produce correct result? Thanks, Vladimir On 6/20/18 1:50 PM, Kamath, Smita wrote: > Hi Vladimir, > > As per ?Intel Architecture Instruction Set Extensions and Future > Features Programming Reference? ?manual [1], vector aes decrypt (vaesdec > and vaesdeclast) instructions will be supported in future Intel ISA. I > have updated AES-CBC decryption algorithm to take advantage of these > instructions. Shravya(cc?ed) and I are co-contributors. Shay Gueron and > Regev Shemy (regev.shemy at intel.com ) are > the authors of the algorithm. > > I have tested ?the algorithm with Intel SDE [2] to confirm encoding and > semantics are correctly implemented. > > Please take a look and let me know if you have any questions or comments. > > http://cr.openjdk.java.net/~vdeshpande/AES_CBC_AVX512/webrev.00/ > > [1] > https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf > > [2] > https://software.intel.com/en-us/articles/intel-software-development-emulator > > > [3] https://bugs.openjdk.java.net/browse/JDK-8205398 > > Thanks, > > Smita > From dean.long at oracle.com Wed Jun 20 21:57:05 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 20 Jun 2018 14:57:05 -0700 Subject: RFR(S) 8204209: [Graal] Compilation fails during nmethod printing with "assert(bci == 0 || 0 <= bci && bci < code_size()) failed: illegal bci" In-Reply-To: References: Message-ID: Looks good. dl On 6/18/18 6:28 PM, Igor Veresov wrote: > Make hotspot tolerate negative placeholder BCIs that are produced by Graal. > > Should this fix be deemed acceptable I?ll backport it to graal-jvmci-8. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8204209 > Webrev: http://cr.openjdk.java.net/~iveresov/8204209/webrev/ > > Thanks, > igor From doug.simon at oracle.com Wed Jun 20 22:06:35 2018 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 21 Jun 2018 00:06:35 +0200 Subject: RFR(S) 8205105: VM crashes with "assert(Universe::heap()->is_in_reserved(start + words - 1)) failed: not in heap In-Reply-To: <198397B5-FB87-4B4A-8761-3D5191880D01@oracle.com> References: <198397B5-FB87-4B4A-8761-3D5191880D01@oracle.com> Message-ID: Looks good to me. > On 20 Jun 2018, at 23:47, Igor Veresov wrote: > > Low-Overhead Heap Profiling is not compatible with fast TLAB refill. It needs to be disabled. > > Webrev: http://cr.openjdk.java.net/~iveresov/8205105/webrev/ > > Thanks, > igor From igor.veresov at oracle.com Wed Jun 20 22:10:43 2018 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 20 Jun 2018 15:10:43 -0700 Subject: RFR(S) 8205105: VM crashes with "assert(Universe::heap()->is_in_reserved(start + words - 1)) failed: not in heap In-Reply-To: References: <198397B5-FB87-4B4A-8761-3D5191880D01@oracle.com> Message-ID: <6970BB79-F9C6-41D8-8E89-CC15E93B9050@oracle.com> Thanks, Doug! igor > On Jun 20, 2018, at 3:06 PM, Doug Simon wrote: > > Looks good to me. > >> On 20 Jun 2018, at 23:47, Igor Veresov wrote: >> >> Low-Overhead Heap Profiling is not compatible with fast TLAB refill. It needs to be disabled. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8205105/webrev/ >> >> Thanks, >> igor > From vladimir.kozlov at oracle.com Wed Jun 20 22:20:24 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 20 Jun 2018 15:20:24 -0700 Subject: RFR(S) 8205105: VM crashes with "assert(Universe::heap()->is_in_reserved(start + words - 1)) failed: not in heap In-Reply-To: <198397B5-FB87-4B4A-8761-3D5191880D01@oracle.com> References: <198397B5-FB87-4B4A-8761-3D5191880D01@oracle.com> Message-ID: Why Graal is affected even when LOHP is not used? I don't see changes which mapped new TLAB fields added by Low-Overhead Heap Profiling. I don't see your answers to Stefan's comment in bug report about Graal's code which is not fixed for _allocation_end. Does Graal still use fast TLAB refill as default mode? FastTLABRefill was deprecated by 8194084: "Obsolete FastTLABRefill and remove the related code": http://hg.openjdk.java.net/jdk/jdk/rev/9010e596f391 Should we remove it from Graal too? Thanks, Vladimir On 6/20/18 2:47 PM, Igor Veresov wrote: > Low-Overhead Heap Profiling is not compatible with fast TLAB refill. It > needs to be disabled. > > Webrev: http://cr.openjdk.java.net/~iveresov/8205105/webrev/ > > Thanks, > igor From igor.veresov at oracle.com Wed Jun 20 22:22:34 2018 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 20 Jun 2018 15:22:34 -0700 Subject: RFR(S) 8205105: VM crashes with "assert(Universe::heap()->is_in_reserved(start + words - 1)) failed: not in heap In-Reply-To: References: <198397B5-FB87-4B4A-8761-3D5191880D01@oracle.com> Message-ID: <490C78D8-4047-4AA0-B8AE-49D8A733C1EF@oracle.com> > On Jun 20, 2018, at 3:20 PM, Vladimir Kozlov wrote: > > Why Graal is affected even when LOHP is not used? LOHP is dynamically turned on by JVMTI. > > I don't see changes which mapped new TLAB fields added by Low-Overhead Heap Profiling. > > I don't see your answers to Stefan's comment in bug report about Graal's code which is not fixed for _allocation_end. > > Does Graal still use fast TLAB refill as default mode? You cannot use TLAB refill with LOHP at all. > > FastTLABRefill was deprecated by 8194084: "Obsolete FastTLABRefill and remove the related code": > > http://hg.openjdk.java.net/jdk/jdk/rev/9010e596f391 > > Should we remove it from Graal too? > Not for JDKs <11. igor > Thanks, > Vladimir > > On 6/20/18 2:47 PM, Igor Veresov wrote: >> Low-Overhead Heap Profiling is not compatible with fast TLAB refill. It needs to be disabled. >> Webrev: http://cr.openjdk.java.net/~iveresov/8205105/webrev/ >> Thanks, >> igor From vladimir.kozlov at oracle.com Wed Jun 20 22:43:36 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 20 Jun 2018 15:43:36 -0700 Subject: RFR(S) 8205105: VM crashes with "assert(Universe::heap()->is_in_reserved(start + words - 1)) failed: not in heap In-Reply-To: <490C78D8-4047-4AA0-B8AE-49D8A733C1EF@oracle.com> References: <198397B5-FB87-4B4A-8761-3D5191880D01@oracle.com> <490C78D8-4047-4AA0-B8AE-49D8A733C1EF@oracle.com> Message-ID: <23f223cb-0590-eae0-0851-d35e6e7ed57b@oracle.com> On 6/20/18 3:22 PM, Igor Veresov wrote: > > >> On Jun 20, 2018, at 3:20 PM, Vladimir Kozlov wrote: >> >> Why Graal is affected even when LOHP is not used? > > LOHP is dynamically turned on by JVMTI. Okay. In other world we can't use fast TLAB refill because JVMTI can switch on LOHP at any time. Got it. I still did not get why GC tests which do not use LOHP still fail with Graal. And how these changes fix it? Thanks, Vladimir > >> >> I don't see changes which mapped new TLAB fields added by Low-Overhead Heap Profiling. >> >> I don't see your answers to Stefan's comment in bug report about Graal's code which is not fixed for _allocation_end. >> >> Does Graal still use fast TLAB refill as default mode? > > You cannot use TLAB refill with LOHP at all. > >> >> FastTLABRefill was deprecated by 8194084: "Obsolete FastTLABRefill and remove the related code": >> >> http://hg.openjdk.java.net/jdk/jdk/rev/9010e596f391 >> >> Should we remove it from Graal too? >> > > Not for JDKs <11. > > igor > >> Thanks, >> Vladimir >> >> On 6/20/18 2:47 PM, Igor Veresov wrote: >>> Low-Overhead Heap Profiling is not compatible with fast TLAB refill. It needs to be disabled. >>> Webrev: http://cr.openjdk.java.net/~iveresov/8205105/webrev/ >>> Thanks, >>> igor > From smita.kamath at intel.com Wed Jun 20 22:49:05 2018 From: smita.kamath at intel.com (Kamath, Smita) Date: Wed, 20 Jun 2018 22:49:05 +0000 Subject: RFR(S) 8205398: AES-CBC decryption algorithm using AVX512 instructions In-Reply-To: <174162ef-15a4-22e1-8852-ceb06bee2f89@oracle.com> References: <6563F381B547594081EF9DE181D0791277AABEA0@FMSMSX119.amr.corp.intel.com> <174162ef-15a4-22e1-8852-ceb06bee2f89@oracle.com> Message-ID: <6563F381B547594081EF9DE181D0791277AABF16@FMSMSX119.amr.corp.intel.com> Hi Vladimir, I ran all tests for AES-CBC in TestAESMain.java using SDE. The new code produced correct results. Regards, Smita -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Wednesday, June 20, 2018 2:51 PM To: Kamath, Smita Cc: Rukmannagari, Shravya ; hotspot compiler Subject: Re: RFR(S) 8205398: AES-CBC decryption algorithm using AVX512 instructions Hi, Smita Changes looks fine to me. Can you run set of tests defined in test/hotspot/jtreg/compiler/codegen/aes/TestAESMain.java on Intel SDE to make sure new code produce correct result? Thanks, Vladimir On 6/20/18 1:50 PM, Kamath, Smita wrote: > Hi Vladimir, > > As per "Intel Architecture Instruction Set Extensions and Future > Features Programming Reference" ?manual [1], vector aes decrypt > (vaesdec and vaesdeclast) instructions will be supported in future > Intel ISA. I have updated AES-CBC decryption algorithm to take > advantage of these instructions. Shravya(cc'ed) and I are > co-contributors. Shay Gueron and Regev Shemy (regev.shemy at intel.com > ) are the authors of the algorithm. > > I have tested ?the algorithm with Intel SDE [2] to confirm encoding > and semantics are correctly implemented. > > Please take a look and let me know if you have any questions or comments. > > http://cr.openjdk.java.net/~vdeshpande/AES_CBC_AVX512/webrev.00/ > > [1] > https://software.intel.com/sites/default/files/managed/c5/15/architect > ure-instruction-set-extensions-programming-reference.pdf > > [2] > https://software.intel.com/en-us/articles/intel-software-development-e > mulator > > > [3] https://bugs.openjdk.java.net/browse/JDK-8205398 > > Thanks, > > Smita > From vladimir.kozlov at oracle.com Wed Jun 20 23:09:22 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 20 Jun 2018 16:09:22 -0700 Subject: RFR(S) 8205398: AES-CBC decryption algorithm using AVX512 instructions In-Reply-To: <6563F381B547594081EF9DE181D0791277AABF16@FMSMSX119.amr.corp.intel.com> References: <6563F381B547594081EF9DE181D0791277AABEA0@FMSMSX119.amr.corp.intel.com> <174162ef-15a4-22e1-8852-ceb06bee2f89@oracle.com> <6563F381B547594081EF9DE181D0791277AABF16@FMSMSX119.amr.corp.intel.com> Message-ID: Good. Let me test it. Thanks, Vladimir On 6/20/18 3:49 PM, Kamath, Smita wrote: > Hi Vladimir, > > I ran all tests for AES-CBC in TestAESMain.java using SDE. The new code produced correct results. > > Regards, > Smita > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, June 20, 2018 2:51 PM > To: Kamath, Smita > Cc: Rukmannagari, Shravya ; hotspot compiler > Subject: Re: RFR(S) 8205398: AES-CBC decryption algorithm using AVX512 instructions > > Hi, Smita > > Changes looks fine to me. > > Can you run set of tests defined in > test/hotspot/jtreg/compiler/codegen/aes/TestAESMain.java on Intel SDE to make sure new code produce correct result? > > Thanks, > Vladimir > > On 6/20/18 1:50 PM, Kamath, Smita wrote: >> Hi Vladimir, >> >> As per "Intel Architecture Instruction Set Extensions and Future >> Features Programming Reference" ?manual [1], vector aes decrypt >> (vaesdec and vaesdeclast) instructions will be supported in future >> Intel ISA. I have updated AES-CBC decryption algorithm to take >> advantage of these instructions. Shravya(cc'ed) and I are >> co-contributors. Shay Gueron and Regev Shemy (regev.shemy at intel.com >> ) are the authors of the algorithm. >> >> I have tested ?the algorithm with Intel SDE [2] to confirm encoding >> and semantics are correctly implemented. >> >> Please take a look and let me know if you have any questions or comments. >> >> http://cr.openjdk.java.net/~vdeshpande/AES_CBC_AVX512/webrev.00/ >> >> [1] >> https://software.intel.com/sites/default/files/managed/c5/15/architect >> ure-instruction-set-extensions-programming-reference.pdf >> >> [2] >> https://software.intel.com/en-us/articles/intel-software-development-e >> mulator >> >> >> [3] https://bugs.openjdk.java.net/browse/JDK-8205398 >> >> Thanks, >> >> Smita >> From igor.veresov at oracle.com Wed Jun 20 23:17:31 2018 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 20 Jun 2018 16:17:31 -0700 Subject: RFR(S) 8205105: VM crashes with "assert(Universe::heap()->is_in_reserved(start + words - 1)) failed: not in heap In-Reply-To: <23f223cb-0590-eae0-0851-d35e6e7ed57b@oracle.com> References: <198397B5-FB87-4B4A-8761-3D5191880D01@oracle.com> <490C78D8-4047-4AA0-B8AE-49D8A733C1EF@oracle.com> <23f223cb-0590-eae0-0851-d35e6e7ed57b@oracle.com> Message-ID: <73973268-B7E9-4EDF-AB22-DAD5E06E6207@oracle.com> > On Jun 20, 2018, at 3:43 PM, Vladimir Kozlov wrote: > > On 6/20/18 3:22 PM, Igor Veresov wrote: >>> On Jun 20, 2018, at 3:20 PM, Vladimir Kozlov wrote: >>> >>> Why Graal is affected even when LOHP is not used? >> LOHP is dynamically turned on by JVMTI. > > Okay. In other world we can't use fast TLAB refill because JVMTI can switch on LOHP at any time. Got it. > Well, unless we want to add an additional dynamic check of the LOHP state. That?s also a possible solution if we want to keep the fast TLAB refill. > I still did not get why GC tests which do not use LOHP still fail with Graal. And how these changes fix it? Because, as Stefan noted in the bug, when Graal does fast TLAB refill it does so without setting the new _allocation_end field. The changes fix it by avoiding manually allocating TLABs in the stub (during fast TLAB refill) and calling the runtime instead. igor > > Thanks, > Vladimir > >>> >>> I don't see changes which mapped new TLAB fields added by Low-Overhead Heap Profiling. >>> >>> I don't see your answers to Stefan's comment in bug report about Graal's code which is not fixed for _allocation_end. >>> >>> Does Graal still use fast TLAB refill as default mode? >> You cannot use TLAB refill with LOHP at all. >>> >>> FastTLABRefill was deprecated by 8194084: "Obsolete FastTLABRefill and remove the related code": >>> >>> http://hg.openjdk.java.net/jdk/jdk/rev/9010e596f391 >>> >>> Should we remove it from Graal too? >>> >> Not for JDKs <11. >> igor >>> Thanks, >>> Vladimir >>> >>> On 6/20/18 2:47 PM, Igor Veresov wrote: >>>> Low-Overhead Heap Profiling is not compatible with fast TLAB refill. It needs to be disabled. >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8205105/webrev/ >>>> Thanks, >>>> igor From vladimir.kozlov at oracle.com Wed Jun 20 23:43:52 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 20 Jun 2018 16:43:52 -0700 Subject: RFR(S) 8205105: VM crashes with "assert(Universe::heap()->is_in_reserved(start + words - 1)) failed: not in heap In-Reply-To: <73973268-B7E9-4EDF-AB22-DAD5E06E6207@oracle.com> References: <198397B5-FB87-4B4A-8761-3D5191880D01@oracle.com> <490C78D8-4047-4AA0-B8AE-49D8A733C1EF@oracle.com> <23f223cb-0590-eae0-0851-d35e6e7ed57b@oracle.com> <73973268-B7E9-4EDF-AB22-DAD5E06E6207@oracle.com> Message-ID: On 6/20/18 4:17 PM, Igor Veresov wrote: > > >> On Jun 20, 2018, at 3:43 PM, Vladimir Kozlov wrote: >> >> On 6/20/18 3:22 PM, Igor Veresov wrote: >>>> On Jun 20, 2018, at 3:20 PM, Vladimir Kozlov wrote: >>>> >>>> Why Graal is affected even when LOHP is not used? >>> LOHP is dynamically turned on by JVMTI. >> >> Okay. In other world we can't use fast TLAB refill because JVMTI can switch on LOHP at any time. Got it. >> > > Well, unless we want to add an additional dynamic check of the LOHP state. That?s also a possible solution if we want to keep the fast TLAB refill. Nope. We removed it from Hotspot in JDK 11. I don't think we should spend time supporting it in Graal. > >> I still did not get why GC tests which do not use LOHP still fail with Graal. And how these changes fix it? > > Because, as Stefan noted in the bug, when Graal does fast TLAB refill it does so without setting the new _allocation_end field. It means Graal uses fast TLAB refill by default. That is answer I was waiting for. > The changes fix it by avoiding manually allocating TLABs in the stub (during fast TLAB refill) and calling the runtime instead. Okay. Got it. Reviewed. Thanks, Vladimir > > igor > >> >> Thanks, >> Vladimir >> >>>> >>>> I don't see changes which mapped new TLAB fields added by Low-Overhead Heap Profiling. >>>> >>>> I don't see your answers to Stefan's comment in bug report about Graal's code which is not fixed for _allocation_end. >>>> >>>> Does Graal still use fast TLAB refill as default mode? >>> You cannot use TLAB refill with LOHP at all. >>>> >>>> FastTLABRefill was deprecated by 8194084: "Obsolete FastTLABRefill and remove the related code": >>>> >>>> http://hg.openjdk.java.net/jdk/jdk/rev/9010e596f391 >>>> >>>> Should we remove it from Graal too? >>>> >>> Not for JDKs <11. >>> igor >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/20/18 2:47 PM, Igor Veresov wrote: >>>>> Low-Overhead Heap Profiling is not compatible with fast TLAB refill. It needs to be disabled. >>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8205105/webrev/ >>>>> Thanks, >>>>> igor > From igor.veresov at oracle.com Wed Jun 20 23:51:58 2018 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 20 Jun 2018 16:51:58 -0700 Subject: RFR(S) 8205105: VM crashes with "assert(Universe::heap()->is_in_reserved(start + words - 1)) failed: not in heap In-Reply-To: References: <198397B5-FB87-4B4A-8761-3D5191880D01@oracle.com> <490C78D8-4047-4AA0-B8AE-49D8A733C1EF@oracle.com> <23f223cb-0590-eae0-0851-d35e6e7ed57b@oracle.com> <73973268-B7E9-4EDF-AB22-DAD5E06E6207@oracle.com> Message-ID: <1A762372-2BB8-4E32-83A6-D7D094DF78CA@oracle.com> Thanks, Vladimir! igor > On Jun 20, 2018, at 4:43 PM, Vladimir Kozlov wrote: > > On 6/20/18 4:17 PM, Igor Veresov wrote: >>> On Jun 20, 2018, at 3:43 PM, Vladimir Kozlov wrote: >>> >>> On 6/20/18 3:22 PM, Igor Veresov wrote: >>>>> On Jun 20, 2018, at 3:20 PM, Vladimir Kozlov wrote: >>>>> >>>>> Why Graal is affected even when LOHP is not used? >>>> LOHP is dynamically turned on by JVMTI. >>> >>> Okay. In other world we can't use fast TLAB refill because JVMTI can switch on LOHP at any time. Got it. >>> >> Well, unless we want to add an additional dynamic check of the LOHP state. That?s also a possible solution if we want to keep the fast TLAB refill. > > Nope. We removed it from Hotspot in JDK 11. I don't think we should spend time supporting it in Graal. > >>> I still did not get why GC tests which do not use LOHP still fail with Graal. And how these changes fix it? >> Because, as Stefan noted in the bug, when Graal does fast TLAB refill it does so without setting the new _allocation_end field. > > It means Graal uses fast TLAB refill by default. That is answer I was waiting for. > >> The changes fix it by avoiding manually allocating TLABs in the stub (during fast TLAB refill) and calling the runtime instead. > > Okay. Got it. Reviewed. > > Thanks, > Vladimir > >> igor >>> >>> Thanks, >>> Vladimir >>> >>>>> >>>>> I don't see changes which mapped new TLAB fields added by Low-Overhead Heap Profiling. >>>>> >>>>> I don't see your answers to Stefan's comment in bug report about Graal's code which is not fixed for _allocation_end. >>>>> >>>>> Does Graal still use fast TLAB refill as default mode? >>>> You cannot use TLAB refill with LOHP at all. >>>>> >>>>> FastTLABRefill was deprecated by 8194084: "Obsolete FastTLABRefill and remove the related code": >>>>> >>>>> http://hg.openjdk.java.net/jdk/jdk/rev/9010e596f391 >>>>> >>>>> Should we remove it from Graal too? >>>>> >>>> Not for JDKs <11. >>>> igor >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 6/20/18 2:47 PM, Igor Veresov wrote: >>>>>> Low-Overhead Heap Profiling is not compatible with fast TLAB refill. It needs to be disabled. >>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8205105/webrev/ >>>>>> Thanks, >>>>>> igor From tom.rodriguez at oracle.com Thu Jun 21 01:07:29 2018 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 20 Jun 2018 18:07:29 -0700 Subject: RFR(S) 8205105: VM crashes with "assert(Universe::heap()->is_in_reserved(start + words - 1)) failed: not in heap In-Reply-To: References: <198397B5-FB87-4B4A-8761-3D5191880D01@oracle.com> <490C78D8-4047-4AA0-B8AE-49D8A733C1EF@oracle.com> <23f223cb-0590-eae0-0851-d35e6e7ed57b@oracle.com> <73973268-B7E9-4EDF-AB22-DAD5E06E6207@oracle.com> Message-ID: Vladimir Kozlov wrote on 6/20/18 4:43 PM: > On 6/20/18 4:17 PM, Igor Veresov wrote: >> >> >>> On Jun 20, 2018, at 3:43 PM, Vladimir Kozlov >>> wrote: >>> >>> On 6/20/18 3:22 PM, Igor Veresov wrote: >>>>> On Jun 20, 2018, at 3:20 PM, Vladimir Kozlov >>>>> wrote: >>>>> >>>>> Why Graal is affected even when LOHP is not used? >>>> LOHP is dynamically turned on by JVMTI. >>> >>> Okay. In other world we can't use fast TLAB refill because JVMTI can >>> switch on LOHP at any time. Got it. >>> >> >> Well, unless we want to add an additional dynamic check of the LOHP >> state. That?s also a possible solution if we want to keep the fast >> TLAB refill. > > Nope. We removed it from Hotspot in JDK 11. I don't think we should > spend time supporting it in Graal. I'll file an issue to remove it completely from Graal, even in JDK8. It was something that came over from C1 where it was really a client side optimization since TLABs were small and fixed size in the -client world. I think it's not likely to be particularly beneficial in the tiered world. tom > >> >>> I still did not get why GC tests which do not use LOHP still fail >>> with Graal. And how these changes fix it? >> >> Because, as Stefan noted in the bug, when Graal does fast TLAB refill >> it does so without setting the new _allocation_end field. > > It means Graal uses fast TLAB refill by default. That is answer I was > waiting for. > >> The changes fix it by avoiding manually allocating TLABs in the stub >> (during fast TLAB refill) and calling the runtime instead. > > Okay. Got it. Reviewed. > > Thanks, > Vladimir > >> >> igor >> >>> >>> Thanks, >>> Vladimir >>> >>>>> >>>>> I don't see changes which mapped new TLAB fields added by >>>>> Low-Overhead Heap Profiling. >>>>> >>>>> I don't see your answers to Stefan's comment in bug report about >>>>> Graal's code which is not fixed for _allocation_end. >>>>> >>>>> Does Graal still use fast TLAB refill as default mode? >>>> You cannot use TLAB refill with LOHP at all. >>>>> >>>>> FastTLABRefill was deprecated by 8194084: "Obsolete FastTLABRefill >>>>> and remove the related code": >>>>> >>>>> http://hg.openjdk.java.net/jdk/jdk/rev/9010e596f391 >>>>> >>>>> Should we remove it from Graal too? >>>>> >>>> Not for JDKs <11. >>>> igor >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 6/20/18 2:47 PM, Igor Veresov wrote: >>>>>> Low-Overhead Heap Profiling is not compatible with fast TLAB >>>>>> refill. It needs to be disabled. >>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8205105/webrev/ >>>>>> Thanks, >>>>>> igor >> From igor.ignatyev at oracle.com Thu Jun 21 03:28:39 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 20 Jun 2018 20:28:39 -0700 Subject: RFR(XS) : 8155192 : [TESTBUG] SHA tests assumes that x86 does not have SHA intrinsics Message-ID: <475373C8-367F-4600-B246-F5E91608B4FD@oracle.com> http://cr.openjdk.java.net/~iignatyev//8155192/webrev.00/index.html > 29 lines changed: 10 ins; 3 del; 16 mod; Hi all, could you please review this tiny fix for SHA tests? the fix adjusts definitions of supported/unsupported CPUs in sha tests. JBS: https://bugs.openjdk.java.net/browse/JDK-8155192 webrev: http://cr.openjdk.java.net/~iignatyev//8155192/webrev.00/index.htm testing: test/hotspot/jtreg/compiler/intrinsics tests Thanks, -- Igor From aph at redhat.com Thu Jun 21 07:40:48 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 21 Jun 2018 08:40:48 +0100 Subject: RFR: 8189105: AARCH64: create intrinsic for sin and cos In-Reply-To: References: <4de41b0c-e318-c70f-a864-4f6c8bd14297@redhat.com> <5B12CAEF.8050105@bell-sw.com> <2bd89c11-d234-ceae-3b04-4c547ef5836c@redhat.com> <752dd93c-7a95-c674-08df-3e054f178196@redhat.com> <9a8968ee-4432-19a2-f4f2-08a1fb4b4034@redhat.com> Message-ID: <3cde2f37-6f79-21fe-7064-1f5258967364@redhat.com> On 06/20/2018 07:40 PM, Dmitrij Pochepko wrote: > Though your calculation of Taylor series coefficient is imprecise, That's what I meant when I said "approximately". How much space have you got? :-) > you are right in your assessment this is not Taylor series. It's a > polynomial coefficients derived by using Remez approximation > algorithm, Indeed. > which typically use Taylor series coefficients as initial > approximation. > I updated webrev by removing Taylor mentioning: > http://cr.openjdk.java.net/~dpochepk/8189105/webrev.05/ Please go back and remove the rest of them. With that we're good to go. Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Thu Jun 21 12:27:23 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 21 Jun 2018 15:27:23 +0300 Subject: RFR: 8189105: AARCH64: create intrinsic for sin and cos In-Reply-To: <3cde2f37-6f79-21fe-7064-1f5258967364@redhat.com> References: <4de41b0c-e318-c70f-a864-4f6c8bd14297@redhat.com> <5B12CAEF.8050105@bell-sw.com> <2bd89c11-d234-ceae-3b04-4c547ef5836c@redhat.com> <752dd93c-7a95-c674-08df-3e054f178196@redhat.com> <9a8968ee-4432-19a2-f4f2-08a1fb4b4034@redhat.com> <3cde2f37-6f79-21fe-7064-1f5258967364@redhat.com> Message-ID: <1d73f942-af67-8a64-85b0-9b9056801f86@bell-sw.com> On 21.06.2018 10:40, Andrew Haley wrote: > On 06/20/2018 07:40 PM, Dmitrij Pochepko wrote: >> Though your calculation of Taylor series coefficient is imprecise, > That's what I meant when I said "approximately". How much space have > you got? :-) > >> you are right in your assessment this is not Taylor series. It's a >> polynomial coefficients derived by using Remez approximation >> algorithm, > Indeed. > >> which typically use Taylor series coefficients as initial >> approximation. >> I updated webrev by removing Taylor mentioning: >> http://cr.openjdk.java.net/~dpochepk/8189105/webrev.05/ > Please go back and remove the rest of them. With that we're good to > go. Thanks. > Yes. Forgot to update one more source. Clean version: http://cr.openjdk.java.net/~dpochepk/8189105/webrev.06/ Thanks, Dmitrij From erik.osterlund at oracle.com Thu Jun 21 13:26:16 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 21 Jun 2018 15:26:16 +0200 Subject: RFR (S): 8198909: [Graal] compiler/codecache/stress/UnexpectedDeoptimizationTest.java crashed with SIGSEGV In-Reply-To: <7809c59d-5f2f-30aa-44e6-7cf4db03df05@oracle.com> References: <64c722cd-14e3-e0db-6a16-08ca69605205@oracle.com> <5B1E3C35.3090506@oracle.com> <7809c59d-5f2f-30aa-44e6-7cf4db03df05@oracle.com> Message-ID: <5B2BA778.70508@oracle.com> Hi, In src/hotspot/share/jvmci/jvmciCompilerToVM.cpp Please remove #include "gc/g1/g1BarrierSet.hpp" In src/hotspot/share/jvmci/jvmciCompilerToVM.hpp: I would prefer if KlassRefHandle was called JVMCIKlassHandle, because it is very specific to JVMCI. On that note it is unfortunate that we can not simply reuse ciInstanceKlass, which is the klass handle used by the other compilers. Klass* _value; should be called _klass Handle _phantom; should be called _holder Klass* obj() should be called klass() Otherwise, this looks good, and I don't need another webrev for this. Thanks, /Erik On 2018-06-19 23:34, Tom Rodriguez wrote: > I've generated a webrev with a new KlassRefHandle protecting > questionable uses in JVMCI. > http://cr.openjdk.java.net/~never/8198909.1/webrev > > One outstanding question is whether ObjArrayKlass also needs a working > holder_phantom method. It would seem so to me but maybe there's some > reason not? > > tom > > Tom Rodriguez wrote on 6/11/18 10:04 AM: >> >> >> Erik ?sterlund wrote on 6/11/18 2:09 AM: >>> Hi Tom, >>> >>> Could you please call InstanceKlass::holder_phantom() instead to >>> keep the class alive? That is the more general mechanism that is >>> also used by ciInstanceKlass. We don't want to use explicit G1 >>> enqueue calls anymore. >> >> Ok. I guess the same fix in JDK8 will have the use the explicit >> enqueue though or is it not required in JDK8? >> >>> Also, you must not perform any thread transition between loading the >>> weak klass from the MDO until you call holder_phantom, otherwise it >>> might have been unloaded before you get to call holder_phantom(). Is >>> this guaranteed somehow in this scenario? I looked through all >>> callsites and could not find where the Klass pointer is read in the >>> MDO and subsequently passed into the CompilerToVM::get_jvmci_type >>> API, and therefore I do not know if this is guaranteed. >> >> The obviously problematic path is at >> http://hg.openjdk.java.net/jdk/jdk/file/50469fb301c4/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp#l334 >> when either base_address is a Klass* or base_object is NULL which is >> where we are reading from non-heap memory. There are other paths >> which are reading Klasses through more standard APIs from the >> ConstantPool for instance. >> >> There isn't an easy way to ensure no safepoint occurs in between so >> maybe we require the caller of get_jvmci_type to pass in the >> phantom_holder() as a way of forcing the caller to call >> holder_phantom() at the appropriate places? Or is it the case that >> getResolvedType is the only place where special effort is required? >> All the other paths are fairly normal HotSpot code but though place >> that uses klass->implementor() for instance seems like it could be >> considered to be weak by G1. >> >> http://hg.openjdk.java.net/jdk/jdk/file/50469fb301c4/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp#l368 >> >> >> The lack of a properly working KlassHandle seems like an oversight in >> the API to me. >> >> tom >> >>> >>> Thanks, >>> /Erik >>> >>> On 2018-06-08 22:46, Tom Rodriguez wrote: >>>> The JVMCI API may read Klass* and java.lang.Class instances from >>>> locations which G1 would consider to be weakly referenced. This >>>> can result in HotSpotResolvedObjectTypeImpl instances with >>>> references to Classes that have been unloaded. In the this crash, >>>> JVMCI was reading a Klass* from the profile in an MDO and building >>>> a wrapper around it. The MDO reference is weak and was the only >>>> remaining reference to the type so it could be dropped resulting in >>>> an eventual crash. >>>> >>>> I've added an explicit G1 enqueue before we call out to create the >>>> wrapper object but is there a more recommended way of doing this? >>>> Dean had pointed out the oddly named InstanceKlass::holder_phantom >>>> which is used by the CI. Should I be using that? The G1 barrier is >>>> only really need when reading from non-Java heap memory but since >>>> the get_jvmci_type method is the main entry point for this logic it >>>> safest to always perform it in this path. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8198909 >>>> http://cr.openjdk.java.net/~never/8198909/webrev >>> From dmitrij.pochepko at bell-sw.com Thu Jun 21 13:42:16 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 21 Jun 2018 16:42:16 +0300 Subject: RFR(S): 8205474 - AARCH64: wrong zr encoding for ccmp instruction Message-ID: <4a67bf49-dd03-d90f-f1ab-fd5c0423c62e@bell-sw.com> Hi, please review small patch for 8205474 - AARCH64: wrong zr encoding for ccmp instruction ccmp instruction hits assert while trying to compare with zero register. Root reason is that zero register needs special handling: zr has internal number 32 in hotspot, while AARCH64 spec require number 31. This patch fix it. webrev: http://cr.openjdk.java.net/~dpochepk/8205474/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8205474 Testing: I created intrinsic which use ccmp with zr and sanity passed. Thanks, Dmitrij From aph at redhat.com Thu Jun 21 13:56:00 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 21 Jun 2018 14:56:00 +0100 Subject: [aarch64-port-dev ] RFR(S): 8205474 - AARCH64: wrong zr encoding for ccmp instruction In-Reply-To: <4a67bf49-dd03-d90f-f1ab-fd5c0423c62e@bell-sw.com> References: <4a67bf49-dd03-d90f-f1ab-fd5c0423c62e@bell-sw.com> Message-ID: On 06/21/2018 02:42 PM, Dmitrij Pochepko wrote: > please review small patch for 8205474 - AARCH64: wrong zr encoding for > ccmp instruction > > ccmp instruction hits assert while trying to compare with zero register. > Root reason is that zero register needs special handling: zr has > internal number 32 in hotspot, while AARCH64 spec require number 31. Oh Lord, I wrote that horrible code. I'm sorry. It was a long time ago. :-) > This patch fix it. > > webrev: http://cr.openjdk.java.net/~dpochepk/8205474/webrev.01/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8205474 OK, thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Thu Jun 21 13:57:39 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 21 Jun 2018 16:57:39 +0300 Subject: [aarch64-port-dev ] RFR(S): 8205474 - AARCH64: wrong zr encoding for ccmp instruction In-Reply-To: References: <4a67bf49-dd03-d90f-f1ab-fd5c0423c62e@bell-sw.com> Message-ID: Thank you for review! On 21.06.2018 16:56, Andrew Haley wrote: > On 06/21/2018 02:42 PM, Dmitrij Pochepko wrote: >> please review small patch for 8205474 - AARCH64: wrong zr encoding for >> ccmp instruction >> >> ccmp instruction hits assert while trying to compare with zero register. >> Root reason is that zero register needs special handling: zr has >> internal number 32 in hotspot, while AARCH64 spec require number 31. > Oh Lord, I wrote that horrible code. I'm sorry. It was a long time ago. > :-) > >> This patch fix it. >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8205474/webrev.01/ >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8205474 > OK, thanks. > From adinn at redhat.com Thu Jun 21 14:43:35 2018 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 21 Jun 2018 15:43:35 +0100 Subject: RFR: 8189105: AARCH64: create intrinsic for sin and cos In-Reply-To: References: <4de41b0c-e318-c70f-a864-4f6c8bd14297@redhat.com> <5B12CAEF.8050105@bell-sw.com> <2bd89c11-d234-ceae-3b04-4c547ef5836c@redhat.com> Message-ID: <301baf35-0835-e4eb-c323-bb59ba964ef5@redhat.com> Hi Dimitrij, Finally catching up on this ... On 18/06/18 19:53, Dmitrij Pochepko wrote: > here is an updated webrev which addresses your suggestions: Thanks very much for this great improvement. Andrew seems to have noted all outstanding changes to code and comments. So, with all his points are addressed you can count this as a 2nd review. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From nils.eliasson at oracle.com Thu Jun 21 14:54:36 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 21 Jun 2018 16:54:36 +0200 Subject: RFR(S): 8205107: assert(c->Opcode() == Op_SafePoint) failed: broken outer loop In-Reply-To: <0c2b7c85-71ec-3bd5-ac31-6715f32a5c90@oracle.com> References: <06ce5035-4eb9-d56f-0a46-7188c3e74b6c@oracle.com> <26c32258-1e42-01cd-fb64-0ff4cd4ff0b8@oracle.com> <185a0fd0-6876-a6e4-d647-9bde5a7f89cf@oracle.com> <5521318c-ed90-9d04-5cc2-2dbd964dcf63@oracle.com> <1e09c221-7c6e-093c-6dc8-53759eb162ea@oracle.com> <0c2b7c85-71ec-3bd5-ac31-6715f32a5c90@oracle.com> Message-ID: On 2018-06-20 21:33, Vladimir Kozlov wrote: > On 6/20/18 12:22 PM, Nils Eliasson wrote: >> >> >> On 2018-06-20 18:32, Vladimir Kozlov wrote: >>> On 6/20/18 2:01 AM, Nils Eliasson wrote: >>>> I simplified it to: >>>> >>>> ?? virtual bool guaranteed_safepoint() { >>>> ?????? // Calls to boxing methods will be expanded, and safepoints >>>> aren't guaranteed >>>> ?????? return !is_boxing_method(); >>>> ?? } >>>> >>>> is_boxing_method() checks is_macro() that checks the Flag_is_macro >>>> which is only set when C->eliminate_boxing() is true. >>> >>> Okay. >>> >>>> >>>> "(proj_out_or_null(TypeFunc::Parms) == NULL));" seems redundant too >>>> me. What would that guard against? >>> >>> It checks that result of the call is not used (Box object is >>> eliminated by EA). It is needed otherwise you will get bad graph. >> >> We don't need that check since we prevent an optimization for >> happening. The graph is kept as it is. > > So the result is only used by Safepoint? Then how it is eliminated later? It has other uses also. I'm not sure why the call is left, I will investigate it further and can file a seperate bug if it is something wrong. For this bug the problem is that we have a strip mined loop which must have a safepoint. That safepoint can only be removed together with the OuterStripMinedLoop. I change my mind and think my webrev.02 is the best fix - make SafePoint::Identity to never substitute a strip-mine-loop safepoint. http://cr.openjdk.java.net/~neliasso/8205107/webrev.02 // Nils > > Hmm, may be check _is_scalar_replaceable instead. > > Vladimir > >> >> This is the graph: >> >> Integer.valueOf >> ???? | >> CatchProj >> ???? | >> SafePoint >> ???? | >> OuterCountedLoopEnd >> >> The original problem is that the SafePoint was removed because the >> Integer.valueOf reported that it guarantees a safepoint. With the >> change - guaranteed_safepoint() returns false for boxes - no >> safepoint removal is done, the graph is kept intact. >> >> Regards, >> >> Nils >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> New webrev here: >>>> http://cr.openjdk.java.net/~neliasso/8205107/webrev.03/ >>>> >>>> Thanks for the help! >>>> >>>> Nils >>>> >>>> >>>> >>>> On 2018-06-19 19:18, Vladimir Kozlov wrote: >>>>> On 6/19/18 9:01 AM, Vladimir Kozlov wrote: >>>>>> On 6/19/18 7:22 AM, Nils Eliasson wrote: >>>>>>> I looked at it in a bit more detail. >>>>>>> >>>>>>> The call is a java/lang/Integer::valueOf that is considered a >>>>>>> macro node so it is kept around until macro expansion which >>>>>>> happens after the place where we hit the assert. So the call >>>>>>> will go away. >>>>>> >>>>>> I assume you are talking about eliminate_boxing_node() in macro >>>>>> expansion. >>>>>> >>>>>>> >>>>>>> However SafepointNode::Identity does check: >>>>>>> >>>>>>> if( n0->is_Call() && n0->as_Call()->guaranteed_safepoint() ) { >>>>>>> ?????? // Useless Safepoint, so remove it >>>>>>> >>>>>>> And CallNode::guaranteed_safepoint() is: >>>>>>> >>>>>>> ?? // Are we guaranteed that this node is a safepoint? Not true >>>>>>> for leaf calls and >>>>>>> ?? // for some macro nodes whose expansion does not have a >>>>>>> safepoint on the fast path. >>>>>>> ?? virtual bool??????? guaranteed_safepoint()? { return true; } >>>>>>> >>>>>>> No check for call/macro-nodes is implemeted despite the comment! >>>>>>> If I fix this the problem goes away. >>>>>> >>>>>> It returns false for Allocate nodes which are macro nodes. That >>>>>> is what comment says. >>>>>> >>>>>> In case of boxing node I think we should add to >>>>>> CallStaticJavaNode class >>>>>> >>>>>> ?? // Boxing call which is not used and will be removed. >>>>>> ?? virtual bool??????? guaranteed_safepoint()? { return >>>>>> C->eliminate_boxing() && is_boxing_method() && >>>>>> (proj_out_or_null(TypeFunc::Parms) == NULL); } >>>>> >>>>> Sorry, test should be reversed because it guarantee SP if call is >>>>> *not* removed: >>>>> >>>>> virtual bool??????? guaranteed_safepoint()? { return >>>>> !(C->eliminate_boxing() && is_boxing_method() && >>>>> (proj_out_or_null(TypeFunc::Parms) == NULL)); } >>>>> >>>>> Vladimir >>>>> >>>>>> >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> // Nils >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2018-06-18 15:41, Roland Westrelin wrote: >>>>>>>>> Roland, why we need to keep Safepoint in Outer loop if we have >>>>>>>>> call? >>>>>>>> I double checked with a simple test case and we don't keep the >>>>>>>> safepoint >>>>>>>> if there's a call so it's indeed strange that we would need >>>>>>>> Nils' patch. >>>>>>>> >>>>>>>> Roland. >>>>>>> >>>> >> From dmitrij.pochepko at bell-sw.com Thu Jun 21 15:26:42 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 21 Jun 2018 18:26:42 +0300 Subject: RFR: 8189105: AARCH64: create intrinsic for sin and cos In-Reply-To: <301baf35-0835-e4eb-c323-bb59ba964ef5@redhat.com> References: <4de41b0c-e318-c70f-a864-4f6c8bd14297@redhat.com> <5B12CAEF.8050105@bell-sw.com> <2bd89c11-d234-ceae-3b04-4c547ef5836c@redhat.com> <301baf35-0835-e4eb-c323-bb59ba964ef5@redhat.com> Message-ID: <3efe62e6-19eb-35ab-022e-44c49018fd09@bell-sw.com> Thank for review! On 21.06.2018 17:43, Andrew Dinn wrote: > Hi Dimitrij, > > Finally catching up on this ... > > On 18/06/18 19:53, Dmitrij Pochepko wrote: >> here is an updated webrev which addresses your suggestions: > Thanks very much for this great improvement. Andrew seems to have noted > all outstanding changes to code and comments. So, with all his points > are addressed you can count this as a 2nd review. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From patric.hedlin at oracle.com Thu Jun 21 15:26:08 2018 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Thu, 21 Jun 2018 17:26:08 +0200 Subject: RFR(S): JDK-8191339: [JVMCI] BigInteger compiler intrinsics on Graal. Message-ID: <28011331-bd43-2c32-dba4-e41879ffe28a@oracle.com> Dear all, I would like to ask for help to review the following change/update: Issue: https://bugs.openjdk.java.net/browse/JDK-8191339 Webrev: http://cr.openjdk.java.net/~phedlin/tr8191339/ 8191339: [JVMCI] BigInteger compiler intrinsics on Graal. Enabling BigInteger intrinsics via JVMCI. Best regards, Patric From aph at redhat.com Thu Jun 21 16:30:06 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 21 Jun 2018 17:30:06 +0100 Subject: RFR: 8204289: AARCH64: enable math intrinsics usage in interpreter and C1 In-Reply-To: <6e1457db-9b5c-3bbd-65fc-ebd2a9e99558@bell-sw.com> References: <6bd4bccb-befb-0523-d75e-2c5a99c4ee34@bell-sw.com> <6e1457db-9b5c-3bbd-65fc-ebd2a9e99558@bell-sw.com> Message-ID: On 06/20/2018 03:45 PM, Dmitrij Pochepko wrote: > webrev: http://cr.openjdk.java.net/~dpochepk/8204289/webrev.01/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8204289 Looks OK, but... What is the conditional code in 270 case Interpreter::java_lang_math_log : 271 if (StubRoutines::dlog() == NULL) { 272 fn = CAST_FROM_FN_PTR(address, SharedRuntime::dlog); 273 } else { 274 fn = CAST_FROM_FN_PTR(address, StubRoutines::dlog()); 275 } for? When would StubRoutines::dlog() be NULL? We don't pay any attention to vmIntrinsics::is_intrinsic_available(), so AFAICS it's always there. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Thu Jun 21 16:32:45 2018 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 21 Jun 2018 17:32:45 +0100 Subject: RFC: Experiment in accessing/managing persistent memory from Java In-Reply-To: References: <02FCFB8477C4EF43A2AD8E0C60F3DA2B9EE74C14@FMSMSX126.amr.corp.intel.com> Message-ID: <7bc18707-946b-e4a7-3bfe-0deefa12db57@redhat.com> Hi Paul, Sorry for the delay in responding to this -- holiday and then an urgent bug fix intervened . . . On 08/06/18 01:42, Paul Sandoz wrote: > Sandhya gave an overview to a few of us Oracle folks. I agree with > what Sandhya says regarding the API, a small surface, and on pursuing > an unsafe intrinsic. I like it and would encourage the writing of a > draft JEP, especially to give this visibility. Great! Thanks for your feedback (also to Sandhya). I'll start drafting a JEP staright away. I'll also work on revising the current intrinsic implementation so it is presented via Unsafe (which should be fairly simple to achieve). > It intersects with https://bugs.openjdk.java.net/browse/JDK-8153111 > ((bf) Allocating ByteBuffer on heterogeneous memory), which is > attempting to be more generic. Ok, thanks. I'll have a think about how we night try to integrate these two approaches and see what I can work into the draft JEP. > We might also need to increase the velocity on > https://bugs.openjdk.java.net/browse/JDK-8180628 (retrofit direct > buffer support for size beyond gigabyte scales), and i would be very > interested your views on this, how you might be currently working > around such size limitations, and what buffer enhancements would work > for you. I think Jonathan answered that better than I can in his response. However, if this accelerates delivery of a fix for JDK-8180628 then all to the good. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From vladimir.kozlov at oracle.com Thu Jun 21 17:26:44 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 21 Jun 2018 10:26:44 -0700 Subject: RFR(S): 8205107: assert(c->Opcode() == Op_SafePoint) failed: broken outer loop In-Reply-To: References: <06ce5035-4eb9-d56f-0a46-7188c3e74b6c@oracle.com> <26c32258-1e42-01cd-fb64-0ff4cd4ff0b8@oracle.com> <185a0fd0-6876-a6e4-d647-9bde5a7f89cf@oracle.com> <5521318c-ed90-9d04-5cc2-2dbd964dcf63@oracle.com> <1e09c221-7c6e-093c-6dc8-53759eb162ea@oracle.com> <0c2b7c85-71ec-3bd5-ac31-6715f32a5c90@oracle.com> Message-ID: <3b5fd81c-b69e-888e-dcd6-f969ecaa5601@oracle.com> On 6/21/18 7:54 AM, Nils Eliasson wrote: > > > On 2018-06-20 21:33, Vladimir Kozlov wrote: >> On 6/20/18 12:22 PM, Nils Eliasson wrote: >>> >>> >>> On 2018-06-20 18:32, Vladimir Kozlov wrote: >>>> On 6/20/18 2:01 AM, Nils Eliasson wrote: >>>>> I simplified it to: >>>>> >>>>> ?? virtual bool guaranteed_safepoint() { >>>>> ?????? // Calls to boxing methods will be expanded, and safepoints >>>>> aren't guaranteed >>>>> ?????? return !is_boxing_method(); >>>>> ?? } >>>>> >>>>> is_boxing_method() checks is_macro() that checks the Flag_is_macro >>>>> which is only set when C->eliminate_boxing() is true. >>>> >>>> Okay. >>>> >>>>> >>>>> "(proj_out_or_null(TypeFunc::Parms) == NULL));" seems redundant too >>>>> me. What would that guard against? >>>> >>>> It checks that result of the call is not used (Box object is >>>> eliminated by EA). It is needed otherwise you will get bad graph. >>> >>> We don't need that check since we prevent an optimization for >>> happening. The graph is kept as it is. >> >> So the result is only used by Safepoint? Then how it is eliminated later? > > It has other uses also. I'm not sure why the call is left, I will > investigate it further and can file a seperate bug if it is something > wrong. It is not wrong to have a Call node and Safepoint in a loop. It is just not optimal - that is all. I remember that it could be cases when even if boxing call is marked as not escaping (or scalar replaceable) it may not be eliminated because of it has still have some uses left which were not removed for different reasons. I agree that it is not easy problem. > > For this bug the problem is that we have a strip mined loop which must > have a safepoint. That safepoint can only be removed together with the > OuterStripMinedLoop. > > I change my mind and think my webrev.02 is the best fix - make > SafePoint::Identity to never substitute a strip-mine-loop safepoint. > > http://cr.openjdk.java.net/~neliasso/8205107/webrev.02 Okay, but please extend your comment to explain when we can have a Boxing Call node which may be late removed in Macro extension phase leaving loop without safepoint. Thanks, Vladimir > > // Nils >> >> Hmm, may be check _is_scalar_replaceable instead. >> >> Vladimir >> >>> >>> This is the graph: >>> >>> Integer.valueOf >>> ???? | >>> CatchProj >>> ???? | >>> SafePoint >>> ???? | >>> OuterCountedLoopEnd >>> >>> The original problem is that the SafePoint was removed because the >>> Integer.valueOf reported that it guarantees a safepoint. With the >>> change - guaranteed_safepoint() returns false for boxes - no >>> safepoint removal is done, the graph is kept intact. >>> >>> Regards, >>> >>> Nils >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> New webrev here: >>>>> http://cr.openjdk.java.net/~neliasso/8205107/webrev.03/ >>>>> >>>>> Thanks for the help! >>>>> >>>>> Nils >>>>> >>>>> >>>>> >>>>> On 2018-06-19 19:18, Vladimir Kozlov wrote: >>>>>> On 6/19/18 9:01 AM, Vladimir Kozlov wrote: >>>>>>> On 6/19/18 7:22 AM, Nils Eliasson wrote: >>>>>>>> I looked at it in a bit more detail. >>>>>>>> >>>>>>>> The call is a java/lang/Integer::valueOf that is considered a >>>>>>>> macro node so it is kept around until macro expansion which >>>>>>>> happens after the place where we hit the assert. So the call >>>>>>>> will go away. >>>>>>> >>>>>>> I assume you are talking about eliminate_boxing_node() in macro >>>>>>> expansion. >>>>>>> >>>>>>>> >>>>>>>> However SafepointNode::Identity does check: >>>>>>>> >>>>>>>> if( n0->is_Call() && n0->as_Call()->guaranteed_safepoint() ) { >>>>>>>> ?????? // Useless Safepoint, so remove it >>>>>>>> >>>>>>>> And CallNode::guaranteed_safepoint() is: >>>>>>>> >>>>>>>> ?? // Are we guaranteed that this node is a safepoint? Not true >>>>>>>> for leaf calls and >>>>>>>> ?? // for some macro nodes whose expansion does not have a >>>>>>>> safepoint on the fast path. >>>>>>>> ?? virtual bool??????? guaranteed_safepoint()? { return true; } >>>>>>>> >>>>>>>> No check for call/macro-nodes is implemeted despite the comment! >>>>>>>> If I fix this the problem goes away. >>>>>>> >>>>>>> It returns false for Allocate nodes which are macro nodes. That >>>>>>> is what comment says. >>>>>>> >>>>>>> In case of boxing node I think we should add to >>>>>>> CallStaticJavaNode class >>>>>>> >>>>>>> ?? // Boxing call which is not used and will be removed. >>>>>>> ?? virtual bool??????? guaranteed_safepoint()? { return >>>>>>> C->eliminate_boxing() && is_boxing_method() && >>>>>>> (proj_out_or_null(TypeFunc::Parms) == NULL); } >>>>>> >>>>>> Sorry, test should be reversed because it guarantee SP if call is >>>>>> *not* removed: >>>>>> >>>>>> virtual bool??????? guaranteed_safepoint()? { return >>>>>> !(C->eliminate_boxing() && is_boxing_method() && >>>>>> (proj_out_or_null(TypeFunc::Parms) == NULL)); } >>>>>> >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> // Nils >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2018-06-18 15:41, Roland Westrelin wrote: >>>>>>>>>> Roland, why we need to keep Safepoint in Outer loop if we have >>>>>>>>>> call? >>>>>>>>> I double checked with a simple test case and we don't keep the >>>>>>>>> safepoint >>>>>>>>> if there's a call so it's indeed strange that we would need >>>>>>>>> Nils' patch. >>>>>>>>> >>>>>>>>> Roland. >>>>>>>> >>>>> >>> > From vladimir.kozlov at oracle.com Thu Jun 21 17:47:34 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 21 Jun 2018 10:47:34 -0700 Subject: RFR(XS) : 8155192 : [TESTBUG] SHA tests assumes that x86 does not have SHA intrinsics In-Reply-To: <475373C8-367F-4600-B246-F5E91608B4FD@oracle.com> References: <475373C8-367F-4600-B246-F5E91608B4FD@oracle.com> Message-ID: Changes are fine. But I find it strange that PPC64 (Platform::isPPC) is only listed in one files. According to vm_version_ppc.cpp it supports SHA256 and SHA512. Thanks, Vladimir On 6/20/18 8:28 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8155192/webrev.00/index.html >> 29 lines changed: 10 ins; 3 del; 16 mod; > > Hi all, > > could you please review this tiny fix for SHA tests? the fix adjusts definitions of supported/unsupported CPUs in sha tests. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8155192 > webrev: http://cr.openjdk.java.net/~iignatyev//8155192/webrev.00/index.htm > testing: test/hotspot/jtreg/compiler/intrinsics tests > > Thanks, > -- Igor > From dmitrij.pochepko at bell-sw.com Thu Jun 21 18:06:55 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 21 Jun 2018 21:06:55 +0300 Subject: RFR: 8204289: AARCH64: enable math intrinsics usage in interpreter and C1 In-Reply-To: References: <6bd4bccb-befb-0523-d75e-2c5a99c4ee34@bell-sw.com> <6e1457db-9b5c-3bbd-65fc-ebd2a9e99558@bell-sw.com> Message-ID: <5e2e79cd-8401-f239-d028-0f1ad9a80ff4@bell-sw.com> Thanks for noticing it. I now think it make sense to add vmIntrinsics::is_intrinsic_available check for math intrinsics in this patch. It will make it aligned with other architecture like this: http://cr.openjdk.java.net/~dpochepk/8204289/webrev.02/ What do you think about it? Thanks, Dmitrij On 21.06.2018 19:30, Andrew Haley wrote: > On 06/20/2018 03:45 PM, Dmitrij Pochepko wrote: >> webrev: http://cr.openjdk.java.net/~dpochepk/8204289/webrev.01/ >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8204289 > Looks OK, but... What is the conditional code in > > 270 case Interpreter::java_lang_math_log : > 271 if (StubRoutines::dlog() == NULL) { > 272 fn = CAST_FROM_FN_PTR(address, SharedRuntime::dlog); > 273 } else { > 274 fn = CAST_FROM_FN_PTR(address, StubRoutines::dlog()); > 275 } > > for? When would StubRoutines::dlog() be NULL? We don't pay any attention > to vmIntrinsics::is_intrinsic_available(), so AFAICS it's always there. > From igor.ignatyev at oracle.com Thu Jun 21 18:21:11 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 21 Jun 2018 11:21:11 -0700 Subject: RFR(XS) : 8155192 : [TESTBUG] SHA tests assumes that x86 does not have SHA intrinsics In-Reply-To: References: <475373C8-367F-4600-B246-F5E91608B4FD@oracle.com> Message-ID: <37A0FF1E-1580-46CF-8211-69B343A0DD97@oracle.com> it's strange indeed, I'll file a separate issue for PPC. -- Igor > On Jun 21, 2018, at 10:47 AM, Vladimir Kozlov wrote: > > Changes are fine. > > But I find it strange that PPC64 (Platform::isPPC) is only listed in one files. According to vm_version_ppc.cpp it supports SHA256 and SHA512. > > Thanks, > Vladimir > > On 6/20/18 8:28 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8155192/webrev.00/index.html >>> 29 lines changed: 10 ins; 3 del; 16 mod; >> Hi all, >> could you please review this tiny fix for SHA tests? the fix adjusts definitions of supported/unsupported CPUs in sha tests. >> JBS: https://bugs.openjdk.java.net/browse/JDK-8155192 >> webrev: http://cr.openjdk.java.net/~iignatyev//8155192/webrev.00/index.htm >> testing: test/hotspot/jtreg/compiler/intrinsics tests >> Thanks, >> -- Igor From igor.ignatyev at oracle.com Thu Jun 21 18:51:48 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 21 Jun 2018 11:51:48 -0700 Subject: RFR(XXS) : 8205490 : update ProblemList-graal Message-ID: http://cr.openjdk.java.net/~iignatyev//8205490/webrev.00/index.html > 14 lines changed: 11 ins; 0 del; 3 mod; Hi all, compiler/intrinsics/mathexact/sanity tests are known to fail when run w/ Graal as JIT, this patch adds them into graal specific problem list file. webrev: http://cr.openjdk.java.net/~iignatyev//8205490/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8205490 Thanks, -- Igor From ekaterina.pavlova at oracle.com Thu Jun 21 19:02:25 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Thu, 21 Jun 2018 12:02:25 -0700 Subject: RFR(XXS) : 8205490 : update ProblemList-graal In-Reply-To: References: Message-ID: Good, thanks for adding the tests into the list. -katya On 6/21/18 11:51 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8205490/webrev.00/index.html >> 14 lines changed: 11 ins; 0 del; 3 mod; > > Hi all, > > compiler/intrinsics/mathexact/sanity tests are known to fail when run w/ Graal as JIT, this patch adds them into graal specific problem list file. > > webrev: http://cr.openjdk.java.net/~iignatyev//8205490/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8205490 > > Thanks, > -- Igor > From igor.ignatyev at oracle.com Thu Jun 21 19:22:18 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 21 Jun 2018 12:22:18 -0700 Subject: RFR(XXS) : 8205490 : update ProblemList-graal In-Reply-To: References: Message-ID: Hi Katya, thanks for reviewing. I've updated the patch to problem list compiler/whitebox/DeoptimizeAllTest.java as well: http://cr.openjdk.java.net/~iignatyev//8205490/webrev.01/index.html > diff -r 4cd041e5263a test/hotspot/jtreg/ProblemList-graal.txt > --- a/test/hotspot/jtreg/ProblemList-graal.txt Thu Jun 21 11:56:57 2018 -0700 > +++ b/test/hotspot/jtreg/ProblemList-graal.txt Thu Jun 21 12:18:50 2018 -0700 > @@ -93,6 +93,7 @@ > compiler/intrinsics/mathexact/sanity/SubtractExactIntTest.java 8202124 generic-all > compiler/intrinsics/mathexact/sanity/MultiplyExactLongTest.java 8202124 generic-all > compiler/intrinsics/mathexact/sanity/MultiplyExactIntTest.java 8202124 generic-all > +compiler/whitebox/DeoptimizeAllTest.java 8202124 generic-all > > compiler/jvmci/meta/StableFieldTest.java CODETOOLS-7902162 generic-all > compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/HotSpotConstantReflectionProviderTest.java CODETOOLS-7902162 generic-all Thanks, -- Igor > On Jun 21, 2018, at 12:02 PM, Ekaterina Pavlova wrote: > > Good, thanks for adding the tests into the list. > > -katya > > On 6/21/18 11:51 AM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8205490/webrev.00/index.html >>> 14 lines changed: 11 ins; 0 del; 3 mod; >> Hi all, >> compiler/intrinsics/mathexact/sanity tests are known to fail when run w/ Graal as JIT, this patch adds them into graal specific problem list file. >> webrev: http://cr.openjdk.java.net/~iignatyev//8205490/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8205490 >> Thanks, >> -- Igor > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Thu Jun 21 19:36:57 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 21 Jun 2018 12:36:57 -0700 Subject: RFR(S) : 8185927 : create regression test for 8062950 Message-ID: http://cr.openjdk.java.net/~iignatyev//8185927/webrev.00/index.html > 48 lines changed: 48 ins; 0 del; 0 mod; Hi all, could you please review this small patch which adds a regression test for 8062950? webrev: http://cr.openjdk.java.net/~iignatyev//8185927/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8185927 Thanks, -- Igor From vladimir.kozlov at oracle.com Thu Jun 21 19:49:14 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 21 Jun 2018 12:49:14 -0700 Subject: RFR(XXS) : 8205490 : update ProblemList-graal In-Reply-To: References: Message-ID: I would suggest to add all tests to Graal's problem list which use -XX:CompileCommand=compileonly,compiler.whitebox.SimpleTestCaseHelper::* We can't run test which use CompileOnly and expect that Graal will compile specified methods in time. We can add Graal's and JVMCI's methods to CompileOnly list. Or we should make general exception for Graal's and JVMCI's methods. I found next tests are missing in list: compiler/tiered/LevelTransitionTest.java compiler/whitebox/DeoptimizeAllTest.java compiler/whitebox/DeoptimizeMethodTest.java compiler/whitebox/ForceNMethodSweepTest.java: compiler/whitebox/GetNMethodTest.java compiler/whitebox/IsMethodCompilableTest.java compiler/whitebox/LockCompilationTest.java compiler/whitebox/SetDontInlineMethodTest.java compiler/whitebox/SetForceInlineMethodTest.java May be there are more other tests. Thanks, Vladimir On 6/21/18 11:51 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8205490/webrev.00/index.html >> 14 lines changed: 11 ins; 0 del; 3 mod; > > Hi all, > > compiler/intrinsics/mathexact/sanity tests are known to fail when run w/ Graal as JIT, this patch adds them into graal specific problem list file. > > webrev: http://cr.openjdk.java.net/~iignatyev//8205490/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8205490 > > Thanks, > -- Igor > From vladimir.kozlov at oracle.com Thu Jun 21 19:57:19 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 21 Jun 2018 12:57:19 -0700 Subject: RFR(S) : 8185927 : create regression test for 8062950 In-Reply-To: References: Message-ID: Good. Thanks, Vladimir On 6/21/18 12:36 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8185927/webrev.00/index.html >> 48 lines changed: 48 ins; 0 del; 0 mod; > > Hi all, > > could you please review this small patch which adds a regression test for 8062950? > > webrev: http://cr.openjdk.java.net/~iignatyev//8185927/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8185927 > > Thanks, > -- Igor > From gromero at linux.vnet.ibm.com Thu Jun 21 20:34:37 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 21 Jun 2018 17:34:37 -0300 Subject: RFR(XS) : 8155192 : [TESTBUG] SHA tests assumes that x86 does not have SHA intrinsics In-Reply-To: References: <475373C8-367F-4600-B246-F5E91608B4FD@oracle.com> Message-ID: <1e02be46-38a2-5980-8882-490484c41060@linux.vnet.ibm.com> Hi Vladimir, Igor On 06/21/2018 02:47 PM, Vladimir Kozlov wrote: > But I find it strange that PPC64 (Platform::isPPC) is only listed in one files. According to vm_version_ppc.cpp it supports SHA256 and SHA512. Yes, that's correct. Igor, do you mind to confirm which tests exactly must be enabled on PPC64 (or disabled if the list is smaller...)? For instance, it's not clear to me yet why the suggested fix in [1] is adding PPC to UseSHAIntrinsicsSpecificTestCaseForUnsupportedCPU.java. Current status on PPC64 is: Passed: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java Passed: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnSupportedCPU.java Passed: compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java Passed: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnSupportedCPU.java Passed: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnUnsupportedCPU.java Passed: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnSupportedCPU.java Passed: compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java Passed: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java Passed: compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java Passed: compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java Passed: compiler/intrinsics/sha/sanity/TestSHA512Intrinsics.java Passed: compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java Passed: compiler/intrinsics/sha/sanity/TestSHA512MultiBlockIntrinsics.java Passed: compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java Passed: compiler/intrinsics/sha/TestSHA.java Test results: passed: 15 Thanks. Best regards, Gustavo [1] https://bugs.openjdk.java.net/browse/JDK-8205492 > Thanks, > Vladimir > > On 6/20/18 8:28 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8155192/webrev.00/index.html >>> 29 lines changed: 10 ins; 3 del; 16 mod; >> >> Hi all, >> >> could you please review this tiny fix for SHA tests? the fix adjusts definitions of supported/unsupported CPUs in sha tests. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8155192 >> webrev: http://cr.openjdk.java.net/~iignatyev//8155192/webrev.00/index.htm >> testing: test/hotspot/jtreg/compiler/intrinsics tests >> >> Thanks, >> -- Igor >> > From tom.rodriguez at oracle.com Thu Jun 21 20:46:53 2018 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 21 Jun 2018 13:46:53 -0700 Subject: RFR (S): 8198909: [Graal] compiler/codecache/stress/UnexpectedDeoptimizationTest.java crashed with SIGSEGV In-Reply-To: <5B2BA778.70508@oracle.com> References: <64c722cd-14e3-e0db-6a16-08ca69605205@oracle.com> <5B1E3C35.3090506@oracle.com> <7809c59d-5f2f-30aa-44e6-7cf4db03df05@oracle.com> <5B2BA778.70508@oracle.com> Message-ID: Erik ?sterlund wrote on 6/21/18 6:26 AM: > Hi, > > > In src/hotspot/share/jvmci/jvmciCompilerToVM.cpp > > Please remove > #include "gc/g1/g1BarrierSet.hpp" > > In src/hotspot/share/jvmci/jvmciCompilerToVM.hpp: > > I would prefer if KlassRefHandle was called JVMCIKlassHandle, because it > is very specific to JVMCI. On that note it is unfortunate that we can > not simply reuse ciInstanceKlass, which is the klass handle used by the > other compilers. > > Klass* _value; > should be called _klass > > Handle _phantom; > should be called _holder > > Klass* obj() > should be called klass() > > Otherwise, this looks good, and I don't need another webrev for this. I've made all the requested edits. Additionally I never really got an answer to my question about handling of ObjArrayKlass but concluded that it must be handled, so I've moved phantom_holder from InstanceKlass to Klass so it can be used in a uniform way. I guess the CI handles it implicitly under the assumption that klass->class_loader_data() == ObjArrayKlass::cast(klass)->bottom_klass()->class_loader_data() which should presumably be true. The new webrev is http://cr.openjdk.java.net/~never/8198909.2/webrev. I'll consider the movement of phantom_holder to be acceptable unless I hear an objection soon. tom > > Thanks, > /Erik > > On 2018-06-19 23:34, Tom Rodriguez wrote: >> I've generated a webrev with a new KlassRefHandle protecting >> questionable uses in JVMCI. >> http://cr.openjdk.java.net/~never/8198909.1/webrev >> >> One outstanding question is whether ObjArrayKlass also needs a working >> holder_phantom method. It would seem so to me but maybe there's some >> reason not? >> >> tom >> >> Tom Rodriguez wrote on 6/11/18 10:04 AM: >>> >>> >>> Erik ?sterlund wrote on 6/11/18 2:09 AM: >>>> Hi Tom, >>>> >>>> Could you please call InstanceKlass::holder_phantom() instead to >>>> keep the class alive? That is the more general mechanism that is >>>> also used by ciInstanceKlass. We don't want to use explicit G1 >>>> enqueue calls anymore. >>> >>> Ok. I guess the same fix in JDK8 will have the use the explicit >>> enqueue though or is it not required in JDK8? >>> >>>> Also, you must not perform any thread transition between loading the >>>> weak klass from the MDO until you call holder_phantom, otherwise it >>>> might have been unloaded before you get to call holder_phantom(). Is >>>> this guaranteed somehow in this scenario? I looked through all >>>> callsites and could not find where the Klass pointer is read in the >>>> MDO and subsequently passed into the CompilerToVM::get_jvmci_type >>>> API, and therefore I do not know if this is guaranteed. >>> >>> The obviously problematic path is at >>> http://hg.openjdk.java.net/jdk/jdk/file/50469fb301c4/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp#l334 >>> when either base_address is a Klass* or base_object is NULL which is >>> where we are reading from non-heap memory. There are other paths >>> which are reading Klasses through more standard APIs from the >>> ConstantPool for instance. >>> >>> There isn't an easy way to ensure no safepoint occurs in between so >>> maybe we require the caller of get_jvmci_type to pass in the >>> phantom_holder() as a way of forcing the caller to call >>> holder_phantom() at the appropriate places? Or is it the case that >>> getResolvedType is the only place where special effort is required? >>> All the other paths are fairly normal HotSpot code but though place >>> that uses klass->implementor() for instance seems like it could be >>> considered to be weak by G1. >>> >>> http://hg.openjdk.java.net/jdk/jdk/file/50469fb301c4/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp#l368 >>> >>> >>> The lack of a properly working KlassHandle seems like an oversight in >>> the API to me. >>> >>> tom >>> >>>> >>>> Thanks, >>>> /Erik >>>> >>>> On 2018-06-08 22:46, Tom Rodriguez wrote: >>>>> The JVMCI API may read Klass* and java.lang.Class instances from >>>>> locations which G1 would consider to be weakly referenced. This >>>>> can result in HotSpotResolvedObjectTypeImpl instances with >>>>> references to Classes that have been unloaded. In the this crash, >>>>> JVMCI was reading a Klass* from the profile in an MDO and building >>>>> a wrapper around it. The MDO reference is weak and was the only >>>>> remaining reference to the type so it could be dropped resulting in >>>>> an eventual crash. >>>>> >>>>> I've added an explicit G1 enqueue before we call out to create the >>>>> wrapper object but is there a more recommended way of doing this? >>>>> Dean had pointed out the oddly named InstanceKlass::holder_phantom >>>>> which is used by the CI. Should I be using that? The G1 barrier is >>>>> only really need when reading from non-Java heap memory but since >>>>> the get_jvmci_type method is the main entry point for this logic it >>>>> safest to always perform it in this path. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8198909 >>>>> http://cr.openjdk.java.net/~never/8198909/webrev >>>> > From igor.ignatyev at oracle.com Thu Jun 21 21:43:47 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 21 Jun 2018 14:43:47 -0700 Subject: RFR(XS) : 8155192 : [TESTBUG] SHA tests assumes that x86 does not have SHA intrinsics In-Reply-To: <1e02be46-38a2-5980-8882-490484c41060@linux.vnet.ibm.com> References: <475373C8-367F-4600-B246-F5E91608B4FD@oracle.com> <1e02be46-38a2-5980-8882-490484c41060@linux.vnet.ibm.com> Message-ID: <6CCD8F27-2B41-4D56-9FEB-D804657F3107@oracle.com> Hi Gustavo, please see my answers inline. Thanks, -- Igor > On Jun 21, 2018, at 1:34 PM, Gustavo Romero wrote: > > Hi Vladimir, Igor > > On 06/21/2018 02:47 PM, Vladimir Kozlov wrote: >> But I find it strange that PPC64 (Platform::isPPC) is only listed in one files. According to vm_version_ppc.cpp it supports SHA256 and SHA512. > > Yes, that's correct. > > Igor, do you mind to confirm which tests exactly must be enabled on PPC64 (or > disabled if the list is smaller...)? all the tests are already enabled on PPC64, but they don't do much testing, as they will be skipped by the tests themselves. > > For instance, it's not clear to me yet why the suggested fix in [1] is adding PPC to > UseSHAIntrinsicsSpecificTestCaseForUnsupportedCPU.java. UseSHAIntrinsicsSpecificTestCaseForUnsupportedCPU is supposed to be run to hosts which *do* support some sha instructions, but don't support a specific one. I don't know if it's a case for PPC or not. in any case, it might be better to get rid of Platform::* predicates in this class and just use IntrinsicPredicates and SHAOptionsBase.getPredicateForOption, so its c-tor will be: > super(optionName, new AndPredicate( > IntrinsicPredicates.ANY_SHA_INSTRUCTION_AVAILABLE, > new NotPredicate(SHAOptionsBase.getPredicateForOption(optionName)))); > < ...> and UseSHASpecificTestCaseForSupportedCPU's c-tor can be changed to: > super(SHAOptionsBase.USE_SHA_OPTION, IntrinsicPredicates.ANY_SHA_INSTRUCTION_AVAILABLE); > < ...> I'll retest the patch for 8155192 w/ these changes. > > Current status on PPC64 is: > > Passed: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java > Passed: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnSupportedCPU.java > Passed: compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java > Passed: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnSupportedCPU.java > Passed: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnUnsupportedCPU.java > Passed: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnSupportedCPU.java > Passed: compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java > Passed: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java > Passed: compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java > Passed: compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java > Passed: compiler/intrinsics/sha/sanity/TestSHA512Intrinsics.java > Passed: compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java > Passed: compiler/intrinsics/sha/sanity/TestSHA512MultiBlockIntrinsics.java > Passed: compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java > Passed: compiler/intrinsics/sha/TestSHA.java > Test results: passed: 15 as I explained above, all the tests are run on all platforms, but some of their parts are just skipped on PPC64. > > Thanks. > > Best regards, > Gustavo > > [1] https://bugs.openjdk.java.net/browse/JDK-8205492 > >> Thanks, >> Vladimir >> On 6/20/18 8:28 PM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8155192/webrev.00/index.html >>>> 29 lines changed: 10 ins; 3 del; 16 mod; >>> >>> Hi all, >>> >>> could you please review this tiny fix for SHA tests? the fix adjusts definitions of supported/unsupported CPUs in sha tests. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8155192 >>> webrev: http://cr.openjdk.java.net/~iignatyev//8155192/webrev.00/index.htm >>> testing: test/hotspot/jtreg/compiler/intrinsics tests >>> >>> Thanks, >>> -- Igor >>> > From igor.ignatyev at oracle.com Thu Jun 21 21:57:09 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 21 Jun 2018 14:57:09 -0700 Subject: RFR(XXS) : 8205490 : update ProblemList-graal In-Reply-To: References: Message-ID: <84B7C887-CAC6-4DD6-85FE-9308ACD27699@oracle.com> > On Jun 21, 2018, at 12:49 PM, Vladimir Kozlov wrote: > > I would suggest to add all tests to Graal's problem list which use -XX:CompileCommand=compileonly,compiler.whitebox.SimpleTestCaseHelper::* > > We can't run test which use CompileOnly and expect that Graal will compile specified methods in time. We can add Graal's and JVMCI's methods to CompileOnly list. Or we should make general exception for Graal's and JVMCI's methods. adding these methods to CompileOnly list in each test doesn't sound like a right thing to do, and making general exception for Graal's and JVMCI's methods doesn't either as it will make it impossible/harder to exclude graal/jvmci methods from compilation should it be necessary. adding a special diagnostic-only flag to keep graal/jvmci methods compilable regardless compileOnly might be a good enough compromise. > > > I found next tests are missing in list: > > compiler/tiered/LevelTransitionTest.java > compiler/whitebox/DeoptimizeAllTest.java > compiler/whitebox/DeoptimizeMethodTest.java > compiler/whitebox/ForceNMethodSweepTest.java: > compiler/whitebox/GetNMethodTest.java > compiler/whitebox/IsMethodCompilableTest.java > compiler/whitebox/LockCompilationTest.java > compiler/whitebox/SetDontInlineMethodTest.java > compiler/whitebox/SetForceInlineMethodTest.java AFAIK, we haven't seen these tests (except DeoptimizeAllTest.java which I have already added to 2nd version of webrev) failing w/ Graal as JIT, but yes they seem to be affected by this problem as well, will add them to the problem list. > > May be there are more other tests. > > Thanks, > Vladimir > > On 6/21/18 11:51 AM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8205490/webrev.00/index.html >>> 14 lines changed: 11 ins; 0 del; 3 mod; >> Hi all, >> compiler/intrinsics/mathexact/sanity tests are known to fail when run w/ Graal as JIT, this patch adds them into graal specific problem list file. >> webrev: http://cr.openjdk.java.net/~iignatyev//8205490/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8205490 >> Thanks, >> -- Igor From erik.osterlund at oracle.com Thu Jun 21 22:03:38 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 22 Jun 2018 00:03:38 +0200 Subject: RFR (S): 8198909: [Graal] compiler/codecache/stress/UnexpectedDeoptimizationTest.java crashed with SIGSEGV In-Reply-To: References: <64c722cd-14e3-e0db-6a16-08ca69605205@oracle.com> <5B1E3C35.3090506@oracle.com> <7809c59d-5f2f-30aa-44e6-7cf4db03df05@oracle.com> <5B2BA778.70508@oracle.com> Message-ID: <881e3c84-5835-e6ba-b1aa-1976c5054112@oracle.com> Hi Tom, I approve of having holder_phantom() on Klass. I tried to introduce it there a long time ago but got some push back at the time. But I think it really ought to be on Klass. Thanks, /Erik On 2018-06-21 22:46, Tom Rodriguez wrote: > > > Erik ?sterlund wrote on 6/21/18 6:26 AM: >> Hi, >> >> >> In src/hotspot/share/jvmci/jvmciCompilerToVM.cpp >> >> Please remove >> #include "gc/g1/g1BarrierSet.hpp" >> >> In src/hotspot/share/jvmci/jvmciCompilerToVM.hpp: >> >> I would prefer if KlassRefHandle was called JVMCIKlassHandle, because >> it is very specific to JVMCI. On that note it is unfortunate that we >> can not simply reuse ciInstanceKlass, which is the klass handle used >> by the other compilers. >> >> Klass*???? _value; >> should be called _klass >> >> Handle???? _phantom; >> should be called _holder >> >> Klass*??????? obj() >> should be called klass() >> >> Otherwise, this looks good, and I don't need another webrev for this. > > I've made all the requested edits.? Additionally I never really got an > answer to my question about handling of ObjArrayKlass but concluded > that it must be handled, so I've moved phantom_holder from > InstanceKlass to Klass so it can be used in a uniform way.? I guess > the CI handles it implicitly under the assumption that > klass->class_loader_data() == > ObjArrayKlass::cast(klass)->bottom_klass()->class_loader_data() which > should presumably be true.? The new webrev is > http://cr.openjdk.java.net/~never/8198909.2/webrev.? I'll consider the > movement of phantom_holder to be acceptable unless I hear an objection > soon. > > tom > >> >> Thanks, >> /Erik >> >> On 2018-06-19 23:34, Tom Rodriguez wrote: >>> I've generated a webrev with a new KlassRefHandle protecting >>> questionable uses in JVMCI. >>> http://cr.openjdk.java.net/~never/8198909.1/webrev >>> >>> One outstanding question is whether ObjArrayKlass also needs a >>> working holder_phantom method.? It would seem so to me but maybe >>> there's some reason not? >>> >>> tom >>> >>> Tom Rodriguez wrote on 6/11/18 10:04 AM: >>>> >>>> >>>> Erik ?sterlund wrote on 6/11/18 2:09 AM: >>>>> Hi Tom, >>>>> >>>>> Could you please call InstanceKlass::holder_phantom() instead to >>>>> keep the class alive? That is the more general mechanism that is >>>>> also used by ciInstanceKlass. We don't want to use explicit G1 >>>>> enqueue calls anymore. >>>> >>>> Ok.? I guess the same fix in JDK8 will have the use the explicit >>>> enqueue though or is it not required in JDK8? >>>> >>>>> Also, you must not perform any thread transition between loading >>>>> the weak klass from the MDO until you call holder_phantom, >>>>> otherwise it might have been unloaded before you get to call >>>>> holder_phantom(). Is this guaranteed somehow in this scenario? I >>>>> looked through all callsites and could not find where the Klass >>>>> pointer is read in the MDO and subsequently passed into the >>>>> CompilerToVM::get_jvmci_type API, and therefore I do not know if >>>>> this is guaranteed. >>>> >>>> The obviously problematic path is at >>>> http://hg.openjdk.java.net/jdk/jdk/file/50469fb301c4/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp#l334 >>>> when either base_address is a Klass* or base_object is NULL which >>>> is where we are reading from non-heap memory.? There are other >>>> paths which are reading Klasses through more standard APIs from the >>>> ConstantPool for instance. >>>> >>>> There isn't an easy way to ensure no safepoint occurs in between so >>>> maybe we require the caller of get_jvmci_type to pass in the >>>> phantom_holder() as a way of forcing the caller to call >>>> holder_phantom() at the appropriate places?? Or is it the case that >>>> getResolvedType is the only place where special effort is required? >>>> All the other paths are fairly normal HotSpot code but though place >>>> that uses klass->implementor() for instance seems like it could be >>>> considered to be weak by G1. >>>> >>>> http://hg.openjdk.java.net/jdk/jdk/file/50469fb301c4/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp#l368 >>>> >>>> >>>> The lack of a properly working KlassHandle seems like an oversight >>>> in the API to me. >>>> >>>> tom >>>> >>>>> >>>>> Thanks, >>>>> /Erik >>>>> >>>>> On 2018-06-08 22:46, Tom Rodriguez wrote: >>>>>> The JVMCI API may read Klass* and java.lang.Class instances from >>>>>> locations which G1 would consider to be weakly referenced.? This >>>>>> can result in HotSpotResolvedObjectTypeImpl instances with >>>>>> references to Classes that have been unloaded.? In the this >>>>>> crash, JVMCI was reading a Klass* from the profile in an MDO and >>>>>> building a wrapper around it. The MDO reference is weak and was >>>>>> the only remaining reference to the type so it could be dropped >>>>>> resulting in an eventual crash. >>>>>> >>>>>> I've added an explicit G1 enqueue before we call out to create >>>>>> the wrapper object but is there a more recommended way of doing >>>>>> this? Dean had pointed out the oddly named >>>>>> InstanceKlass::holder_phantom which is used by the CI. Should I >>>>>> be using that?? The G1 barrier is only really need when reading >>>>>> from non-Java heap memory but since the get_jvmci_type method is >>>>>> the main entry point for this logic it safest to always perform >>>>>> it in this path. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8198909 >>>>>> http://cr.openjdk.java.net/~never/8198909/webrev >>>>> >> From vladimir.kozlov at oracle.com Thu Jun 21 23:29:07 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 21 Jun 2018 16:29:07 -0700 Subject: RFR(XXS) : 8205490 : update ProblemList-graal In-Reply-To: <84B7C887-CAC6-4DD6-85FE-9308ACD27699@oracle.com> References: <84B7C887-CAC6-4DD6-85FE-9308ACD27699@oracle.com> Message-ID: On 6/21/18 2:57 PM, Igor Ignatyev wrote: > > >> On Jun 21, 2018, at 12:49 PM, Vladimir Kozlov wrote: >> >> I would suggest to add all tests to Graal's problem list which use -XX:CompileCommand=compileonly,compiler.whitebox.SimpleTestCaseHelper::* >> >> We can't run test which use CompileOnly and expect that Graal will compile specified methods in time. We can add Graal's and JVMCI's methods to CompileOnly list. Or we should make general exception for Graal's and JVMCI's methods. > adding these methods to CompileOnly list in each test doesn't sound like a right thing to do, and making general exception for Graal's and JVMCI's methods doesn't either as it will make it impossible/harder to exclude graal/jvmci methods from compilation should it be necessary. adding a special diagnostic-only flag to keep graal/jvmci methods compilable regardless compileOnly might be a good enough compromise. Good idea. I agree with diagnostic flag. >> >> >> I found next tests are missing in list: >> >> compiler/tiered/LevelTransitionTest.java >> compiler/whitebox/DeoptimizeAllTest.java >> compiler/whitebox/DeoptimizeMethodTest.java >> compiler/whitebox/ForceNMethodSweepTest.java: >> compiler/whitebox/GetNMethodTest.java >> compiler/whitebox/IsMethodCompilableTest.java >> compiler/whitebox/LockCompilationTest.java >> compiler/whitebox/SetDontInlineMethodTest.java >> compiler/whitebox/SetForceInlineMethodTest.java > > AFAIK, we haven't seen these tests (except DeoptimizeAllTest.java which I have already added to 2nd version of webrev) failing w/ Graal as JIT, but yes they seem to be affected by this problem as well, will add them to the problem list. Thanks, Vladimir >> >> May be there are more other tests. >> >> Thanks, >> Vladimir >> >> On 6/21/18 11:51 AM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8205490/webrev.00/index.html >>>> 14 lines changed: 11 ins; 0 del; 3 mod; >>> Hi all, >>> compiler/intrinsics/mathexact/sanity tests are known to fail when run w/ Graal as JIT, this patch adds them into graal specific problem list file. >>> webrev: http://cr.openjdk.java.net/~iignatyev//8205490/webrev.00/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8205490 >>> Thanks, >>> -- Igor > From igor.ignatyev at oracle.com Thu Jun 21 23:36:16 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 21 Jun 2018 16:36:16 -0700 Subject: RFR(XXS) : 8205490 : update ProblemList-graal In-Reply-To: References: <84B7C887-CAC6-4DD6-85FE-9308ACD27699@oracle.com> Message-ID: here is the latest webrev w/ more tests problem listed -- http://cr.openjdk.java.net/~iignatyev//8205490/webrev.02/index.html -- Igor > On Jun 21, 2018, at 4:29 PM, Vladimir Kozlov wrote: > > On 6/21/18 2:57 PM, Igor Ignatyev wrote: >>> On Jun 21, 2018, at 12:49 PM, Vladimir Kozlov > wrote: >>> >>> I would suggest to add all tests to Graal's problem list which use -XX:CompileCommand=compileonly,compiler.whitebox.SimpleTestCaseHelper::* >>> >>> We can't run test which use CompileOnly and expect that Graal will compile specified methods in time. We can add Graal's and JVMCI's methods to CompileOnly list. Or we should make general exception for Graal's and JVMCI's methods. >> adding these methods to CompileOnly list in each test doesn't sound like a right thing to do, and making general exception for Graal's and JVMCI's methods doesn't either as it will make it impossible/harder to exclude graal/jvmci methods from compilation should it be necessary. adding a special diagnostic-only flag to keep graal/jvmci methods compilable regardless compileOnly might be a good enough compromise. > > Good idea. I agree with diagnostic flag. > >>> >>> >>> I found next tests are missing in list: >>> >>> compiler/tiered/LevelTransitionTest.java >>> compiler/whitebox/DeoptimizeAllTest.java >>> compiler/whitebox/DeoptimizeMethodTest.java >>> compiler/whitebox/ForceNMethodSweepTest.java: >>> compiler/whitebox/GetNMethodTest.java >>> compiler/whitebox/IsMethodCompilableTest.java >>> compiler/whitebox/LockCompilationTest.java >>> compiler/whitebox/SetDontInlineMethodTest.java >>> compiler/whitebox/SetForceInlineMethodTest.java >> AFAIK, we haven't seen these tests (except DeoptimizeAllTest.java which I have already added to 2nd version of webrev) failing w/ Graal as JIT, but yes they seem to be affected by this problem as well, will add them to the problem list. > > Thanks, > Vladimir > >>> >>> May be there are more other tests. >>> >>> Thanks, >>> Vladimir >>> >>> On 6/21/18 11:51 AM, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8205490/webrev.00/index.html >>>>> 14 lines changed: 11 ins; 0 del; 3 mod; >>>> Hi all, >>>> compiler/intrinsics/mathexact/sanity tests are known to fail when run w/ Graal as JIT, this patch adds them into graal specific problem list file. >>>> webrev: http://cr.openjdk.java.net/~iignatyev//8205490/webrev.00/index.html >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8205490 >>>> Thanks, >>>> -- Igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Jun 21 23:38:28 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 21 Jun 2018 16:38:28 -0700 Subject: RFR(XXS) : 8205490 : update ProblemList-graal In-Reply-To: References: <84B7C887-CAC6-4DD6-85FE-9308ACD27699@oracle.com> Message-ID: <318b9bd4-852a-de42-b34b-0b47095d73af@oracle.com> Looks good. Thanks, Vladimir On 6/21/18 4:36 PM, Igor Ignatyev wrote: > here is the latest webrev w/ more tests problem listed -- > http://cr.openjdk.java.net/~iignatyev//8205490/webrev.02/index.html > > -- Igor > >> On Jun 21, 2018, at 4:29 PM, Vladimir Kozlov >> > wrote: >> >> On 6/21/18 2:57 PM, Igor Ignatyev wrote: >>>> On Jun 21, 2018, at 12:49 PM, Vladimir Kozlov >>>> > wrote: >>>> >>>> I would suggest to add all tests to Graal's problem list which use >>>> -XX:CompileCommand=compileonly,compiler.whitebox.SimpleTestCaseHelper::* >>>> >>>> We can't run test which use CompileOnly and expect that Graal will >>>> compile specified methods in time. We can add Graal's and JVMCI's >>>> methods to CompileOnly list. Or we should make general exception for >>>> Graal's and JVMCI's methods. >>> adding these methods to CompileOnly list in each test doesn't sound >>> like a right thing to do, and making general exception for Graal's >>> and JVMCI's methods doesn't either as it will make it >>> impossible/harder to exclude graal/jvmci methods from compilation >>> should it be necessary. adding a special diagnostic-only flag to keep >>> graal/jvmci methods compilable regardless compileOnly might be a good >>> enough compromise. >> >> Good idea. I agree with diagnostic flag. >> >>>> >>>> >>>> I found next tests are missing in list: >>>> >>>> compiler/tiered/LevelTransitionTest.java >>>> compiler/whitebox/DeoptimizeAllTest.java >>>> compiler/whitebox/DeoptimizeMethodTest.java >>>> compiler/whitebox/ForceNMethodSweepTest.java: >>>> compiler/whitebox/GetNMethodTest.java >>>> compiler/whitebox/IsMethodCompilableTest.java >>>> compiler/whitebox/LockCompilationTest.java >>>> compiler/whitebox/SetDontInlineMethodTest.java >>>> compiler/whitebox/SetForceInlineMethodTest.java >>> AFAIK, we haven't seen these tests (except DeoptimizeAllTest.java >>> which I have already added to 2nd version of webrev) failing w/ Graal >>> as JIT, but yes they seem to be affected by this problem as well, >>> will add them to the problem list. >> >> Thanks, >> Vladimir >> >>>> >>>> May be there are more other tests. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/21/18 11:51 AM, Igor Ignatyev wrote: >>>>> http://cr.openjdk.java.net/~iignatyev//8205490/webrev.00/index.html >>>>>> 14 lines changed: 11 ins; 0 del; 3 mod; >>>>> Hi all, >>>>> compiler/intrinsics/mathexact/sanity tests are known to fail when >>>>> run w/ Graal as JIT, this patch adds them into graal specific >>>>> problem list file. >>>>> webrev: >>>>> http://cr.openjdk.java.net/~iignatyev//8205490/webrev.00/index.html >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8205490 >>>>> Thanks, >>>>> -- Igor > From igor.ignatyev at oracle.com Thu Jun 21 23:41:19 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 21 Jun 2018 16:41:19 -0700 Subject: RFR(XS) : 8155192 : [TESTBUG] SHA tests assumes that x86 does not have SHA intrinsics In-Reply-To: <6CCD8F27-2B41-4D56-9FEB-D804657F3107@oracle.com> References: <475373C8-367F-4600-B246-F5E91608B4FD@oracle.com> <1e02be46-38a2-5980-8882-490484c41060@linux.vnet.ibm.com> <6CCD8F27-2B41-4D56-9FEB-D804657F3107@oracle.com> Message-ID: http://cr.openjdk.java.net/~iignatyev//8155192/webrev.01/index.html > 33 lines changed: 1 ins; 10 del; 22 mod; I've removed Platforms::* from UseSHAIntrinsicsSpecificTestCaseForUnsupportedCPU and UseSHASpecificTestCaseForSupportedCPU. all compiler/intrinsics/sha tests passed in our labs on sparc and x86 hosts. new version of webrev -- http://cr.openjdk.java.net/~iignatyev//8155192/webrev.01/index.html Gustavo, could you please test this version of path on your platforms? Thanks, -- Igor > On Jun 21, 2018, at 2:43 PM, Igor Ignatyev wrote: > > Hi Gustavo, > > please see my answers inline. > > Thanks, > -- Igor > >> On Jun 21, 2018, at 1:34 PM, Gustavo Romero > wrote: >> >> Hi Vladimir, Igor >> >> On 06/21/2018 02:47 PM, Vladimir Kozlov wrote: >>> But I find it strange that PPC64 (Platform::isPPC) is only listed in one files. According to vm_version_ppc.cpp it supports SHA256 and SHA512. >> >> Yes, that's correct. >> >> Igor, do you mind to confirm which tests exactly must be enabled on PPC64 (or >> disabled if the list is smaller...)? > all the tests are already enabled on PPC64, but they don't do much testing, as they will be skipped by the tests themselves. >> >> For instance, it's not clear to me yet why the suggested fix in [1] is adding PPC to >> UseSHAIntrinsicsSpecificTestCaseForUnsupportedCPU.java. > UseSHAIntrinsicsSpecificTestCaseForUnsupportedCPU is supposed to be run to hosts which *do* support some sha instructions, but don't support a specific one. I don't know if it's a case for PPC or not. in any case, it might be better to get rid of Platform::* predicates in this class and just use IntrinsicPredicates and SHAOptionsBase.getPredicateForOption, so its c-tor will be: >> super(optionName, new AndPredicate( >> IntrinsicPredicates.ANY_SHA_INSTRUCTION_AVAILABLE, >> new NotPredicate(SHAOptionsBase.getPredicateForOption(optionName)))); >> < ...> > > > and UseSHASpecificTestCaseForSupportedCPU's c-tor can be changed to: >> super(SHAOptionsBase.USE_SHA_OPTION, IntrinsicPredicates.ANY_SHA_INSTRUCTION_AVAILABLE); > >> < ...> > > I'll retest the patch for 8155192 w/ these changes. > >> >> Current status on PPC64 is: >> >> Passed: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java >> Passed: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnSupportedCPU.java >> Passed: compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java >> Passed: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnSupportedCPU.java >> Passed: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnUnsupportedCPU.java >> Passed: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnSupportedCPU.java >> Passed: compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java >> Passed: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java >> Passed: compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java >> Passed: compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java >> Passed: compiler/intrinsics/sha/sanity/TestSHA512Intrinsics.java >> Passed: compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java >> Passed: compiler/intrinsics/sha/sanity/TestSHA512MultiBlockIntrinsics.java >> Passed: compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java >> Passed: compiler/intrinsics/sha/TestSHA.java >> Test results: passed: 15 > as I explained above, all the tests are run on all platforms, but some of their parts are just skipped on PPC64. > >> >> Thanks. >> >> Best regards, >> Gustavo >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8205492 >> >>> Thanks, >>> Vladimir >>> On 6/20/18 8:28 PM, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8155192/webrev.00/index.html >>>>> 29 lines changed: 10 ins; 3 del; 16 mod; >>>> >>>> Hi all, >>>> >>>> could you please review this tiny fix for SHA tests? the fix adjusts definitions of supported/unsupported CPUs in sha tests. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8155192 >>>> webrev: http://cr.openjdk.java.net/~iignatyev//8155192/webrev.00/index.htm >>>> testing: test/hotspot/jtreg/compiler/intrinsics tests >>>> >>>> Thanks, >>>> -- Igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From Derek.White at cavium.com Fri Jun 22 01:40:22 2018 From: Derek.White at cavium.com (White, Derek) Date: Fri, 22 Jun 2018 01:40:22 +0000 Subject: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math intrinsics usage in interpreter and C1 In-Reply-To: <6e1457db-9b5c-3bbd-65fc-ebd2a9e99558@bell-sw.com> References: <6bd4bccb-befb-0523-d75e-2c5a99c4ee34@bell-sw.com> <6e1457db-9b5c-3bbd-65fc-ebd2a9e99558@bell-sw.com> Message-ID: Hi Dmitrij, There's some bad indenting in c1_LIRGenerator_aarch64.cpp around lines 815, 828, 829, 849, 850. I didn't follow all of the differences between the change from call_runtime to __ call_runtime_leaf, (although I see that it follows the x86 code.) So I wouldn't call this a full review. Thanks, - Derek > -----Original Message----- > From: aarch64-port-dev [mailto:aarch64-port-dev- > bounces at openjdk.java.net] On Behalf Of Dmitrij Pochepko > Sent: Wednesday, June 20, 2018 10:45 AM > To: aarch64-port-dev at openjdk.java.net; hotspot-compiler- > dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math > intrinsics usage in interpreter and C1 > > External Email > > Hi, > > > can somebody take a look? > > > Thanks, > > Dmitrij > > > On 04.06.2018 18:50, Dmitrij Pochepko wrote: > > Hi all, > > > > please review patch for JDK-8204289: AARCH64: enable math intrinsics > > usage in interpreter and C1 > > > > This patch enables usage of math intrinsics for interpreter and C1 in > > case intrinsics are implemented. Code follows that of x86 port. > > > > > > Testing: I've merged this patch with implemented intrinsic and > > launched jtreg tests and benchmark in 2 more modes: -Xint and > > -XX:TieredStopAtLevel=3 > > > > Benchmark scores were improved as expected of intrinsic. All tests > > passed. > > > > > > webrev: http://cr.openjdk.java.net/~dpochepk/8204289/webrev.01/ > > > > CR: https://bugs.openjdk.java.net/browse/JDK-8204289 > > > > > > Thanks, > > > > Dmitrij > > From igor.ignatyev at oracle.com Fri Jun 22 04:09:28 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 21 Jun 2018 21:09:28 -0700 Subject: RFR(XXS) : 8172854 : [TESTBUG] Exclude runtime/ReservedStack/ReservedStackTest.java from being run with DeoptimizeALot option Message-ID: <0A7A76E4-80DF-4A94-8372-2707260D82FB@oracle.com> http://cr.openjdk.java.net/~iignatyev//8172854/webrev.00/index.html > 8 lines changed: 6 ins; 0 del; 2 mod; Hi all, could you please review this tiny fix which excludes runtime/ReservedStack tests from runs w/ DeoptimizeAlot? JBS: https://bugs.openjdk.java.net/browse/JDK-8172854 webrev: http://cr.openjdk.java.net/~iignatyev//8172854/webrev.00/index.html testing: runtime/ReservedStack tests w/ enabled and disabled DeoptimizeAlot Thanks, -- Igor From vladimir.kozlov at oracle.com Fri Jun 22 04:18:09 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 21 Jun 2018 21:18:09 -0700 Subject: RFR(XXS) : 8172854 : [TESTBUG] Exclude runtime/ReservedStack/ReservedStackTest.java from being run with DeoptimizeALot option In-Reply-To: <0A7A76E4-80DF-4A94-8372-2707260D82FB@oracle.com> References: <0A7A76E4-80DF-4A94-8372-2707260D82FB@oracle.com> Message-ID: Looks good. Thanks, Vladimir On 6/21/18 9:09 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8172854/webrev.00/index.html >> 8 lines changed: 6 ins; 0 del; 2 mod; > > Hi all, > > could you please review this tiny fix which excludes runtime/ReservedStack tests from runs w/ DeoptimizeAlot? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8172854 > webrev: http://cr.openjdk.java.net/~iignatyev//8172854/webrev.00/index.html > testing: runtime/ReservedStack tests w/ enabled and disabled DeoptimizeAlot > > Thanks, > -- Igor > From igor.veresov at oracle.com Fri Jun 22 04:33:05 2018 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 21 Jun 2018 21:33:05 -0700 Subject: RFR(S) 8204209: [Graal] Compilation fails during nmethod printing with "assert(bci == 0 || 0 <= bci && bci < code_size()) failed: illegal bci" In-Reply-To: <489e17d8-c87e-2b78-37af-aee874821b04@oracle.com> References: <489e17d8-c87e-2b78-37af-aee874821b04@oracle.com> Message-ID: After discussing this with Tom, we decided that it would be a bad idea to change values of final static fields as this would break compatibility (since javac inlines these values). So, for now, we?d have to do re-mapping. Webrev: http://cr.openjdk.java.net/~iveresov/8204209/webrev.01 Thanks, igor > On Jun 18, 2018, at 10:12 PM, Vladimir Kozlov wrote: > > CCing to runtime group. > > Seems fine to me. > > Thanks, > Vladimir > > On 6/18/18 6:28 PM, Igor Veresov wrote: >> Make hotspot tolerate negative placeholder BCIs that are produced by Graal. >> Should this fix be deemed acceptable I?ll backport it to graal-jvmci-8. >> JBS: https://bugs.openjdk.java.net/browse/JDK-8204209 >> Webrev: http://cr.openjdk.java.net/~iveresov/8204209/webrev/ >> Thanks, >> igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Fri Jun 22 04:37:45 2018 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 21 Jun 2018 21:37:45 -0700 Subject: RFR (S): 8198909: [Graal] compiler/codecache/stress/UnexpectedDeoptimizationTest.java crashed with SIGSEGV In-Reply-To: References: <64c722cd-14e3-e0db-6a16-08ca69605205@oracle.com> <5B1E3C35.3090506@oracle.com> <7809c59d-5f2f-30aa-44e6-7cf4db03df05@oracle.com> <5B2BA778.70508@oracle.com> Message-ID: <53FDF0AD-330F-4363-9C8B-4DDFC1517888@oracle.com> Looks good to me. igor > On Jun 21, 2018, at 1:46 PM, Tom Rodriguez wrote: > > > > Erik ?sterlund wrote on 6/21/18 6:26 AM: >> Hi, >> In src/hotspot/share/jvmci/jvmciCompilerToVM.cpp >> Please remove >> #include "gc/g1/g1BarrierSet.hpp" >> In src/hotspot/share/jvmci/jvmciCompilerToVM.hpp: >> I would prefer if KlassRefHandle was called JVMCIKlassHandle, because it is very specific to JVMCI. On that note it is unfortunate that we can not simply reuse ciInstanceKlass, which is the klass handle used by the other compilers. >> Klass* _value; >> should be called _klass >> Handle _phantom; >> should be called _holder >> Klass* obj() >> should be called klass() >> Otherwise, this looks good, and I don't need another webrev for this. > > I've made all the requested edits. Additionally I never really got an answer to my question about handling of ObjArrayKlass but concluded that it must be handled, so I've moved phantom_holder from InstanceKlass to Klass so it can be used in a uniform way. I guess the CI handles it implicitly under the assumption that klass->class_loader_data() == ObjArrayKlass::cast(klass)->bottom_klass()->class_loader_data() which should presumably be true. The new webrev is http://cr.openjdk.java.net/~never/8198909.2/webrev. I'll consider the movement of phantom_holder to be acceptable unless I hear an objection soon. > > tom > >> Thanks, >> /Erik >> On 2018-06-19 23:34, Tom Rodriguez wrote: >>> I've generated a webrev with a new KlassRefHandle protecting questionable uses in JVMCI. http://cr.openjdk.java.net/~never/8198909.1/webrev >>> >>> One outstanding question is whether ObjArrayKlass also needs a working holder_phantom method. It would seem so to me but maybe there's some reason not? >>> >>> tom >>> >>> Tom Rodriguez wrote on 6/11/18 10:04 AM: >>>> >>>> >>>> Erik ?sterlund wrote on 6/11/18 2:09 AM: >>>>> Hi Tom, >>>>> >>>>> Could you please call InstanceKlass::holder_phantom() instead to keep the class alive? That is the more general mechanism that is also used by ciInstanceKlass. We don't want to use explicit G1 enqueue calls anymore. >>>> >>>> Ok. I guess the same fix in JDK8 will have the use the explicit enqueue though or is it not required in JDK8? >>>> >>>>> Also, you must not perform any thread transition between loading the weak klass from the MDO until you call holder_phantom, otherwise it might have been unloaded before you get to call holder_phantom(). Is this guaranteed somehow in this scenario? I looked through all callsites and could not find where the Klass pointer is read in the MDO and subsequently passed into the CompilerToVM::get_jvmci_type API, and therefore I do not know if this is guaranteed. >>>> >>>> The obviously problematic path is at http://hg.openjdk.java.net/jdk/jdk/file/50469fb301c4/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp#l334 when either base_address is a Klass* or base_object is NULL which is where we are reading from non-heap memory. There are other paths which are reading Klasses through more standard APIs from the ConstantPool for instance. >>>> >>>> There isn't an easy way to ensure no safepoint occurs in between so maybe we require the caller of get_jvmci_type to pass in the phantom_holder() as a way of forcing the caller to call holder_phantom() at the appropriate places? Or is it the case that getResolvedType is the only place where special effort is required? All the other paths are fairly normal HotSpot code but though place that uses klass->implementor() for instance seems like it could be considered to be weak by G1. >>>> >>>> http://hg.openjdk.java.net/jdk/jdk/file/50469fb301c4/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp#l368 >>>> >>>> The lack of a properly working KlassHandle seems like an oversight in the API to me. >>>> >>>> tom >>>> >>>>> >>>>> Thanks, >>>>> /Erik >>>>> >>>>> On 2018-06-08 22:46, Tom Rodriguez wrote: >>>>>> The JVMCI API may read Klass* and java.lang.Class instances from locations which G1 would consider to be weakly referenced. This can result in HotSpotResolvedObjectTypeImpl instances with references to Classes that have been unloaded. In the this crash, JVMCI was reading a Klass* from the profile in an MDO and building a wrapper around it. The MDO reference is weak and was the only remaining reference to the type so it could be dropped resulting in an eventual crash. >>>>>> >>>>>> I've added an explicit G1 enqueue before we call out to create the wrapper object but is there a more recommended way of doing this? Dean had pointed out the oddly named InstanceKlass::holder_phantom which is used by the CI. Should I be using that? The G1 barrier is only really need when reading from non-Java heap memory but since the get_jvmci_type method is the main entry point for this logic it safest to always perform it in this path. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8198909 >>>>>> http://cr.openjdk.java.net/~never/8198909/webrev >>>>> From vladimir.kozlov at oracle.com Fri Jun 22 05:02:03 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 21 Jun 2018 22:02:03 -0700 Subject: RFR(S) 8204209: [Graal] Compilation fails during nmethod printing with "assert(bci == 0 || 0 <= bci && bci < code_size()) failed: illegal bci" In-Reply-To: References: <489e17d8-c87e-2b78-37af-aee874821b04@oracle.com> Message-ID: It is a little confusing that BeforeBci is the same as SynchronizationEntryBCI. In nmethod.cpp you check SynchronizationEntryBCI while in jvmciCodeInstaller.cpp you check BEFORE_BCI. So one is for legacy Hotspot code and BeforeBci is for Graal code. Right? Spacing of '\' is wrong in jvmciJavaClasses.hpp. How you chose the order of fields in jvmciJavaClasses.hpp? Can it be the same as order of values in MethodCompilation (compilerDefinitions.hpp)? Thanks, Vladimir On 6/21/18 9:33 PM, Igor Veresov wrote: > After discussing this with Tom, we decided that it would be a bad idea > to change values of final static fields as this would break > compatibility (since javac inlines these values). So, for now, we?d have > to do re-mapping. > > Webrev: http://cr.openjdk.java.net/~iveresov/8204209/webrev.01 > > Thanks, > igor > >> On Jun 18, 2018, at 10:12 PM, Vladimir Kozlov >> > wrote: >> >> CCing to runtime group. >> >> Seems fine to me. >> >> Thanks, >> Vladimir >> >> On 6/18/18 6:28 PM, Igor Veresov wrote: >>> Make hotspot tolerate negative placeholder BCIs that are produced by >>> Graal. >>> Should this fix be deemed acceptable I?ll backport it to graal-jvmci-8. >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8204209 >>> Webrev: http://cr.openjdk.java.net/~iveresov/8204209/webrev/ >>> Thanks, >>> igor > From tom.rodriguez at oracle.com Fri Jun 22 05:19:33 2018 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 21 Jun 2018 22:19:33 -0700 Subject: RFR (S): 8198909: [Graal] compiler/codecache/stress/UnexpectedDeoptimizationTest.java crashed with SIGSEGV In-Reply-To: <53FDF0AD-330F-4363-9C8B-4DDFC1517888@oracle.com> References: <64c722cd-14e3-e0db-6a16-08ca69605205@oracle.com> <5B1E3C35.3090506@oracle.com> <7809c59d-5f2f-30aa-44e6-7cf4db03df05@oracle.com> <5B2BA778.70508@oracle.com> <53FDF0AD-330F-4363-9C8B-4DDFC1517888@oracle.com> Message-ID: Thanks! tom Igor Veresov wrote on 6/21/18 9:37 PM: > Looks good to me. > > igor > >> On Jun 21, 2018, at 1:46 PM, Tom Rodriguez wrote: >> >> >> >> Erik ?sterlund wrote on 6/21/18 6:26 AM: >>> Hi, >>> In src/hotspot/share/jvmci/jvmciCompilerToVM.cpp >>> Please remove >>> #include "gc/g1/g1BarrierSet.hpp" >>> In src/hotspot/share/jvmci/jvmciCompilerToVM.hpp: >>> I would prefer if KlassRefHandle was called JVMCIKlassHandle, because it is very specific to JVMCI. On that note it is unfortunate that we can not simply reuse ciInstanceKlass, which is the klass handle used by the other compilers. >>> Klass* _value; >>> should be called _klass >>> Handle _phantom; >>> should be called _holder >>> Klass* obj() >>> should be called klass() >>> Otherwise, this looks good, and I don't need another webrev for this. >> >> I've made all the requested edits. Additionally I never really got an answer to my question about handling of ObjArrayKlass but concluded that it must be handled, so I've moved phantom_holder from InstanceKlass to Klass so it can be used in a uniform way. I guess the CI handles it implicitly under the assumption that klass->class_loader_data() == ObjArrayKlass::cast(klass)->bottom_klass()->class_loader_data() which should presumably be true. The new webrev is http://cr.openjdk.java.net/~never/8198909.2/webrev. I'll consider the movement of phantom_holder to be acceptable unless I hear an objection soon. >> >> tom >> >>> Thanks, >>> /Erik >>> On 2018-06-19 23:34, Tom Rodriguez wrote: >>>> I've generated a webrev with a new KlassRefHandle protecting questionable uses in JVMCI. http://cr.openjdk.java.net/~never/8198909.1/webrev >>>> >>>> One outstanding question is whether ObjArrayKlass also needs a working holder_phantom method. It would seem so to me but maybe there's some reason not? >>>> >>>> tom >>>> >>>> Tom Rodriguez wrote on 6/11/18 10:04 AM: >>>>> >>>>> >>>>> Erik ?sterlund wrote on 6/11/18 2:09 AM: >>>>>> Hi Tom, >>>>>> >>>>>> Could you please call InstanceKlass::holder_phantom() instead to keep the class alive? That is the more general mechanism that is also used by ciInstanceKlass. We don't want to use explicit G1 enqueue calls anymore. >>>>> >>>>> Ok. I guess the same fix in JDK8 will have the use the explicit enqueue though or is it not required in JDK8? >>>>> >>>>>> Also, you must not perform any thread transition between loading the weak klass from the MDO until you call holder_phantom, otherwise it might have been unloaded before you get to call holder_phantom(). Is this guaranteed somehow in this scenario? I looked through all callsites and could not find where the Klass pointer is read in the MDO and subsequently passed into the CompilerToVM::get_jvmci_type API, and therefore I do not know if this is guaranteed. >>>>> >>>>> The obviously problematic path is at http://hg.openjdk.java.net/jdk/jdk/file/50469fb301c4/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp#l334 when either base_address is a Klass* or base_object is NULL which is where we are reading from non-heap memory. There are other paths which are reading Klasses through more standard APIs from the ConstantPool for instance. >>>>> >>>>> There isn't an easy way to ensure no safepoint occurs in between so maybe we require the caller of get_jvmci_type to pass in the phantom_holder() as a way of forcing the caller to call holder_phantom() at the appropriate places? Or is it the case that getResolvedType is the only place where special effort is required? All the other paths are fairly normal HotSpot code but though place that uses klass->implementor() for instance seems like it could be considered to be weak by G1. >>>>> >>>>> http://hg.openjdk.java.net/jdk/jdk/file/50469fb301c4/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp#l368 >>>>> >>>>> The lack of a properly working KlassHandle seems like an oversight in the API to me. >>>>> >>>>> tom >>>>> >>>>>> >>>>>> Thanks, >>>>>> /Erik >>>>>> >>>>>> On 2018-06-08 22:46, Tom Rodriguez wrote: >>>>>>> The JVMCI API may read Klass* and java.lang.Class instances from locations which G1 would consider to be weakly referenced. This can result in HotSpotResolvedObjectTypeImpl instances with references to Classes that have been unloaded. In the this crash, JVMCI was reading a Klass* from the profile in an MDO and building a wrapper around it. The MDO reference is weak and was the only remaining reference to the type so it could be dropped resulting in an eventual crash. >>>>>>> >>>>>>> I've added an explicit G1 enqueue before we call out to create the wrapper object but is there a more recommended way of doing this? Dean had pointed out the oddly named InstanceKlass::holder_phantom which is used by the CI. Should I be using that? The G1 barrier is only really need when reading from non-Java heap memory but since the get_jvmci_type method is the main entry point for this logic it safest to always perform it in this path. >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8198909 >>>>>>> http://cr.openjdk.java.net/~never/8198909/webrev >>>>>> > From aph at redhat.com Fri Jun 22 07:45:03 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 22 Jun 2018 08:45:03 +0100 Subject: RFR(S): JDK-8191339: [JVMCI] BigInteger compiler intrinsics on Graal. In-Reply-To: <28011331-bd43-2c32-dba4-e41879ffe28a@oracle.com> References: <28011331-bd43-2c32-dba4-e41879ffe28a@oracle.com> Message-ID: <2c6a8eec-3253-8790-0d49-544842baf994@redhat.com> On 06/21/2018 04:26 PM, Patric Hedlin wrote: > I would like to ask for help to review the following change/update: Can you tell me what tests to use for this functionality? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gromero at linux.vnet.ibm.com Fri Jun 22 12:42:41 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 22 Jun 2018 09:42:41 -0300 Subject: RFR(XS) : 8155192 : [TESTBUG] SHA tests assumes that x86 does not have SHA intrinsics In-Reply-To: References: <475373C8-367F-4600-B246-F5E91608B4FD@oracle.com> <1e02be46-38a2-5980-8882-490484c41060@linux.vnet.ibm.com> <6CCD8F27-2B41-4D56-9FEB-D804657F3107@oracle.com> Message-ID: Hi Igor, On 06/21/2018 08:41 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8155192/webrev.01/index.html >> 33 lines changed: 1 ins; 10 del; 22 mod; > > I've removed Platforms::* from UseSHAIntrinsicsSpecificTestCaseForUnsupportedCPU and UseSHASpecificTestCaseForSupportedCPU. all compiler/intrinsics/sha tests passed in our labs on sparc and x86 hosts. > > new version of webrev -- http://cr.openjdk.java.net/~iignatyev//8155192/webrev.01/index.html > > Gustavo, could you please test this version of path on your platforms? Sure. So after applying it I got the following state: FAILED: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnSupportedCPU.java Passed: compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java FAILED: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnSupportedCPU.java Passed: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java FAILED: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java Passed: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnUnsupportedCPU.java FAILED: compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java Passed: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnSupportedCPU.java Passed: compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java Passed: compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java Passed: compiler/intrinsics/sha/sanity/TestSHA512Intrinsics.java Passed: compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java Passed: compiler/intrinsics/sha/sanity/TestSHA512MultiBlockIntrinsics.java Passed: compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java Passed: compiler/intrinsics/sha/TestSHA.java Test results: passed: 11; failed: 4 due to (Please see full log at http://cr.openjdk.java.net/~gromero/logs/sha_jtreg_failure.log): java.lang.Error: Support for CPUs different fromn AARCH64, S390x, SPARC, and X86 is not implemented at compiler.intrinsics.sha.cli.SHAOptionsBase.getWarningForUnsupportedCPU(SHAOptionsBase.java:92) at compiler.intrinsics.sha.cli.testcases.GenericTestCaseForSupportedCPU.verifyWarnings(GenericTestCaseForSupportedCPU.java:50) at compiler.intrinsics.sha.cli.SHAOptionsBase$TestCase.test(SHAOptionsBase.java:152) at compiler.intrinsics.sha.cli.SHAOptionsBase.runTestCases(SHAOptionsBase.java:129) at jdk.test.lib.cli.CommandLineOptionTest.test(CommandLineOptionTest.java:537) at compiler.intrinsics.sha.cli.TestUseSHA512IntrinsicsOptionOnSupportedCPU.main(TestUseSHA512IntrinsicsOptionOnSupportedCPU.java:47) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:832) which seems resolved by the following tiny change: diff -r 027c909decaf test/hotspot/jtreg/compiler/intrinsics/sha/cli/SHAOptionsBase.java --- a/test/hotspot/jtreg/compiler/intrinsics/sha/cli/SHAOptionsBase.java Fri Jun 22 08:10:43 2018 -0400 +++ b/test/hotspot/jtreg/compiler/intrinsics/sha/cli/SHAOptionsBase.java Fri Jun 22 08:33:42 2018 -0400 @@ -75,7 +75,7 @@ */ public static String getWarningForUnsupportedCPU(String optionName) { if (Platform.isAArch64() || Platform.isS390x() || Platform.isSparc() || - Platform.isX64() || Platform.isX86()) { + Platform.isX64() || Platform.isX86() || Platform.isPPC()) { switch (optionName) { case SHAOptionsBase.USE_SHA_OPTION: return SHAOptionsBase.SHA_INSTRUCTIONS_ARE_NOT_AVAILABLE; @@ -89,7 +89,7 @@ throw new Error("Unexpected option " + optionName); } } else { - throw new Error("Support for CPUs different fromn AARCH64, S390x, SPARC, and X86 " + throw new Error("Support for CPUs different from AARCH64, S390x, SPARC, X86, and PPC " + "is not implemented"); } } Thus with your fix plus that fix above ^ the current state looks ok: Passed: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnSupportedCPU.java Passed: compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java Passed: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java Passed: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnUnsupportedCPU.java Passed: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java Passed: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnSupportedCPU.java Passed: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnSupportedCPU.java Passed: compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java Passed: compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java Passed: compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java Passed: compiler/intrinsics/sha/sanity/TestSHA512Intrinsics.java Passed: compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java Passed: compiler/intrinsics/sha/sanity/TestSHA512MultiBlockIntrinsics.java Passed: compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java Passed: compiler/intrinsics/sha/TestSHA.java Test results: passed: 15 Thanks, Gustavo > Thanks, > -- Igor > > >> On Jun 21, 2018, at 2:43 PM, Igor Ignatyev wrote: >> >> Hi Gustavo, >> >> please see my answers inline. >> >> Thanks, >> -- Igor >> >>> On Jun 21, 2018, at 1:34 PM, Gustavo Romero > wrote: >>> >>> Hi Vladimir, Igor >>> >>> On 06/21/2018 02:47 PM, Vladimir Kozlov wrote: >>>> But I find it strange that PPC64 (Platform::isPPC) is only listed in one files. According to vm_version_ppc.cpp it supports SHA256 and SHA512. >>> >>> Yes, that's correct. >>> >>> Igor, do you mind to confirm which tests exactly must be enabled on PPC64 (or >>> disabled if the list is smaller...)? >> all the tests are already enabled on PPC64, but they don't do much testing, as they will be skipped by the tests themselves. >>> >>> For instance, it's not clear to me yet why the suggested fix in [1] is adding PPC to >>> UseSHAIntrinsicsSpecificTestCaseForUnsupportedCPU.java. >> UseSHAIntrinsicsSpecificTestCaseForUnsupportedCPU is supposed to be run to hosts which *do* support some sha instructions, but don't support a specific one. I don't know if it's a case for PPC or not. in any case, it might be better to get rid of Platform::* predicates in this class and just use IntrinsicPredicates and SHAOptionsBase.getPredicateForOption, so its c-tor will be: >>> ????????super(optionName, new AndPredicate( >>> ????????????????????????IntrinsicPredicates.ANY_SHA_INSTRUCTION_AVAILABLE, >>> ????????????????????????new NotPredicate(SHAOptionsBase.getPredicateForOption(optionName)))); >>> ???< ...> >> >> >> and UseSHASpecificTestCaseForSupportedCPU's c-tor can be changed to: >>> ????????super(SHAOptionsBase.USE_SHA_OPTION, IntrinsicPredicates.ANY_SHA_INSTRUCTION_AVAILABLE); >> >>> ???< ...> >> >> I'll retest the patch for 8155192 w/ these changes. >> >>> >>> Current status on PPC64 is: >>> >>> Passed: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java >>> Passed: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnSupportedCPU.java >>> Passed: compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java >>> Passed: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnSupportedCPU.java >>> Passed: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnUnsupportedCPU.java >>> Passed: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnSupportedCPU.java >>> Passed: compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java >>> Passed: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java >>> Passed: compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java >>> Passed: compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java >>> Passed: compiler/intrinsics/sha/sanity/TestSHA512Intrinsics.java >>> Passed: compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java >>> Passed: compiler/intrinsics/sha/sanity/TestSHA512MultiBlockIntrinsics.java >>> Passed: compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java >>> Passed: compiler/intrinsics/sha/TestSHA.java >>> Test results: passed: 15 >> as I explained above, all the tests are run on all platforms, but some of their parts are just skipped on PPC64. >> >>> >>> Thanks. >>> >>> Best regards, >>> Gustavo >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8205492 >>> >>>> Thanks, >>>> Vladimir >>>> On 6/20/18 8:28 PM, Igor Ignatyev wrote: >>>>> http://cr.openjdk.java.net/~iignatyev//8155192/webrev.00/index.html >>>>>> 29 lines changed: 10 ins; 3 del; 16 mod; >>>>> >>>>> Hi all, >>>>> >>>>> could you please review this tiny fix for SHA tests? the fix adjusts definitions of supported/unsupported CPUs in sha tests. >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8155192 >>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8155192/webrev.00/index.htm >>>>> testing: test/hotspot/jtreg/compiler/intrinsics tests >>>>> >>>>> Thanks, >>>>> -- Igor > From dmitrij.pochepko at bell-sw.com Fri Jun 22 12:53:08 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 22 Jun 2018 15:53:08 +0300 Subject: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math intrinsics usage in interpreter and C1 In-Reply-To: References: <6bd4bccb-befb-0523-d75e-2c5a99c4ee34@bell-sw.com> <6e1457db-9b5c-3bbd-65fc-ebd2a9e99558@bell-sw.com> Message-ID: Hi Derek, Andrew, Here is an updated version with your comments addressed: http://cr.openjdk.java.net/~dpochepk/8204289/webrev.03/ Thanks, Dmitrij On 22.06.2018 04:40, White, Derek wrote: > Hi Dmitrij, > > There's some bad indenting in c1_LIRGenerator_aarch64.cpp around lines > 815, 828, 829, 849, 850. > > I didn't follow all of the differences between the change from call_runtime to __ call_runtime_leaf, (although I see that it follows the x86 code.) So I wouldn't call this a full review. > > Thanks, > - Derek > >> -----Original Message----- >> From: aarch64-port-dev [mailto:aarch64-port-dev- >> bounces at openjdk.java.net] On Behalf Of Dmitrij Pochepko >> Sent: Wednesday, June 20, 2018 10:45 AM >> To: aarch64-port-dev at openjdk.java.net; hotspot-compiler- >> dev at openjdk.java.net >> Subject: Re: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math >> intrinsics usage in interpreter and C1 >> >> External Email >> >> Hi, >> >> >> can somebody take a look? >> >> >> Thanks, >> >> Dmitrij >> >> >> On 04.06.2018 18:50, Dmitrij Pochepko wrote: >>> Hi all, >>> >>> please review patch for JDK-8204289: AARCH64: enable math intrinsics >>> usage in interpreter and C1 >>> >>> This patch enables usage of math intrinsics for interpreter and C1 in >>> case intrinsics are implemented. Code follows that of x86 port. >>> >>> >>> Testing: I've merged this patch with implemented intrinsic and >>> launched jtreg tests and benchmark in 2 more modes: -Xint and >>> -XX:TieredStopAtLevel=3 >>> >>> Benchmark scores were improved as expected of intrinsic. All tests >>> passed. >>> >>> >>> webrev: http://cr.openjdk.java.net/~dpochepk/8204289/webrev.01/ >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8204289 >>> >>> >>> Thanks, >>> >>> Dmitrij >>> From igor.veresov at oracle.com Fri Jun 22 15:04:52 2018 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 22 Jun 2018 08:04:52 -0700 Subject: RFR(S) 8204209: [Graal] Compilation fails during nmethod printing with "assert(bci == 0 || 0 <= bci && bci < code_size()) failed: illegal bci" In-Reply-To: References: <489e17d8-c87e-2b78-37af-aee874821b04@oracle.com> Message-ID: <680D3D07-BA68-4772-8851-134B05E27F2E@oracle.com> > On Jun 21, 2018, at 10:02 PM, Vladimir Kozlov wrote: > > It is a little confusing that BeforeBci is the same as SynchronizationEntryBCI. Yes, they mean the same thing. BeforeBci == SyncronizationEntryBCI == InvocationEntryBci == -1. However BytecodeFrame::BEFORE_BCI() is currently -2. In Infopoints that come from Graal it?s -2 and it has to be changed to -1 when we synthesize ScopeDescs. Unfortunate choice of values that I hope we can soon reconcile but for now we have to do the remapping. > In nmethod.cpp you check SynchronizationEntryBCI while in jvmciCodeInstaller.cpp you check BEFORE_BCI. So one is for legacy Hotspot code and BeforeBci is for Graal code. Right? Right. > > Spacing of '\' is wrong in jvmciJavaClasses.hpp. Sorry I don?t see it, which line is that? > > How you chose the order of fields in jvmciJavaClasses.hpp? Can it be the same as order of values in MethodCompilation (compilerDefinitions.hpp)? > Currently they are in the order they are defined in BytecodeFrame.java, which they refer to. But the order doesn?t matter, do you want me to change it? igor > Thanks, > Vladimir > > On 6/21/18 9:33 PM, Igor Veresov wrote: >> After discussing this with Tom, we decided that it would be a bad idea to change values of final static fields as this would break compatibility (since javac inlines these values). So, for now, we?d have to do re-mapping. >> Webrev: http://cr.openjdk.java.net/~iveresov/8204209/webrev.01 >> Thanks, >> igor >>> On Jun 18, 2018, at 10:12 PM, Vladimir Kozlov > wrote: >>> >>> CCing to runtime group. >>> >>> Seems fine to me. >>> >>> Thanks, >>> Vladimir >>> >>> On 6/18/18 6:28 PM, Igor Veresov wrote: >>>> Make hotspot tolerate negative placeholder BCIs that are produced by Graal. >>>> Should this fix be deemed acceptable I?ll backport it to graal-jvmci-8. >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8204209 >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8204209/webrev/ >>>> Thanks, >>>> igor From vladimir.kozlov at oracle.com Fri Jun 22 15:29:35 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Jun 2018 08:29:35 -0700 Subject: RFR(S) 8204209: [Graal] Compilation fails during nmethod printing with "assert(bci == 0 || 0 <= bci && bci < code_size()) failed: illegal bci" In-Reply-To: <680D3D07-BA68-4772-8851-134B05E27F2E@oracle.com> References: <489e17d8-c87e-2b78-37af-aee874821b04@oracle.com> <680D3D07-BA68-4772-8851-134B05E27F2E@oracle.com> Message-ID: <29454b0d-33f0-b418-8246-02bf3918a3b0@oracle.com> On 6/22/18 8:04 AM, Igor Veresov wrote: > > >> On Jun 21, 2018, at 10:02 PM, Vladimir Kozlov wrote: >> >> It is a little confusing that BeforeBci is the same as SynchronizationEntryBCI. > > Yes, they mean the same thing. BeforeBci == SyncronizationEntryBCI == InvocationEntryBci == -1. > However BytecodeFrame::BEFORE_BCI() is currently -2. In Infopoints that come from Graal it?s -2 and it has to be changed to -1 when we synthesize ScopeDescs. Unfortunate choice of values that I hope we can soon reconcile but for now we have to do the remapping. Okay. > >> In nmethod.cpp you check SynchronizationEntryBCI while in jvmciCodeInstaller.cpp you check BEFORE_BCI. So one is for legacy Hotspot code and BeforeBci is for Graal code. Right? > > Right. > >> >> Spacing of '\' is wrong in jvmciJavaClasses.hpp. > > Sorry I don?t see it, which line is that? They are at the end of new lines and not aligned to other '\'. >> >> How you chose the order of fields in jvmciJavaClasses.hpp? Can it be the same as order of values in MethodCompilation (compilerDefinitions.hpp)? >> > > Currently they are in the order they are defined in BytecodeFrame.java, which they refer to. But the order doesn?t matter, do you want me to change it? I did not look on BytecodeFrame.java that is why I had question. Keep in as it is. Thanks, Vladimir > > igor > >> Thanks, >> Vladimir >> >> On 6/21/18 9:33 PM, Igor Veresov wrote: >>> After discussing this with Tom, we decided that it would be a bad idea to change values of final static fields as this would break compatibility (since javac inlines these values). So, for now, we?d have to do re-mapping. >>> Webrev: http://cr.openjdk.java.net/~iveresov/8204209/webrev.01 >>> Thanks, >>> igor >>>> On Jun 18, 2018, at 10:12 PM, Vladimir Kozlov > wrote: >>>> >>>> CCing to runtime group. >>>> >>>> Seems fine to me. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/18/18 6:28 PM, Igor Veresov wrote: >>>>> Make hotspot tolerate negative placeholder BCIs that are produced by Graal. >>>>> Should this fix be deemed acceptable I?ll backport it to graal-jvmci-8. >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8204209 >>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8204209/webrev/ >>>>> Thanks, >>>>> igor > From vladimir.kozlov at oracle.com Fri Jun 22 16:04:45 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Jun 2018 09:04:45 -0700 Subject: RFR(S): JDK-8191339: [JVMCI] BigInteger compiler intrinsics on Graal. In-Reply-To: <28011331-bd43-2c32-dba4-e41879ffe28a@oracle.com> References: <28011331-bd43-2c32-dba4-e41879ffe28a@oracle.com> Message-ID: <02f34a26-2a97-6a30-384f-115327781aac@oracle.com> Hi Patric, Do you need Graal changes for this? Or it already has these intrinsics and the only problem is these flags were not set in vm_version_x86.cpp? Small note. In vm_version_x86.cpp previous code has already COMPILER2_OR_JVMCI check. You can remove previous #endif and new #ifdef. Also change comment for closing #endif at line 1080 to // COMPILER2_OR_JVMCI 1080 #endif // COMPILER2 What testing you did? Thanks, Vladimir On 6/21/18 8:26 AM, Patric Hedlin wrote: > Dear all, > > I would like to ask for help to review the following change/update: > > Issue:? https://bugs.openjdk.java.net/browse/JDK-8191339 > > Webrev: http://cr.openjdk.java.net/~phedlin/tr8191339/ > > > 8191339: [JVMCI] BigInteger compiler intrinsics on Graal. > > ??? Enabling BigInteger intrinsics via JVMCI. > > > > Best regards, > Patric From igor.veresov at oracle.com Fri Jun 22 17:47:02 2018 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 22 Jun 2018 10:47:02 -0700 Subject: RFR(S) 8204209: [Graal] Compilation fails during nmethod printing with "assert(bci == 0 || 0 <= bci && bci < code_size()) failed: illegal bci" In-Reply-To: <29454b0d-33f0-b418-8246-02bf3918a3b0@oracle.com> References: <489e17d8-c87e-2b78-37af-aee874821b04@oracle.com> <680D3D07-BA68-4772-8851-134B05E27F2E@oracle.com> <29454b0d-33f0-b418-8246-02bf3918a3b0@oracle.com> Message-ID: > On Jun 22, 2018, at 8:29 AM, Vladimir Kozlov wrote: > > On 6/22/18 8:04 AM, Igor Veresov wrote: >>> On Jun 21, 2018, at 10:02 PM, Vladimir Kozlov wrote: >>> >>> It is a little confusing that BeforeBci is the same as SynchronizationEntryBCI. >> Yes, they mean the same thing. BeforeBci == SyncronizationEntryBCI == InvocationEntryBci == -1. >> However BytecodeFrame::BEFORE_BCI() is currently -2. In Infopoints that come from Graal it?s -2 and it has to be changed to -1 when we synthesize ScopeDescs. Unfortunate choice of values that I hope we can soon reconcile but for now we have to do the remapping. > > Okay. > >>> In nmethod.cpp you check SynchronizationEntryBCI while in jvmciCodeInstaller.cpp you check BEFORE_BCI. So one is for legacy Hotspot code and BeforeBci is for Graal code. Right? >> Right. >>> >>> Spacing of '\' is wrong in jvmciJavaClasses.hpp. >> Sorry I don?t see it, which line is that? > > They are at the end of new lines and not aligned to other '\?. Oh, yeah, I see them now. I?ll fix that. Thanks for the review! igor > >>> >>> How you chose the order of fields in jvmciJavaClasses.hpp? Can it be the same as order of values in MethodCompilation (compilerDefinitions.hpp)? >>> >> Currently they are in the order they are defined in BytecodeFrame.java, which they refer to. But the order doesn?t matter, do you want me to change it? > > I did not look on BytecodeFrame.java that is why I had question. Keep in as it is. > > Thanks, > Vladimir > >> igor >>> Thanks, >>> Vladimir >>> >>> On 6/21/18 9:33 PM, Igor Veresov wrote: >>>> After discussing this with Tom, we decided that it would be a bad idea to change values of final static fields as this would break compatibility (since javac inlines these values). So, for now, we?d have to do re-mapping. >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8204209/webrev.01 >>>> Thanks, >>>> igor >>>>> On Jun 18, 2018, at 10:12 PM, Vladimir Kozlov > wrote: >>>>> >>>>> CCing to runtime group. >>>>> >>>>> Seems fine to me. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 6/18/18 6:28 PM, Igor Veresov wrote: >>>>>> Make hotspot tolerate negative placeholder BCIs that are produced by Graal. >>>>>> Should this fix be deemed acceptable I?ll backport it to graal-jvmci-8. >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8204209 >>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8204209/webrev/ >>>>>> Thanks, >>>>>> igor From tom.rodriguez at oracle.com Fri Jun 22 18:20:40 2018 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 22 Jun 2018 11:20:40 -0700 Subject: RFR(S) 8204209: [Graal] Compilation fails during nmethod printing with "assert(bci == 0 || 0 <= bci && bci < code_size()) failed: illegal bci" In-Reply-To: References: <489e17d8-c87e-2b78-37af-aee874821b04@oracle.com> Message-ID: <33a534f2-1d57-46c2-cd82-9ef0d91534f0@oracle.com> I think this looks good. We can correct the numbering next time we break binary compatibility. tom Igor Veresov wrote on 6/21/18 9:33 PM: > After discussing this with Tom, we decided that it would be a bad idea > to change values of final static fields as this would break > compatibility (since javac inlines these values). So, for now, we?d have > to do re-mapping. > > Webrev: http://cr.openjdk.java.net/~iveresov/8204209/webrev.01 > > Thanks, > igor > >> On Jun 18, 2018, at 10:12 PM, Vladimir Kozlov >> > wrote: >> >> CCing to runtime group. >> >> Seems fine to me. >> >> Thanks, >> Vladimir >> >> On 6/18/18 6:28 PM, Igor Veresov wrote: >>> Make hotspot tolerate negative placeholder BCIs that are produced by >>> Graal. >>> Should this fix be deemed acceptable I?ll backport it to graal-jvmci-8. >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8204209 >>> Webrev: http://cr.openjdk.java.net/~iveresov/8204209/webrev/ >>> Thanks, >>> igor > From igor.ignatyev at oracle.com Fri Jun 22 18:41:15 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 22 Jun 2018 11:41:15 -0700 Subject: RFR(XS) : 8155192 : [TESTBUG] SHA tests assumes that x86 does not have SHA intrinsics In-Reply-To: References: <475373C8-367F-4600-B246-F5E91608B4FD@oracle.com> <1e02be46-38a2-5980-8882-490484c41060@linux.vnet.ibm.com> <6CCD8F27-2B41-4D56-9FEB-D804657F3107@oracle.com> Message-ID: Hi Gustavo, thanks for checking. I'll push webrev.01 + your diff later today. -- Igor > On Jun 22, 2018, at 5:42 AM, Gustavo Romero wrote: > > Hi Igor, > > On 06/21/2018 08:41 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8155192/webrev.01/index.html >>> 33 lines changed: 1 ins; 10 del; 22 mod; >> I've removed Platforms::* from UseSHAIntrinsicsSpecificTestCaseForUnsupportedCPU and UseSHASpecificTestCaseForSupportedCPU. all compiler/intrinsics/sha tests passed in our labs on sparc and x86 hosts. >> new version of webrev -- http://cr.openjdk.java.net/~iignatyev//8155192/webrev.01/index.html >> Gustavo, could you please test this version of path on your platforms? > > Sure. > > So after applying it I got the following state: > > FAILED: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnSupportedCPU.java > Passed: compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java > FAILED: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnSupportedCPU.java > Passed: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java > FAILED: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java > Passed: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnUnsupportedCPU.java > FAILED: compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java > Passed: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnSupportedCPU.java > Passed: compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java > Passed: compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java > Passed: compiler/intrinsics/sha/sanity/TestSHA512Intrinsics.java > Passed: compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java > Passed: compiler/intrinsics/sha/sanity/TestSHA512MultiBlockIntrinsics.java > Passed: compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java > Passed: compiler/intrinsics/sha/TestSHA.java > Test results: passed: 11; failed: 4 > > due to (Please see full log at http://cr.openjdk.java.net/~gromero/logs/sha_jtreg_failure.log): > > java.lang.Error: Support for CPUs different fromn AARCH64, S390x, SPARC, and X86 is not implemented > at compiler.intrinsics.sha.cli.SHAOptionsBase.getWarningForUnsupportedCPU(SHAOptionsBase.java:92) > at compiler.intrinsics.sha.cli.testcases.GenericTestCaseForSupportedCPU.verifyWarnings(GenericTestCaseForSupportedCPU.java:50) > at compiler.intrinsics.sha.cli.SHAOptionsBase$TestCase.test(SHAOptionsBase.java:152) > at compiler.intrinsics.sha.cli.SHAOptionsBase.runTestCases(SHAOptionsBase.java:129) > at jdk.test.lib.cli.CommandLineOptionTest.test(CommandLineOptionTest.java:537) > at compiler.intrinsics.sha.cli.TestUseSHA512IntrinsicsOptionOnSupportedCPU.main(TestUseSHA512IntrinsicsOptionOnSupportedCPU.java:47) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) > at java.base/java.lang.Thread.run(Thread.java:832) > > which seems resolved by the following tiny change: > > diff -r 027c909decaf test/hotspot/jtreg/compiler/intrinsics/sha/cli/SHAOptionsBase.java > --- a/test/hotspot/jtreg/compiler/intrinsics/sha/cli/SHAOptionsBase.java Fri Jun 22 08:10:43 2018 -0400 > +++ b/test/hotspot/jtreg/compiler/intrinsics/sha/cli/SHAOptionsBase.java Fri Jun 22 08:33:42 2018 -0400 > @@ -75,7 +75,7 @@ > */ > public static String getWarningForUnsupportedCPU(String optionName) { > if (Platform.isAArch64() || Platform.isS390x() || Platform.isSparc() || > - Platform.isX64() || Platform.isX86()) { > + Platform.isX64() || Platform.isX86() || Platform.isPPC()) { > switch (optionName) { > case SHAOptionsBase.USE_SHA_OPTION: > return SHAOptionsBase.SHA_INSTRUCTIONS_ARE_NOT_AVAILABLE; > @@ -89,7 +89,7 @@ > throw new Error("Unexpected option " + optionName); > } > } else { > - throw new Error("Support for CPUs different fromn AARCH64, S390x, SPARC, and X86 " > + throw new Error("Support for CPUs different from AARCH64, S390x, SPARC, X86, and PPC " > + "is not implemented"); > } > } > > Thus with your fix plus that fix above ^ the current state looks ok: > > Passed: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnSupportedCPU.java > Passed: compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java > Passed: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java > Passed: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnUnsupportedCPU.java > Passed: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java > Passed: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnSupportedCPU.java > Passed: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnSupportedCPU.java > Passed: compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java > Passed: compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java > Passed: compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java > Passed: compiler/intrinsics/sha/sanity/TestSHA512Intrinsics.java > Passed: compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java > Passed: compiler/intrinsics/sha/sanity/TestSHA512MultiBlockIntrinsics.java > Passed: compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java > Passed: compiler/intrinsics/sha/TestSHA.java > Test results: passed: 15 > > > Thanks, > Gustavo > >> Thanks, >> -- Igor >>> On Jun 21, 2018, at 2:43 PM, Igor Ignatyev wrote: >>> >>> Hi Gustavo, >>> >>> please see my answers inline. >>> >>> Thanks, >>> -- Igor >>> >>>> On Jun 21, 2018, at 1:34 PM, Gustavo Romero > wrote: >>>> >>>> Hi Vladimir, Igor >>>> >>>> On 06/21/2018 02:47 PM, Vladimir Kozlov wrote: >>>>> But I find it strange that PPC64 (Platform::isPPC) is only listed in one files. According to vm_version_ppc.cpp it supports SHA256 and SHA512. >>>> >>>> Yes, that's correct. >>>> >>>> Igor, do you mind to confirm which tests exactly must be enabled on PPC64 (or >>>> disabled if the list is smaller...)? >>> all the tests are already enabled on PPC64, but they don't do much testing, as they will be skipped by the tests themselves. >>>> >>>> For instance, it's not clear to me yet why the suggested fix in [1] is adding PPC to >>>> UseSHAIntrinsicsSpecificTestCaseForUnsupportedCPU.java. >>> UseSHAIntrinsicsSpecificTestCaseForUnsupportedCPU is supposed to be run to hosts which *do* support some sha instructions, but don't support a specific one. I don't know if it's a case for PPC or not. in any case, it might be better to get rid of Platform::* predicates in this class and just use IntrinsicPredicates and SHAOptionsBase.getPredicateForOption, so its c-tor will be: >>>> super(optionName, new AndPredicate( >>>> IntrinsicPredicates.ANY_SHA_INSTRUCTION_AVAILABLE, >>>> new NotPredicate(SHAOptionsBase.getPredicateForOption(optionName)))); >>>> < ...> >>> >>> >>> and UseSHASpecificTestCaseForSupportedCPU's c-tor can be changed to: >>>> super(SHAOptionsBase.USE_SHA_OPTION, IntrinsicPredicates.ANY_SHA_INSTRUCTION_AVAILABLE); >>> >>>> < ...> >>> >>> I'll retest the patch for 8155192 w/ these changes. >>> >>>> >>>> Current status on PPC64 is: >>>> >>>> Passed: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java >>>> Passed: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnSupportedCPU.java >>>> Passed: compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java >>>> Passed: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnSupportedCPU.java >>>> Passed: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnUnsupportedCPU.java >>>> Passed: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnSupportedCPU.java >>>> Passed: compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java >>>> Passed: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java >>>> Passed: compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java >>>> Passed: compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java >>>> Passed: compiler/intrinsics/sha/sanity/TestSHA512Intrinsics.java >>>> Passed: compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java >>>> Passed: compiler/intrinsics/sha/sanity/TestSHA512MultiBlockIntrinsics.java >>>> Passed: compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java >>>> Passed: compiler/intrinsics/sha/TestSHA.java >>>> Test results: passed: 15 >>> as I explained above, all the tests are run on all platforms, but some of their parts are just skipped on PPC64. >>> >>>> >>>> Thanks. >>>> >>>> Best regards, >>>> Gustavo >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8205492 >>>> >>>>> Thanks, >>>>> Vladimir >>>>> On 6/20/18 8:28 PM, Igor Ignatyev wrote: >>>>>> http://cr.openjdk.java.net/~iignatyev//8155192/webrev.00/index.html >>>>>>> 29 lines changed: 10 ins; 3 del; 16 mod; >>>>>> >>>>>> Hi all, >>>>>> >>>>>> could you please review this tiny fix for SHA tests? the fix adjusts definitions of supported/unsupported CPUs in sha tests. >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8155192 >>>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8155192/webrev.00/index.htm >>>>>> testing: test/hotspot/jtreg/compiler/intrinsics tests >>>>>> >>>>>> Thanks, >>>>>> -- Igor > From smita.kamath at intel.com Fri Jun 22 18:47:42 2018 From: smita.kamath at intel.com (Kamath, Smita) Date: Fri, 22 Jun 2018 18:47:42 +0000 Subject: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions Message-ID: <6563F381B547594081EF9DE181D0791277AAD1EC@FMSMSX119.amr.corp.intel.com> Hi Vladimir, I'd like to contribute an optimization for Base64 Encoding Algorithm using AVX512 Instructions. This optimization shows 1.5x improvement on x86_64 platform(SKL). Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8205528 Link to webrev: http://cr.openjdk.java.net/~vdeshpande/Base64/webrev.00/ For testing the implementation, I have run tests under test/jdk/java/util/Base64/ and also ran test/jdk/com/sun/jndi/ldap/Base64Test.java I have also run jtreg. Please review and let me know if you have any comments. Thanks and Regards, Smita -------------- next part -------------- An HTML attachment was scrubbed... URL: From gromero at linux.vnet.ibm.com Fri Jun 22 19:03:13 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 22 Jun 2018 16:03:13 -0300 Subject: RFR(XS) : 8155192 : [TESTBUG] SHA tests assumes that x86 does not have SHA intrinsics In-Reply-To: References: <475373C8-367F-4600-B246-F5E91608B4FD@oracle.com> <1e02be46-38a2-5980-8882-490484c41060@linux.vnet.ibm.com> <6CCD8F27-2B41-4D56-9FEB-D804657F3107@oracle.com> Message-ID: <39034e35-d770-40d8-c8ef-268b12923d94@linux.vnet.ibm.com> Hi Igor, On 06/22/2018 03:41 PM, Igor Ignatyev wrote: > thanks for checking. I'll push webrev.01 + your diff later today. Sounds good, thanks! Regards, Gustavo > -- Igor > >> On Jun 22, 2018, at 5:42 AM, Gustavo Romero wrote: >> >> Hi Igor, >> >> On 06/21/2018 08:41 PM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8155192/webrev.01/index.html >>>> 33 lines changed: 1 ins; 10 del; 22 mod; >>> I've removed Platforms::* from UseSHAIntrinsicsSpecificTestCaseForUnsupportedCPU and UseSHASpecificTestCaseForSupportedCPU. all compiler/intrinsics/sha tests passed in our labs on sparc and x86 hosts. >>> new version of webrev -- http://cr.openjdk.java.net/~iignatyev//8155192/webrev.01/index.html >>> Gustavo, could you please test this version of path on your platforms? >> >> Sure. >> >> So after applying it I got the following state: >> >> FAILED: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnSupportedCPU.java >> Passed: compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java >> FAILED: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnSupportedCPU.java >> Passed: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java >> FAILED: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java >> Passed: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnUnsupportedCPU.java >> FAILED: compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java >> Passed: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnSupportedCPU.java >> Passed: compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java >> Passed: compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java >> Passed: compiler/intrinsics/sha/sanity/TestSHA512Intrinsics.java >> Passed: compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java >> Passed: compiler/intrinsics/sha/sanity/TestSHA512MultiBlockIntrinsics.java >> Passed: compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java >> Passed: compiler/intrinsics/sha/TestSHA.java >> Test results: passed: 11; failed: 4 >> >> due to (Please see full log at http://cr.openjdk.java.net/~gromero/logs/sha_jtreg_failure.log): >> >> java.lang.Error: Support for CPUs different fromn AARCH64, S390x, SPARC, and X86 is not implemented >> at compiler.intrinsics.sha.cli.SHAOptionsBase.getWarningForUnsupportedCPU(SHAOptionsBase.java:92) >> at compiler.intrinsics.sha.cli.testcases.GenericTestCaseForSupportedCPU.verifyWarnings(GenericTestCaseForSupportedCPU.java:50) >> at compiler.intrinsics.sha.cli.SHAOptionsBase$TestCase.test(SHAOptionsBase.java:152) >> at compiler.intrinsics.sha.cli.SHAOptionsBase.runTestCases(SHAOptionsBase.java:129) >> at jdk.test.lib.cli.CommandLineOptionTest.test(CommandLineOptionTest.java:537) >> at compiler.intrinsics.sha.cli.TestUseSHA512IntrinsicsOptionOnSupportedCPU.main(TestUseSHA512IntrinsicsOptionOnSupportedCPU.java:47) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) >> at java.base/java.lang.Thread.run(Thread.java:832) >> >> which seems resolved by the following tiny change: >> >> diff -r 027c909decaf test/hotspot/jtreg/compiler/intrinsics/sha/cli/SHAOptionsBase.java >> --- a/test/hotspot/jtreg/compiler/intrinsics/sha/cli/SHAOptionsBase.java Fri Jun 22 08:10:43 2018 -0400 >> +++ b/test/hotspot/jtreg/compiler/intrinsics/sha/cli/SHAOptionsBase.java Fri Jun 22 08:33:42 2018 -0400 >> @@ -75,7 +75,7 @@ >> */ >> public static String getWarningForUnsupportedCPU(String optionName) { >> if (Platform.isAArch64() || Platform.isS390x() || Platform.isSparc() || >> - Platform.isX64() || Platform.isX86()) { >> + Platform.isX64() || Platform.isX86() || Platform.isPPC()) { >> switch (optionName) { >> case SHAOptionsBase.USE_SHA_OPTION: >> return SHAOptionsBase.SHA_INSTRUCTIONS_ARE_NOT_AVAILABLE; >> @@ -89,7 +89,7 @@ >> throw new Error("Unexpected option " + optionName); >> } >> } else { >> - throw new Error("Support for CPUs different fromn AARCH64, S390x, SPARC, and X86 " >> + throw new Error("Support for CPUs different from AARCH64, S390x, SPARC, X86, and PPC " >> + "is not implemented"); >> } >> } >> >> Thus with your fix plus that fix above ^ the current state looks ok: >> >> Passed: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnSupportedCPU.java >> Passed: compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java >> Passed: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java >> Passed: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnUnsupportedCPU.java >> Passed: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java >> Passed: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnSupportedCPU.java >> Passed: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnSupportedCPU.java >> Passed: compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java >> Passed: compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java >> Passed: compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java >> Passed: compiler/intrinsics/sha/sanity/TestSHA512Intrinsics.java >> Passed: compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java >> Passed: compiler/intrinsics/sha/sanity/TestSHA512MultiBlockIntrinsics.java >> Passed: compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java >> Passed: compiler/intrinsics/sha/TestSHA.java >> Test results: passed: 15 >> >> >> Thanks, >> Gustavo >> >>> Thanks, >>> -- Igor >>>> On Jun 21, 2018, at 2:43 PM, Igor Ignatyev wrote: >>>> >>>> Hi Gustavo, >>>> >>>> please see my answers inline. >>>> >>>> Thanks, >>>> -- Igor >>>> >>>>> On Jun 21, 2018, at 1:34 PM, Gustavo Romero > wrote: >>>>> >>>>> Hi Vladimir, Igor >>>>> >>>>> On 06/21/2018 02:47 PM, Vladimir Kozlov wrote: >>>>>> But I find it strange that PPC64 (Platform::isPPC) is only listed in one files. According to vm_version_ppc.cpp it supports SHA256 and SHA512. >>>>> >>>>> Yes, that's correct. >>>>> >>>>> Igor, do you mind to confirm which tests exactly must be enabled on PPC64 (or >>>>> disabled if the list is smaller...)? >>>> all the tests are already enabled on PPC64, but they don't do much testing, as they will be skipped by the tests themselves. >>>>> >>>>> For instance, it's not clear to me yet why the suggested fix in [1] is adding PPC to >>>>> UseSHAIntrinsicsSpecificTestCaseForUnsupportedCPU.java. >>>> UseSHAIntrinsicsSpecificTestCaseForUnsupportedCPU is supposed to be run to hosts which *do* support some sha instructions, but don't support a specific one. I don't know if it's a case for PPC or not. in any case, it might be better to get rid of Platform::* predicates in this class and just use IntrinsicPredicates and SHAOptionsBase.getPredicateForOption, so its c-tor will be: >>>>> super(optionName, new AndPredicate( >>>>> IntrinsicPredicates.ANY_SHA_INSTRUCTION_AVAILABLE, >>>>> new NotPredicate(SHAOptionsBase.getPredicateForOption(optionName)))); >>>>> < ...> >>>> >>>> >>>> and UseSHASpecificTestCaseForSupportedCPU's c-tor can be changed to: >>>>> super(SHAOptionsBase.USE_SHA_OPTION, IntrinsicPredicates.ANY_SHA_INSTRUCTION_AVAILABLE); >>>> >>>>> < ...> >>>> >>>> I'll retest the patch for 8155192 w/ these changes. >>>> >>>>> >>>>> Current status on PPC64 is: >>>>> >>>>> Passed: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java >>>>> Passed: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnSupportedCPU.java >>>>> Passed: compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java >>>>> Passed: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnSupportedCPU.java >>>>> Passed: compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnUnsupportedCPU.java >>>>> Passed: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnSupportedCPU.java >>>>> Passed: compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java >>>>> Passed: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java >>>>> Passed: compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java >>>>> Passed: compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java >>>>> Passed: compiler/intrinsics/sha/sanity/TestSHA512Intrinsics.java >>>>> Passed: compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java >>>>> Passed: compiler/intrinsics/sha/sanity/TestSHA512MultiBlockIntrinsics.java >>>>> Passed: compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java >>>>> Passed: compiler/intrinsics/sha/TestSHA.java >>>>> Test results: passed: 15 >>>> as I explained above, all the tests are run on all platforms, but some of their parts are just skipped on PPC64. >>>> >>>>> >>>>> Thanks. >>>>> >>>>> Best regards, >>>>> Gustavo >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8205492 >>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> On 6/20/18 8:28 PM, Igor Ignatyev wrote: >>>>>>> http://cr.openjdk.java.net/~iignatyev//8155192/webrev.00/index.html >>>>>>>> 29 lines changed: 10 ins; 3 del; 16 mod; >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> could you please review this tiny fix for SHA tests? the fix adjusts definitions of supported/unsupported CPUs in sha tests. >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8155192 >>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8155192/webrev.00/index.htm >>>>>>> testing: test/hotspot/jtreg/compiler/intrinsics tests >>>>>>> >>>>>>> Thanks, >>>>>>> -- Igor >> > From vladimir.kozlov at oracle.com Fri Jun 22 19:29:16 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Jun 2018 12:29:16 -0700 Subject: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions In-Reply-To: <6563F381B547594081EF9DE181D0791277AAD1EC@FMSMSX119.amr.corp.intel.com> References: <6563F381B547594081EF9DE181D0791277AAD1EC@FMSMSX119.amr.corp.intel.com> Message-ID: Hi Smita, I CCing to Libs to review code changes in Base64.java. Looks like you changed all need place to implement intrinsic. One question so: why you have own copy of base64 charsets and not using one in library: private int encode0(byte[] src, int off, int end, byte[] dst) { char[] base64 = isURL ? toBase64URL : toBase64; Some indents in new and old Assembler::emit_operand() are off. In new Assembler::emit_operand() is better use } else { instead of 'return' in one branch. This is first time I see that XMM register can be used for index in address. Is it true? Can you point to Intel's document which describes it. What testing you did? Please, add tests to test/hotspot/jtreg/compiler/intrinsics/base64 (may be similar to sha or AES in compiler/codegen/aes) to make sure that all flags, intrinsic is used and it produces correct result. I know there is test/jdk/java/util/Base64/ tests but they may not trigger intrinsic usage. But you can use them as starting point for new tests. Thanks, Vladimir On 6/22/18 11:47 AM, Kamath, Smita wrote: > Hi Vladimir, > > I?d like to contribute an optimization for Base64 Encoding Algorithm > using AVX512 Instructions. This optimization shows 1.5x improvement on > x86_64 platform(SKL). > > Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8205528 > > Link to webrev: http://cr.openjdk.java.net/~vdeshpande/Base64/webrev.00/ > > For testing the implementation, I have run tests under > test/jdk/java/util/Base64/ and also ran > test/jdk/com/sun/jndi/ldap/Base64Test.java > > I have also run jtreg. > > Please review and let me know if you have any comments. > > Thanks and Regards, > > Smita > From fw at deneb.enyo.de Fri Jun 22 20:15:20 2018 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 22 Jun 2018 22:15:20 +0200 Subject: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions In-Reply-To: <6563F381B547594081EF9DE181D0791277AAD1EC@FMSMSX119.amr.corp.intel.com> (Smita Kamath's message of "Fri, 22 Jun 2018 18:47:42 +0000") References: <6563F381B547594081EF9DE181D0791277AAD1EC@FMSMSX119.amr.corp.intel.com> Message-ID: <87sh5e8tnr.fsf@mid.deneb.enyo.de> * Smita Kamath: > I'd like to contribute an optimization for Base64 Encoding Algorithm > using AVX512 Instructions. This optimization shows 1.5x improvement on > x86_64 platform(SKL). Does this code require a turbo license (or whatever the thing is called what causes other cores to clock down)? From igor.ignatyev at oracle.com Fri Jun 22 20:53:43 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 22 Jun 2018 13:53:43 -0700 Subject: RFR(XS) : 8177899 : Tests fail due to code cache exhaustion on machines with many cores Message-ID: <65D2D3EB-A637-41EA-8351-094BC26CE322@oracle.com> http://cr.openjdk.java.net/~iignatyev//8177899/webrev.00/index.html > 13 lines changed: 9 ins; 0 del; 4 mod; Hi all, could you please review this small patch which limits number of compiler threads in the tests which set code cache explicitly? webrev: http://cr.openjdk.java.net/~iignatyev//8177899/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8177899 testing: compiler/codecache tests Thanks, -- Igor From vladimir.kozlov at oracle.com Fri Jun 22 21:03:31 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Jun 2018 14:03:31 -0700 Subject: RFR(XS) : 8177899 : Tests fail due to code cache exhaustion on machines with many cores In-Reply-To: <65D2D3EB-A637-41EA-8351-094BC26CE322@oracle.com> References: <65D2D3EB-A637-41EA-8351-094BC26CE322@oracle.com> Message-ID: <786714ce-7616-7279-5529-19c9c9d951e3@oracle.com> Changes looks good. Should we also limit number of GC threads? There was recent fix which takes into account small available memory when creating Compiler threads: https://bugs.openjdk.java.net/browse/JDK-8198756 Thanks, Vladimir On 6/22/18 1:53 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8177899/webrev.00/index.html >> 13 lines changed: 9 ins; 0 del; 4 mod; > > Hi all, > > could you please review this small patch which limits number of compiler threads in the tests which set code cache explicitly? > > webrev: http://cr.openjdk.java.net/~iignatyev//8177899/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8177899 > testing: compiler/codecache tests > > Thanks, > -- Igor > From ekaterina.pavlova at oracle.com Fri Jun 22 21:16:34 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Fri, 22 Jun 2018 14:16:34 -0700 Subject: RFR(M): 8205207: Port Graal unit tests under jtreg In-Reply-To: <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com> References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com> <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com> Message-ID: <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com> Erik, Doug, thank you a lot for your reviews and advises. I fixed everything what Erik has pointed out, please see my answers inlined. As about moving more staff in 'updategraalinopenjdk' can we consider this as next step? I am not quite familiar with 'updategraalinopenjdk' and didn't contribute into Graal ws yet, so I will prefer to do this improvement/refactoring as part of separate JDK issue. New webrev is here: webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 testing: tested by building and running graal unit tests On 6/19/18 2:00 PM, Erik Joelsson wrote: > Hello, > > Please always include build-dev when reviewing build changes. > > In general this looks pretty good but there are some details that need fixing. > > (Aside from this particular review, I must state my reservation against all the special treatment graal is enjoying from a source and test layout and build perspective. My understanding here is that someone will have to regularly update the wrapper jtreg tests manually using the script. This in addition to having to implement this very convoluted redirection logic because the tests are in the wrong place. Wouldn't it make a lot more sense to put the complicated logic in the import procedure for graal source so that it would fit nicely into the OpenJDK source/build/test model, instead of adding more and more complicated workarounds in the OpenJDK build and test procedures?) > > On 2018-06-18 22:26, Ekaterina Pavlova wrote: >> Hi All, >> >> please review porting of Graal unit tests under jtreg. The main idea of this porting is to keep Graal unit tests as is >> (located in src/jdk.internal.vm.compiler/share/classes/*.test) and run them similar way they are run in Graal project. >> To achieve this test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java helper class has been written >> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to run specified set of Graal unit tests. The groups of >> Graal unit tests to run are defined in auto-generated test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests. >> >> New make/test/JtregGraalUnit.gmk is used to build Graal unit tests into jdk.vm.compiler.tests.jar and then install >> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/. >> > GRAALUNIT_LIB is never defined (in the open). Since this is used in open makefiles, we need an open configure option to set it. ok, I created open/make/autoconf/lib-tests.m4 and did put Graal related staff there. > To make things clearer, I would rename LIB_DIR to something like LIB_OUTPUTDIR to signal that this is a location to put files in, rather than read them from. ok, renamed > > FLATTEN has no effect in the SetupCopyFiles call since all the jar files found by wildcard can only be in one directory anyway. ok, removed > BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. Tests classes and jars should be built into $(SUPPORT_OUTPUTDIR)/test/..> Please create a suitable sub directory there for the output from this makefile. ok, introduced COMPILE_OUTPUTDIR := $(SUPPORT_OUTPUTDIR)/test/graalunit to be used to build graal unit test classes. > The all and test-image targets are never called so no need to declare them. > > There are some style issues too. (Please see http://openjdk.java.net/groups/build/doc/code-conventions.html for details.) > * 43 logic indent 2 spaces > * 52 we like to put the ending )) on a new line with ', \' at the end of the line before > * 58 continuation indent 4 spaces > * 88, 89 please break long lines > * 90 continuation indent 4 spaces > * 99 continuation indent 4 spaces > * 120 break before )) I think I fixed everything >> make/Main.gmk adds proper dependencies for build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal. >> > The target build-test-hotspot-jtreg-graal only needs to depend on exploded-image-optimize. fixed > The new graal specific targets should be guarded by INCLUDE_GRAAL in Main.gmk. Otherwise those targets will silently do nothing if invoked without graal. That means adding them to JVM_TEST_IMAGE_TARGETS needs to be conditional too. fixed >> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg knows where to find Graal tests and libs. >> > This needs to be duplicated for make/RunTest.gmk so that these tests work with "make run-test" as well. added thanks, -katya > /Erik >> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file defines "testName -> testPrefix [requiresStatement]" mapping >> which is used by test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to generate jtreg tests. >> >> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was ported from mx project without any changes. >> >> >> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 >> ?webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html >> testing: new tests were executed as part of automatic HS testing for several months. >> >> >> thanks, >> -katya >> >> p.s. >> ?Igor Ignatyev volunteered to sponsor this change. > From paul.sandoz at oracle.com Fri Jun 22 21:17:14 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 22 Jun 2018 14:17:14 -0700 Subject: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions In-Reply-To: References: <6563F381B547594081EF9DE181D0791277AAD1EC@FMSMSX119.amr.corp.intel.com> Message-ID: <13665270-28A9-498D-A5BC-0CCCE1402856@oracle.com> > On Jun 22, 2018, at 12:29 PM, Vladimir Kozlov wrote: > > Hi Smita, > > I CCing to Libs to review code changes in Base64.java. > > Looks like you changed all need place to implement intrinsic. > One question so: why you have own copy of base64 charsets and not using one in library: > > private int encode0(byte[] src, int off, int end, byte[] dst) { > char[] base64 = isURL ? toBase64URL : toBase64; > Yes, especially if we converted those from char[] to byte[] (which might also improve the C2 generated code) and pass the selected byte[] to the intrinsic. Naming wise for the Java methods here are some suggestions: generateImplEncode -> encodeBlockWithBoundsCheck implEncode -> encodeBlock Also can generateImplEncode be private? Further. is there is a need to perform bounds checks in generateImplEncode given the public methods calling encode will, i presume, have dominating checks? Paul. > Some indents in new and old Assembler::emit_operand() are off. > > In new Assembler::emit_operand() is better use } else { instead of 'return' in one branch. > > This is first time I see that XMM register can be used for index in address. Is it true? Can you point to Intel's document which describes it. > > What testing you did? > > Please, add tests to test/hotspot/jtreg/compiler/intrinsics/base64 (may be similar to sha or AES in compiler/codegen/aes) to make sure that all flags, intrinsic is used and it produces correct result. > > I know there is test/jdk/java/util/Base64/ tests but they may not trigger intrinsic usage. But you can use them as starting point for new tests. > > Thanks, > Vladimir > > On 6/22/18 11:47 AM, Kamath, Smita wrote: >> Hi Vladimir, >> I?d like to contribute an optimization for Base64 Encoding Algorithm using AVX512 Instructions. This optimization shows 1.5x improvement on x86_64 platform(SKL). >> Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8205528 >> Link to webrev: http://cr.openjdk.java.net/~vdeshpande/Base64/webrev.00/ >> For testing the implementation, I have run tests under test/jdk/java/util/Base64/ and also ran test/jdk/com/sun/jndi/ldap/Base64Test.java >> I have also run jtreg. >> Please review and let me know if you have any comments. >> Thanks and Regards, >> Smita From fweimer at redhat.com Fri Jun 22 21:22:51 2018 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 22 Jun 2018 23:22:51 +0200 Subject: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions In-Reply-To: <87sh5e8tnr.fsf@mid.deneb.enyo.de> References: <6563F381B547594081EF9DE181D0791277AAD1EC@FMSMSX119.amr.corp.intel.com> <87sh5e8tnr.fsf@mid.deneb.enyo.de> Message-ID: On 06/22/2018 10:15 PM, Florian Weimer wrote: > * Smita Kamath: > >> I'd like to contribute an optimization for Base64 Encoding Algorithm >> using AVX512 Instructions. This optimization shows 1.5x improvement on >> x86_64 platform(SKL). > > Does this code require a turbo license (or whatever the thing is > called what causes other cores to clock down)? I found a machine and a silly benchmark calling Encode::encode(byte[]) in a loop, and I get this before: 1.102951702 409,517,502 core_power_lvl1_turbo_license 1.102951702 0 core_power_lvl2_turbo_license 1.102951702 0 core_power_throttle 1.102951702 5,789,506,258 cycles 2.154409863 0 core_power_lvl1_turbo_license 2.154409863 0 core_power_lvl2_turbo_license 2.154409863 0 core_power_throttle 2.154409863 5,578,099,821 cycles 3.205880145 0 core_power_lvl1_turbo_license 3.205880145 0 core_power_lvl2_turbo_license 3.205880145 0 core_power_throttle 3.205880145 4,704,036,297 cycles 4.257820031 0 core_power_lvl1_turbo_license 4.257820031 0 core_power_lvl2_turbo_license 4.257820031 0 core_power_throttle 4.257820031 4,297,183,302 cycles 5.308664009 0 core_power_lvl1_turbo_license 5.308664009 0 core_power_lvl2_turbo_license 5.308664009 0 core_power_throttle 5.308664009 4,272,656,488 cycles 6.360519693 0 core_power_lvl1_turbo_license 6.360519693 0 core_power_lvl2_turbo_license 6.360519693 0 core_power_throttle 6.360519693 4,271,119,933 cycles 7.411707353 0 core_power_lvl1_turbo_license 7.411707353 0 core_power_lvl2_turbo_license 7.411707353 0 core_power_throttle 7.411707353 4,258,814,898 cycles 8.462806875 0 core_power_lvl1_turbo_license 8.462806875 0 core_power_lvl2_turbo_license 8.462806875 0 core_power_throttle 8.462806875 4,273,534,600 cycles 9.513850481 0 core_power_lvl1_turbo_license 9.513850481 0 core_power_lvl2_turbo_license 9.513850481 0 core_power_throttle 9.513850481 4,300,081,431 cycles 10.565774495 0 core_power_lvl1_turbo_license 10.565774495 0 core_power_lvl2_turbo_license 10.565774495 0 core_power_throttle 10.565774495 4,392,364,553 cycles and after: 1.101046948 2,304,232,482 core_power_lvl1_turbo_license 1.101046948 0 core_power_lvl2_turbo_license 1.101046948 147,688 core_power_throttle 1.101046948 4,577,482,611 cycles 2.151755765 7,278,927,100 core_power_lvl1_turbo_license 2.151755765 0 core_power_lvl2_turbo_license 2.151755765 42,228 core_power_throttle 2.151755765 4,120,536,502 cycles 3.201901416 7,208,954,425 core_power_lvl1_turbo_license 3.201901416 0 core_power_lvl2_turbo_license 3.201901416 67,576 core_power_throttle 3.201901416 5,418,392,188 cycles 4.252669983 7,285,847,565 core_power_lvl1_turbo_license 4.252669983 0 core_power_lvl2_turbo_license 4.252669983 41,600 core_power_throttle 4.252669983 5,199,576,369 cycles 5.304219300 7,277,640,225 core_power_lvl1_turbo_license 5.304219300 0 core_power_lvl2_turbo_license 5.304219300 45,834 core_power_throttle 5.304219300 4,145,273,167 cycles 6.352663275 7,292,924,536 core_power_lvl1_turbo_license 6.352663275 0 core_power_lvl2_turbo_license 6.352663275 44,310 core_power_throttle 6.352663275 10,615,605,184 cycles 7.403349636 7,243,993,590 core_power_lvl1_turbo_license 7.403349636 0 core_power_lvl2_turbo_license 7.403349636 84,554 core_power_throttle 7.403349636 4,135,245,407 cycles 8.453630335 7,275,471,168 core_power_lvl1_turbo_license 8.453630335 0 core_power_lvl2_turbo_license 8.453630335 43,434 core_power_throttle 8.453630335 5,548,353,295 cycles So the AVX-512 instructions used appear to be low-current ones. Still there is some impact, and for glibc, we tend to avoid using those instructions due to the overall system impact (we've been burnt by this before). Smita, is it possible to use low-current AVX-256 instructions instead for your optimization? Thanks, Florian From doug.simon at oracle.com Fri Jun 22 21:29:14 2018 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 22 Jun 2018 23:29:14 +0200 Subject: RFR(M): 8205207: Port Graal unit tests under jtreg In-Reply-To: <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com> References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com> <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com> <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com> Message-ID: > On 22 Jun 2018, at 23:16, Ekaterina Pavlova wrote: > > Erik, Doug, > > thank you a lot for your reviews and advises. > I fixed everything what Erik has pointed out, please see my answers inlined. > As about moving more staff in 'updategraalinopenjdk' can we consider this as next step? > I am not quite familiar with 'updategraalinopenjdk' and didn't contribute into Graal ws yet, > so I will prefer to do this improvement/refactoring as part of separate JDK issue. Sorry for not being clearer. I don't expect you to fix/enhance updategraalinopenjdk. I was simply commenting on a possible solution to Joel's reasonable request for having Graal sources and test layout more normalized in the JDK code base. -Doug From erik.joelsson at oracle.com Fri Jun 22 21:38:43 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 22 Jun 2018 14:38:43 -0700 Subject: RFR(M): 8205207: Port Graal unit tests under jtreg In-Reply-To: <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com> References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com> <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com> <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com> Message-ID: <5116257e-472d-13f5-f800-5e42d800934d@oracle.com> Hello Katya, This looks much better, thanks! A few suggestions still: Main.gmk: instead of repeating the assignment in both if and else block: ifeq ($(INCLUDE_GRAAL), true) ? JVM_TEST_IMAGE_TARGETS += test-image-hotspot-jtreg-graal endif I think it's fine to do that without the ?= because an alternative JVM implementation is unlikely to be using graal anyway. In JtregGraalUnit.gmk: Some minor style nits: 54: align )) with first eval line as you have done with the other eval calls 118: Since 117 is a one line parameter, please move comma to 117 133: Same as for 118 130-132: Please indent 4 spaces for continuation /Erik On 2018-06-22 14:16, Ekaterina Pavlova wrote: > Erik, Doug, > > thank you a lot for your reviews and advises. > I fixed everything what Erik has pointed out, please see my answers > inlined. > As about moving more staff in 'updategraalinopenjdk' can we consider > this as next step? > I am not quite familiar with 'updategraalinopenjdk' and didn't > contribute into Graal ws yet, > so I will prefer to do this improvement/refactoring as part of > separate JDK issue. > > New webrev is here: > ? webrev: > http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html > ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 > ?testing: tested by building and running graal unit tests > > > On 6/19/18 2:00 PM, Erik Joelsson wrote: >> Hello, >> >> Please always include build-dev when reviewing build changes. >> >> In general this looks pretty good but there are some details that >> need fixing. >> >> (Aside from this particular review, I must state my reservation >> against all the special treatment graal is enjoying from a source and >> test layout and build perspective. My understanding here is that >> someone will have to regularly update the wrapper jtreg tests >> manually using the script. This in addition to having to implement >> this very convoluted redirection logic because the tests are in the >> wrong place. Wouldn't it make a lot more sense to put the complicated >> logic in the import procedure for graal source so that it would fit >> nicely into the OpenJDK source/build/test model, instead of adding >> more and more complicated workarounds in the OpenJDK build and test >> procedures?) >> >> On 2018-06-18 22:26, Ekaterina Pavlova wrote: >>> Hi All, >>> >>> please review porting of Graal unit tests under jtreg. The main idea >>> of this porting is to keep Graal unit tests as is >>> (located in src/jdk.internal.vm.compiler/share/classes/*.test) and >>> run them similar way they are run in Graal project. >>> To achieve this >>> test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java >>> helper class has been written >>> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to run >>> specified set of Graal unit tests. The groups of >>> Graal unit tests to run are defined in auto-generated >>> test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests. >>> >>> New make/test/JtregGraalUnit.gmk is used to build Graal unit tests >>> into jdk.vm.compiler.tests.jar and then install >>> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/. >>> >> GRAALUNIT_LIB is never defined (in the open). Since this is used in >> open makefiles, we need an open configure option to set it. > > ok, I created open/make/autoconf/lib-tests.m4 and did put Graal > related staff there. > >> To make things clearer, I would rename LIB_DIR to something like >> LIB_OUTPUTDIR to signal that this is a location to put files in, >> rather than read them from. > > ok, renamed > >> >> FLATTEN has no effect in the SetupCopyFiles call since all the jar >> files found by wildcard can only be in one directory anyway. > > ok, removed > >> BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. Tests >> classes and jars should be built into $(SUPPORT_OUTPUTDIR)/test/..> >> Please create a suitable sub directory there for the output from this >> makefile. > > ok, introduced COMPILE_OUTPUTDIR := > $(SUPPORT_OUTPUTDIR)/test/graalunit to be used to build graal unit > test classes. > >> The all and test-image targets are never called so no need to declare >> them. >> >> There are some style issues too. (Please see >> http://openjdk.java.net/groups/build/doc/code-conventions.html for >> details.) >> * 43 logic indent 2 spaces >> * 52 we like to put the ending )) on a new line with ', \' at the end >> of the line before >> * 58 continuation indent 4 spaces >> * 88, 89 please break long lines >> * 90 continuation indent 4 spaces >> * 99 continuation indent 4 spaces >> * 120 break before )) > > I think I fixed everything > >>> make/Main.gmk adds proper dependencies for >>> build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal. >>> >> The target build-test-hotspot-jtreg-graal only needs to depend on >> exploded-image-optimize. > > fixed > >> The new graal specific targets should be guarded by INCLUDE_GRAAL in >> Main.gmk. Otherwise those targets will silently do nothing if invoked >> without graal. That means adding them to JVM_TEST_IMAGE_TARGETS needs >> to be conditional too. > > fixed > >>> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg >>> knows where to find Graal tests and libs. >>> >> This needs to be duplicated for make/RunTest.gmk so that these tests >> work with "make run-test" as well. > > added > > thanks, > -katya > >> /Erik >>> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file defines >>> "testName -> testPrefix [requiresStatement]" mapping >>> which is used by >>> test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to >>> generate jtreg tests. >>> >>> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was >>> ported from mx project without any changes. >>> >>> >>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 >>> ?webrev: >>> http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html >>> testing: new tests were executed as part of automatic HS testing for >>> several months. >>> >>> >>> thanks, >>> -katya >>> >>> p.s. >>> ?Igor Ignatyev volunteered to sponsor this change. >> > From smita.kamath at intel.com Fri Jun 22 21:49:56 2018 From: smita.kamath at intel.com (Kamath, Smita) Date: Fri, 22 Jun 2018 21:49:56 +0000 Subject: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions In-Reply-To: References: <6563F381B547594081EF9DE181D0791277AAD1EC@FMSMSX119.amr.corp.intel.com> Message-ID: <6563F381B547594081EF9DE181D0791277AAD2D4@FMSMSX119.amr.corp.intel.com> Hi Vladimir, Please see my answers to your questions as below: 1) One question so: why you have own copy of base64 charsets and not using one in library: I am using vpgatherdd instruction to fetch multiple values from base64 array in a single instruction with a vector index. Vpgatherdd instruction works on 32 bit array and so I need to define base64 charset in a 32 bit array. I have given reference to gather instruction below. 2) Some indents in new and old Assembler::emit_operand() are off. In new Assembler::emit_operand() is better use } else { instead of 'return' in one branch. I'll make the necessary changes and send an updated webrev. 3) This is first time I see that XMM register can be used for index in address. Is it true? Can you point to Intel's document which describes it. I am using vpgatherdd instruction which requires index vector with scale. It uses VSIB addressing where the index register is a zmm register. Please refer to reference manual, volume 2c, page 2211: https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf Also see, section 2.3.12, page 524 for VSIB memory addressing information. 4) Please, add tests to test/hotspot/jtreg/compiler/intrinsics/base64 (may be similar to sha or AES in compiler/codegen/aes) to make sure that all flags, intrinsic is used and it produces correct result. I will add test cases as per your suggestion. Please let me know if you have additional questions. Thanks, Smita -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Friday, June 22, 2018 12:29 PM To: Kamath, Smita Cc: hotspot compiler Subject: Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions Hi Smita, I CCing to Libs to review code changes in Base64.java. Looks like you changed all need place to implement intrinsic. One question so: why you have own copy of base64 charsets and not using one in library: private int encode0(byte[] src, int off, int end, byte[] dst) { char[] base64 = isURL ? toBase64URL : toBase64; Some indents in new and old Assembler::emit_operand() are off. In new Assembler::emit_operand() is better use } else { instead of 'return' in one branch. This is first time I see that XMM register can be used for index in address. Is it true? Can you point to Intel's document which describes it. What testing you did? Please, add tests to test/hotspot/jtreg/compiler/intrinsics/base64 (may be similar to sha or AES in compiler/codegen/aes) to make sure that all flags, intrinsic is used and it produces correct result. I know there is test/jdk/java/util/Base64/ tests but they may not trigger intrinsic usage. But you can use them as starting point for new tests. Thanks, Vladimir On 6/22/18 11:47 AM, Kamath, Smita wrote: > Hi Vladimir, > > I'd like to contribute an optimization for Base64 Encoding Algorithm > using AVX512 Instructions. This optimization shows 1.5x improvement on > x86_64 platform(SKL). > > Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8205528 > > Link to webrev: > http://cr.openjdk.java.net/~vdeshpande/Base64/webrev.00/ > > For testing the implementation, I have run tests under > test/jdk/java/util/Base64/ and also ran > test/jdk/com/sun/jndi/ldap/Base64Test.java > > I have also run jtreg. > > Please review and let me know if you have any comments. > > Thanks and Regards, > > Smita > From smita.kamath at intel.com Fri Jun 22 22:00:43 2018 From: smita.kamath at intel.com (Kamath, Smita) Date: Fri, 22 Jun 2018 22:00:43 +0000 Subject: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions In-Reply-To: <13665270-28A9-498D-A5BC-0CCCE1402856@oracle.com> References: <6563F381B547594081EF9DE181D0791277AAD1EC@FMSMSX119.amr.corp.intel.com> <13665270-28A9-498D-A5BC-0CCCE1402856@oracle.com> Message-ID: <6563F381B547594081EF9DE181D0791277AAD2F6@FMSMSX119.amr.corp.intel.com> Please see my answers inline in your email below. Thanks, Smita -----Original Message----- From: Paul Sandoz [mailto:paul.sandoz at oracle.com] Sent: Friday, June 22, 2018 2:17 PM To: Vladimir Kozlov Cc: Kamath, Smita ; hotspot compiler Subject: Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions > On Jun 22, 2018, at 12:29 PM, Vladimir Kozlov wrote: > > Hi Smita, > > I CCing to Libs to review code changes in Base64.java. > > Looks like you changed all need place to implement intrinsic. > One question so: why you have own copy of base64 charsets and not using one in library: > > private int encode0(byte[] src, int off, int end, byte[] dst) { > char[] base64 = isURL ? toBase64URL : toBase64; > Yes, especially if we converted those from char[] to byte[] (which might also improve the C2 generated code) and pass the selected byte[] to the intrinsic. Smita>> I need an integer array in order to use vpgatherdd instruction with vector index. Vpgather instruction works on 32 bit array and so I need to define base64 charset in a 32 bit array. Naming wise for the Java methods here are some suggestions: generateImplEncode -> encodeBlockWithBoundsCheck implEncode -> encodeBlock Also can generateImplEncode be private? Smita>> I'll make these changes and send an updated webrev. Further. is there is a need to perform bounds checks in generateImplEncode given the public methods calling encode will, i presume, have dominating checks? Smita>> The check is not required. I'll retain encodeBlock and remove encodeBlockWithBoundsCheck. Paul. > Some indents in new and old Assembler::emit_operand() are off. > > In new Assembler::emit_operand() is better use } else { instead of 'return' in one branch. > > This is first time I see that XMM register can be used for index in address. Is it true? Can you point to Intel's document which describes it. > > What testing you did? > > Please, add tests to test/hotspot/jtreg/compiler/intrinsics/base64 (may be similar to sha or AES in compiler/codegen/aes) to make sure that all flags, intrinsic is used and it produces correct result. > > I know there is test/jdk/java/util/Base64/ tests but they may not trigger intrinsic usage. But you can use them as starting point for new tests. > > Thanks, > Vladimir > > On 6/22/18 11:47 AM, Kamath, Smita wrote: >> Hi Vladimir, >> I?d like to contribute an optimization for Base64 Encoding Algorithm using AVX512 Instructions. This optimization shows 1.5x improvement on x86_64 platform(SKL). >> Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8205528 >> Link to webrev: http://cr.openjdk.java.net/~vdeshpande/Base64/webrev.00/ >> For testing the implementation, I have run tests under test/jdk/java/util/Base64/ and also ran test/jdk/com/sun/jndi/ldap/Base64Test.java >> I have also run jtreg. >> Please review and let me know if you have any comments. >> Thanks and Regards, >> Smita From vladimir.kozlov at oracle.com Fri Jun 22 22:04:27 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Jun 2018 15:04:27 -0700 Subject: [11] RFR(S) 8205400: [Graal] compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java fails with can't be enqueued for compilation on level 4 Message-ID: http://cr.openjdk.java.net/~kvn/8205400/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8205400 I was not able to reproduce the problem. I did 170 runs of the test with Graal in mach5. I can only speculate what happen. By default JVMCI and Graal are initialized only on first tier4 compilation request. Usually there are hot methods which trigger such compilation and initialization before the test requests compilation. It is still possible that test's compilation request is the first. The test asks blocking (BackgroundCompilation = false) compilation to wait when it complete [1]. But JVMCI code will unblock first compilation when JVMCI and Graal are not initialized yet [2]. As result execution continue before Graal's compilation finished (or even started) and WB::compile_method() will return NULL value. To trigger eager JVMCI and Graal initialization flag -XX:+EagerJVMCI or -Xbatch (-XX:-BackgroundCompilation) should be used to run test. And 2 of jvmci/compilerToVM/ tests which use the same WB compilation API are using -XX:-BackgroundCompilation. I am suggesting to do the same in 2 other tests. To find if this is really what happen I added error prints in WhiteBox::compile_method() which have several cases when it can return false. Tested with tier1,tier2,tier3-graal,precheckin-comp [1] http://hg.openjdk.java.net/jdk/jdk/file/d91a64467683/test/hotspot/jtreg/compiler/jvmci/compilerToVM/CompileCodeTestCase.java#l108 [2] http://hg.openjdk.java.net/jdk/jdk/file/d91a64467683/src/hotspot/share/compiler/compileBroker.cpp#l1082 -- Thanks, Vladimir From doug.simon at oracle.com Fri Jun 22 22:07:13 2018 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 23 Jun 2018 00:07:13 +0200 Subject: RFR(M): 8205207: Port Graal unit tests under jtreg In-Reply-To: References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com> <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com> <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com> Message-ID: <7CFCE7E6-DA8A-4B3C-8743-5A895B948DBB@oracle.com> > On 22 Jun 2018, at 23:29, Doug Simon wrote: > > > >> On 22 Jun 2018, at 23:16, Ekaterina Pavlova wrote: >> >> Erik, Doug, >> >> thank you a lot for your reviews and advises. >> I fixed everything what Erik has pointed out, please see my answers inlined. >> As about moving more staff in 'updategraalinopenjdk' can we consider this as next step? >> I am not quite familiar with 'updategraalinopenjdk' and didn't contribute into Graal ws yet, >> so I will prefer to do this improvement/refactoring as part of separate JDK issue. > > Sorry for not being clearer. I don't expect you to fix/enhance updategraalinopenjdk. I was simply commenting on a possible solution to Joel's reasonable request for having Graal sources and test layout more normalized in the JDK code base. Of course I meant Erik's request ;-) -Doug From ekaterina.pavlova at oracle.com Fri Jun 22 22:08:06 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Fri, 22 Jun 2018 15:08:06 -0700 Subject: RFR(M): 8205207: Port Graal unit tests under jtreg In-Reply-To: References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com> <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com> <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com> Message-ID: On 6/22/18 2:29 PM, Doug Simon wrote: > > >> On 22 Jun 2018, at 23:16, Ekaterina Pavlova wrote: >> >> Erik, Doug, >> >> thank you a lot for your reviews and advises. >> I fixed everything what Erik has pointed out, please see my answers inlined. >> As about moving more staff in 'updategraalinopenjdk' can we consider this as next step? >> I am not quite familiar with 'updategraalinopenjdk' and didn't contribute into Graal ws yet, >> so I will prefer to do this improvement/refactoring as part of separate JDK issue. > > Sorry for not being clearer. I don't expect you to fix/enhance updategraalinopenjdk. I was simply commenting on a possible solution to Joel's reasonabl> request for having Graal sources and test layout more normalized in the JDK code base. ok, good :) -katya From paul.sandoz at oracle.com Fri Jun 22 22:18:20 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 22 Jun 2018 15:18:20 -0700 Subject: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions In-Reply-To: <6563F381B547594081EF9DE181D0791277AAD2F6@FMSMSX119.amr.corp.intel.com> References: <6563F381B547594081EF9DE181D0791277AAD1EC@FMSMSX119.amr.corp.intel.com> <13665270-28A9-498D-A5BC-0CCCE1402856@oracle.com> <6563F381B547594081EF9DE181D0791277AAD2F6@FMSMSX119.amr.corp.intel.com> Message-ID: <71BBF912-081E-4385-8940-B8FE802F6699@oracle.com> > On Jun 22, 2018, at 3:00 PM, Kamath, Smita wrote: >> Looks like you changed all need place to implement intrinsic. >> One question so: why you have own copy of base64 charsets and not using one in library: >> >> private int encode0(byte[] src, int off, int end, byte[] dst) { >> char[] base64 = isURL ? toBase64URL : toBase64; >> > > Yes, especially if we converted those from char[] to byte[] (which might also improve the C2 generated code) and pass the selected byte[] to the intrinsic. > Smita>> I need an integer array in order to use vpgatherdd instruction with vector index. Vpgather instruction works on 32 bit array and so I need to define base64 charset in a 32 bit array. > Thanks, I also saw your reply to Vladimir and see why you need this [*]. We could still unify leveraging a Java int[] array at the expense of extra space required on non-intrisified platforms. IMHO the less stub code and the more Java code the better with regards to maintenance. > Naming wise for the Java methods here are some suggestions: > > generateImplEncode -> encodeBlockWithBoundsCheck > implEncode -> encodeBlock > > Also can generateImplEncode be private? > Smita>> I'll make these changes and send an updated webrev. > Ok. > Further. is there is a need to perform bounds checks in generateImplEncode given the public methods calling encode will, i presume, have dominating checks? > Smita>> The check is not required. I'll retain encodeBlock and remove encodeBlockWithBoundsCheck. > Ok. Thanks, Paul. [*] On AVX-512 it's tempting to explore permute/rearrange operations on bytes, if there are any such instructions, since the translation array of bytes (toBase64URL or toBase64) fits neatly into one z register, or for AVX-2 in two y registers if some masked variant, based on ranges, is possible. From smita.kamath at intel.com Fri Jun 22 22:19:08 2018 From: smita.kamath at intel.com (Kamath, Smita) Date: Fri, 22 Jun 2018 22:19:08 +0000 Subject: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions In-Reply-To: References: <6563F381B547594081EF9DE181D0791277AAD1EC@FMSMSX119.amr.corp.intel.com> <87sh5e8tnr.fsf@mid.deneb.enyo.de> Message-ID: <6563F381B547594081EF9DE181D0791277AAD335@FMSMSX119.amr.corp.intel.com> Hi Florian, Thanks a lot for your inputs. Yes, the AVX512 loop will run at lower frequency. We still see 1.5x performance gain as multiple operations are happening per clock. I cannot use AVX256 because the algorithm is needing some instructions which are only supported in AVX512, for example, vpsrlvw and vpsllvw. Also, reducing the vector length to half may not show any gain. We are seeing 50% gain with AVX512 currently. Regards, Smita -----Original Message----- From: Florian Weimer [mailto:fweimer at redhat.com] Sent: Friday, June 22, 2018 2:23 PM To: Kamath, Smita Cc: Vladimir Kozlov ; hotspot compiler Subject: Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions On 06/22/2018 10:15 PM, Florian Weimer wrote: > * Smita Kamath: > >> I'd like to contribute an optimization for Base64 Encoding Algorithm >> using AVX512 Instructions. This optimization shows 1.5x improvement >> on >> x86_64 platform(SKL). > > Does this code require a turbo license (or whatever the thing is > called what causes other cores to clock down)? I found a machine and a silly benchmark calling Encode::encode(byte[]) in a loop, and I get this before: 1.102951702 409,517,502 core_power_lvl1_turbo_license 1.102951702 0 core_power_lvl2_turbo_license 1.102951702 0 core_power_throttle 1.102951702 5,789,506,258 cycles 2.154409863 0 core_power_lvl1_turbo_license 2.154409863 0 core_power_lvl2_turbo_license 2.154409863 0 core_power_throttle 2.154409863 5,578,099,821 cycles 3.205880145 0 core_power_lvl1_turbo_license 3.205880145 0 core_power_lvl2_turbo_license 3.205880145 0 core_power_throttle 3.205880145 4,704,036,297 cycles 4.257820031 0 core_power_lvl1_turbo_license 4.257820031 0 core_power_lvl2_turbo_license 4.257820031 0 core_power_throttle 4.257820031 4,297,183,302 cycles 5.308664009 0 core_power_lvl1_turbo_license 5.308664009 0 core_power_lvl2_turbo_license 5.308664009 0 core_power_throttle 5.308664009 4,272,656,488 cycles 6.360519693 0 core_power_lvl1_turbo_license 6.360519693 0 core_power_lvl2_turbo_license 6.360519693 0 core_power_throttle 6.360519693 4,271,119,933 cycles 7.411707353 0 core_power_lvl1_turbo_license 7.411707353 0 core_power_lvl2_turbo_license 7.411707353 0 core_power_throttle 7.411707353 4,258,814,898 cycles 8.462806875 0 core_power_lvl1_turbo_license 8.462806875 0 core_power_lvl2_turbo_license 8.462806875 0 core_power_throttle 8.462806875 4,273,534,600 cycles 9.513850481 0 core_power_lvl1_turbo_license 9.513850481 0 core_power_lvl2_turbo_license 9.513850481 0 core_power_throttle 9.513850481 4,300,081,431 cycles 10.565774495 0 core_power_lvl1_turbo_license 10.565774495 0 core_power_lvl2_turbo_license 10.565774495 0 core_power_throttle 10.565774495 4,392,364,553 cycles and after: 1.101046948 2,304,232,482 core_power_lvl1_turbo_license 1.101046948 0 core_power_lvl2_turbo_license 1.101046948 147,688 core_power_throttle 1.101046948 4,577,482,611 cycles 2.151755765 7,278,927,100 core_power_lvl1_turbo_license 2.151755765 0 core_power_lvl2_turbo_license 2.151755765 42,228 core_power_throttle 2.151755765 4,120,536,502 cycles 3.201901416 7,208,954,425 core_power_lvl1_turbo_license 3.201901416 0 core_power_lvl2_turbo_license 3.201901416 67,576 core_power_throttle 3.201901416 5,418,392,188 cycles 4.252669983 7,285,847,565 core_power_lvl1_turbo_license 4.252669983 0 core_power_lvl2_turbo_license 4.252669983 41,600 core_power_throttle 4.252669983 5,199,576,369 cycles 5.304219300 7,277,640,225 core_power_lvl1_turbo_license 5.304219300 0 core_power_lvl2_turbo_license 5.304219300 45,834 core_power_throttle 5.304219300 4,145,273,167 cycles 6.352663275 7,292,924,536 core_power_lvl1_turbo_license 6.352663275 0 core_power_lvl2_turbo_license 6.352663275 44,310 core_power_throttle 6.352663275 10,615,605,184 cycles 7.403349636 7,243,993,590 core_power_lvl1_turbo_license 7.403349636 0 core_power_lvl2_turbo_license 7.403349636 84,554 core_power_throttle 7.403349636 4,135,245,407 cycles 8.453630335 7,275,471,168 core_power_lvl1_turbo_license 8.453630335 0 core_power_lvl2_turbo_license 8.453630335 43,434 core_power_throttle 8.453630335 5,548,353,295 cycles So the AVX-512 instructions used appear to be low-current ones. Still there is some impact, and for glibc, we tend to avoid using those instructions due to the overall system impact (we've been burnt by this before). Smita, is it possible to use low-current AVX-256 instructions instead for your optimization? Thanks, Florian From ekaterina.pavlova at oracle.com Fri Jun 22 22:22:16 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Fri, 22 Jun 2018 15:22:16 -0700 Subject: RFR(M): 8205207: Port Graal unit tests under jtreg In-Reply-To: <5116257e-472d-13f5-f800-5e42d800934d@oracle.com> References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com> <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com> <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com> <5116257e-472d-13f5-f800-5e42d800934d@oracle.com> Message-ID: Fixed and regenerated webrev at the same location: http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html Erik, thanks again for your detailed reviews! -katya On 6/22/18 2:38 PM, Erik Joelsson wrote: > Hello Katya, > > This looks much better, thanks! > > A few suggestions still: > > Main.gmk: instead of repeating the assignment in both if and else block: > > ifeq ($(INCLUDE_GRAAL), true) > ? JVM_TEST_IMAGE_TARGETS += test-image-hotspot-jtreg-graal > endif > > I think it's fine to do that without the ?= because an alternative JVM implementation is unlikely to be using graal anyway. > > In JtregGraalUnit.gmk: Some minor style nits: > 54: align )) with first eval line as you have done with the other eval calls > 118: Since 117 is a one line parameter, please move comma to 117 > 133: Same as for 118 > 130-132: Please indent 4 spaces for continuation > > /Erik > > On 2018-06-22 14:16, Ekaterina Pavlova wrote: >> Erik, Doug, >> >> thank you a lot for your reviews and advises. >> I fixed everything what Erik has pointed out, please see my answers inlined. >> As about moving more staff in 'updategraalinopenjdk' can we consider this as next step? >> I am not quite familiar with 'updategraalinopenjdk' and didn't contribute into Graal ws yet, >> so I will prefer to do this improvement/refactoring as part of separate JDK issue. >> >> New webrev is here: >> ? webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html >> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 >> ?testing: tested by building and running graal unit tests >> >> >> On 6/19/18 2:00 PM, Erik Joelsson wrote: >>> Hello, >>> >>> Please always include build-dev when reviewing build changes. >>> >>> In general this looks pretty good but there are some details that need fixing. >>> >>> (Aside from this particular review, I must state my reservation against all the special treatment graal is enjoying from a source and test layout and build perspective. My understanding here is that someone will have to regularly update the wrapper jtreg tests manually using the script. This in addition to having to implement this very convoluted redirection logic because the tests are in the wrong place. Wouldn't it make a lot more sense to put the complicated logic in the import procedure for graal source so that it would fit nicely into the OpenJDK source/build/test model, instead of adding more and more complicated workarounds in the OpenJDK build and test procedures?) >>> >>> On 2018-06-18 22:26, Ekaterina Pavlova wrote: >>>> Hi All, >>>> >>>> please review porting of Graal unit tests under jtreg. The main idea of this porting is to keep Graal unit tests as is >>>> (located in src/jdk.internal.vm.compiler/share/classes/*.test) and run them similar way they are run in Graal project. >>>> To achieve this test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java helper class has been written >>>> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to run specified set of Graal unit tests. The groups of >>>> Graal unit tests to run are defined in auto-generated test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests. >>>> >>>> New make/test/JtregGraalUnit.gmk is used to build Graal unit tests into jdk.vm.compiler.tests.jar and then install >>>> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/. >>>> >>> GRAALUNIT_LIB is never defined (in the open). Since this is used in open makefiles, we need an open configure option to set it. >> >> ok, I created open/make/autoconf/lib-tests.m4 and did put Graal related staff there. >> >>> To make things clearer, I would rename LIB_DIR to something like LIB_OUTPUTDIR to signal that this is a location to put files in, rather than read them from. >> >> ok, renamed >> >>> >>> FLATTEN has no effect in the SetupCopyFiles call since all the jar files found by wildcard can only be in one directory anyway. >> >> ok, removed >> >>> BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. Tests classes and jars should be built into $(SUPPORT_OUTPUTDIR)/test/..> Please create a suitable sub directory there for the output from this makefile. >> >> ok, introduced COMPILE_OUTPUTDIR := $(SUPPORT_OUTPUTDIR)/test/graalunit to be used to build graal unit test classes. >> >>> The all and test-image targets are never called so no need to declare them. >>> >>> There are some style issues too. (Please see http://openjdk.java.net/groups/build/doc/code-conventions.html for details.) >>> * 43 logic indent 2 spaces >>> * 52 we like to put the ending )) on a new line with ', \' at the end of the line before >>> * 58 continuation indent 4 spaces >>> * 88, 89 please break long lines >>> * 90 continuation indent 4 spaces >>> * 99 continuation indent 4 spaces >>> * 120 break before )) >> >> I think I fixed everything >> >>>> make/Main.gmk adds proper dependencies for build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal. >>>> >>> The target build-test-hotspot-jtreg-graal only needs to depend on exploded-image-optimize. >> >> fixed >> >>> The new graal specific targets should be guarded by INCLUDE_GRAAL in Main.gmk. Otherwise those targets will silently do nothing if invoked without graal. That means adding them to JVM_TEST_IMAGE_TARGETS needs to be conditional too. >> >> fixed >> >>>> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg knows where to find Graal tests and libs. >>>> >>> This needs to be duplicated for make/RunTest.gmk so that these tests work with "make run-test" as well. >> >> added >> >> thanks, >> -katya >> >>> /Erik >>>> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file defines "testName -> testPrefix [requiresStatement]" mapping >>>> which is used by test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to generate jtreg tests. >>>> >>>> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was ported from mx project without any changes. >>>> >>>> >>>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 >>>> ?webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html >>>> testing: new tests were executed as part of automatic HS testing for several months. >>>> >>>> >>>> thanks, >>>> -katya >>>> >>>> p.s. >>>> ?Igor Ignatyev volunteered to sponsor this change. >>> >> > From igor.ignatyev at oracle.com Fri Jun 22 22:23:23 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 22 Jun 2018 15:23:23 -0700 Subject: RFR(XS) : 8177899 : Tests fail due to code cache exhaustion on machines with many cores In-Reply-To: <786714ce-7616-7279-5529-19c9c9d951e3@oracle.com> References: <65D2D3EB-A637-41EA-8351-094BC26CE322@oracle.com> <786714ce-7616-7279-5529-19c9c9d951e3@oracle.com> Message-ID: <5A2D03AB-7FF8-40EB-94DF-A2AF49945679@oracle.com> > On Jun 22, 2018, at 2:03 PM, Vladimir Kozlov wrote: > > Changes looks good. > > Should we also limit number of GC threads? we don't have to. > > There was recent fix which takes into account small available memory when creating Compiler threads: > > https://bugs.openjdk.java.net/browse/JDK-8198756 it seems w/ 8198756 8177899 isn't an issue anymore, the tests are passing w/o this patch on the hosts where they failed before, so I'm withdrawing this RFR and closing 8177899. -- Igor > > Thanks, > Vladimir > > On 6/22/18 1:53 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8177899/webrev.00/index.html >>> 13 lines changed: 9 ins; 0 del; 4 mod; >> Hi all, >> could you please review this small patch which limits number of compiler threads in the tests which set code cache explicitly? >> webrev: http://cr.openjdk.java.net/~iignatyev//8177899/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8177899 >> testing: compiler/codecache tests >> Thanks, >> -- Igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From smita.kamath at intel.com Fri Jun 22 22:25:35 2018 From: smita.kamath at intel.com (Kamath, Smita) Date: Fri, 22 Jun 2018 22:25:35 +0000 Subject: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions In-Reply-To: <71BBF912-081E-4385-8940-B8FE802F6699@oracle.com> References: <6563F381B547594081EF9DE181D0791277AAD1EC@FMSMSX119.amr.corp.intel.com> <13665270-28A9-498D-A5BC-0CCCE1402856@oracle.com> <6563F381B547594081EF9DE181D0791277AAD2F6@FMSMSX119.amr.corp.intel.com> <71BBF912-081E-4385-8940-B8FE802F6699@oracle.com> Message-ID: <6563F381B547594081EF9DE181D0791277AAD356@FMSMSX119.amr.corp.intel.com> Hi Paul, I can change the Java arrays(toBase64URL and toBase64) to int[] and use them in the intrinsic if it is acceptable. Please let me know. Thanks, Smita -----Original Message----- From: Paul Sandoz [mailto:paul.sandoz at oracle.com] Sent: Friday, June 22, 2018 3:18 PM To: Kamath, Smita Cc: Vladimir Kozlov ; hotspot compiler Subject: Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions > On Jun 22, 2018, at 3:00 PM, Kamath, Smita wrote: >> Looks like you changed all need place to implement intrinsic. >> One question so: why you have own copy of base64 charsets and not using one in library: >> >> private int encode0(byte[] src, int off, int end, byte[] dst) { >> char[] base64 = isURL ? toBase64URL : toBase64; >> > > Yes, especially if we converted those from char[] to byte[] (which might also improve the C2 generated code) and pass the selected byte[] to the intrinsic. > Smita>> I need an integer array in order to use vpgatherdd instruction with vector index. Vpgather instruction works on 32 bit array and so I need to define base64 charset in a 32 bit array. > Thanks, I also saw your reply to Vladimir and see why you need this [*]. We could still unify leveraging a Java int[] array at the expense of extra space required on non-intrisified platforms. IMHO the less stub code and the more Java code the better with regards to maintenance. > Naming wise for the Java methods here are some suggestions: > > generateImplEncode -> encodeBlockWithBoundsCheck implEncode -> > encodeBlock > > Also can generateImplEncode be private? > Smita>> I'll make these changes and send an updated webrev. > Ok. > Further. is there is a need to perform bounds checks in generateImplEncode given the public methods calling encode will, i presume, have dominating checks? > Smita>> The check is not required. I'll retain encodeBlock and remove encodeBlockWithBoundsCheck. > Ok. Thanks, Paul. [*] On AVX-512 it's tempting to explore permute/rearrange operations on bytes, if there are any such instructions, since the translation array of bytes (toBase64URL or toBase64) fits neatly into one z register, or for AVX-2 in two y registers if some masked variant, based on ranges, is possible. From igor.veresov at oracle.com Fri Jun 22 22:53:35 2018 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 22 Jun 2018 15:53:35 -0700 Subject: RFR(S) 8204209: [Graal] Compilation fails during nmethod printing with "assert(bci == 0 || 0 <= bci && bci < code_size()) failed: illegal bci" In-Reply-To: <33a534f2-1d57-46c2-cd82-9ef0d91534f0@oracle.com> References: <489e17d8-c87e-2b78-37af-aee874821b04@oracle.com> <33a534f2-1d57-46c2-cd82-9ef0d91534f0@oracle.com> Message-ID: <90E66242-0CBE-4F9B-84BF-649578D76187@oracle.com> Thanks, Tom! igor > On Jun 22, 2018, at 11:20 AM, Tom Rodriguez wrote: > > I think this looks good. We can correct the numbering next time we break binary compatibility. > > tom > > Igor Veresov wrote on 6/21/18 9:33 PM: >> After discussing this with Tom, we decided that it would be a bad idea to change values of final static fields as this would break compatibility (since javac inlines these values). So, for now, we?d have to do re-mapping. >> Webrev: http://cr.openjdk.java.net/~iveresov/8204209/webrev.01 >> Thanks, >> igor >>> On Jun 18, 2018, at 10:12 PM, Vladimir Kozlov > wrote: >>> >>> CCing to runtime group. >>> >>> Seems fine to me. >>> >>> Thanks, >>> Vladimir >>> >>> On 6/18/18 6:28 PM, Igor Veresov wrote: >>>> Make hotspot tolerate negative placeholder BCIs that are produced by Graal. >>>> Should this fix be deemed acceptable I?ll backport it to graal-jvmci-8. >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8204209 >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8204209/webrev/ >>>> Thanks, >>>> igor From paul.sandoz at oracle.com Fri Jun 22 22:58:47 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 22 Jun 2018 15:58:47 -0700 Subject: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions In-Reply-To: <6563F381B547594081EF9DE181D0791277AAD356@FMSMSX119.amr.corp.intel.com> References: <6563F381B547594081EF9DE181D0791277AAD1EC@FMSMSX119.amr.corp.intel.com> <13665270-28A9-498D-A5BC-0CCCE1402856@oracle.com> <6563F381B547594081EF9DE181D0791277AAD2F6@FMSMSX119.amr.corp.intel.com> <71BBF912-081E-4385-8940-B8FE802F6699@oracle.com> <6563F381B547594081EF9DE181D0791277AAD356@FMSMSX119.amr.corp.intel.com> Message-ID: Hi Smita, I am ok with it if Vladimir is :-) One slight concern is this may be biasing towards the x86 implementation of the intrinsic. I dunno if an int[] table is as useful for an AARCH64 intrinsic. Paul. > On Jun 22, 2018, at 3:25 PM, Kamath, Smita wrote: > > Hi Paul, > > I can change the Java arrays(toBase64URL and toBase64) to int[] and use them in the intrinsic if it is acceptable. Please let me know. > > Thanks, > Smita > > -----Original Message----- > From: Paul Sandoz [mailto:paul.sandoz at oracle.com] > Sent: Friday, June 22, 2018 3:18 PM > To: Kamath, Smita > Cc: Vladimir Kozlov ; hotspot compiler > Subject: Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions > > > >> On Jun 22, 2018, at 3:00 PM, Kamath, Smita wrote: >>> Looks like you changed all need place to implement intrinsic. >>> One question so: why you have own copy of base64 charsets and not using one in library: >>> >>> private int encode0(byte[] src, int off, int end, byte[] dst) { >>> char[] base64 = isURL ? toBase64URL : toBase64; >>> >> >> Yes, especially if we converted those from char[] to byte[] (which might also improve the C2 generated code) and pass the selected byte[] to the intrinsic. >> Smita>> I need an integer array in order to use vpgatherdd instruction with vector index. Vpgather instruction works on 32 bit array and so I need to define base64 charset in a 32 bit array. >> > > Thanks, I also saw your reply to Vladimir and see why you need this [*]. We could still unify leveraging a Java int[] array at the expense of extra space required on non-intrisified platforms. IMHO the less stub code and the more Java code the better with regards to maintenance. > > >> Naming wise for the Java methods here are some suggestions: >> >> generateImplEncode -> encodeBlockWithBoundsCheck implEncode -> >> encodeBlock >> >> Also can generateImplEncode be private? >> Smita>> I'll make these changes and send an updated webrev. >> > > Ok. > > >> Further. is there is a need to perform bounds checks in generateImplEncode given the public methods calling encode will, i presume, have dominating checks? >> Smita>> The check is not required. I'll retain encodeBlock and remove encodeBlockWithBoundsCheck. >> > > Ok. > > Thanks, > Paul. > > [*] On AVX-512 it's tempting to explore permute/rearrange operations on bytes, if there are any such instructions, since the translation array of bytes (toBase64URL or toBase64) fits neatly into one z register, or for AVX-2 in two y registers if some masked variant, based on ranges, is possible. From vladimir.kozlov at oracle.com Fri Jun 22 23:55:39 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Jun 2018 16:55:39 -0700 Subject: RFR(XS) : 8177899 : Tests fail due to code cache exhaustion on machines with many cores In-Reply-To: <5A2D03AB-7FF8-40EB-94DF-A2AF49945679@oracle.com> References: <65D2D3EB-A637-41EA-8351-094BC26CE322@oracle.com> <786714ce-7616-7279-5529-19c9c9d951e3@oracle.com> <5A2D03AB-7FF8-40EB-94DF-A2AF49945679@oracle.com> Message-ID: <381ea546-0412-dfe1-e9c7-16148370fe84@oracle.com> On 6/22/18 3:23 PM, Igor Ignatyev wrote: > >> On Jun 22, 2018, at 2:03 PM, Vladimir Kozlov >> > wrote: >> >> Changes looks good. >> >> Should we also limit number of GC threads? > we don't have to. >> >> There was recent fix which takes into account small available memory >> when creating Compiler threads: >> >> https://bugs.openjdk.java.net/browse/JDK-8198756 > it seems w/ 8198756 > 8177899 isn't an issue anymore, the tests are passing w/o this patch on > the hosts where they failed before, so I'm withdrawing this RFR and > closing 8177899. Good. Thanks, Vladimir > > -- Igor >> >> Thanks, >> Vladimir >> >> On 6/22/18 1:53 PM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8177899/webrev.00/index.html >>>> 13 lines changed: 9 ins; 0 del; 4 mod; >>> Hi all, >>> could you please review this small patch which limits number of >>> compiler threads in the tests which set code cache explicitly? >>> webrev: >>> http://cr.openjdk.java.net/~iignatyev//8177899/webrev.00/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8177899 >>> testing: compiler/codecache tests >>> Thanks, >>> -- Igor > From vladimir.kozlov at oracle.com Sat Jun 23 00:17:56 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Jun 2018 17:17:56 -0700 Subject: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions In-Reply-To: References: <6563F381B547594081EF9DE181D0791277AAD1EC@FMSMSX119.amr.corp.intel.com> <13665270-28A9-498D-A5BC-0CCCE1402856@oracle.com> <6563F381B547594081EF9DE181D0791277AAD2F6@FMSMSX119.amr.corp.intel.com> <71BBF912-081E-4385-8940-B8FE802F6699@oracle.com> <6563F381B547594081EF9DE181D0791277AAD356@FMSMSX119.amr.corp.intel.com> Message-ID: <3fc63a04-984b-d101-c5ac-a811f285d35c@oracle.com> On 6/22/18 3:58 PM, Paul Sandoz wrote: > Hi Smita, > > I am ok with it if Vladimir is :-) One slight concern is this may be biasing towards the x86 implementation of the intrinsic. Looking on code and it will be a lot of changes in Base64.java. I am concern about that late in JDK 11. I think we should keep duplicated code for x86 intrinsic as Smita suggested. And we can return to this when/if we intrinsify Decoder too. > I dunno if an int[] table is as useful for an AARCH64 intrinsic. We should ask RH to check. But I think SPARC is better operating on 32-bit values than 16-bit (at least it was issue before). Vladimir > > Paul. > >> On Jun 22, 2018, at 3:25 PM, Kamath, Smita wrote: >> >> Hi Paul, >> >> I can change the Java arrays(toBase64URL and toBase64) to int[] and use them in the intrinsic if it is acceptable. Please let me know. >> >> Thanks, >> Smita >> >> -----Original Message----- >> From: Paul Sandoz [mailto:paul.sandoz at oracle.com] >> Sent: Friday, June 22, 2018 3:18 PM >> To: Kamath, Smita >> Cc: Vladimir Kozlov ; hotspot compiler >> Subject: Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions >> >> >> >>> On Jun 22, 2018, at 3:00 PM, Kamath, Smita wrote: >>>> Looks like you changed all need place to implement intrinsic. >>>> One question so: why you have own copy of base64 charsets and not using one in library: >>>> >>>> private int encode0(byte[] src, int off, int end, byte[] dst) { >>>> char[] base64 = isURL ? toBase64URL : toBase64; >>>> >>> >>> Yes, especially if we converted those from char[] to byte[] (which might also improve the C2 generated code) and pass the selected byte[] to the intrinsic. >>> Smita>> I need an integer array in order to use vpgatherdd instruction with vector index. Vpgather instruction works on 32 bit array and so I need to define base64 charset in a 32 bit array. >>> >> >> Thanks, I also saw your reply to Vladimir and see why you need this [*]. We could still unify leveraging a Java int[] array at the expense of extra space required on non-intrisified platforms. IMHO the less stub code and the more Java code the better with regards to maintenance. >> >> >>> Naming wise for the Java methods here are some suggestions: >>> >>> generateImplEncode -> encodeBlockWithBoundsCheck implEncode -> >>> encodeBlock >>> >>> Also can generateImplEncode be private? >>> Smita>> I'll make these changes and send an updated webrev. >>> >> >> Ok. >> >> >>> Further. is there is a need to perform bounds checks in generateImplEncode given the public methods calling encode will, i presume, have dominating checks? >>> Smita>> The check is not required. I'll retain encodeBlock and remove encodeBlockWithBoundsCheck. >>> >> >> Ok. >> >> Thanks, >> Paul. >> >> [*] On AVX-512 it's tempting to explore permute/rearrange operations on bytes, if there are any such instructions, since the translation array of bytes (toBase64URL or toBase64) fits neatly into one z register, or for AVX-2 in two y registers if some masked variant, based on ranges, is possible. > From Derek.White at cavium.com Mon Jun 25 03:39:26 2018 From: Derek.White at cavium.com (White, Derek) Date: Mon, 25 Jun 2018 03:39:26 +0000 Subject: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math intrinsics usage in interpreter and C1 In-Reply-To: References: <6bd4bccb-befb-0523-d75e-2c5a99c4ee34@bell-sw.com> <6e1457db-9b5c-3bbd-65fc-ebd2a9e99558@bell-sw.com> Message-ID: Hi Dmitrij, So it looks like fixing it this way means that when InlineMathNatives is set false, then it disables these intrinsics in C1, C2 and interpreter? Looks good! - Derek > -----Original Message----- > From: Dmitrij Pochepko [mailto:dmitrij.pochepko at bell-sw.com] > Sent: Friday, June 22, 2018 8:53 AM > To: White, Derek ; Andrew Haley > > Cc: aarch64-port-dev at openjdk.java.net; hotspot-compiler- > dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math > intrinsics usage in interpreter and C1 > > External Email > > Hi Derek, Andrew, > > Here is an updated version with your comments addressed: > http://cr.openjdk.java.net/~dpochepk/8204289/webrev.03/ > > Thanks, > > Dmitrij > > > On 22.06.2018 04:40, White, Derek wrote: > > Hi Dmitrij, > > > > There's some bad indenting in c1_LIRGenerator_aarch64.cpp around lines > > 815, 828, 829, 849, 850. > > > > I didn't follow all of the differences between the change from call_runtime > to __ call_runtime_leaf, (although I see that it follows the x86 code.) So I > wouldn't call this a full review. > > > > Thanks, > > - Derek > > > >> -----Original Message----- > >> From: aarch64-port-dev [mailto:aarch64-port-dev- > >> bounces at openjdk.java.net] On Behalf Of Dmitrij Pochepko > >> Sent: Wednesday, June 20, 2018 10:45 AM > >> To: aarch64-port-dev at openjdk.java.net; hotspot-compiler- > >> dev at openjdk.java.net > >> Subject: Re: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math > >> intrinsics usage in interpreter and C1 > >> > >> External Email > >> > >> Hi, > >> > >> > >> can somebody take a look? > >> > >> > >> Thanks, > >> > >> Dmitrij > >> > >> > >> On 04.06.2018 18:50, Dmitrij Pochepko wrote: > >>> Hi all, > >>> > >>> please review patch for JDK-8204289: AARCH64: enable math intrinsics > >>> usage in interpreter and C1 > >>> > >>> This patch enables usage of math intrinsics for interpreter and C1 > >>> in case intrinsics are implemented. Code follows that of x86 port. > >>> > >>> > >>> Testing: I've merged this patch with implemented intrinsic and > >>> launched jtreg tests and benchmark in 2 more modes: -Xint and > >>> -XX:TieredStopAtLevel=3 > >>> > >>> Benchmark scores were improved as expected of intrinsic. All tests > >>> passed. > >>> > >>> > >>> webrev: http://cr.openjdk.java.net/~dpochepk/8204289/webrev.01/ > >>> > >>> CR: https://bugs.openjdk.java.net/browse/JDK-8204289 > >>> > >>> > >>> Thanks, > >>> > >>> Dmitrij > >>> From aph at redhat.com Mon Jun 25 07:10:24 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 25 Jun 2018 08:10:24 +0100 Subject: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math intrinsics usage in interpreter and C1 In-Reply-To: References: <6bd4bccb-befb-0523-d75e-2c5a99c4ee34@bell-sw.com> <6e1457db-9b5c-3bbd-65fc-ebd2a9e99558@bell-sw.com> Message-ID: <1d82da14-f1f5-1629-065f-dd091b2346e3@redhat.com> On 06/22/2018 01:53 PM, Dmitrij Pochepko wrote: > Here is an updated version with your comments addressed: > http://cr.openjdk.java.net/~dpochepk/8204289/webrev.03/ OK, we're good. Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Jun 25 07:15:26 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 25 Jun 2018 08:15:26 +0100 Subject: RFR: 8189105: AARCH64: create intrinsic for sin and cos In-Reply-To: <1d73f942-af67-8a64-85b0-9b9056801f86@bell-sw.com> References: <4de41b0c-e318-c70f-a864-4f6c8bd14297@redhat.com> <5B12CAEF.8050105@bell-sw.com> <2bd89c11-d234-ceae-3b04-4c547ef5836c@redhat.com> <752dd93c-7a95-c674-08df-3e054f178196@redhat.com> <9a8968ee-4432-19a2-f4f2-08a1fb4b4034@redhat.com> <3cde2f37-6f79-21fe-7064-1f5258967364@redhat.com> <1d73f942-af67-8a64-85b0-9b9056801f86@bell-sw.com> Message-ID: <336e4830-f1a9-75af-8e64-851cdeac5480@redhat.com> On 06/21/2018 01:27 PM, Dmitrij Pochepko wrote: > Yes. Forgot to update one more source. Clean version: > http://cr.openjdk.java.net/~dpochepk/8189105/webrev.06/ Looks good. Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gromero at linux.vnet.ibm.com Mon Jun 25 08:18:39 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 25 Jun 2018 05:18:39 -0300 Subject: RFR(s): 8205582: PPC64: RTM: Fix counter for aborts on nested transactions Message-ID: <8aadb20a-fba7-0c52-04c0-015a731e60bd@linux.vnet.ibm.com> Hi, Could the following change be reviewed please? bug : https://bugs.openjdk.java.net/browse/JDK-8205582 webrev: http://cr.openjdk.java.net/~gromero/8205582/v1/ It fixes the RTM counter for nested aborts (rtm lock aborts type 5) by extracting and checking bits in the Transactional Level field of TEXASR register. It also fixes the memory conflict counter (rtm lock aborts type 2). Power TM status register supports two bits to inform two different types of memory conflict between threads: non-transactional and transactional. According to how the jtreg RTM tests are designed the memory conflict counter counts non-transactional conflicts: on TestPrintPreciseRTMLockingStatistics a RTM lock is held on a static variable while another thread without any synchronization (non-trasactional) tries to modify the same variable. Hence that small adjustment satisfies the TestPrintPreciseRTMLockingStatistics making it pass on Power. The memory conflict counter is not used in any other place besides by the RTM precise statistics (no decision is made by the JVM based on that amount). This change partially fixes some failures in compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java regarding the nested and memory conflict abort counters. The remaining issue will be fixed by aborting on calling JNI (next RFR). Thank you and best regards, Gustavo From gromero at linux.vnet.ibm.com Mon Jun 25 08:21:07 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 25 Jun 2018 05:21:07 -0300 Subject: RFR(s): 8205581: PPC64: RTM: Fix abort on native calls Message-ID: Hi, Could the following change be reviewed please? bug : https://bugs.openjdk.java.net/browse/JDK-8205581 webrev: http://cr.openjdk.java.net/~gromero/8205581/v1/ It forces a transactional state to abort before calling native methods, before calling runtime, and on uncommon trap checking, mostly because transaction will be aborted soon or latter in either case, similarly to what happens on Intel. The abort instruction (tabort) is only emitted if UseRTMLocking is "true" and any 'tabort' instruction is treated as a 'nop' instruction if TM state is non-transactional. It fixes the following tests: +Passed: compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java +Passed: compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java Thank you and best regards, Gustavo From gromero at linux.vnet.ibm.com Mon Jun 25 08:24:13 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 25 Jun 2018 05:24:13 -0300 Subject: RFR(s): 8205580: PPC64: RTM: Don't retry lock on abort if abort was intentional Message-ID: Hi, Could the following change be reviewed please? bug : https://bugs.openjdk.java.net/browse/JDK-8205580 webrev: http://cr.openjdk.java.net/~gromero/8205580/v1/ It changes the behavior of rtm_retry_lock_on_abort() by avoiding retry if abort was a deliberate abort, i.e. caused by a 'tabort r0' instruction. On Intel bit 1 in abort_status_Reg (which communicates the abort status) is always clear when a 'xabort 0' instruction is executed in order to inform that a transactional retry /can not/ succeed on retry. So rtm_retry_lock_on_abort() on Intel, on finding bit 1 clear in abort_status_Reg, skips the retry (don't retry). Currently on Power rtm_retry_lock_on_abort() is just checking the persistent bit (if set => skip) which /is not set/ by 'tabort r0'. Hence rtm_retry_lock_on_abort() does retry to lock on an intentional abort caused by 'tabort'. It leads, for instance when -XX:RTMRetryCount=1, to the following discrepancy between Intel and Power regarding the number of retries/aborts: [Power] # rtm locks total (estimated): 3 # rtm lock aborts : 3 # rtm lock aborts 0: 3 # rtm lock aborts 1: 3 # rtm lock aborts 2: 0 # rtm lock aborts 3: 0 # rtm lock aborts 4: 0 # rtm lock aborts 5: 0 [Intel] # rtm locks total (estimated): 2 # rtm lock aborts : 2 # rtm lock aborts 0: 2 # rtm lock aborts 1: 2 # rtm lock aborts 2: 0 # rtm lock aborts 3: 0 # rtm lock aborts 4: 0 # rtm lock aborts 5: 0 So for -XX:RTMRetryCount=X: on Power the number of aborts is: X*2+1 [1 first failure + 1 rtm_retry_lock_on_abort() + 1 rtm_retry_lock_on_busy()]; on Intel the number of aborts is: X+1 [1 first failure + 1 rtm_retry_lock_on_busy()] This change fixes that discrepancy by using bit "Abort" in TEXASR register (abort_status_Reg) that tells if a transaction was aborted due to a 'tabort' instruction and skip the retry if such a bit is set. It fixes the following tests: +Passed: compiler/rtm/locking/TestRTMRetryCount.java +Passed: compiler/rtm/locking/TestRTMAbortThreshold.java Thank you and best regards, Gustavo From gromero at linux.vnet.ibm.com Mon Jun 25 08:29:01 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 25 Jun 2018 05:29:01 -0300 Subject: RFR(xs): 8205578: jtreg: Fix failing TestRTMAbortRatio on PPC64 Message-ID: <37227b8b-7977-349a-249c-f7613d06d64f@linux.vnet.ibm.com> Hi, Could the following simple change be reviewed please? bug : https://bugs.openjdk.java.net/browse/JDK-8205578 webrev: http://cr.openjdk.java.net/~gromero/8205578/v1/ Currently native method pageSize() is used to cause deliberate transactional aborts. However in test TestRTMAbortRatio pageSize() is not marked to be compilable and as a consequence it's never called through the code path of SharedRuntime::generate_native_wrapper(). As that code path is never exercised no 'tabort' on JNI call is executed and the test fails on Power because of fewer aborts than expected by the test. I can't say for sure why that test is getting the correct number of aborts on x86. Nonetheless I can confirm that even on x86 the aborts do not come from the native wrapper, i.e. from 'xabort' in SharedRuntime::generate_native_wrapper(). I suspect the aborts on x86 are occurring a bit latter when the native function is called and a "Far Call" is executed in the native method by chance and not in a controlled way. As far as I know there is no way to inspect the exact address when a transaction failed on Intel as it's possible on Power. Anyway, marking pageSize() as compilable does not cause any regression on Intel (at the same time it starts to exercise the generate_native_wrapper code path) and makes the test pass on Power as expected. So it fixes the following test on Power: +Passed: compiler/rtm/locking/TestRTMAbortRatio.java Thank you and best regards, Gustavo From gromero at linux.vnet.ibm.com Mon Jun 25 08:31:09 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 25 Jun 2018 05:31:09 -0300 Subject: RFR(xs): 8205390: jtreg: Fix failing TestRTMSpinLoopCount on PPC64 Message-ID: Hi, Could the following change be reviewed please? bug : https://bugs.openjdk.java.net/browse/JDK-8205390 webrev: http://cr.openjdk.java.net/~gromero/8205390/v1/ It adds a new throttling sequence for PPC64 because the last value on current sequence does not fit on PPC64. By using the new sequence the following test is fixed: +Passed: compiler/rtm/locking/TestRTMSpinLoopCount.java Thank you and best regards, Gustavo From dmitrij.pochepko at bell-sw.com Mon Jun 25 09:45:21 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Mon, 25 Jun 2018 12:45:21 +0300 Subject: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math intrinsics usage in interpreter and C1 In-Reply-To: <1d82da14-f1f5-1629-065f-dd091b2346e3@redhat.com> References: <6bd4bccb-befb-0523-d75e-2c5a99c4ee34@bell-sw.com> <6e1457db-9b5c-3bbd-65fc-ebd2a9e99558@bell-sw.com> <1d82da14-f1f5-1629-065f-dd091b2346e3@redhat.com> Message-ID: Dmitry, Derek, Andrew, Thank you for review! On 25.06.2018 10:10, Andrew Haley wrote: > On 06/22/2018 01:53 PM, Dmitrij Pochepko wrote: >> Here is an updated version with your comments addressed: >> http://cr.openjdk.java.net/~dpochepk/8204289/webrev.03/ > OK, we're good. Thanks. > From cthalinger at twitter.com Mon Jun 25 12:16:31 2018 From: cthalinger at twitter.com (Christian Thalinger) Date: Mon, 25 Jun 2018 08:16:31 -0400 Subject: [11] RTM tests fail Message-ID: <515395B7-31C9-4502-A9A1-323DB768280C@twitter.com> Hi! Is anyone running the compiler/rtm/ tests on a machine that actually supports RTM? Every time one of our nightly jobs ends up on a machine that supports RTM a bunch of locking tests and the print test fail: ? compiler/rtm/locking/TestRTMAbortRatio.java.TestRTMAbortRatio ? compiler/rtm/locking/TestRTMAbortThreshold.java.TestRTMAbortThreshold ? compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java.TestRTMAfterNonRTMDeopt ? compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java.TestRTMDeoptOnHighAbortRatio ? compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java.TestRTMDeoptOnLowAbortRatio ? compiler/rtm/locking/TestRTMLockingThreshold.java.TestRTMLockingThreshold ? compiler/rtm/locking/TestUseRTMXendForLockBusy.java.TestUseRTMXendForLockBusy ? compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java.TestPrintPreciseRTMLockingStatistics Exceptions look like this (for all the failures above in order): java.lang.RuntimeException: Actual abort ratio (10000) should lower or equal to specified (100).: expected that 10000 <= 100 java.lang.RuntimeException: Expected that method with rtm lock elision was deoptimized after 1 lock attempts: expected 3320 to equal 1 java.lang.RuntimeException: Two uncommon traps with reason rtm_state_change should be fired.: expected 0 to equal 2 java.lang.RuntimeException: Expected to get only one deoptimization due to rtm state change: expected 0 to equal 1 java.lang.RuntimeException: Expected to get only one deoptimization due to rtm state change: expected 0 to equal 1 java.lang.RuntimeException: There should be exactly one statistics entry corresponding to ProfileRTM state.: expected null to not equal null java.lang.RuntimeException: VM output should contain exactly one rtm locking statistics entry for method compiler.testlibrary.rtm.BusyLock::test: expected 0 to equal 1 java.lang.RuntimeException: RTM locking statistics should contain non zero aborts count for abort reason 0: expected 0 > 0 Since these tests are not excluded I have to assume that either (a) they work for you (really?) or (b) that Oracle (or someone else) doesn?t have machines that support RTM. From cthalinger at twitter.com Mon Jun 25 12:26:59 2018 From: cthalinger at twitter.com (Christian Thalinger) Date: Mon, 25 Jun 2018 08:26:59 -0400 Subject: [11] RTM tests fail In-Reply-To: <515395B7-31C9-4502-A9A1-323DB768280C@twitter.com> References: <515395B7-31C9-4502-A9A1-323DB768280C@twitter.com> Message-ID: > On Jun 25, 2018, at 8:16 AM, Christian Thalinger wrote: > > Hi! Is anyone running the compiler/rtm/ tests on a machine that actually supports RTM? > > Every time one of our nightly jobs ends up on a machine that supports RTM a bunch of locking tests and the print test fail: > > ? compiler/rtm/locking/TestRTMAbortRatio.java.TestRTMAbortRatio > ? compiler/rtm/locking/TestRTMAbortThreshold.java.TestRTMAbortThreshold > ? compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java.TestRTMAfterNonRTMDeopt > ? compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java.TestRTMDeoptOnHighAbortRatio > ? compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java.TestRTMDeoptOnLowAbortRatio > ? compiler/rtm/locking/TestRTMLockingThreshold.java.TestRTMLockingThreshold > ? compiler/rtm/locking/TestUseRTMXendForLockBusy.java.TestUseRTMXendForLockBusy > ? compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java.TestPrintPreciseRTMLockingStatistics > > Exceptions look like this (for all the failures above in order): > > java.lang.RuntimeException: Actual abort ratio (10000) should lower or equal to specified (100).: expected that 10000 <= 100 > > java.lang.RuntimeException: Expected that method with rtm lock elision was deoptimized after 1 lock attempts: expected 3320 to equal 1 > > java.lang.RuntimeException: Two uncommon traps with reason rtm_state_change should be fired.: expected 0 to equal 2 > > java.lang.RuntimeException: Expected to get only one deoptimization due to rtm state change: expected 0 to equal 1 > > java.lang.RuntimeException: Expected to get only one deoptimization due to rtm state change: expected 0 to equal 1 > > java.lang.RuntimeException: There should be exactly one statistics entry corresponding to ProfileRTM state.: expected null to not equal null > > java.lang.RuntimeException: VM output should contain exactly one rtm locking statistics entry for method compiler.testlibrary.rtm.BusyLock::test: expected 0 to equal 1 > > java.lang.RuntimeException: RTM locking statistics should contain non zero aborts count for abort reason 0: expected 0 > 0 > > Since these tests are not excluded I have to assume that either (a) they work for you (really?) or (b) that Oracle (or someone else) doesn?t have machines that support RTM. Was this maybe fixed by https://bugs.openjdk.java.net/browse/JDK-8204134? It?s hard to tell because the bug doesn?t say how the tests failed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Mon Jun 25 12:35:42 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 25 Jun 2018 12:35:42 +0000 Subject: [11] RTM tests fail In-Reply-To: <515395B7-31C9-4502-A9A1-323DB768280C@twitter.com> References: <515395B7-31C9-4502-A9A1-323DB768280C@twitter.com> Message-ID: <25bbc06005eb4e929f2bcd697618e3f8@sap.com> Hi Christian, We also saw lot's of failures here, but Gustavo fixed a row of issues: 8204134: jtreg: Fix RTM abort provoker for various tests after "8149159: Clean up Unsafe" 8204135: jtreg: Fix failing RTM test TestUseRTMXendForLockBusy 8204136: jtreg: Fix failing RTM test RTMSpinLoopCount Did you check with or without these fixes? Best regards, Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Christian Thalinger > Sent: Montag, 25. Juni 2018 14:17 > To: hotspot compiler > Subject: [11] RTM tests fail > > Hi! Is anyone running the compiler/rtm/ tests on a machine that actually > supports RTM? > > Every time one of our nightly jobs ends up on a machine that supports RTM a > bunch of locking tests and the print test fail: > > ? compiler/rtm/locking/TestRTMAbortRatio.java.TestRTMAbortRatio > ? > compiler/rtm/locking/TestRTMAbortThreshold.java.TestRTMAbortThreshold > ? > compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java.TestRTMAfterNonR > TMDeopt > ? > compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java.TestRTMDeopt > OnHighAbortRatio > ? > compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java.TestRTMDeopt > OnLowAbortRatio > ? > compiler/rtm/locking/TestRTMLockingThreshold.java.TestRTMLockingThresh > old > ? > compiler/rtm/locking/TestUseRTMXendForLockBusy.java.TestUseRTMXend > ForLockBusy > ? > compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java.TestPrintPreci > seRTMLockingStatistics > > Exceptions look like this (for all the failures above in order): > > java.lang.RuntimeException: Actual abort ratio (10000) should lower or equal > to specified (100).: expected that 10000 <= 100 > > java.lang.RuntimeException: Expected that method with rtm lock elision was > deoptimized after 1 lock attempts: expected 3320 to equal 1 > > java.lang.RuntimeException: Two uncommon traps with reason > rtm_state_change should be fired.: expected 0 to equal 2 > > java.lang.RuntimeException: Expected to get only one deoptimization due to > rtm state change: expected 0 to equal 1 > > java.lang.RuntimeException: Expected to get only one deoptimization due to > rtm state change: expected 0 to equal 1 > > java.lang.RuntimeException: There should be exactly one statistics entry > corresponding to ProfileRTM state.: expected null to not equal null > > java.lang.RuntimeException: VM output should contain exactly one rtm > locking statistics entry for method compiler.testlibrary.rtm.BusyLock::test: > expected 0 to equal 1 > > java.lang.RuntimeException: RTM locking statistics should contain non zero > aborts count for abort reason 0: expected 0 > 0 > > Since these tests are not excluded I have to assume that either (a) they work > for you (really?) or (b) that Oracle (or someone else) doesn?t have machines > that support RTM. From cthalinger at twitter.com Mon Jun 25 12:39:00 2018 From: cthalinger at twitter.com (Christian Thalinger) Date: Mon, 25 Jun 2018 08:39:00 -0400 Subject: [11] RTM tests fail In-Reply-To: <25bbc06005eb4e929f2bcd697618e3f8@sap.com> References: <515395B7-31C9-4502-A9A1-323DB768280C@twitter.com> <25bbc06005eb4e929f2bcd697618e3f8@sap.com> Message-ID: > On Jun 25, 2018, at 8:35 AM, Lindenmaier, Goetz wrote: > > Hi Christian, > > We also saw lot's of failures here, but Gustavo fixed a row of issues: > 8204134: jtreg: Fix RTM abort provoker for various tests after "8149159: Clean up Unsafe" > 8204135: jtreg: Fix failing RTM test TestUseRTMXendForLockBusy > 8204136: jtreg: Fix failing RTM test RTMSpinLoopCount > > Did you check with or without these fixes? Without, unfortunately. Are all of the failures fixed now (in jdk-11+19)? > > Best regards, > Goetz. > >> -----Original Message----- >> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- >> bounces at openjdk.java.net] On Behalf Of Christian Thalinger >> Sent: Montag, 25. Juni 2018 14:17 >> To: hotspot compiler >> Subject: [11] RTM tests fail >> >> Hi! Is anyone running the compiler/rtm/ tests on a machine that actually >> supports RTM? >> >> Every time one of our nightly jobs ends up on a machine that supports RTM a >> bunch of locking tests and the print test fail: >> >> ? compiler/rtm/locking/TestRTMAbortRatio.java.TestRTMAbortRatio >> ? >> compiler/rtm/locking/TestRTMAbortThreshold.java.TestRTMAbortThreshold >> ? >> compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java.TestRTMAfterNonR >> TMDeopt >> ? >> compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java.TestRTMDeopt >> OnHighAbortRatio >> ? >> compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java.TestRTMDeopt >> OnLowAbortRatio >> ? >> compiler/rtm/locking/TestRTMLockingThreshold.java.TestRTMLockingThresh >> old >> ? >> compiler/rtm/locking/TestUseRTMXendForLockBusy.java.TestUseRTMXend >> ForLockBusy >> ? >> compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java.TestPrintPreci >> seRTMLockingStatistics >> >> Exceptions look like this (for all the failures above in order): >> >> java.lang.RuntimeException: Actual abort ratio (10000) should lower or equal >> to specified (100).: expected that 10000 <= 100 >> >> java.lang.RuntimeException: Expected that method with rtm lock elision was >> deoptimized after 1 lock attempts: expected 3320 to equal 1 >> >> java.lang.RuntimeException: Two uncommon traps with reason >> rtm_state_change should be fired.: expected 0 to equal 2 >> >> java.lang.RuntimeException: Expected to get only one deoptimization due to >> rtm state change: expected 0 to equal 1 >> >> java.lang.RuntimeException: Expected to get only one deoptimization due to >> rtm state change: expected 0 to equal 1 >> >> java.lang.RuntimeException: There should be exactly one statistics entry >> corresponding to ProfileRTM state.: expected null to not equal null >> >> java.lang.RuntimeException: VM output should contain exactly one rtm >> locking statistics entry for method compiler.testlibrary.rtm.BusyLock::test: >> expected 0 to equal 1 >> >> java.lang.RuntimeException: RTM locking statistics should contain non zero >> aborts count for abort reason 0: expected 0 > 0 >> >> Since these tests are not excluded I have to assume that either (a) they work >> for you (really?) or (b) that Oracle (or someone else) doesn?t have machines >> that support RTM. From cthalinger at twitter.com Mon Jun 25 12:41:31 2018 From: cthalinger at twitter.com (Christian Thalinger) Date: Mon, 25 Jun 2018 08:41:31 -0400 Subject: [11] RTM tests fail In-Reply-To: <939736eb-f96d-63fa-cb15-c519ec8c1d2d@linux.vnet.ibm.com> References: <515395B7-31C9-4502-A9A1-323DB768280C@twitter.com> <939736eb-f96d-63fa-cb15-c519ec8c1d2d@linux.vnet.ibm.com> Message-ID: <34AB351F-4A1C-4437-BE6D-C4F050BF3E55@twitter.com> > On Jun 25, 2018, at 8:40 AM, Gustavo Romero wrote: > > Hi Christian, > > I'm facing major issues with infra in our lab right now. > > Once it gets solved I'll list the state I get on our lab before "JDK-8204134". > > But given your list I would say "JDK-8204134" is exactly the fix missing in your > case. Excellent, thank you. I will update our copy and let you know if everything is passing then. > > > Regards, > Gustavo > > On 06/25/2018 09:26 AM, Christian Thalinger wrote: >>> On Jun 25, 2018, at 8:16 AM, Christian Thalinger > wrote: >>> >>> Hi! Is anyone running the compiler/rtm/ tests on a machine that actually supports RTM? >>> >>> Every time one of our nightly jobs ends up on a machine that supports RTM a bunch of locking tests and the print test fail: >>> >>> ? compiler/rtm/locking/TestRTMAbortRatio.java.TestRTMAbortRatio >>> ? compiler/rtm/locking/TestRTMAbortThreshold.java.TestRTMAbortThreshold >>> ? compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java.TestRTMAfterNonRTMDeopt >>> ? compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java.TestRTMDeoptOnHighAbortRatio >>> ? compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java.TestRTMDeoptOnLowAbortRatio >>> ? compiler/rtm/locking/TestRTMLockingThreshold.java.TestRTMLockingThreshold >>> ? compiler/rtm/locking/TestUseRTMXendForLockBusy.java.TestUseRTMXendForLockBusy >>> ? compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java.TestPrintPreciseRTMLockingStatistics >>> >>> Exceptions look like this (for all the failures above in order): >>> >>> java.lang.RuntimeException: Actual abort ratio (10000) should lower or equal to specified (100).: expected that 10000 <= 100 >>> >>> java.lang.RuntimeException: Expected that method with rtm lock elision was deoptimized after 1 lock attempts: expected 3320 to equal 1 >>> >>> java.lang.RuntimeException: Two uncommon traps with reason rtm_state_change should be fired.: expected 0 to equal 2 >>> >>> java.lang.RuntimeException: Expected to get only one deoptimization due to rtm state change: expected 0 to equal 1 >>> >>> java.lang.RuntimeException: Expected to get only one deoptimization due to rtm state change: expected 0 to equal 1 >>> >>> java.lang.RuntimeException: There should be exactly one statistics entry corresponding to ProfileRTM state.: expected null to not equal null >>> >>> java.lang.RuntimeException: VM output should contain exactly one rtm locking statistics entry for method compiler.testlibrary.rtm.BusyLock::test: expected 0 to equal 1 >>> >>> java.lang.RuntimeException: RTM locking statistics should contain non zero aborts count for abort reason 0: expected 0 > 0 >>> >>> Since these tests are not excluded I have to assume that either (a) they work for you (really?) or (b) that Oracle (or someone else) doesn?t have machines that support RTM. >> Was this maybe fixed by https://bugs.openjdk.java.net/browse/JDK-8204134? It?s hard to tell because the bug doesn?t say how the tests failed. > From gromero at linux.vnet.ibm.com Mon Jun 25 12:40:14 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 25 Jun 2018 09:40:14 -0300 Subject: [11] RTM tests fail In-Reply-To: References: <515395B7-31C9-4502-A9A1-323DB768280C@twitter.com> Message-ID: <939736eb-f96d-63fa-cb15-c519ec8c1d2d@linux.vnet.ibm.com> Hi Christian, I'm facing major issues with infra in our lab right now. Once it gets solved I'll list the state I get on our lab before "JDK-8204134". But given your list I would say "JDK-8204134" is exactly the fix missing in your case. Regards, Gustavo On 06/25/2018 09:26 AM, Christian Thalinger wrote: > >> On Jun 25, 2018, at 8:16 AM, Christian Thalinger > wrote: >> >> Hi! Is anyone running the compiler/rtm/ tests on a machine that actually supports RTM? >> >> Every time one of our nightly jobs ends up on a machine that supports RTM a bunch of locking tests and the print test fail: >> >> ? compiler/rtm/locking/TestRTMAbortRatio.java.TestRTMAbortRatio >> ? compiler/rtm/locking/TestRTMAbortThreshold.java.TestRTMAbortThreshold >> ? compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java.TestRTMAfterNonRTMDeopt >> ? compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java.TestRTMDeoptOnHighAbortRatio >> ? compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java.TestRTMDeoptOnLowAbortRatio >> ? compiler/rtm/locking/TestRTMLockingThreshold.java.TestRTMLockingThreshold >> ? compiler/rtm/locking/TestUseRTMXendForLockBusy.java.TestUseRTMXendForLockBusy >> ? compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java.TestPrintPreciseRTMLockingStatistics >> >> Exceptions look like this (for all the failures above in order): >> >> java.lang.RuntimeException: Actual abort ratio (10000) should lower or equal to specified (100).: expected that 10000 <= 100 >> >> java.lang.RuntimeException: Expected that method with rtm lock elision was deoptimized after 1 lock attempts: expected 3320 to equal 1 >> >> java.lang.RuntimeException: Two uncommon traps with reason rtm_state_change should be fired.: expected 0 to equal 2 >> >> java.lang.RuntimeException: Expected to get only one deoptimization due to rtm state change: expected 0 to equal 1 >> >> java.lang.RuntimeException: Expected to get only one deoptimization due to rtm state change: expected 0 to equal 1 >> >> java.lang.RuntimeException: There should be exactly one statistics entry corresponding to ProfileRTM state.: expected null to not equal null >> >> java.lang.RuntimeException: VM output should contain exactly one rtm locking statistics entry for method compiler.testlibrary.rtm.BusyLock::test: expected 0 to equal 1 >> >> java.lang.RuntimeException: RTM locking statistics should contain non zero aborts count for abort reason 0: expected 0 > 0 >> >> Since these tests are not excluded I have to assume that either (a) they work for you (really?) or (b) that Oracle (or someone else) doesn?t have machines that support RTM. > > Was this maybe fixed by https://bugs.openjdk.java.net/browse/JDK-8204134? It?s hard to tell because the bug doesn?t say how the tests failed. From goetz.lindenmaier at sap.com Mon Jun 25 12:46:03 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 25 Jun 2018 12:46:03 +0000 Subject: [11] RTM tests fail In-Reply-To: References: <515395B7-31C9-4502-A9A1-323DB768280C@twitter.com> <25bbc06005eb4e929f2bcd697618e3f8@sap.com> Message-ID: <8f31a45d24f84732ae7915f22aae61a5@sap.com> > > Did you check with or without these fixes? > > Without, unfortunately. Are all of the failures fixed now (in jdk-11+19)? I don't know, our machines do not have RTM, only our Power ones do. But I think Gustavo Romero from IBM claimed so. Best regards, Goetz. > > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > >> bounces at openjdk.java.net] On Behalf Of Christian Thalinger > >> Sent: Montag, 25. Juni 2018 14:17 > >> To: hotspot compiler > >> Subject: [11] RTM tests fail > >> > >> Hi! Is anyone running the compiler/rtm/ tests on a machine that actually > >> supports RTM? > >> > >> Every time one of our nightly jobs ends up on a machine that supports > RTM a > >> bunch of locking tests and the print test fail: > >> > >> ? compiler/rtm/locking/TestRTMAbortRatio.java.TestRTMAbortRatio > >> ? > >> > compiler/rtm/locking/TestRTMAbortThreshold.java.TestRTMAbortThreshold > >> ? > >> > compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java.TestRTMAfterNonR > >> TMDeopt > >> ? > >> > compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java.TestRTMDeopt > >> OnHighAbortRatio > >> ? > >> > compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java.TestRTMDeopt > >> OnLowAbortRatio > >> ? > >> > compiler/rtm/locking/TestRTMLockingThreshold.java.TestRTMLockingThresh > >> old > >> ? > >> > compiler/rtm/locking/TestUseRTMXendForLockBusy.java.TestUseRTMXend > >> ForLockBusy > >> ? > >> > compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java.TestPrintPreci > >> seRTMLockingStatistics > >> > >> Exceptions look like this (for all the failures above in order): > >> > >> java.lang.RuntimeException: Actual abort ratio (10000) should lower or > equal > >> to specified (100).: expected that 10000 <= 100 > >> > >> java.lang.RuntimeException: Expected that method with rtm lock elision > was > >> deoptimized after 1 lock attempts: expected 3320 to equal 1 > >> > >> java.lang.RuntimeException: Two uncommon traps with reason > >> rtm_state_change should be fired.: expected 0 to equal 2 > >> > >> java.lang.RuntimeException: Expected to get only one deoptimization due > to > >> rtm state change: expected 0 to equal 1 > >> > >> java.lang.RuntimeException: Expected to get only one deoptimization due > to > >> rtm state change: expected 0 to equal 1 > >> > >> java.lang.RuntimeException: There should be exactly one statistics entry > >> corresponding to ProfileRTM state.: expected null to not equal null > >> > >> java.lang.RuntimeException: VM output should contain exactly one rtm > >> locking statistics entry for method compiler.testlibrary.rtm.BusyLock::test: > >> expected 0 to equal 1 > >> > >> java.lang.RuntimeException: RTM locking statistics should contain non > zero > >> aborts count for abort reason 0: expected 0 > 0 > >> > >> Since these tests are not excluded I have to assume that either (a) they > work > >> for you (really?) or (b) that Oracle (or someone else) doesn?t have > machines > >> that support RTM. From gromero at linux.vnet.ibm.com Mon Jun 25 12:49:25 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 25 Jun 2018 09:49:25 -0300 Subject: [11] RTM tests fail In-Reply-To: <8f31a45d24f84732ae7915f22aae61a5@sap.com> References: <515395B7-31C9-4502-A9A1-323DB768280C@twitter.com> <25bbc06005eb4e929f2bcd697618e3f8@sap.com> <8f31a45d24f84732ae7915f22aae61a5@sap.com> Message-ID: <26e36040-4b08-8293-21d8-ca770b945f57@linux.vnet.ibm.com> On 06/25/2018 09:46 AM, Lindenmaier, Goetz wrote: >>> Did you check with or without these fixes? >> >> Without, unfortunately. Are all of the failures fixed now (in jdk-11+19)? > I don't know, our machines do not have RTM, only our Power ones do. > But I think Gustavo Romero from IBM claimed so. Yup, after the three fixes Goetz mentioned all RTM tests must pass on Intel. Regards, Gustavo > Best regards, > Goetz. > > >> >>> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- >>>> bounces at openjdk.java.net] On Behalf Of Christian Thalinger >>>> Sent: Montag, 25. Juni 2018 14:17 >>>> To: hotspot compiler >>>> Subject: [11] RTM tests fail >>>> >>>> Hi! Is anyone running the compiler/rtm/ tests on a machine that actually >>>> supports RTM? >>>> >>>> Every time one of our nightly jobs ends up on a machine that supports >> RTM a >>>> bunch of locking tests and the print test fail: >>>> >>>> ? compiler/rtm/locking/TestRTMAbortRatio.java.TestRTMAbortRatio >>>> ? >>>> >> compiler/rtm/locking/TestRTMAbortThreshold.java.TestRTMAbortThreshold >>>> ? >>>> >> compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java.TestRTMAfterNonR >>>> TMDeopt >>>> ? >>>> >> compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java.TestRTMDeopt >>>> OnHighAbortRatio >>>> ? >>>> >> compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java.TestRTMDeopt >>>> OnLowAbortRatio >>>> ? >>>> >> compiler/rtm/locking/TestRTMLockingThreshold.java.TestRTMLockingThresh >>>> old >>>> ? >>>> >> compiler/rtm/locking/TestUseRTMXendForLockBusy.java.TestUseRTMXend >>>> ForLockBusy >>>> ? >>>> >> compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java.TestPrintPreci >>>> seRTMLockingStatistics >>>> >>>> Exceptions look like this (for all the failures above in order): >>>> >>>> java.lang.RuntimeException: Actual abort ratio (10000) should lower or >> equal >>>> to specified (100).: expected that 10000 <= 100 >>>> >>>> java.lang.RuntimeException: Expected that method with rtm lock elision >> was >>>> deoptimized after 1 lock attempts: expected 3320 to equal 1 >>>> >>>> java.lang.RuntimeException: Two uncommon traps with reason >>>> rtm_state_change should be fired.: expected 0 to equal 2 >>>> >>>> java.lang.RuntimeException: Expected to get only one deoptimization due >> to >>>> rtm state change: expected 0 to equal 1 >>>> >>>> java.lang.RuntimeException: Expected to get only one deoptimization due >> to >>>> rtm state change: expected 0 to equal 1 >>>> >>>> java.lang.RuntimeException: There should be exactly one statistics entry >>>> corresponding to ProfileRTM state.: expected null to not equal null >>>> >>>> java.lang.RuntimeException: VM output should contain exactly one rtm >>>> locking statistics entry for method compiler.testlibrary.rtm.BusyLock::test: >>>> expected 0 to equal 1 >>>> >>>> java.lang.RuntimeException: RTM locking statistics should contain non >> zero >>>> aborts count for abort reason 0: expected 0 > 0 >>>> >>>> Since these tests are not excluded I have to assume that either (a) they >> work >>>> for you (really?) or (b) that Oracle (or someone else) doesn?t have >> machines >>>> that support RTM. > From cthalinger at twitter.com Mon Jun 25 12:54:00 2018 From: cthalinger at twitter.com (Christian Thalinger) Date: Mon, 25 Jun 2018 08:54:00 -0400 Subject: [11] RTM tests fail In-Reply-To: <26e36040-4b08-8293-21d8-ca770b945f57@linux.vnet.ibm.com> References: <515395B7-31C9-4502-A9A1-323DB768280C@twitter.com> <25bbc06005eb4e929f2bcd697618e3f8@sap.com> <8f31a45d24f84732ae7915f22aae61a5@sap.com> <26e36040-4b08-8293-21d8-ca770b945f57@linux.vnet.ibm.com> Message-ID: > On Jun 25, 2018, at 8:49 AM, Gustavo Romero wrote: > > On 06/25/2018 09:46 AM, Lindenmaier, Goetz wrote: >>>> Did you check with or without these fixes? >>> >>> Without, unfortunately. Are all of the failures fixed now (in jdk-11+19)? >> I don't know, our machines do not have RTM, only our Power ones do. >> But I think Gustavo Romero from IBM claimed so. > > Yup, after the three fixes Goetz mentioned all RTM tests must pass on Intel. Ok, I?ll get back to you? > > > Regards, > Gustavo > >> Best regards, >> Goetz. >>> >>>> >>>> Best regards, >>>> Goetz. >>>> >>>>> -----Original Message----- >>>>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- >>>>> bounces at openjdk.java.net] On Behalf Of Christian Thalinger >>>>> Sent: Montag, 25. Juni 2018 14:17 >>>>> To: hotspot compiler >>>>> Subject: [11] RTM tests fail >>>>> >>>>> Hi! Is anyone running the compiler/rtm/ tests on a machine that actually >>>>> supports RTM? >>>>> >>>>> Every time one of our nightly jobs ends up on a machine that supports >>> RTM a >>>>> bunch of locking tests and the print test fail: >>>>> >>>>> ? compiler/rtm/locking/TestRTMAbortRatio.java.TestRTMAbortRatio >>>>> ? >>>>> >>> compiler/rtm/locking/TestRTMAbortThreshold.java.TestRTMAbortThreshold >>>>> ? >>>>> >>> compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java.TestRTMAfterNonR >>>>> TMDeopt >>>>> ? >>>>> >>> compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java.TestRTMDeopt >>>>> OnHighAbortRatio >>>>> ? >>>>> >>> compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java.TestRTMDeopt >>>>> OnLowAbortRatio >>>>> ? >>>>> >>> compiler/rtm/locking/TestRTMLockingThreshold.java.TestRTMLockingThresh >>>>> old >>>>> ? >>>>> >>> compiler/rtm/locking/TestUseRTMXendForLockBusy.java.TestUseRTMXend >>>>> ForLockBusy >>>>> ? >>>>> >>> compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java.TestPrintPreci >>>>> seRTMLockingStatistics >>>>> >>>>> Exceptions look like this (for all the failures above in order): >>>>> >>>>> java.lang.RuntimeException: Actual abort ratio (10000) should lower or >>> equal >>>>> to specified (100).: expected that 10000 <= 100 >>>>> >>>>> java.lang.RuntimeException: Expected that method with rtm lock elision >>> was >>>>> deoptimized after 1 lock attempts: expected 3320 to equal 1 >>>>> >>>>> java.lang.RuntimeException: Two uncommon traps with reason >>>>> rtm_state_change should be fired.: expected 0 to equal 2 >>>>> >>>>> java.lang.RuntimeException: Expected to get only one deoptimization due >>> to >>>>> rtm state change: expected 0 to equal 1 >>>>> >>>>> java.lang.RuntimeException: Expected to get only one deoptimization due >>> to >>>>> rtm state change: expected 0 to equal 1 >>>>> >>>>> java.lang.RuntimeException: There should be exactly one statistics entry >>>>> corresponding to ProfileRTM state.: expected null to not equal null >>>>> >>>>> java.lang.RuntimeException: VM output should contain exactly one rtm >>>>> locking statistics entry for method compiler.testlibrary.rtm.BusyLock::test: >>>>> expected 0 to equal 1 >>>>> >>>>> java.lang.RuntimeException: RTM locking statistics should contain non >>> zero >>>>> aborts count for abort reason 0: expected 0 > 0 >>>>> >>>>> Since these tests are not excluded I have to assume that either (a) they >>> work >>>>> for you (really?) or (b) that Oracle (or someone else) doesn?t have >>> machines >>>>> that support RTM. > From dmitrij.pochepko at bell-sw.com Mon Jun 25 14:53:41 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Mon, 25 Jun 2018 17:53:41 +0300 Subject: RFR(S): 8205475 - AARCH64: optimize FPU loads and stores in C1_Runtime1_aarch64.cpp Message-ID: <381edc4e-a686-31b5-e26f-593d26bc2683@bell-sw.com> Hi all, please review patch for 8205475 - AARCH64: optimize FPU loads and stores in C1_Runtime1_aarch64.cpp This patch replaces ldpd/stpd instructions with ld1/st1 for saving/restoring registers in C1_Runtime1_aarch64.cpp which is more compact and more beneficial for a number of stubs. webrev: http://cr.openjdk.java.net/~dpochepk/8205475/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8205475 Testing: hotspot jtreg test in fastdebug and release builds. example: ? 0x0000ffff88b23468: ldp?????? d0, d1, [sp], #16 ? 0x0000ffff88b2346c: ldp?????? d2, d3, [sp], #16 ? 0x0000ffff88b23470: ldp?????? d4, d5, [sp], #16 ? 0x0000ffff88b23474: ldp?????? d6, d7, [sp], #16 ? 0x0000ffff88b23478: ldp?????? d8, d9, [sp], #16 ? 0x0000ffff88b2347c: ldp?????? d10, d11, [sp], #16 ? 0x0000ffff88b23480: ldp?????? d12, d13, [sp], #16 ? 0x0000ffff88b23484: ldp?????? d14, d15, [sp], #16 ? 0x0000ffff88b23488: ldp?????? d16, d17, [sp], #16 ? 0x0000ffff88b2348c: ldp?????? d18, d19, [sp], #16 ? 0x0000ffff88b23490: ldp?????? d20, d21, [sp], #16 ? 0x0000ffff88b23494: ldp?????? d22, d23, [sp], #16 ? 0x0000ffff88b23498: ldp?????? d24, d25, [sp], #16 ? 0x0000ffff88b2349c: ldp?????? d26, d27, [sp], #16 ? 0x0000ffff88b234a0: ldp?????? d28, d29, [sp], #16 ? 0x0000ffff88b234a4: ldp?????? d30, d31, [sp], #16 changed to: ? 0x0000ffff9cb23468: ld1?????? {v0.1d-v3.1d}, [sp], #32 ? 0x0000ffff9cb2346c: ld1?????? {v4.1d-v7.1d}, [sp], #32 ? 0x0000ffff9cb23470: ld1?????? {v8.1d-v11.1d}, [sp], #32 ? 0x0000ffff9cb23474: ld1?????? {v12.1d-v15.1d}, [sp], #32 ? 0x0000ffff9cb23478: ld1?????? {v16.1d-v19.1d}, [sp], #32 ? 0x0000ffff9cb2347c: ld1?????? {v20.1d-v23.1d}, [sp], #32 ? 0x0000ffff9cb23480: ld1?????? {v24.1d-v27.1d}, [sp], #32 ? 0x0000ffff9cb23484: ld1?????? {v28.1d-v31.1d}, [sp], #32 Thanks, Dmitrij From aph at redhat.com Mon Jun 25 15:08:08 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 25 Jun 2018 16:08:08 +0100 Subject: RFR(S): 8205475 - AARCH64: optimize FPU loads and stores in C1_Runtime1_aarch64.cpp In-Reply-To: <381edc4e-a686-31b5-e26f-593d26bc2683@bell-sw.com> References: <381edc4e-a686-31b5-e26f-593d26bc2683@bell-sw.com> Message-ID: <6720d2b7-620c-a7b8-c1c1-e377e9e1332d@redhat.com> On 06/25/2018 03:53 PM, Dmitrij Pochepko wrote: > webrev: http://cr.openjdk.java.net/~dpochepk/8205475/webrev.01/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8205475 OK, that looks fine. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Mon Jun 25 15:34:02 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Mon, 25 Jun 2018 18:34:02 +0300 Subject: RFR(S): 8205475 - AARCH64: optimize FPU loads and stores in C1_Runtime1_aarch64.cpp In-Reply-To: <6720d2b7-620c-a7b8-c1c1-e377e9e1332d@redhat.com> References: <381edc4e-a686-31b5-e26f-593d26bc2683@bell-sw.com> <6720d2b7-620c-a7b8-c1c1-e377e9e1332d@redhat.com> Message-ID: <1361e806-17ec-16bb-d915-1e0dfdab624a@bell-sw.com> Thank you for review! On 25.06.2018 18:08, Andrew Haley wrote: > On 06/25/2018 03:53 PM, Dmitrij Pochepko wrote: >> webrev: http://cr.openjdk.java.net/~dpochepk/8205475/webrev.01/ >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8205475 > OK, that looks fine. > From adinn at redhat.com Mon Jun 25 15:43:37 2018 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 25 Jun 2018 16:43:37 +0100 Subject: RFR(S): 8205475 - AARCH64: optimize FPU loads and stores in C1_Runtime1_aarch64.cpp In-Reply-To: <381edc4e-a686-31b5-e26f-593d26bc2683@bell-sw.com> References: <381edc4e-a686-31b5-e26f-593d26bc2683@bell-sw.com> Message-ID: On 25/06/18 15:53, Dmitrij Pochepko wrote: > please review patch for 8205475 - AARCH64: optimize FPU loads and stores > in C1_Runtime1_aarch64.cpp Looks good. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From erik.joelsson at oracle.com Mon Jun 25 15:52:17 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 25 Jun 2018 08:52:17 -0700 Subject: RFR(M): 8205207: Port Graal unit tests under jtreg In-Reply-To: References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com> <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com> <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com> <5116257e-472d-13f5-f800-5e42d800934d@oracle.com> Message-ID: <00f1cb15-8968-5412-e357-79f11d4fd013@oracle.com> Looks ok to me. /Erik On 2018-06-22 15:22, Ekaterina Pavlova wrote: > Fixed and regenerated webrev at the same location: > ?http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html > > Erik, > thanks again for your detailed reviews! > > -katya > > On 6/22/18 2:38 PM, Erik Joelsson wrote: >> Hello Katya, >> >> This looks much better, thanks! >> >> A few suggestions still: >> >> Main.gmk: instead of repeating the assignment in both if and else block: >> >> ifeq ($(INCLUDE_GRAAL), true) >> ?? JVM_TEST_IMAGE_TARGETS += test-image-hotspot-jtreg-graal >> endif >> >> I think it's fine to do that without the ?= because an alternative >> JVM implementation is unlikely to be using graal anyway. >> >> In JtregGraalUnit.gmk: Some minor style nits: >> 54: align )) with first eval line as you have done with the other >> eval calls >> 118: Since 117 is a one line parameter, please move comma to 117 >> 133: Same as for 118 >> 130-132: Please indent 4 spaces for continuation >> >> /Erik >> >> On 2018-06-22 14:16, Ekaterina Pavlova wrote: >>> Erik, Doug, >>> >>> thank you a lot for your reviews and advises. >>> I fixed everything what Erik has pointed out, please see my answers >>> inlined. >>> As about moving more staff in 'updategraalinopenjdk' can we consider >>> this as next step? >>> I am not quite familiar with 'updategraalinopenjdk' and didn't >>> contribute into Graal ws yet, >>> so I will prefer to do this improvement/refactoring as part of >>> separate JDK issue. >>> >>> New webrev is here: >>> ? webrev: >>> http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html >>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 >>> ?testing: tested by building and running graal unit tests >>> >>> >>> On 6/19/18 2:00 PM, Erik Joelsson wrote: >>>> Hello, >>>> >>>> Please always include build-dev when reviewing build changes. >>>> >>>> In general this looks pretty good but there are some details that >>>> need fixing. >>>> >>>> (Aside from this particular review, I must state my reservation >>>> against all the special treatment graal is enjoying from a source >>>> and test layout and build perspective. My understanding here is >>>> that someone will have to regularly update the wrapper jtreg tests >>>> manually using the script. This in addition to having to implement >>>> this very convoluted redirection logic because the tests are in the >>>> wrong place. Wouldn't it make a lot more sense to put the >>>> complicated logic in the import procedure for graal source so that >>>> it would fit nicely into the OpenJDK source/build/test model, >>>> instead of adding more and more complicated workarounds in the >>>> OpenJDK build and test procedures?) >>>> >>>> On 2018-06-18 22:26, Ekaterina Pavlova wrote: >>>>> Hi All, >>>>> >>>>> please review porting of Graal unit tests under jtreg. The main >>>>> idea of this porting is to keep Graal unit tests as is >>>>> (located in src/jdk.internal.vm.compiler/share/classes/*.test) and >>>>> run them similar way they are run in Graal project. >>>>> To achieve this >>>>> test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java >>>>> helper class has been written >>>>> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to >>>>> run specified set of Graal unit tests. The groups of >>>>> Graal unit tests to run are defined in auto-generated >>>>> test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests. >>>>> >>>>> New make/test/JtregGraalUnit.gmk is used to build Graal unit tests >>>>> into jdk.vm.compiler.tests.jar and then install >>>>> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/. >>>>> >>>> GRAALUNIT_LIB is never defined (in the open). Since this is used in >>>> open makefiles, we need an open configure option to set it. >>> >>> ok, I created open/make/autoconf/lib-tests.m4 and did put Graal >>> related staff there. >>> >>>> To make things clearer, I would rename LIB_DIR to something like >>>> LIB_OUTPUTDIR to signal that this is a location to put files in, >>>> rather than read them from. >>> >>> ok, renamed >>> >>>> >>>> FLATTEN has no effect in the SetupCopyFiles call since all the jar >>>> files found by wildcard can only be in one directory anyway. >>> >>> ok, removed >>> >>>> BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. >>>> Tests classes and jars should be built into >>>> $(SUPPORT_OUTPUTDIR)/test/..> Please create a suitable sub >>>> directory there for the output from this makefile. >>> >>> ok, introduced COMPILE_OUTPUTDIR := >>> $(SUPPORT_OUTPUTDIR)/test/graalunit to be used to build graal unit >>> test classes. >>> >>>> The all and test-image targets are never called so no need to >>>> declare them. >>>> >>>> There are some style issues too. (Please see >>>> http://openjdk.java.net/groups/build/doc/code-conventions.html for >>>> details.) >>>> * 43 logic indent 2 spaces >>>> * 52 we like to put the ending )) on a new line with ', \' at the >>>> end of the line before >>>> * 58 continuation indent 4 spaces >>>> * 88, 89 please break long lines >>>> * 90 continuation indent 4 spaces >>>> * 99 continuation indent 4 spaces >>>> * 120 break before )) >>> >>> I think I fixed everything >>> >>>>> make/Main.gmk adds proper dependencies for >>>>> build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal. >>>>> >>>> The target build-test-hotspot-jtreg-graal only needs to depend on >>>> exploded-image-optimize. >>> >>> fixed >>> >>>> The new graal specific targets should be guarded by INCLUDE_GRAAL >>>> in Main.gmk. Otherwise those targets will silently do nothing if >>>> invoked without graal. That means adding them to >>>> JVM_TEST_IMAGE_TARGETS needs to be conditional too. >>> >>> fixed >>> >>>>> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg >>>>> knows where to find Graal tests and libs. >>>>> >>>> This needs to be duplicated for make/RunTest.gmk so that these >>>> tests work with "make run-test" as well. >>> >>> added >>> >>> thanks, >>> -katya >>> >>>> /Erik >>>>> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file >>>>> defines "testName -> testPrefix [requiresStatement]" mapping >>>>> which is used by >>>>> test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to >>>>> generate jtreg tests. >>>>> >>>>> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was >>>>> ported from mx project without any changes. >>>>> >>>>> >>>>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 >>>>> ?webrev: >>>>> http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html >>>>> testing: new tests were executed as part of automatic HS testing >>>>> for several months. >>>>> >>>>> >>>>> thanks, >>>>> -katya >>>>> >>>>> p.s. >>>>> ?Igor Ignatyev volunteered to sponsor this change. >>>> >>> >> > From xueming.shen at oracle.com Mon Jun 25 16:13:40 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 25 Jun 2018 09:13:40 -0700 Subject: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions In-Reply-To: <6563F381B547594081EF9DE181D0791277AAD2D4@FMSMSX119.amr.corp.intel.com> References: <6563F381B547594081EF9DE181D0791277AAD1EC@FMSMSX119.amr.corp.intel.com> <6563F381B547594081EF9DE181D0791277AAD2D4@FMSMSX119.amr.corp.intel.com> Message-ID: <5B3114B4.1090000@oracle.com> Hi Kamath, Instead of throwing an aiobe, should the generateImplEncode() be like void generateImplEncode(byte[] src, int sp, int sl, byte[] dst, int dp) { if (sp < sl) { implEncode(src, sp, sl, dst, dp, ...); } } Any benefit of separating it into its own method? Thanks, Sherman On 6/22/18, 2:49 PM, Kamath, Smita wrote: > Hi Vladimir, > > Please see my answers to your questions as below: > > 1) One question so: why you have own copy of base64 charsets and not using one in library: > I am using vpgatherdd instruction to fetch multiple values from base64 array in a single instruction with a vector index. Vpgatherdd instruction works on 32 bit array and so I need to define base64 charset in a 32 bit array. I have given reference to gather instruction below. > > 2) Some indents in new and old Assembler::emit_operand() are off. In new Assembler::emit_operand() is better use } else { instead of 'return' in one branch. > I'll make the necessary changes and send an updated webrev. > > 3) This is first time I see that XMM register can be used for index in address. Is it true? Can you point to Intel's document which describes it. > I am using vpgatherdd instruction which requires index vector with scale. It uses VSIB addressing where the index register is a zmm register. > Please refer to reference manual, volume 2c, page 2211: https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf > Also see, section 2.3.12, page 524 for VSIB memory addressing information. > > 4) Please, add tests to test/hotspot/jtreg/compiler/intrinsics/base64 (may be similar to sha or AES in compiler/codegen/aes) to make sure that all flags, intrinsic is used and it produces correct result. > I will add test cases as per your suggestion. > > Please let me know if you have additional questions. > > Thanks, > Smita > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Friday, June 22, 2018 12:29 PM > To: Kamath, Smita > Cc: hotspot compiler > Subject: Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions > > Hi Smita, > > I CCing to Libs to review code changes in Base64.java. > > Looks like you changed all need place to implement intrinsic. > One question so: why you have own copy of base64 charsets and not using one in library: > > private int encode0(byte[] src, int off, int end, byte[] dst) { > char[] base64 = isURL ? toBase64URL : toBase64; > > Some indents in new and old Assembler::emit_operand() are off. > > In new Assembler::emit_operand() is better use } else { instead of 'return' in one branch. > > This is first time I see that XMM register can be used for index in address. Is it true? Can you point to Intel's document which describes it. > > What testing you did? > > Please, add tests to test/hotspot/jtreg/compiler/intrinsics/base64 (may be similar to sha or AES in compiler/codegen/aes) to make sure that all flags, intrinsic is used and it produces correct result. > > I know there is test/jdk/java/util/Base64/ tests but they may not trigger intrinsic usage. But you can use them as starting point for new tests. > > Thanks, > Vladimir > > On 6/22/18 11:47 AM, Kamath, Smita wrote: >> Hi Vladimir, >> >> I'd like to contribute an optimization for Base64 Encoding Algorithm >> using AVX512 Instructions. This optimization shows 1.5x improvement on >> x86_64 platform(SKL). >> >> Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8205528 >> >> Link to webrev: >> http://cr.openjdk.java.net/~vdeshpande/Base64/webrev.00/ >> >> For testing the implementation, I have run tests under >> test/jdk/java/util/Base64/ and also ran >> test/jdk/com/sun/jndi/ldap/Base64Test.java >> >> I have also run jtreg. >> >> Please review and let me know if you have any comments. >> >> Thanks and Regards, >> >> Smita >> From martin.doerr at sap.com Mon Jun 25 16:31:32 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 25 Jun 2018 16:31:32 +0000 Subject: RFR(s): 8205582: PPC64: RTM: Fix counter for aborts on nested transactions In-Reply-To: <8aadb20a-fba7-0c52-04c0-015a731e60bd@linux.vnet.ibm.com> References: <8aadb20a-fba7-0c52-04c0-015a731e60bd@linux.vnet.ibm.com> Message-ID: <571b4e4aa8d04c55a2c68d655aff4023@sap.com> Hi Gustavo, thanks for addressing this issue. I think it would be better to ignore bit 63 in the macroAssembler code and use the definition from the spec in assembler_ppc.hpp. Somebody may want to use the definition for other purposes. I wonder if Assembler::tm_trans_cf | Assembler::tm_non_trans_cf would be a better match for x86's description for tm_failure_bit[2]. It's also a little unfortunate to print the same bit twice as tm_failure_bit[4]. Best regards, Martin -----Original Message----- From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] Sent: Montag, 25. Juni 2018 10:19 To: Lindenmaier, Goetz ; Doerr, Martin ; hotspot-compiler-dev at openjdk.java.net Cc: ppc-aix-port-dev at openjdk.java.net Subject: RFR(s): 8205582: PPC64: RTM: Fix counter for aborts on nested transactions Hi, Could the following change be reviewed please? bug : https://bugs.openjdk.java.net/browse/JDK-8205582 webrev: http://cr.openjdk.java.net/~gromero/8205582/v1/ It fixes the RTM counter for nested aborts (rtm lock aborts type 5) by extracting and checking bits in the Transactional Level field of TEXASR register. It also fixes the memory conflict counter (rtm lock aborts type 2). Power TM status register supports two bits to inform two different types of memory conflict between threads: non-transactional and transactional. According to how the jtreg RTM tests are designed the memory conflict counter counts non-transactional conflicts: on TestPrintPreciseRTMLockingStatistics a RTM lock is held on a static variable while another thread without any synchronization (non-trasactional) tries to modify the same variable. Hence that small adjustment satisfies the TestPrintPreciseRTMLockingStatistics making it pass on Power. The memory conflict counter is not used in any other place besides by the RTM precise statistics (no decision is made by the JVM based on that amount). This change partially fixes some failures in compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java regarding the nested and memory conflict abort counters. The remaining issue will be fixed by aborting on calling JNI (next RFR). Thank you and best regards, Gustavo From paul.sandoz at oracle.com Mon Jun 25 16:32:18 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 25 Jun 2018 09:32:18 -0700 Subject: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions In-Reply-To: <3fc63a04-984b-d101-c5ac-a811f285d35c@oracle.com> References: <6563F381B547594081EF9DE181D0791277AAD1EC@FMSMSX119.amr.corp.intel.com> <13665270-28A9-498D-A5BC-0CCCE1402856@oracle.com> <6563F381B547594081EF9DE181D0791277AAD2F6@FMSMSX119.amr.corp.intel.com> <71BBF912-081E-4385-8940-B8FE802F6699@oracle.com> <6563F381B547594081EF9DE181D0791277AAD356@FMSMSX119.amr.corp.intel.com> <3fc63a04-984b-d101-c5ac-a811f285d35c@oracle.com> Message-ID: <3844C8EE-A299-4434-9341-833E3E5177B1@oracle.com> > On Jun 22, 2018, at 5:17 PM, Vladimir Kozlov wrote: > > On 6/22/18 3:58 PM, Paul Sandoz wrote: >> Hi Smita, >> I am ok with it if Vladimir is :-) One slight concern is this may be biasing towards the x86 implementation of the intrinsic. > > Looking on code and it will be a lot of changes in Base64.java. I am concern about that late in JDK 11. > > I think we should keep duplicated code for x86 intrinsic as Smita suggested. And we can return to this when/if we intrinsify Decoder too. > Agreed. Paul. >> I dunno if an int[] table is as useful for an AARCH64 intrinsic. > > We should ask RH to check. > > But I think SPARC is better operating on 32-bit values than 16-bit (at least it was issue before). > > Vladimir > From martin.doerr at sap.com Mon Jun 25 16:37:09 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 25 Jun 2018 16:37:09 +0000 Subject: RFR(s): 8205581: PPC64: RTM: Fix abort on native calls In-Reply-To: References: Message-ID: <86a9e4085b424a58a28436415786e312@sap.com> Hi Gustavo, I wonder why you placed the tabort so late in generate_native_wrapper. I'd put it at the Verified Entry Point. Besides that, it looks good to me. Thanks, Martin -----Original Message----- From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] Sent: Montag, 25. Juni 2018 10:21 To: Lindenmaier, Goetz ; Doerr, Martin ; hotspot-compiler-dev at openjdk.java.net Cc: ppc-aix-port-dev at openjdk.java.net Subject: RFR(s): 8205581: PPC64: RTM: Fix abort on native calls Hi, Could the following change be reviewed please? bug : https://bugs.openjdk.java.net/browse/JDK-8205581 webrev: http://cr.openjdk.java.net/~gromero/8205581/v1/ It forces a transactional state to abort before calling native methods, before calling runtime, and on uncommon trap checking, mostly because transaction will be aborted soon or latter in either case, similarly to what happens on Intel. The abort instruction (tabort) is only emitted if UseRTMLocking is "true" and any 'tabort' instruction is treated as a 'nop' instruction if TM state is non-transactional. It fixes the following tests: +Passed: compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java +Passed: compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java Thank you and best regards, Gustavo From martin.doerr at sap.com Mon Jun 25 16:49:50 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 25 Jun 2018 16:49:50 +0000 Subject: RFR(s): 8205580: PPC64: RTM: Don't retry lock on abort if abort was intentional In-Reply-To: References: Message-ID: Hi Gustavo, Looks good for the case UseRTMXendForLockBusy is active (which is default). If this flag is deactivated, we use tabort if we see the object locked so your change prevents retrying the transaction in this case. I guess this was not intended? Thanks and best regards, Martin -----Original Message----- From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] Sent: Montag, 25. Juni 2018 10:24 To: Lindenmaier, Goetz ; Doerr, Martin ; hotspot-compiler-dev at openjdk.java.net Cc: ppc-aix-port-dev at openjdk.java.net Subject: RFR(s): 8205580: PPC64: RTM: Don't retry lock on abort if abort was intentional Hi, Could the following change be reviewed please? bug : https://bugs.openjdk.java.net/browse/JDK-8205580 webrev: http://cr.openjdk.java.net/~gromero/8205580/v1/ It changes the behavior of rtm_retry_lock_on_abort() by avoiding retry if abort was a deliberate abort, i.e. caused by a 'tabort r0' instruction. On Intel bit 1 in abort_status_Reg (which communicates the abort status) is always clear when a 'xabort 0' instruction is executed in order to inform that a transactional retry /can not/ succeed on retry. So rtm_retry_lock_on_abort() on Intel, on finding bit 1 clear in abort_status_Reg, skips the retry (don't retry). Currently on Power rtm_retry_lock_on_abort() is just checking the persistent bit (if set => skip) which /is not set/ by 'tabort r0'. Hence rtm_retry_lock_on_abort() does retry to lock on an intentional abort caused by 'tabort'. It leads, for instance when -XX:RTMRetryCount=1, to the following discrepancy between Intel and Power regarding the number of retries/aborts: [Power] # rtm locks total (estimated): 3 # rtm lock aborts : 3 # rtm lock aborts 0: 3 # rtm lock aborts 1: 3 # rtm lock aborts 2: 0 # rtm lock aborts 3: 0 # rtm lock aborts 4: 0 # rtm lock aborts 5: 0 [Intel] # rtm locks total (estimated): 2 # rtm lock aborts : 2 # rtm lock aborts 0: 2 # rtm lock aborts 1: 2 # rtm lock aborts 2: 0 # rtm lock aborts 3: 0 # rtm lock aborts 4: 0 # rtm lock aborts 5: 0 So for -XX:RTMRetryCount=X: on Power the number of aborts is: X*2+1 [1 first failure + 1 rtm_retry_lock_on_abort() + 1 rtm_retry_lock_on_busy()]; on Intel the number of aborts is: X+1 [1 first failure + 1 rtm_retry_lock_on_busy()] This change fixes that discrepancy by using bit "Abort" in TEXASR register (abort_status_Reg) that tells if a transaction was aborted due to a 'tabort' instruction and skip the retry if such a bit is set. It fixes the following tests: +Passed: compiler/rtm/locking/TestRTMRetryCount.java +Passed: compiler/rtm/locking/TestRTMAbortThreshold.java Thank you and best regards, Gustavo From vladimir.kozlov at oracle.com Mon Jun 25 17:21:40 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 25 Jun 2018 10:21:40 -0700 Subject: RFR(xs): 8205390: jtreg: Fix failing TestRTMSpinLoopCount on PPC64 In-Reply-To: References: Message-ID: <13b30945-b86b-5c4e-c92b-a47b7ed425d3@oracle.com> Good. Thanks, Vladimir On 6/25/18 1:31 AM, Gustavo Romero wrote: > Hi, > > Could the following change be reviewed please? > > bug?? : https://bugs.openjdk.java.net/browse/JDK-8205390 > webrev: http://cr.openjdk.java.net/~gromero/8205390/v1/ > > It adds a new throttling sequence for PPC64 because the last value on > current > sequence does not fit on PPC64. > > By using the new sequence the following test is fixed: > > +Passed: compiler/rtm/locking/TestRTMSpinLoopCount.java > > > Thank you and best regards, > Gustavo > From dmitrij.pochepko at bell-sw.com Mon Jun 25 17:28:52 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Mon, 25 Jun 2018 20:28:52 +0300 Subject: RFR(S): 8205475 - AARCH64: optimize FPU loads and stores in C1_Runtime1_aarch64.cpp In-Reply-To: References: <381edc4e-a686-31b5-e26f-593d26bc2683@bell-sw.com> Message-ID: Thank you for review! On 25.06.2018 18:43, Andrew Dinn wrote: > On 25/06/18 15:53, Dmitrij Pochepko wrote: >> please review patch for 8205475 - AARCH64: optimize FPU loads and stores >> in C1_Runtime1_aarch64.cpp > Looks good. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From vladimir.kozlov at oracle.com Mon Jun 25 17:48:09 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 25 Jun 2018 10:48:09 -0700 Subject: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions In-Reply-To: <6563F381B547594081EF9DE181D0791277AAD2D4@FMSMSX119.amr.corp.intel.com> References: <6563F381B547594081EF9DE181D0791277AAD1EC@FMSMSX119.amr.corp.intel.com> <6563F381B547594081EF9DE181D0791277AAD2D4@FMSMSX119.amr.corp.intel.com> Message-ID: <980cfd3b-a6c1-eeda-3add-3165feea4fb9@oracle.com> I forgot to reply to your answers. On 6/22/18 2:49 PM, Kamath, Smita wrote: > Hi Vladimir, > > Please see my answers to your questions as below: > > 1) One question so: why you have own copy of base64 charsets and not using one in library: > I am using vpgatherdd instruction to fetch multiple values from base64 array in a single instruction with a vector index. Vpgatherdd instruction works on 32 bit array and so I need to define base64 charset in a 32 bit array. I have given reference to gather instruction below. As was discussed in an other e-mail lets keep your copy. > > 2) Some indents in new and old Assembler::emit_operand() are off. In new Assembler::emit_operand() is better use } else { instead of 'return' in one branch. > I'll make the necessary changes and send an updated webrev. > > 3) This is first time I see that XMM register can be used for index in address. Is it true? Can you point to Intel's document which describes it. > I am using vpgatherdd instruction which requires index vector with scale. It uses VSIB addressing where the index register is a zmm register. > Please refer to reference manual, volume 2c, page 2211: https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf > Also see, section 2.3.12, page 524 for VSIB memory addressing information. Got it. Thanks for document reference. > > 4) Please, add tests to test/hotspot/jtreg/compiler/intrinsics/base64 (may be similar to sha or AES in compiler/codegen/aes) to make sure that all flags, intrinsic is used and it produces correct result. > I will add test cases as per your suggestion. Thanks, Vladimir > > Please let me know if you have additional questions. > > Thanks, > Smita > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Friday, June 22, 2018 12:29 PM > To: Kamath, Smita > Cc: hotspot compiler > Subject: Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions > > Hi Smita, > > I CCing to Libs to review code changes in Base64.java. > > Looks like you changed all need place to implement intrinsic. > One question so: why you have own copy of base64 charsets and not using one in library: > > private int encode0(byte[] src, int off, int end, byte[] dst) { > char[] base64 = isURL ? toBase64URL : toBase64; > > Some indents in new and old Assembler::emit_operand() are off. > > In new Assembler::emit_operand() is better use } else { instead of 'return' in one branch. > > This is first time I see that XMM register can be used for index in address. Is it true? Can you point to Intel's document which describes it. > > What testing you did? > > Please, add tests to test/hotspot/jtreg/compiler/intrinsics/base64 (may be similar to sha or AES in compiler/codegen/aes) to make sure that all flags, intrinsic is used and it produces correct result. > > I know there is test/jdk/java/util/Base64/ tests but they may not trigger intrinsic usage. But you can use them as starting point for new tests. > > Thanks, > Vladimir > > On 6/22/18 11:47 AM, Kamath, Smita wrote: >> Hi Vladimir, >> >> I'd like to contribute an optimization for Base64 Encoding Algorithm >> using AVX512 Instructions. This optimization shows 1.5x improvement on >> x86_64 platform(SKL). >> >> Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8205528 >> >> Link to webrev: >> http://cr.openjdk.java.net/~vdeshpande/Base64/webrev.00/ >> >> For testing the implementation, I have run tests under >> test/jdk/java/util/Base64/ and also ran >> test/jdk/com/sun/jndi/ldap/Base64Test.java >> >> I have also run jtreg. >> >> Please review and let me know if you have any comments. >> >> Thanks and Regards, >> >> Smita >> From ekaterina.pavlova at oracle.com Mon Jun 25 19:47:06 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Mon, 25 Jun 2018 12:47:06 -0700 Subject: RFR(M): 8205207: Port Graal unit tests under jtreg In-Reply-To: <00f1cb15-8968-5412-e357-79f11d4fd013@oracle.com> References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com> <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com> <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com> <5116257e-472d-13f5-f800-5e42d800934d@oracle.com> <00f1cb15-8968-5412-e357-79f11d4fd013@oracle.com> Message-ID: <90f60412-c7ec-d9f8-af88-946e383c867f@oracle.com> Thanks Erik! -katya On 6/25/18 8:52 AM, Erik Joelsson wrote: > Looks ok to me. > > /Erik > > > On 2018-06-22 15:22, Ekaterina Pavlova wrote: >> Fixed and regenerated webrev at the same location: >> ?http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html >> >> Erik, >> thanks again for your detailed reviews! >> >> -katya >> >> On 6/22/18 2:38 PM, Erik Joelsson wrote: >>> Hello Katya, >>> >>> This looks much better, thanks! >>> >>> A few suggestions still: >>> >>> Main.gmk: instead of repeating the assignment in both if and else block: >>> >>> ifeq ($(INCLUDE_GRAAL), true) >>> ?? JVM_TEST_IMAGE_TARGETS += test-image-hotspot-jtreg-graal >>> endif >>> >>> I think it's fine to do that without the ?= because an alternative JVM implementation is unlikely to be using graal anyway. >>> >>> In JtregGraalUnit.gmk: Some minor style nits: >>> 54: align )) with first eval line as you have done with the other eval calls >>> 118: Since 117 is a one line parameter, please move comma to 117 >>> 133: Same as for 118 >>> 130-132: Please indent 4 spaces for continuation >>> >>> /Erik >>> >>> On 2018-06-22 14:16, Ekaterina Pavlova wrote: >>>> Erik, Doug, >>>> >>>> thank you a lot for your reviews and advises. >>>> I fixed everything what Erik has pointed out, please see my answers inlined. >>>> As about moving more staff in 'updategraalinopenjdk' can we consider this as next step? >>>> I am not quite familiar with 'updategraalinopenjdk' and didn't contribute into Graal ws yet, >>>> so I will prefer to do this improvement/refactoring as part of separate JDK issue. >>>> >>>> New webrev is here: >>>> ? webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html >>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 >>>> ?testing: tested by building and running graal unit tests >>>> >>>> >>>> On 6/19/18 2:00 PM, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> Please always include build-dev when reviewing build changes. >>>>> >>>>> In general this looks pretty good but there are some details that need fixing. >>>>> >>>>> (Aside from this particular review, I must state my reservation against all the special treatment graal is enjoying from a source and test layout and build perspective. My understanding here is that someone will have to regularly update the wrapper jtreg tests manually using the script. This in addition to having to implement this very convoluted redirection logic because the tests are in the wrong place. Wouldn't it make a lot more sense to put the complicated logic in the import procedure for graal source so that it would fit nicely into the OpenJDK source/build/test model, instead of adding more and more complicated workarounds in the OpenJDK build and test procedures?) >>>>> >>>>> On 2018-06-18 22:26, Ekaterina Pavlova wrote: >>>>>> Hi All, >>>>>> >>>>>> please review porting of Graal unit tests under jtreg. The main idea of this porting is to keep Graal unit tests as is >>>>>> (located in src/jdk.internal.vm.compiler/share/classes/*.test) and run them similar way they are run in Graal project. >>>>>> To achieve this test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java helper class has been written >>>>>> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to run specified set of Graal unit tests. The groups of >>>>>> Graal unit tests to run are defined in auto-generated test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests. >>>>>> >>>>>> New make/test/JtregGraalUnit.gmk is used to build Graal unit tests into jdk.vm.compiler.tests.jar and then install >>>>>> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/. >>>>>> >>>>> GRAALUNIT_LIB is never defined (in the open). Since this is used in open makefiles, we need an open configure option to set it. >>>> >>>> ok, I created open/make/autoconf/lib-tests.m4 and did put Graal related staff there. >>>> >>>>> To make things clearer, I would rename LIB_DIR to something like LIB_OUTPUTDIR to signal that this is a location to put files in, rather than read them from. >>>> >>>> ok, renamed >>>> >>>>> >>>>> FLATTEN has no effect in the SetupCopyFiles call since all the jar files found by wildcard can only be in one directory anyway. >>>> >>>> ok, removed >>>> >>>>> BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. Tests classes and jars should be built into $(SUPPORT_OUTPUTDIR)/test/..> Please create a suitable sub directory there for the output from this makefile. >>>> >>>> ok, introduced COMPILE_OUTPUTDIR := $(SUPPORT_OUTPUTDIR)/test/graalunit to be used to build graal unit test classes. >>>> >>>>> The all and test-image targets are never called so no need to declare them. >>>>> >>>>> There are some style issues too. (Please see http://openjdk.java.net/groups/build/doc/code-conventions.html for details.) >>>>> * 43 logic indent 2 spaces >>>>> * 52 we like to put the ending )) on a new line with ', \' at the end of the line before >>>>> * 58 continuation indent 4 spaces >>>>> * 88, 89 please break long lines >>>>> * 90 continuation indent 4 spaces >>>>> * 99 continuation indent 4 spaces >>>>> * 120 break before )) >>>> >>>> I think I fixed everything >>>> >>>>>> make/Main.gmk adds proper dependencies for build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal. >>>>>> >>>>> The target build-test-hotspot-jtreg-graal only needs to depend on exploded-image-optimize. >>>> >>>> fixed >>>> >>>>> The new graal specific targets should be guarded by INCLUDE_GRAAL in Main.gmk. Otherwise those targets will silently do nothing if invoked without graal. That means adding them to JVM_TEST_IMAGE_TARGETS needs to be conditional too. >>>> >>>> fixed >>>> >>>>>> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg knows where to find Graal tests and libs. >>>>>> >>>>> This needs to be duplicated for make/RunTest.gmk so that these tests work with "make run-test" as well. >>>> >>>> added >>>> >>>> thanks, >>>> -katya >>>> >>>>> /Erik >>>>>> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file defines "testName -> testPrefix [requiresStatement]" mapping >>>>>> which is used by test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to generate jtreg tests. >>>>>> >>>>>> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was ported from mx project without any changes. >>>>>> >>>>>> >>>>>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 >>>>>> ?webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html >>>>>> testing: new tests were executed as part of automatic HS testing for several months. >>>>>> >>>>>> >>>>>> thanks, >>>>>> -katya >>>>>> >>>>>> p.s. >>>>>> ?Igor Ignatyev volunteered to sponsor this change. >>>>> >>>> >>> >> > From gromero at linux.vnet.ibm.com Mon Jun 25 20:35:28 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 25 Jun 2018 17:35:28 -0300 Subject: RFR(xs): 8205390: jtreg: Fix failing TestRTMSpinLoopCount on PPC64 In-Reply-To: <13b30945-b86b-5c4e-c92b-a47b7ed425d3@oracle.com> References: <13b30945-b86b-5c4e-c92b-a47b7ed425d3@oracle.com> Message-ID: On 06/25/2018 02:21 PM, Vladimir Kozlov wrote: > Good. Thanks for reviewing it Vladimir! Regards, Gustavo > Thanks, > Vladimir > > On 6/25/18 1:31 AM, Gustavo Romero wrote: >> Hi, >> >> Could the following change be reviewed please? >> >> bug?? : https://bugs.openjdk.java.net/browse/JDK-8205390 >> webrev: http://cr.openjdk.java.net/~gromero/8205390/v1/ >> >> It adds a new throttling sequence for PPC64 because the last value on current >> sequence does not fit on PPC64. >> >> By using the new sequence the following test is fixed: >> >> +Passed: compiler/rtm/locking/TestRTMSpinLoopCount.java >> >> >> Thank you and best regards, >> Gustavo >> > From nils.eliasson at oracle.com Mon Jun 25 21:08:49 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 25 Jun 2018 23:08:49 +0200 Subject: RFR(S): 8205107: assert(c->Opcode() == Op_SafePoint) failed: broken outer loop In-Reply-To: <3b5fd81c-b69e-888e-dcd6-f969ecaa5601@oracle.com> References: <06ce5035-4eb9-d56f-0a46-7188c3e74b6c@oracle.com> <26c32258-1e42-01cd-fb64-0ff4cd4ff0b8@oracle.com> <185a0fd0-6876-a6e4-d647-9bde5a7f89cf@oracle.com> <5521318c-ed90-9d04-5cc2-2dbd964dcf63@oracle.com> <1e09c221-7c6e-093c-6dc8-53759eb162ea@oracle.com> <0c2b7c85-71ec-3bd5-ac31-6715f32a5c90@oracle.com> <3b5fd81c-b69e-888e-dcd6-f969ecaa5601@oracle.com> Message-ID: <358db601-ae00-56dc-5b02-7157ca88044d@oracle.com> On 2018-06-21 19:26, Vladimir Kozlov wrote: > On 6/21/18 7:54 AM, Nils Eliasson wrote: >> >> >> On 2018-06-20 21:33, Vladimir Kozlov wrote: >>> On 6/20/18 12:22 PM, Nils Eliasson wrote: >>>> >>>> >>>> On 2018-06-20 18:32, Vladimir Kozlov wrote: >>>>> On 6/20/18 2:01 AM, Nils Eliasson wrote: >>>>>> I simplified it to: >>>>>> >>>>>> ?? virtual bool guaranteed_safepoint() { >>>>>> ?????? // Calls to boxing methods will be expanded, and >>>>>> safepoints aren't guaranteed >>>>>> ?????? return !is_boxing_method(); >>>>>> ?? } >>>>>> >>>>>> is_boxing_method() checks is_macro() that checks the >>>>>> Flag_is_macro which is only set when C->eliminate_boxing() is true. >>>>> >>>>> Okay. >>>>> >>>>>> >>>>>> "(proj_out_or_null(TypeFunc::Parms) == NULL));" seems redundant >>>>>> too me. What would that guard against? >>>>> >>>>> It checks that result of the call is not used (Box object is >>>>> eliminated by EA). It is needed otherwise you will get bad graph. >>>> >>>> We don't need that check since we prevent an optimization for >>>> happening. The graph is kept as it is. >>> >>> So the result is only used by Safepoint? Then how it is eliminated >>> later? >> >> It has other uses also. I'm not sure why the call is left, I will >> investigate it further and can file a seperate bug if it is something >> wrong. > > It is not wrong to have a Call node and Safepoint in a loop. It is > just not optimal - that is all. > I remember that it could be cases when even if boxing call is marked > as not escaping (or scalar replaceable) it may not be eliminated > because of it has still have some uses left which were not removed for > different reasons. > I agree that it is not easy problem. The problem with the test is related to Xcomp. It refuses to inline valueOf beacuse it isn't loaded. The output gets confusing beacuse it delays the inline until the macro-expansion, and then it reports "failed inital checks". Running in normal mode makes it behave as expected. > > >> >> For this bug the problem is that we have a strip mined loop which >> must have a safepoint. That safepoint can only be removed together >> with the OuterStripMinedLoop. >> >> I change my mind and think my webrev.02 is the best fix - make >> SafePoint::Identity to never substitute a strip-mine-loop safepoint. >> >> http://cr.openjdk.java.net/~neliasso/8205107/webrev.02 > > Okay, but please extend your comment to explain when we can have a > Boxing Call node which may be late removed in Macro extension phase > leaving loop without safepoint. This change guarantees that the (OuterStripMinedLoop) safepoint doesn't get removed, even though a very unlikely call is left in the countedloop. // Nils > > Thanks, > Vladimir > >> >> // Nils >>> >>> Hmm, may be check _is_scalar_replaceable instead. >>> >>> Vladimir >>> >>>> >>>> This is the graph: >>>> >>>> Integer.valueOf >>>> ???? | >>>> CatchProj >>>> ???? | >>>> SafePoint >>>> ???? | >>>> OuterCountedLoopEnd >>>> >>>> The original problem is that the SafePoint was removed because the >>>> Integer.valueOf reported that it guarantees a safepoint. With the >>>> change - guaranteed_safepoint() returns false for boxes - no >>>> safepoint removal is done, the graph is kept intact. >>>> >>>> Regards, >>>> >>>> Nils >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> New webrev here: >>>>>> http://cr.openjdk.java.net/~neliasso/8205107/webrev.03/ >>>>>> >>>>>> Thanks for the help! >>>>>> >>>>>> Nils >>>>>> >>>>>> >>>>>> >>>>>> On 2018-06-19 19:18, Vladimir Kozlov wrote: >>>>>>> On 6/19/18 9:01 AM, Vladimir Kozlov wrote: >>>>>>>> On 6/19/18 7:22 AM, Nils Eliasson wrote: >>>>>>>>> I looked at it in a bit more detail. >>>>>>>>> >>>>>>>>> The call is a java/lang/Integer::valueOf that is considered a >>>>>>>>> macro node so it is kept around until macro expansion which >>>>>>>>> happens after the place where we hit the assert. So the call >>>>>>>>> will go away. >>>>>>>> >>>>>>>> I assume you are talking about eliminate_boxing_node() in macro >>>>>>>> expansion. >>>>>>>> >>>>>>>>> >>>>>>>>> However SafepointNode::Identity does check: >>>>>>>>> >>>>>>>>> if( n0->is_Call() && n0->as_Call()->guaranteed_safepoint() ) { >>>>>>>>> ?????? // Useless Safepoint, so remove it >>>>>>>>> >>>>>>>>> And CallNode::guaranteed_safepoint() is: >>>>>>>>> >>>>>>>>> ?? // Are we guaranteed that this node is a safepoint? Not >>>>>>>>> true for leaf calls and >>>>>>>>> ?? // for some macro nodes whose expansion does not have a >>>>>>>>> safepoint on the fast path. >>>>>>>>> ?? virtual bool??????? guaranteed_safepoint()? { return true; } >>>>>>>>> >>>>>>>>> No check for call/macro-nodes is implemeted despite the >>>>>>>>> comment! If I fix this the problem goes away. >>>>>>>> >>>>>>>> It returns false for Allocate nodes which are macro nodes. That >>>>>>>> is what comment says. >>>>>>>> >>>>>>>> In case of boxing node I think we should add to >>>>>>>> CallStaticJavaNode class >>>>>>>> >>>>>>>> ?? // Boxing call which is not used and will be removed. >>>>>>>> ?? virtual bool??????? guaranteed_safepoint()? { return >>>>>>>> C->eliminate_boxing() && is_boxing_method() && >>>>>>>> (proj_out_or_null(TypeFunc::Parms) == NULL); } >>>>>>> >>>>>>> Sorry, test should be reversed because it guarantee SP if call >>>>>>> is *not* removed: >>>>>>> >>>>>>> virtual bool??????? guaranteed_safepoint()? { return >>>>>>> !(C->eliminate_boxing() && is_boxing_method() && >>>>>>> (proj_out_or_null(TypeFunc::Parms) == NULL)); } >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> >>>>>>>>> // Nils >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2018-06-18 15:41, Roland Westrelin wrote: >>>>>>>>>>> Roland, why we need to keep Safepoint in Outer loop if we >>>>>>>>>>> have call? >>>>>>>>>> I double checked with a simple test case and we don't keep >>>>>>>>>> the safepoint >>>>>>>>>> if there's a call so it's indeed strange that we would need >>>>>>>>>> Nils' patch. >>>>>>>>>> >>>>>>>>>> Roland. >>>>>>>>> >>>>>> >>>> >> From gromero at linux.vnet.ibm.com Mon Jun 25 21:32:18 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 25 Jun 2018 18:32:18 -0300 Subject: [11] RTM tests fail In-Reply-To: References: <515395B7-31C9-4502-A9A1-323DB768280C@twitter.com> <25bbc06005eb4e929f2bcd697618e3f8@sap.com> <8f31a45d24f84732ae7915f22aae61a5@sap.com> <26e36040-4b08-8293-21d8-ca770b945f57@linux.vnet.ibm.com> Message-ID: <70dca568-53b3-695d-f135-ac6e1f152529@linux.vnet.ibm.com> Hi Christian, On 06/25/2018 09:54 AM, Christian Thalinger wrote: > > >> On Jun 25, 2018, at 8:49 AM, Gustavo Romero wrote: >> >> On 06/25/2018 09:46 AM, Lindenmaier, Goetz wrote: >>>>> Did you check with or without these fixes? >>>> >>>> Without, unfortunately. Are all of the failures fixed now (in jdk-11+19)? >>> I don't know, our machines do not have RTM, only our Power ones do. >>> But I think Gustavo Romero from IBM claimed so. >> >> Yup, after the three fixes Goetz mentioned all RTM tests must pass on Intel. > > Ok, I?ll get back to you? Yes, please let me know if all went fine :) I checked again the current state on Intel (jdk/jdk tip) and all tests passed. After applying the fixes it's good to verify if there isn't a stale ./JTwork by deleting it. If that helps, find below some information about the system: gromero at moog:~/hg/jdk/jdk$ uname -a Linux moog 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux gromero at moog:~/hg/jdk/jdk$ lscpu | egrep "rtm|Model" Model: 94 Model name: Intel(R) Xeon(R) CPU E3-1280 v5 @ 3.70GHz Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb invpcid_single intel_pt retpoline kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp gromero at moog:~/hg/jdk/jdk$ JT_JAVA=/usr/lib/jvm/java-8-openjdk-amd64 /home/gromero/jtreg/bin/jtreg -v1 -conc:20 -jdk:./build/linux-x86_64-normal-server-release/jdk/ ./test/hotspot/jtreg/compiler/rtm Passed: compiler/rtm/cli/TestRTMLockingThresholdOption.java Passed: compiler/rtm/cli/TestRTMLockingCalculationDelayOption.java Passed: compiler/rtm/cli/TestUseRTMXendForLockBusyOption.java Passed: compiler/rtm/cli/TestRTMRetryCountOption.java Passed: compiler/rtm/cli/TestRTMAbortThresholdOption.java Passed: compiler/rtm/cli/TestRTMSpinLoopCountOption.java Passed: compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java Passed: compiler/rtm/locking/TestUseRTMAfterLockInflation.java Passed: compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java Passed: compiler/rtm/locking/TestUseRTMForInflatedLocks.java Passed: compiler/rtm/locking/TestUseRTMForStackLocks.java Passed: compiler/rtm/locking/TestRTMLockingCalculationDelay.java Passed: compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java Passed: compiler/rtm/locking/TestUseRTMDeopt.java Passed: compiler/rtm/method_options/TestUseRTMLockElidingOption.java Passed: compiler/rtm/method_options/TestNoRTMLockElidingOption.java Passed: compiler/rtm/locking/TestRTMAbortThreshold.java Passed: compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java Passed: compiler/rtm/locking/TestRTMTotalCountIncrRate.java Passed: compiler/rtm/locking/TestRTMAbortRatio.java Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java Passed: compiler/rtm/locking/TestRTMRetryCount.java Passed: compiler/rtm/locking/TestRTMLockingThreshold.java Passed: compiler/rtm/locking/TestRTMSpinLoopCount.java Passed: compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java Passed: compiler/rtm/locking/TestUseRTMXendForLockBusy.java Test results: passed: 30 I also ran it with -conc:1: gromero at moog:~/hg/jdk/jdk$ JT_JAVA=/usr/lib/jvm/java-8-openjdk-amd64 /home/gromero/jtreg/bin/jtreg -v1 -conc:1 -jdk:./build/linux-x86_64-normal-server-release/jdk/ ./test/hotspot/jtreg/compiler/rtm Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java Passed: compiler/rtm/cli/TestRTMAbortThresholdOption.java Passed: compiler/rtm/cli/TestRTMLockingCalculationDelayOption.java Passed: compiler/rtm/cli/TestRTMLockingThresholdOption.java Passed: compiler/rtm/cli/TestRTMRetryCountOption.java Passed: compiler/rtm/cli/TestRTMSpinLoopCountOption.java Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java Passed: compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java Passed: compiler/rtm/cli/TestUseRTMXendForLockBusyOption.java Passed: compiler/rtm/locking/TestRTMAbortRatio.java Passed: compiler/rtm/locking/TestRTMAbortThreshold.java Passed: compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java Passed: compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java Passed: compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java Passed: compiler/rtm/locking/TestRTMLockingCalculationDelay.java Passed: compiler/rtm/locking/TestRTMLockingThreshold.java Passed: compiler/rtm/locking/TestRTMRetryCount.java Passed: compiler/rtm/locking/TestRTMSpinLoopCount.java Passed: compiler/rtm/locking/TestRTMTotalCountIncrRate.java Passed: compiler/rtm/locking/TestUseRTMAfterLockInflation.java Passed: compiler/rtm/locking/TestUseRTMDeopt.java Passed: compiler/rtm/locking/TestUseRTMForInflatedLocks.java Passed: compiler/rtm/locking/TestUseRTMForStackLocks.java Passed: compiler/rtm/locking/TestUseRTMXendForLockBusy.java Passed: compiler/rtm/method_options/TestNoRTMLockElidingOption.java Passed: compiler/rtm/method_options/TestUseRTMLockElidingOption.java Passed: compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java Test results: passed: 30 Regards, Gustavo >> >> >> Regards, >> Gustavo >> >>> Best regards, >>> Goetz. >>>> >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>>> -----Original Message----- >>>>>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- >>>>>> bounces at openjdk.java.net] On Behalf Of Christian Thalinger >>>>>> Sent: Montag, 25. Juni 2018 14:17 >>>>>> To: hotspot compiler >>>>>> Subject: [11] RTM tests fail >>>>>> >>>>>> Hi! Is anyone running the compiler/rtm/ tests on a machine that actually >>>>>> supports RTM? >>>>>> >>>>>> Every time one of our nightly jobs ends up on a machine that supports >>>> RTM a >>>>>> bunch of locking tests and the print test fail: >>>>>> >>>>>> ? compiler/rtm/locking/TestRTMAbortRatio.java.TestRTMAbortRatio >>>>>> ? >>>>>> >>>> compiler/rtm/locking/TestRTMAbortThreshold.java.TestRTMAbortThreshold >>>>>> ? >>>>>> >>>> compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java.TestRTMAfterNonR >>>>>> TMDeopt >>>>>> ? >>>>>> >>>> compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java.TestRTMDeopt >>>>>> OnHighAbortRatio >>>>>> ? >>>>>> >>>> compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java.TestRTMDeopt >>>>>> OnLowAbortRatio >>>>>> ? >>>>>> >>>> compiler/rtm/locking/TestRTMLockingThreshold.java.TestRTMLockingThresh >>>>>> old >>>>>> ? >>>>>> >>>> compiler/rtm/locking/TestUseRTMXendForLockBusy.java.TestUseRTMXend >>>>>> ForLockBusy >>>>>> ? >>>>>> >>>> compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java.TestPrintPreci >>>>>> seRTMLockingStatistics >>>>>> >>>>>> Exceptions look like this (for all the failures above in order): >>>>>> >>>>>> java.lang.RuntimeException: Actual abort ratio (10000) should lower or >>>> equal >>>>>> to specified (100).: expected that 10000 <= 100 >>>>>> >>>>>> java.lang.RuntimeException: Expected that method with rtm lock elision >>>> was >>>>>> deoptimized after 1 lock attempts: expected 3320 to equal 1 >>>>>> >>>>>> java.lang.RuntimeException: Two uncommon traps with reason >>>>>> rtm_state_change should be fired.: expected 0 to equal 2 >>>>>> >>>>>> java.lang.RuntimeException: Expected to get only one deoptimization due >>>> to >>>>>> rtm state change: expected 0 to equal 1 >>>>>> >>>>>> java.lang.RuntimeException: Expected to get only one deoptimization due >>>> to >>>>>> rtm state change: expected 0 to equal 1 >>>>>> >>>>>> java.lang.RuntimeException: There should be exactly one statistics entry >>>>>> corresponding to ProfileRTM state.: expected null to not equal null >>>>>> >>>>>> java.lang.RuntimeException: VM output should contain exactly one rtm >>>>>> locking statistics entry for method compiler.testlibrary.rtm.BusyLock::test: >>>>>> expected 0 to equal 1 >>>>>> >>>>>> java.lang.RuntimeException: RTM locking statistics should contain non >>>> zero >>>>>> aborts count for abort reason 0: expected 0 > 0 >>>>>> >>>>>> Since these tests are not excluded I have to assume that either (a) they >>>> work >>>>>> for you (really?) or (b) that Oracle (or someone else) doesn?t have >>>> machines >>>>>> that support RTM. >> > From vivek.r.deshpande at intel.com Mon Jun 25 23:49:57 2018 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Mon, 25 Jun 2018 23:49:57 +0000 Subject: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes performance regression In-Reply-To: <12e43222-4cb8-a5a0-83b6-8790a74f326c@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A9073FB24@ORSMSX106.amr.corp.intel.com> <04aa0928-9be8-69bc-9a40-8e0a4436b176@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A90740968@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A907415AB@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A907415DC@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A90742C0C@ORSMSX106.amr.corp.intel.com> <12e43222-4cb8-a5a0-83b6-8790a74f326c@oracle.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A9074D8EC@ORSMSX106.amr.corp.intel.com> Hi Vladimir With this fix, the unrolling is limited to the loops with the presence of subword in the loop, which is correct for Subword Analysis and avoids unrolling for the loops with no subword operations in the loop. This fixes the regression with MPEG. I analyzed the workloads SPECjvm2008-SOR.small and SPECjvm2008-MonteCarlo. On MonteCarlo, with Subword Analysis work the loop was getting unrolled because of the following condition and was seeing the performance gain as a side effect. if (UseSubwordForMaxVector || xors_in_loop >= 4) && body_size < (uint)LoopUnrollLimit * 4) { With the fix the condition changed to check for the presence of Subword in the loop as following. if ((cl->is_subword_loop() || xors_in_loop >= 4) && body_size < (uint)LoopUnrollLimit * 4) { This caused the performance on MonteCarlo to go back to before UseSubwordForMaxVector changes. I did not notice much of a performance impact on SOR.small with Parallel GC and Parallel Old GC on Skylake server. For all the experiments I used single socket with membind to avoid run to run variations on skylake server. I also used these options -XX:-TieredCompilation -Xmx25G -Xms25G -Xmn15G -XX:+UseParallelGC -XX:ParallelGCThreads=66 Please let me know what you think. Regards, Vivek -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Wednesday, June 13, 2018 12:32 PM To: Deshpande, Vivek R ; Tobias Hartmann ; hotspot-compiler-dev at openjdk.java.net compiler Subject: Re: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes performance regression Hi Vivek, Performance testing is finished and we see regressions. SPECjvm2008-SOR.small with Parallel GC - 5-7% on all platfroms. There is also 3-5% regression in MonteCarlo with G1 (we did not test with Praallel GC - it may also regress). Please investigate it. Thanks, Vladimir On 6/12/18 9:51 AM, Deshpande, Vivek R wrote: > Hi Tobias > > Thanks for testing it. I have changed the status to - In Progress. > > Regards, > Vivek > > -----Original Message----- > From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] > Sent: Tuesday, June 12, 2018 2:48 AM > To: Deshpande, Vivek R ; Vladimir Kozlov > ; hotspot-compiler-dev at openjdk.java.net > compiler > Subject: Re: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes > performance regression > > Hi Vivek, > > On 11.06.2018 20:51, Deshpande, Vivek R wrote: >> http://cr.openjdk.java.net/~vdeshpande/SubwordFix/webrev.01/ > > This looks good to me as well. I've just submitted performance testing and premature results look great (+3.17% on SpecJVM2008 MPEG). > > I'll let you know once the runs are completed. Please set the status of the bug to "In Progress". > > Best regards, > Tobias > From smita.kamath at intel.com Tue Jun 26 05:25:25 2018 From: smita.kamath at intel.com (Kamath, Smita) Date: Tue, 26 Jun 2018 05:25:25 +0000 Subject: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions In-Reply-To: <980cfd3b-a6c1-eeda-3add-3165feea4fb9@oracle.com> References: <6563F381B547594081EF9DE181D0791277AAD1EC@FMSMSX119.amr.corp.intel.com> <6563F381B547594081EF9DE181D0791277AAD2D4@FMSMSX119.amr.corp.intel.com> <980cfd3b-a6c1-eeda-3add-3165feea4fb9@oracle.com> Message-ID: <6563F381B547594081EF9DE181D0791277AAF5C2@FMSMSX119.amr.corp.intel.com> Hi Vladimir, Please find the updated webrev link. Webrev Link: http://cr.openjdk.java.net/~srukmannagar/Base64/webrev.00/ Bug link: https://bugs.openjdk.java.net/browse/JDK-8205528 Please let me know if you have additional questions. Thanks and Regards, Smita -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Monday, June 25, 2018 10:48 AM To: Kamath, Smita Cc: hotspot compiler ; core-libs-dev at openjdk.java.net; Paul Sandoz Subject: Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions I forgot to reply to your answers. On 6/22/18 2:49 PM, Kamath, Smita wrote: > Hi Vladimir, > > Please see my answers to your questions as below: > > 1) One question so: why you have own copy of base64 charsets and not using one in library: > I am using vpgatherdd instruction to fetch multiple values from base64 array in a single instruction with a vector index. Vpgatherdd instruction works on 32 bit array and so I need to define base64 charset in a 32 bit array. I have given reference to gather instruction below. As was discussed in an other e-mail lets keep your copy. > > 2) Some indents in new and old Assembler::emit_operand() are off. In new Assembler::emit_operand() is better use } else { instead of 'return' in one branch. > I'll make the necessary changes and send an updated webrev. > > 3) This is first time I see that XMM register can be used for index in address. Is it true? Can you point to Intel's document which describes it. > I am using vpgatherdd instruction which requires index vector with scale. It uses VSIB addressing where the index register is a zmm register. > Please refer to reference manual, volume 2c, page 2211: > https://software.intel.com/sites/default/files/managed/39/c5/325462-sd > m-vol-1-2abcd-3abcd.pdf Also see, section 2.3.12, page 524 for VSIB > memory addressing information. Got it. Thanks for document reference. > > 4) Please, add tests to test/hotspot/jtreg/compiler/intrinsics/base64 (may be similar to sha or AES in compiler/codegen/aes) to make sure that all flags, intrinsic is used and it produces correct result. > I will add test cases as per your suggestion. Thanks, Vladimir > > Please let me know if you have additional questions. > > Thanks, > Smita > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Friday, June 22, 2018 12:29 PM > To: Kamath, Smita > Cc: hotspot compiler > Subject: Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 > Instructions > > Hi Smita, > > I CCing to Libs to review code changes in Base64.java. > > Looks like you changed all need place to implement intrinsic. > One question so: why you have own copy of base64 charsets and not using one in library: > > private int encode0(byte[] src, int off, int end, byte[] dst) { > char[] base64 = isURL ? toBase64URL : toBase64; > > Some indents in new and old Assembler::emit_operand() are off. > > In new Assembler::emit_operand() is better use } else { instead of 'return' in one branch. > > This is first time I see that XMM register can be used for index in address. Is it true? Can you point to Intel's document which describes it. > > What testing you did? > > Please, add tests to test/hotspot/jtreg/compiler/intrinsics/base64 (may be similar to sha or AES in compiler/codegen/aes) to make sure that all flags, intrinsic is used and it produces correct result. > > I know there is test/jdk/java/util/Base64/ tests but they may not trigger intrinsic usage. But you can use them as starting point for new tests. > > Thanks, > Vladimir > > On 6/22/18 11:47 AM, Kamath, Smita wrote: >> Hi Vladimir, >> >> I'd like to contribute an optimization for Base64 Encoding Algorithm >> using AVX512 Instructions. This optimization shows 1.5x improvement >> on >> x86_64 platform(SKL). >> >> Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8205528 >> >> Link to webrev: >> http://cr.openjdk.java.net/~vdeshpande/Base64/webrev.00/ >> >> For testing the implementation, I have run tests under >> test/jdk/java/util/Base64/ and also ran >> test/jdk/com/sun/jndi/ldap/Base64Test.java >> >> I have also run jtreg. >> >> Please review and let me know if you have any comments. >> >> Thanks and Regards, >> >> Smita >> From magnus.ihse.bursie at oracle.com Tue Jun 26 07:50:46 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 26 Jun 2018 09:50:46 +0200 Subject: RFR(M): 8205207: Port Graal unit tests under jtreg In-Reply-To: References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com> <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com> <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com> <5116257e-472d-13f5-f800-5e42d800934d@oracle.com> Message-ID: <5F6B2552-C6F7-44BB-9036-847F60A0737B@oracle.com> > 23 juni 2018 kl. 00:22 skrev Ekaterina Pavlova : > > Fixed and regenerated webrev at the same location: > http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html Better, but not done yet. In JtregGraalUnit.gmk: line 52-53 should be on a single line. The SRC list for BUILD_VM_COMPILER_TESTS looks insane, but the root cause here is the weird layout on disk. But the .test part really surprises me, I thought we had a clear rule to have no test source in src?! In lib-tests.m4: Copy paste error: AC_MSG_ERROR([You must specify the path to tonga jar]) The addition in RunTests.gmk and TestCommon.gmk should be guarded by: ifeq ($(INCLUDE_GRAAL), true) /Magnus > > Erik, > thanks again for your detailed reviews! > > -katya > >> On 6/22/18 2:38 PM, Erik Joelsson wrote: >> Hello Katya, >> This looks much better, thanks! >> A few suggestions still: >> Main.gmk: instead of repeating the assignment in both if and else block: >> ifeq ($(INCLUDE_GRAAL), true) >> JVM_TEST_IMAGE_TARGETS += test-image-hotspot-jtreg-graal >> endif >> I think it's fine to do that without the ?= because an alternative JVM implementation is unlikely to be using graal anyway. >> In JtregGraalUnit.gmk: Some minor style nits: >> 54: align )) with first eval line as you have done with the other eval calls >> 118: Since 117 is a one line parameter, please move comma to 117 >> 133: Same as for 118 >> 130-132: Please indent 4 spaces for continuation >> /Erik >>> On 2018-06-22 14:16, Ekaterina Pavlova wrote: >>> Erik, Doug, >>> >>> thank you a lot for your reviews and advises. >>> I fixed everything what Erik has pointed out, please see my answers inlined. >>> As about moving more staff in 'updategraalinopenjdk' can we consider this as next step? >>> I am not quite familiar with 'updategraalinopenjdk' and didn't contribute into Graal ws yet, >>> so I will prefer to do this improvement/refactoring as part of separate JDK issue. >>> >>> New webrev is here: >>> webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 >>> testing: tested by building and running graal unit tests >>> >>> >>>> On 6/19/18 2:00 PM, Erik Joelsson wrote: >>>> Hello, >>>> >>>> Please always include build-dev when reviewing build changes. >>>> >>>> In general this looks pretty good but there are some details that need fixing. >>>> >>>> (Aside from this particular review, I must state my reservation against all the special treatment graal is enjoying from a source and test layout and build perspective. My understanding here is that someone will have to regularly update the wrapper jtreg tests manually using the script. This in addition to having to implement this very convoluted redirection logic because the tests are in the wrong place. Wouldn't it make a lot more sense to put the complicated logic in the import procedure for graal source so that it would fit nicely into the OpenJDK source/build/test model, instead of adding more and more complicated workarounds in the OpenJDK build and test procedures?) >>>> >>>>> On 2018-06-18 22:26, Ekaterina Pavlova wrote: >>>>> Hi All, >>>>> >>>>> please review porting of Graal unit tests under jtreg. The main idea of this porting is to keep Graal unit tests as is >>>>> (located in src/jdk.internal.vm.compiler/share/classes/*.test) and run them similar way they are run in Graal project. >>>>> To achieve this test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java helper class has been written >>>>> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to run specified set of Graal unit tests. The groups of >>>>> Graal unit tests to run are defined in auto-generated test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests. >>>>> >>>>> New make/test/JtregGraalUnit.gmk is used to build Graal unit tests into jdk.vm.compiler.tests.jar and then install >>>>> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/. >>>>> >>>> GRAALUNIT_LIB is never defined (in the open). Since this is used in open makefiles, we need an open configure option to set it. >>> >>> ok, I created open/make/autoconf/lib-tests.m4 and did put Graal related staff there. >>> >>>> To make things clearer, I would rename LIB_DIR to something like LIB_OUTPUTDIR to signal that this is a location to put files in, rather than read them from. >>> >>> ok, renamed >>> >>>> >>>> FLATTEN has no effect in the SetupCopyFiles call since all the jar files found by wildcard can only be in one directory anyway. >>> >>> ok, removed >>> >>>> BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. Tests classes and jars should be built into $(SUPPORT_OUTPUTDIR)/test/..> Please create a suitable sub directory there for the output from this makefile. >>> >>> ok, introduced COMPILE_OUTPUTDIR := $(SUPPORT_OUTPUTDIR)/test/graalunit to be used to build graal unit test classes. >>> >>>> The all and test-image targets are never called so no need to declare them. >>>> >>>> There are some style issues too. (Please see http://openjdk.java.net/groups/build/doc/code-conventions.html for details.) >>>> * 43 logic indent 2 spaces >>>> * 52 we like to put the ending )) on a new line with ', \' at the end of the line before >>>> * 58 continuation indent 4 spaces >>>> * 88, 89 please break long lines >>>> * 90 continuation indent 4 spaces >>>> * 99 continuation indent 4 spaces >>>> * 120 break before )) >>> >>> I think I fixed everything >>> >>>>> make/Main.gmk adds proper dependencies for build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal. >>>>> >>>> The target build-test-hotspot-jtreg-graal only needs to depend on exploded-image-optimize. >>> >>> fixed >>> >>>> The new graal specific targets should be guarded by INCLUDE_GRAAL in Main.gmk. Otherwise those targets will silently do nothing if invoked without graal. That means adding them to JVM_TEST_IMAGE_TARGETS needs to be conditional too. >>> >>> fixed >>> >>>>> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg knows where to find Graal tests and libs. >>>>> >>>> This needs to be duplicated for make/RunTest.gmk so that these tests work with "make run-test" as well. >>> >>> added >>> >>> thanks, >>> -katya >>> >>>> /Erik >>>>> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file defines "testName -> testPrefix [requiresStatement]" mapping >>>>> which is used by test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to generate jtreg tests. >>>>> >>>>> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was ported from mx project without any changes. >>>>> >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 >>>>> webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html >>>>> testing: new tests were executed as part of automatic HS testing for several months. >>>>> >>>>> >>>>> thanks, >>>>> -katya >>>>> >>>>> p.s. >>>>> Igor Ignatyev volunteered to sponsor this change. >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nils.eliasson at oracle.com Tue Jun 26 09:20:11 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 26 Jun 2018 11:20:11 +0200 Subject: RFR(S): 8205107: assert(c->Opcode() == Op_SafePoint) failed: broken outer loop In-Reply-To: <358db601-ae00-56dc-5b02-7157ca88044d@oracle.com> References: <06ce5035-4eb9-d56f-0a46-7188c3e74b6c@oracle.com> <26c32258-1e42-01cd-fb64-0ff4cd4ff0b8@oracle.com> <185a0fd0-6876-a6e4-d647-9bde5a7f89cf@oracle.com> <5521318c-ed90-9d04-5cc2-2dbd964dcf63@oracle.com> <1e09c221-7c6e-093c-6dc8-53759eb162ea@oracle.com> <0c2b7c85-71ec-3bd5-ac31-6715f32a5c90@oracle.com> <3b5fd81c-b69e-888e-dcd6-f969ecaa5601@oracle.com> <358db601-ae00-56dc-5b02-7157ca88044d@oracle.com> Message-ID: Are you ok with the change? http://cr.openjdk.java.net/~neliasso/8205107/webrev.02 Regards, Nils On 2018-06-25 23:08, Nils Eliasson wrote: > > On 2018-06-21 19:26, Vladimir Kozlov wrote: >> On 6/21/18 7:54 AM, Nils Eliasson wrote: >>> >>> >>> On 2018-06-20 21:33, Vladimir Kozlov wrote: >>>> On 6/20/18 12:22 PM, Nils Eliasson wrote: >>>>> >>>>> >>>>> On 2018-06-20 18:32, Vladimir Kozlov wrote: >>>>>> On 6/20/18 2:01 AM, Nils Eliasson wrote: >>>>>>> I simplified it to: >>>>>>> >>>>>>> ?? virtual bool guaranteed_safepoint() { >>>>>>> ?????? // Calls to boxing methods will be expanded, and >>>>>>> safepoints aren't guaranteed >>>>>>> ?????? return !is_boxing_method(); >>>>>>> ?? } >>>>>>> >>>>>>> is_boxing_method() checks is_macro() that checks the >>>>>>> Flag_is_macro which is only set when C->eliminate_boxing() is true. >>>>>> >>>>>> Okay. >>>>>> >>>>>>> >>>>>>> "(proj_out_or_null(TypeFunc::Parms) == NULL));" seems redundant >>>>>>> too me. What would that guard against? >>>>>> >>>>>> It checks that result of the call is not used (Box object is >>>>>> eliminated by EA). It is needed otherwise you will get bad graph. >>>>> >>>>> We don't need that check since we prevent an optimization for >>>>> happening. The graph is kept as it is. >>>> >>>> So the result is only used by Safepoint? Then how it is eliminated >>>> later? >>> >>> It has other uses also. I'm not sure why the call is left, I will >>> investigate it further and can file a seperate bug if it is >>> something wrong. >> >> It is not wrong to have a Call node and Safepoint in a loop. It is >> just not optimal - that is all. >> I remember that it could be cases when even if boxing call is marked >> as not escaping (or scalar replaceable) it may not be eliminated >> because of it has still have some uses left which were not removed >> for different reasons. >> I agree that it is not easy problem. > > The problem with the test is related to Xcomp. It refuses to inline > valueOf beacuse it isn't loaded. The output gets confusing beacuse it > delays the inline until the macro-expansion, and then it reports > "failed inital checks". Running in normal mode makes it behave as > expected. > >> >> >>> >>> For this bug the problem is that we have a strip mined loop which >>> must have a safepoint. That safepoint can only be removed together >>> with the OuterStripMinedLoop. >>> >>> I change my mind and think my webrev.02 is the best fix - make >>> SafePoint::Identity to never substitute a strip-mine-loop safepoint. >>> >>> http://cr.openjdk.java.net/~neliasso/8205107/webrev.02 >> >> Okay, but please extend your comment to explain when we can have a >> Boxing Call node which may be late removed in Macro extension phase >> leaving loop without safepoint. > > This change guarantees that the (OuterStripMinedLoop) safepoint > doesn't get removed, even though a very unlikely call is left in the > countedloop. > > // Nils > >> >> Thanks, >> Vladimir >> >>> >>> // Nils >>>> >>>> Hmm, may be check _is_scalar_replaceable instead. >>>> >>>> Vladimir >>>> >>>>> >>>>> This is the graph: >>>>> >>>>> Integer.valueOf >>>>> ???? | >>>>> CatchProj >>>>> ???? | >>>>> SafePoint >>>>> ???? | >>>>> OuterCountedLoopEnd >>>>> >>>>> The original problem is that the SafePoint was removed because the >>>>> Integer.valueOf reported that it guarantees a safepoint. With the >>>>> change - guaranteed_safepoint() returns false for boxes - no >>>>> safepoint removal is done, the graph is kept intact. >>>>> >>>>> Regards, >>>>> >>>>> Nils >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> New webrev here: >>>>>>> http://cr.openjdk.java.net/~neliasso/8205107/webrev.03/ >>>>>>> >>>>>>> Thanks for the help! >>>>>>> >>>>>>> Nils >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2018-06-19 19:18, Vladimir Kozlov wrote: >>>>>>>> On 6/19/18 9:01 AM, Vladimir Kozlov wrote: >>>>>>>>> On 6/19/18 7:22 AM, Nils Eliasson wrote: >>>>>>>>>> I looked at it in a bit more detail. >>>>>>>>>> >>>>>>>>>> The call is a java/lang/Integer::valueOf that is considered a >>>>>>>>>> macro node so it is kept around until macro expansion which >>>>>>>>>> happens after the place where we hit the assert. So the call >>>>>>>>>> will go away. >>>>>>>>> >>>>>>>>> I assume you are talking about eliminate_boxing_node() in >>>>>>>>> macro expansion. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> However SafepointNode::Identity does check: >>>>>>>>>> >>>>>>>>>> if( n0->is_Call() && n0->as_Call()->guaranteed_safepoint() ) { >>>>>>>>>> ?????? // Useless Safepoint, so remove it >>>>>>>>>> >>>>>>>>>> And CallNode::guaranteed_safepoint() is: >>>>>>>>>> >>>>>>>>>> ?? // Are we guaranteed that this node is a safepoint? Not >>>>>>>>>> true for leaf calls and >>>>>>>>>> ?? // for some macro nodes whose expansion does not have a >>>>>>>>>> safepoint on the fast path. >>>>>>>>>> ?? virtual bool??????? guaranteed_safepoint()? { return true; } >>>>>>>>>> >>>>>>>>>> No check for call/macro-nodes is implemeted despite the >>>>>>>>>> comment! If I fix this the problem goes away. >>>>>>>>> >>>>>>>>> It returns false for Allocate nodes which are macro nodes. >>>>>>>>> That is what comment says. >>>>>>>>> >>>>>>>>> In case of boxing node I think we should add to >>>>>>>>> CallStaticJavaNode class >>>>>>>>> >>>>>>>>> ?? // Boxing call which is not used and will be removed. >>>>>>>>> ?? virtual bool??????? guaranteed_safepoint()? { return >>>>>>>>> C->eliminate_boxing() && is_boxing_method() && >>>>>>>>> (proj_out_or_null(TypeFunc::Parms) == NULL); } >>>>>>>> >>>>>>>> Sorry, test should be reversed because it guarantee SP if call >>>>>>>> is *not* removed: >>>>>>>> >>>>>>>> virtual bool??????? guaranteed_safepoint()? { return >>>>>>>> !(C->eliminate_boxing() && is_boxing_method() && >>>>>>>> (proj_out_or_null(TypeFunc::Parms) == NULL)); } >>>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>>> >>>>>>>>>> // Nils >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2018-06-18 15:41, Roland Westrelin wrote: >>>>>>>>>>>> Roland, why we need to keep Safepoint in Outer loop if we >>>>>>>>>>>> have call? >>>>>>>>>>> I double checked with a simple test case and we don't keep >>>>>>>>>>> the safepoint >>>>>>>>>>> if there's a call so it's indeed strange that we would need >>>>>>>>>>> Nils' patch. >>>>>>>>>>> >>>>>>>>>>> Roland. >>>>>>>>>> >>>>>>> >>>>> >>> > From gromero at linux.vnet.ibm.com Tue Jun 26 12:41:15 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 26 Jun 2018 09:41:15 -0300 Subject: RFR(s): 8205581: PPC64: RTM: Fix abort on native calls In-Reply-To: <86a9e4085b424a58a28436415786e312@sap.com> References: <86a9e4085b424a58a28436415786e312@sap.com> Message-ID: <7c133789-e13a-d675-17ad-8338fc19c9ce@linux.vnet.ibm.com> Hi Martin, Thanks for the quick review! On 06/25/2018 01:37 PM, Doerr, Martin wrote: > I wonder why you placed the tabort so late in generate_native_wrapper. I'd put it at the Verified Entry Point. Actually for no particular reason. So previously: 2247 [Verified Entry Point] 2248 0x00007fff9c816520: mfcr r22 2249 0x00007fff9c816524: std r22,8(r1) 2250 0x00007fff9c816528: mflr r22 2251 0x00007fff9c81652c: std r22,16(r1) 2252 0x00007fff9c816530: addis r11,r1,-2 2253 0x00007fff9c816534: std r0,0(r11) 2254 0x00007fff9c816538: mr r21,r1 2255 0x00007fff9c81653c: stdu r1,-176(r1) 2256 0x00007fff9c816540: std r3,96(r1) 2257 0x00007fff9c816544: addi r4,r1,96 2258 0x00007fff9c816548: cmpdi r3,0 2259 0x00007fff9c81654c: bne- 0x00007fff9c816554 2260 0x00007fff9c816550: li r4,0 2261 0x00007fff9c816554: addi r3,r16,824 ; ImmutableOopMap{[96]=Oop } 2262 0x00007fff9c816558: addis r28,r29,7 2263 0x00007fff9c81655c: addi r28,r28,25944 ; {internal_word} 2264 0x00007fff9c816560: tabort. r0 <== ... Now: 2169 [Verified Entry Point] 2170 0x00007fff78816320: tabort. r0 <== 2171 0x00007fff78816324: mfcr r22 2172 0x00007fff78816328: std r22,8(r1) 2173 0x00007fff7881632c: mflr r22 2174 0x00007fff78816330: std r22,16(r1) 2175 0x00007fff78816334: addis r11,r1,-2 2176 0x00007fff78816338: std r0,0(r11) 2177 0x00007fff7881633c: mr r21,r1 2178 0x00007fff78816340: stdu r1,-176(r1) 2179 0x00007fff78816344: std r3,96(r1) 2180 0x00007fff78816348: addi r4,r1,96 2181 0x00007fff7881634c: cmpdi r3,0 2182 0x00007fff78816350: bne- 0x00007fff78816358 2183 0x00007fff78816354: li r4,0 2184 0x00007fff78816358: addi r3,r16,824 ; ImmutableOopMap{[96]=Oop } 2185 0x00007fff7881635c: addis r28,r29,7 2186 0x00007fff78816360: addi r28,r28,25436 ; {internal_word} ... Yep, it's better to abort sooner. new webrev: http://cr.openjdk.java.net/~gromero/8205581/v2/ Best regards, Gustavo > Besides that, it looks good to me. > > Thanks, > Martin > > > -----Original Message----- > From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] > Sent: Montag, 25. Juni 2018 10:21 > To: Lindenmaier, Goetz ; Doerr, Martin ; hotspot-compiler-dev at openjdk.java.net > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: RFR(s): 8205581: PPC64: RTM: Fix abort on native calls > > Hi, > > Could the following change be reviewed please? > > bug : https://bugs.openjdk.java.net/browse/JDK-8205581 > webrev: http://cr.openjdk.java.net/~gromero/8205581/v1/ > > It forces a transactional state to abort before calling native methods, before > calling runtime, and on uncommon trap checking, mostly because transaction will > be aborted soon or latter in either case, similarly to what happens on Intel. > The abort instruction (tabort) is only emitted if UseRTMLocking is "true" and > any 'tabort' instruction is treated as a 'nop' instruction if TM state is > non-transactional. > > It fixes the following tests: > > +Passed: compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java > +Passed: compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java > > > Thank you and best regards, > Gustavo > From martin.doerr at sap.com Tue Jun 26 12:54:18 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 26 Jun 2018 12:54:18 +0000 Subject: RFR(s): 8205581: PPC64: RTM: Fix abort on native calls In-Reply-To: <7c133789-e13a-d675-17ad-8338fc19c9ce@linux.vnet.ibm.com> References: <86a9e4085b424a58a28436415786e312@sap.com> <7c133789-e13a-d675-17ad-8338fc19c9ce@linux.vnet.ibm.com> Message-ID: Hi Gustavo, thanks for the update. Looks good to me. Best regards, Martin -----Original Message----- From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] Sent: Dienstag, 26. Juni 2018 14:41 To: Doerr, Martin ; Lindenmaier, Goetz ; hotspot-compiler-dev at openjdk.java.net Cc: ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR(s): 8205581: PPC64: RTM: Fix abort on native calls Hi Martin, Thanks for the quick review! On 06/25/2018 01:37 PM, Doerr, Martin wrote: > I wonder why you placed the tabort so late in generate_native_wrapper. I'd put it at the Verified Entry Point. Actually for no particular reason. So previously: 2247 [Verified Entry Point] 2248 0x00007fff9c816520: mfcr r22 2249 0x00007fff9c816524: std r22,8(r1) 2250 0x00007fff9c816528: mflr r22 2251 0x00007fff9c81652c: std r22,16(r1) 2252 0x00007fff9c816530: addis r11,r1,-2 2253 0x00007fff9c816534: std r0,0(r11) 2254 0x00007fff9c816538: mr r21,r1 2255 0x00007fff9c81653c: stdu r1,-176(r1) 2256 0x00007fff9c816540: std r3,96(r1) 2257 0x00007fff9c816544: addi r4,r1,96 2258 0x00007fff9c816548: cmpdi r3,0 2259 0x00007fff9c81654c: bne- 0x00007fff9c816554 2260 0x00007fff9c816550: li r4,0 2261 0x00007fff9c816554: addi r3,r16,824 ; ImmutableOopMap{[96]=Oop } 2262 0x00007fff9c816558: addis r28,r29,7 2263 0x00007fff9c81655c: addi r28,r28,25944 ; {internal_word} 2264 0x00007fff9c816560: tabort. r0 <== ... Now: 2169 [Verified Entry Point] 2170 0x00007fff78816320: tabort. r0 <== 2171 0x00007fff78816324: mfcr r22 2172 0x00007fff78816328: std r22,8(r1) 2173 0x00007fff7881632c: mflr r22 2174 0x00007fff78816330: std r22,16(r1) 2175 0x00007fff78816334: addis r11,r1,-2 2176 0x00007fff78816338: std r0,0(r11) 2177 0x00007fff7881633c: mr r21,r1 2178 0x00007fff78816340: stdu r1,-176(r1) 2179 0x00007fff78816344: std r3,96(r1) 2180 0x00007fff78816348: addi r4,r1,96 2181 0x00007fff7881634c: cmpdi r3,0 2182 0x00007fff78816350: bne- 0x00007fff78816358 2183 0x00007fff78816354: li r4,0 2184 0x00007fff78816358: addi r3,r16,824 ; ImmutableOopMap{[96]=Oop } 2185 0x00007fff7881635c: addis r28,r29,7 2186 0x00007fff78816360: addi r28,r28,25436 ; {internal_word} ... Yep, it's better to abort sooner. new webrev: http://cr.openjdk.java.net/~gromero/8205581/v2/ Best regards, Gustavo > Besides that, it looks good to me. > > Thanks, > Martin > > > -----Original Message----- > From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] > Sent: Montag, 25. Juni 2018 10:21 > To: Lindenmaier, Goetz ; Doerr, Martin ; hotspot-compiler-dev at openjdk.java.net > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: RFR(s): 8205581: PPC64: RTM: Fix abort on native calls > > Hi, > > Could the following change be reviewed please? > > bug : https://bugs.openjdk.java.net/browse/JDK-8205581 > webrev: http://cr.openjdk.java.net/~gromero/8205581/v1/ > > It forces a transactional state to abort before calling native methods, before > calling runtime, and on uncommon trap checking, mostly because transaction will > be aborted soon or latter in either case, similarly to what happens on Intel. > The abort instruction (tabort) is only emitted if UseRTMLocking is "true" and > any 'tabort' instruction is treated as a 'nop' instruction if TM state is > non-transactional. > > It fixes the following tests: > > +Passed: compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java > +Passed: compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java > > > Thank you and best regards, > Gustavo > From tobias.hartmann at oracle.com Tue Jun 26 14:01:19 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 26 Jun 2018 16:01:19 +0200 Subject: [11] RFR(S) 8205400: [Graal] compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java fails with can't be enqueued for compilation on level 4 In-Reply-To: References: Message-ID: Hi Vladimir, this looks good to me. Best regards, Tobias On 23.06.2018 00:04, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8205400/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8205400 > > I was not able to reproduce the problem. I did 170 runs of the test with Graal in mach5. I can only > speculate what happen. > By default JVMCI and Graal are initialized only on first tier4 compilation request. Usually there > are hot methods which trigger such compilation and initialization before the test requests compilation. > > It is still possible that test's compilation request is the first. > The test asks blocking (BackgroundCompilation = false) compilation to wait when it complete [1]. > But JVMCI code will unblock first compilation when JVMCI and Graal are not initialized yet [2]. > As result execution continue before Graal's compilation finished (or even started) and > WB::compile_method() will return NULL value. > > To trigger eager JVMCI and Graal initialization flag -XX:+EagerJVMCI or -Xbatch > (-XX:-BackgroundCompilation) should be used to run test. And 2 of jvmci/compilerToVM/ tests which > use the same WB compilation API are using -XX:-BackgroundCompilation. I am suggesting to do the same > in 2 other tests. > > To find if this is really what happen I added error prints in WhiteBox::compile_method() which have > several cases when it can return false. > > Tested with tier1,tier2,tier3-graal,precheckin-comp > > [1] > http://hg.openjdk.java.net/jdk/jdk/file/d91a64467683/test/hotspot/jtreg/compiler/jvmci/compilerToVM/CompileCodeTestCase.java#l108 > > [2] > http://hg.openjdk.java.net/jdk/jdk/file/d91a64467683/src/hotspot/share/compiler/compileBroker.cpp#l1082 > From gromero at linux.vnet.ibm.com Tue Jun 26 16:01:07 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 26 Jun 2018 13:01:07 -0300 Subject: RFR(s): 8205580: PPC64: RTM: Don't retry lock on abort if abort was intentional In-Reply-To: References: Message-ID: <56e66a89-42a7-eb72-05a2-a97c696379c9@linux.vnet.ibm.com> Hi Martin, On 06/25/2018 01:49 PM, Doerr, Martin wrote: > Looks good for the case UseRTMXendForLockBusy is active (which is default). I did all the tests focusing on when it's deactivated (-UseRTMXendForLockBusy). This is also the flag passed in jtreg tests since if it's active there are no aborts caused by 'tabort or xabort' and so no abort statistics (related to that event, which is used by the jtreg tests). > If this flag is deactivated, we use tabort if we see the object locked so your change prevents retrying the transaction in this case. > I guess this was not intended? I think that rtm_retry_lock_on_abort() is a misleading name, it should be something like rtm_retry_lock_on_conflict(), since the purpose of this function is to no retry if abort is caused by a tabort/xabort in my understanding. On Intel that function checks for bit 1 (0x2 mask) and if it is set the operation is retried. But to bit 1 be set it implies that transaction didn't abort due to xabort, otherwise that bit would be clear as: 77 // 0 Set if abort caused by XABORT instruction. 78 // 1 If set, the transaction may succeed on a retry. This bit is always clear if bit 0 is set (or is always clear if abort is caused by XABORT) That's why filtering on Power by the "Abort" bit in TEXASR makes the number of aborts behave like on x64. If we don't filter abort caused by tabort we find the pattern X*2+1 times of retries, because both rtm_retry_lock_on_abort() and rtm_retry_lock_on_busy() will try RTMRetryCount of times the operation. My change won't prevent retrying because after rtm_retry_lock_on_abort(), if cmpxchgd() does not succeed it calls rtm_retry_lock_on_busy(), which by its turn will retry the operation based too on the value specified by RTMRetryCount. I prepared a simple test-case where UseRTMXendForLockBusy is deactivated to show that if we increase the number of RTMRetryCount even with that flag deactivated the operation is retried exactly RTMRetryCount+1 times after the fix, like on Intel: https://github.com/gromero/retry You just need to clone and run it pointing to a build dir: $ git clone https://github.com/gromero/retry && cd retry $ ./retry You have to build the WhiteBox lib through "make build-test-lib" before running it. So for RTMRetryCount=1 and RTMRetryCount=2 w/ -UseRTMXendForLockBusy before the change: gromero at gromero16:~/git/retry$ ./retry.sh /home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release 1 ++ /home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release/jdk/bin/javac -cp /home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release/support/test/lib/wb.jar --add-exports java.base/jdk.internal.misc=ALL-UNNAMED retry.java ++ LD_LIBRARY_PATH=/home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release/jdk/../..//src/utils/hsdis/build/linux-ppc64le ++ /home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release/jdk/bin/java -Xbootclasspath/a:/home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release/support/test/lib/wb.jar -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -XX:+UseRTMLocking -XX:+PrintPreciseRTMLockingStatistics -XX:-TieredCompilation -Xcomp -XX:-UseRTMXendForLockBusy -XX:RTMTotalCountIncrRate=1 -XX:RTMRetryCount=1 -XX:CompileOnly=RTM.syncAndTest --add-exports java.base/jdk.internal.misc=ALL-UNNAMED retry Creating thread0... Trying to inflate lock... Is monitor inflated? Yes Entering thread to sleep... RTM.syncAndTest at 26 # rtm locks total (estimated): 3 # rtm lock aborts : 3 # rtm lock aborts 0: 3 # rtm lock aborts 1: 3 # rtm lock aborts 2: 0 # rtm lock aborts 3: 0 # rtm lock aborts 4: 0 # rtm lock aborts 5: 0 ++ set +x gromero at gromero16:~/git/retry$ ./retry.sh /home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release 2 ++ /home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release/jdk/bin/javac -cp /home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release/support/test/lib/wb.jar --add-exports java.base/jdk.internal.misc=ALL-UNNAMED retry.java ++ LD_LIBRARY_PATH=/home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release/jdk/../..//src/utils/hsdis/build/linux-ppc64le ++ /home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release/jdk/bin/java -Xbootclasspath/a:/home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release/support/test/lib/wb.jar -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -XX:+UseRTMLocking -XX:+PrintPreciseRTMLockingStatistics -XX:-TieredCompilation -Xcomp -XX:-UseRTMXendForLockBusy -XX:RTMTotalCountIncrRate=1 -XX:RTMRetryCount=2 -XX:CompileOnly=RTM.syncAndTest --add-exports java.base/jdk.internal.misc=ALL-UNNAMED retry Creating thread0... Trying to inflate lock... Is monitor inflated? Yes Entering thread to sleep... RTM.syncAndTest at 26 # rtm locks total (estimated): 5 # rtm lock aborts : 5 # rtm lock aborts 0: 5 # rtm lock aborts 1: 5 # rtm lock aborts 2: 0 # rtm lock aborts 3: 0 # rtm lock aborts 4: 0 # rtm lock aborts 5: 0 ++ set +x and after the change: gromero at gromero16:~/git/retry$ ./retry.sh /home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release 1 ++ /home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release/jdk/bin/javac -cp /home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release/support/test/lib/wb.jar --add-exports java.base/jdk.internal.misc=ALL-UNNAMED retry.java ++ LD_LIBRARY_PATH=/home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release/jdk/../..//src/utils/hsdis/build/linux-ppc64le ++ /home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release/jdk/bin/java -Xbootclasspath/a:/home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release/support/test/lib/wb.jar -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -XX:+UseRTMLocking -XX:+PrintPreciseRTMLockingStatistics -XX:-TieredCompilation -Xcomp -XX:-UseRTMXendForLockBusy -XX:RTMTotalCountIncrRate=1 -XX:RTMRetryCount=1 -XX:CompileOnly=RTM.syncAndTest --add-exports java.base/jdk.internal.misc=ALL-UNNAMED retry Creating thread0... Trying to inflate lock... Is monitor inflated? Yes Entering thread to sleep... RTM.syncAndTest at 26 # rtm locks total (estimated): 2 # rtm lock aborts : 2 # rtm lock aborts 0: 2 # rtm lock aborts 1: 2 # rtm lock aborts 2: 0 # rtm lock aborts 3: 0 # rtm lock aborts 4: 0 # rtm lock aborts 5: 0 ++ set +x gromero at gromero16:~/git/retry$ ./retry.sh /home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release 2 ++ /home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release/jdk/bin/javac -cp /home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release/support/test/lib/wb.jar --add-exports java.base/jdk.internal.misc=ALL-UNNAMED retry.java ++ LD_LIBRARY_PATH=/home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release/jdk/../..//src/utils/hsdis/build/linux-ppc64le ++ /home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release/jdk/bin/java -Xbootclasspath/a:/home/gromero/hg/jdk/jdk/build/linux-ppc64le-normal-server-release/support/test/lib/wb.jar -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -XX:+UseRTMLocking -XX:+PrintPreciseRTMLockingStatistics -XX:-TieredCompilation -Xcomp -XX:-UseRTMXendForLockBusy -XX:RTMTotalCountIncrRate=1 -XX:RTMRetryCount=2 -XX:CompileOnly=RTM.syncAndTest --add-exports java.base/jdk.internal.misc=ALL-UNNAMED retry Creating thread0... Trying to inflate lock... Is monitor inflated? Yes Entering thread to sleep... RTM.syncAndTest at 26 # rtm locks total (estimated): 3 # rtm lock aborts : 3 # rtm lock aborts 0: 3 # rtm lock aborts 1: 3 # rtm lock aborts 2: 0 # rtm lock aborts 3: 0 # rtm lock aborts 4: 0 # rtm lock aborts 5: 0 ++ set +x Best regards, Gustavo > Thanks and best regards, > Martin > > > -----Original Message----- > From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] > Sent: Montag, 25. Juni 2018 10:24 > To: Lindenmaier, Goetz ; Doerr, Martin ; hotspot-compiler-dev at openjdk.java.net > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: RFR(s): 8205580: PPC64: RTM: Don't retry lock on abort if abort was intentional > > Hi, > > Could the following change be reviewed please? > > bug : https://bugs.openjdk.java.net/browse/JDK-8205580 > webrev: http://cr.openjdk.java.net/~gromero/8205580/v1/ > > It changes the behavior of rtm_retry_lock_on_abort() by avoiding retry if abort > was a deliberate abort, i.e. caused by a 'tabort r0' instruction. > > On Intel bit 1 in abort_status_Reg (which communicates the abort status) is > always clear when a 'xabort 0' instruction is executed in order to inform that a > transactional retry /can not/ succeed on retry. So rtm_retry_lock_on_abort() on > Intel, on finding bit 1 clear in abort_status_Reg, skips the retry (don't > retry). > > Currently on Power rtm_retry_lock_on_abort() is just checking the persistent bit > (if set => skip) which /is not set/ by 'tabort r0'. Hence > rtm_retry_lock_on_abort() does retry to lock on an intentional abort caused by > 'tabort'. It leads, for instance when -XX:RTMRetryCount=1, to the following > discrepancy between Intel and Power regarding the number of retries/aborts: > > [Power] > # rtm locks total (estimated): 3 > # rtm lock aborts : 3 > # rtm lock aborts 0: 3 > # rtm lock aborts 1: 3 > # rtm lock aborts 2: 0 > # rtm lock aborts 3: 0 > # rtm lock aborts 4: 0 > # rtm lock aborts 5: 0 > > [Intel] > # rtm locks total (estimated): 2 > # rtm lock aborts : 2 > # rtm lock aborts 0: 2 > # rtm lock aborts 1: 2 > # rtm lock aborts 2: 0 > # rtm lock aborts 3: 0 > # rtm lock aborts 4: 0 > # rtm lock aborts 5: 0 > > So for -XX:RTMRetryCount=X: > on Power the number of aborts is: X*2+1 [1 first failure + 1 rtm_retry_lock_on_abort() + 1 rtm_retry_lock_on_busy()]; > on Intel the number of aborts is: X+1 [1 first failure + 1 rtm_retry_lock_on_busy()] > > This change fixes that discrepancy by using bit "Abort" in TEXASR register > (abort_status_Reg) that tells if a transaction was aborted due to a 'tabort' > instruction and skip the retry if such a bit is set. > > It fixes the following tests: > > +Passed: compiler/rtm/locking/TestRTMRetryCount.java > +Passed: compiler/rtm/locking/TestRTMAbortThreshold.java > > > Thank you and best regards, > Gustavo > From vladimir.kozlov at oracle.com Tue Jun 26 16:04:53 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Jun 2018 09:04:53 -0700 Subject: [11] RFR(S) 8205400: [Graal] compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java fails with can't be enqueued for compilation on level 4 In-Reply-To: References: Message-ID: Thank you, Tobias Vladimir On 6/26/18 7:01 AM, Tobias Hartmann wrote: > Hi Vladimir, > > this looks good to me. > > Best regards, > Tobias > > On 23.06.2018 00:04, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8205400/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8205400 >> >> I was not able to reproduce the problem. I did 170 runs of the test with Graal in mach5. I can only >> speculate what happen. >> By default JVMCI and Graal are initialized only on first tier4 compilation request. Usually there >> are hot methods which trigger such compilation and initialization before the test requests compilation. >> >> It is still possible that test's compilation request is the first. >> The test asks blocking (BackgroundCompilation = false) compilation to wait when it complete [1]. >> But JVMCI code will unblock first compilation when JVMCI and Graal are not initialized yet [2]. >> As result execution continue before Graal's compilation finished (or even started) and >> WB::compile_method() will return NULL value. >> >> To trigger eager JVMCI and Graal initialization flag -XX:+EagerJVMCI or -Xbatch >> (-XX:-BackgroundCompilation) should be used to run test. And 2 of jvmci/compilerToVM/ tests which >> use the same WB compilation API are using -XX:-BackgroundCompilation. I am suggesting to do the same >> in 2 other tests. >> >> To find if this is really what happen I added error prints in WhiteBox::compile_method() which have >> several cases when it can return false. >> >> Tested with tier1,tier2,tier3-graal,precheckin-comp >> >> [1] >> http://hg.openjdk.java.net/jdk/jdk/file/d91a64467683/test/hotspot/jtreg/compiler/jvmci/compilerToVM/CompileCodeTestCase.java#l108 >> >> [2] >> http://hg.openjdk.java.net/jdk/jdk/file/d91a64467683/src/hotspot/share/compiler/compileBroker.cpp#l1082 >> From ekaterina.pavlova at oracle.com Tue Jun 26 16:08:30 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Tue, 26 Jun 2018 09:08:30 -0700 Subject: RFR(M): 8205207: Port Graal unit tests under jtreg In-Reply-To: <5F6B2552-C6F7-44BB-9036-847F60A0737B@oracle.com> References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com> <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com> <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com> <5116257e-472d-13f5-f800-5e42d800934d@oracle.com> <5F6B2552-C6F7-44BB-9036-847F60A0737B@oracle.com> Message-ID: <42868f25-ab86-628d-55f9-e81e2fec8985@oracle.com> Hello Magnus, On 6/26/18 12:50 AM, Magnus Ihse Bursie wrote: > 23 juni 2018 kl. 00:22 skrev Ekaterina Pavlova >: > >> Fixed and regenerated webrev at the same location: >> http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html > > Better, but not done yet. > > In JtregGraalUnit.gmk: line 52-53 should be on a single line. will fix > The SRC list for?BUILD_VM_COMPILER_TESTS looks insane, but the root cause here is the weird layout on disk. But the .test part really surprises me, I thought we had a clear rule to have no test source in src?! These are not jtreg tests, these are graalunit tests which are coming as part of Graal port (from Graal ws). We can't change this layout right now. > In lib-tests.m4: Copy paste error:?AC_MSG_ERROR([You must specify the path to tonga jar]) ops, will fix > The addition in RunTests.gmk and TestCommon.gmk should be guarded by: > ? ifeq ($(INCLUDE_GRAAL), true) ok, will look > /Magnus > >> >> Erik, >> thanks again for your detailed reviews! >> >> -katya >> >> On 6/22/18 2:38 PM, Erik Joelsson wrote: >>> Hello Katya, >>> This looks much better, thanks! >>> A few suggestions still: >>> Main.gmk: instead of repeating the assignment in both if and else block: >>> ifeq ($(INCLUDE_GRAAL), true) >>> ? JVM_TEST_IMAGE_TARGETS += test-image-hotspot-jtreg-graal >>> endif >>> I think it's fine to do that without the ?= because an alternative JVM implementation is unlikely to be using graal anyway. >>> In JtregGraalUnit.gmk: Some minor style nits: >>> 54: align )) with first eval line as you have done with the other eval calls >>> 118: Since 117 is a one line parameter, please move comma to 117 >>> 133: Same as for 118 >>> 130-132: Please indent 4 spaces for continuation >>> /Erik >>> On 2018-06-22 14:16, Ekaterina Pavlova wrote: >>>> Erik, Doug, >>>> >>>> thank you a lot for your reviews and advises. >>>> I fixed everything what Erik has pointed out, please see my answers inlined. >>>> As about moving more staff in 'updategraalinopenjdk' can we consider this as next step? >>>> I am not quite familiar with 'updategraalinopenjdk' and didn't contribute into Graal ws yet, >>>> so I will prefer to do this improvement/refactoring as part of separate JDK issue. >>>> >>>> New webrev is here: >>>> ? webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html >>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 >>>> ?testing: tested by building and running graal unit tests >>>> >>>> >>>> On 6/19/18 2:00 PM, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> Please always include build-dev when reviewing build changes. >>>>> >>>>> In general this looks pretty good but there are some details that need fixing. >>>>> >>>>> (Aside from this particular review, I must state my reservation against all the special treatment graal is enjoying from a source and test layout and build perspective. My understanding here is that someone will have to regularly update the wrapper jtreg tests manually using the script. This in addition to having to implement this very convoluted redirection logic because the tests are in the wrong place. Wouldn't it make a lot more sense to put the complicated logic in the import procedure for graal source so that it would fit nicely into the OpenJDK source/build/test model, instead of adding more and more complicated workarounds in the OpenJDK build and test procedures?) >>>>> >>>>> On 2018-06-18 22:26, Ekaterina Pavlova wrote: >>>>>> Hi All, >>>>>> >>>>>> please review porting of Graal unit tests under jtreg. The main idea of this porting is to keep Graal unit tests as is >>>>>> (located in src/jdk.internal.vm.compiler/share/classes/*.test) and run them similar way they are run in Graal project. >>>>>> To achieve this test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java helper class has been written >>>>>> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to run specified set of Graal unit tests. The groups of >>>>>> Graal unit tests to run are defined in auto-generated test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests. >>>>>> >>>>>> New make/test/JtregGraalUnit.gmk is used to build Graal unit tests into jdk.vm.compiler.tests.jar and then install >>>>>> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/. >>>>>> >>>>> GRAALUNIT_LIB is never defined (in the open). Since this is used in open makefiles, we need an open configure option to set it. >>>> >>>> ok, I created open/make/autoconf/lib-tests.m4 and did put Graal related staff there. >>>> >>>>> To make things clearer, I would rename LIB_DIR to something like LIB_OUTPUTDIR to signal that this is a location to put files in, rather than read them from. >>>> >>>> ok, renamed >>>> >>>>> >>>>> FLATTEN has no effect in the SetupCopyFiles call since all the jar files found by wildcard can only be in one directory anyway. >>>> >>>> ok, removed >>>> >>>>> BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. Tests classes and jars should be built into $(SUPPORT_OUTPUTDIR)/test/..> Please create a suitable sub directory there for the output from this makefile. >>>> >>>> ok, introduced COMPILE_OUTPUTDIR := $(SUPPORT_OUTPUTDIR)/test/graalunit to be used to build graal unit test classes. >>>> >>>>> The all and test-image targets are never called so no need to declare them. >>>>> >>>>> There are some style issues too. (Please see http://openjdk.java.net/groups/build/doc/code-conventions.html for details.) >>>>> * 43 logic indent 2 spaces >>>>> * 52 we like to put the ending )) on a new line with ', \' at the end of the line before >>>>> * 58 continuation indent 4 spaces >>>>> * 88, 89 please break long lines >>>>> * 90 continuation indent 4 spaces >>>>> * 99 continuation indent 4 spaces >>>>> * 120 break before )) >>>> >>>> I think I fixed everything >>>> >>>>>> make/Main.gmk adds proper dependencies for build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal. >>>>>> >>>>> The target build-test-hotspot-jtreg-graal only needs to depend on exploded-image-optimize. >>>> >>>> fixed >>>> >>>>> The new graal specific targets should be guarded by INCLUDE_GRAAL in Main.gmk. Otherwise those targets will silently do nothing if invoked without graal. That means adding them to JVM_TEST_IMAGE_TARGETS needs to be conditional too. >>>> >>>> fixed >>>> >>>>>> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg knows where to find Graal tests and libs. >>>>>> >>>>> This needs to be duplicated for make/RunTest.gmk so that these tests work with "make run-test" as well. >>>> >>>> added >>>> >>>> thanks, >>>> -katya >>>> >>>>> /Erik >>>>>> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file defines "testName -> testPrefix [requiresStatement]" mapping >>>>>> which is used by test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to generate jtreg tests. >>>>>> >>>>>> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was ported from mx project without any changes. >>>>>> >>>>>> >>>>>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 >>>>>> ?webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html >>>>>> testing: new tests were executed as part of automatic HS testing for several months. >>>>>> >>>>>> >>>>>> thanks, >>>>>> -katya >>>>>> >>>>>> p.s. >>>>>> ?Igor Ignatyev volunteered to sponsor this change. >>>>> >>>> >> From vladimir.kozlov at oracle.com Tue Jun 26 16:34:24 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Jun 2018 09:34:24 -0700 Subject: RFR(S): 8205107: assert(c->Opcode() == Op_SafePoint) failed: broken outer loop In-Reply-To: References: <06ce5035-4eb9-d56f-0a46-7188c3e74b6c@oracle.com> <26c32258-1e42-01cd-fb64-0ff4cd4ff0b8@oracle.com> <185a0fd0-6876-a6e4-d647-9bde5a7f89cf@oracle.com> <5521318c-ed90-9d04-5cc2-2dbd964dcf63@oracle.com> <1e09c221-7c6e-093c-6dc8-53759eb162ea@oracle.com> <0c2b7c85-71ec-3bd5-ac31-6715f32a5c90@oracle.com> <3b5fd81c-b69e-888e-dcd6-f969ecaa5601@oracle.com> <358db601-ae00-56dc-5b02-7157ca88044d@oracle.com> Message-ID: It is old webrev. Comment did not change. Vladimir On 6/26/18 2:20 AM, Nils Eliasson wrote: > Are you ok with the change? > > http://cr.openjdk.java.net/~neliasso/8205107/webrev.02 > > Regards, > > Nils > > > On 2018-06-25 23:08, Nils Eliasson wrote: >> >> On 2018-06-21 19:26, Vladimir Kozlov wrote: >>> On 6/21/18 7:54 AM, Nils Eliasson wrote: >>>> >>>> >>>> On 2018-06-20 21:33, Vladimir Kozlov wrote: >>>>> On 6/20/18 12:22 PM, Nils Eliasson wrote: >>>>>> >>>>>> >>>>>> On 2018-06-20 18:32, Vladimir Kozlov wrote: >>>>>>> On 6/20/18 2:01 AM, Nils Eliasson wrote: >>>>>>>> I simplified it to: >>>>>>>> >>>>>>>> ?? virtual bool guaranteed_safepoint() { >>>>>>>> ?????? // Calls to boxing methods will be expanded, and >>>>>>>> safepoints aren't guaranteed >>>>>>>> ?????? return !is_boxing_method(); >>>>>>>> ?? } >>>>>>>> >>>>>>>> is_boxing_method() checks is_macro() that checks the >>>>>>>> Flag_is_macro which is only set when C->eliminate_boxing() is true. >>>>>>> >>>>>>> Okay. >>>>>>> >>>>>>>> >>>>>>>> "(proj_out_or_null(TypeFunc::Parms) == NULL));" seems redundant >>>>>>>> too me. What would that guard against? >>>>>>> >>>>>>> It checks that result of the call is not used (Box object is >>>>>>> eliminated by EA). It is needed otherwise you will get bad graph. >>>>>> >>>>>> We don't need that check since we prevent an optimization for >>>>>> happening. The graph is kept as it is. >>>>> >>>>> So the result is only used by Safepoint? Then how it is eliminated >>>>> later? >>>> >>>> It has other uses also. I'm not sure why the call is left, I will >>>> investigate it further and can file a seperate bug if it is >>>> something wrong. >>> >>> It is not wrong to have a Call node and Safepoint in a loop. It is >>> just not optimal - that is all. >>> I remember that it could be cases when even if boxing call is marked >>> as not escaping (or scalar replaceable) it may not be eliminated >>> because of it has still have some uses left which were not removed >>> for different reasons. >>> I agree that it is not easy problem. >> >> The problem with the test is related to Xcomp. It refuses to inline >> valueOf beacuse it isn't loaded. The output gets confusing beacuse it >> delays the inline until the macro-expansion, and then it reports >> "failed inital checks". Running in normal mode makes it behave as >> expected. >> >>> >>> >>>> >>>> For this bug the problem is that we have a strip mined loop which >>>> must have a safepoint. That safepoint can only be removed together >>>> with the OuterStripMinedLoop. >>>> >>>> I change my mind and think my webrev.02 is the best fix - make >>>> SafePoint::Identity to never substitute a strip-mine-loop safepoint. >>>> >>>> http://cr.openjdk.java.net/~neliasso/8205107/webrev.02 >>> >>> Okay, but please extend your comment to explain when we can have a >>> Boxing Call node which may be late removed in Macro extension phase >>> leaving loop without safepoint. >> >> This change guarantees that the (OuterStripMinedLoop) safepoint >> doesn't get removed, even though a very unlikely call is left in the >> countedloop. >> >> // Nils >> >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> // Nils >>>>> >>>>> Hmm, may be check _is_scalar_replaceable instead. >>>>> >>>>> Vladimir >>>>> >>>>>> >>>>>> This is the graph: >>>>>> >>>>>> Integer.valueOf >>>>>> ???? | >>>>>> CatchProj >>>>>> ???? | >>>>>> SafePoint >>>>>> ???? | >>>>>> OuterCountedLoopEnd >>>>>> >>>>>> The original problem is that the SafePoint was removed because the >>>>>> Integer.valueOf reported that it guarantees a safepoint. With the >>>>>> change - guaranteed_safepoint() returns false for boxes - no >>>>>> safepoint removal is done, the graph is kept intact. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Nils >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> New webrev here: >>>>>>>> http://cr.openjdk.java.net/~neliasso/8205107/webrev.03/ >>>>>>>> >>>>>>>> Thanks for the help! >>>>>>>> >>>>>>>> Nils >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2018-06-19 19:18, Vladimir Kozlov wrote: >>>>>>>>> On 6/19/18 9:01 AM, Vladimir Kozlov wrote: >>>>>>>>>> On 6/19/18 7:22 AM, Nils Eliasson wrote: >>>>>>>>>>> I looked at it in a bit more detail. >>>>>>>>>>> >>>>>>>>>>> The call is a java/lang/Integer::valueOf that is considered a >>>>>>>>>>> macro node so it is kept around until macro expansion which >>>>>>>>>>> happens after the place where we hit the assert. So the call >>>>>>>>>>> will go away. >>>>>>>>>> >>>>>>>>>> I assume you are talking about eliminate_boxing_node() in >>>>>>>>>> macro expansion. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> However SafepointNode::Identity does check: >>>>>>>>>>> >>>>>>>>>>> if( n0->is_Call() && n0->as_Call()->guaranteed_safepoint() ) { >>>>>>>>>>> ?????? // Useless Safepoint, so remove it >>>>>>>>>>> >>>>>>>>>>> And CallNode::guaranteed_safepoint() is: >>>>>>>>>>> >>>>>>>>>>> ?? // Are we guaranteed that this node is a safepoint? Not >>>>>>>>>>> true for leaf calls and >>>>>>>>>>> ?? // for some macro nodes whose expansion does not have a >>>>>>>>>>> safepoint on the fast path. >>>>>>>>>>> ?? virtual bool??????? guaranteed_safepoint()? { return true; } >>>>>>>>>>> >>>>>>>>>>> No check for call/macro-nodes is implemeted despite the >>>>>>>>>>> comment! If I fix this the problem goes away. >>>>>>>>>> >>>>>>>>>> It returns false for Allocate nodes which are macro nodes. >>>>>>>>>> That is what comment says. >>>>>>>>>> >>>>>>>>>> In case of boxing node I think we should add to >>>>>>>>>> CallStaticJavaNode class >>>>>>>>>> >>>>>>>>>> ?? // Boxing call which is not used and will be removed. >>>>>>>>>> ?? virtual bool??????? guaranteed_safepoint()? { return >>>>>>>>>> C->eliminate_boxing() && is_boxing_method() && >>>>>>>>>> (proj_out_or_null(TypeFunc::Parms) == NULL); } >>>>>>>>> >>>>>>>>> Sorry, test should be reversed because it guarantee SP if call >>>>>>>>> is *not* removed: >>>>>>>>> >>>>>>>>> virtual bool??????? guaranteed_safepoint()? { return >>>>>>>>> !(C->eliminate_boxing() && is_boxing_method() && >>>>>>>>> (proj_out_or_null(TypeFunc::Parms) == NULL)); } >>>>>>>>> >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> // Nils >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2018-06-18 15:41, Roland Westrelin wrote: >>>>>>>>>>>>> Roland, why we need to keep Safepoint in Outer loop if we >>>>>>>>>>>>> have call? >>>>>>>>>>>> I double checked with a simple test case and we don't keep >>>>>>>>>>>> the safepoint >>>>>>>>>>>> if there's a call so it's indeed strange that we would need >>>>>>>>>>>> Nils' patch. >>>>>>>>>>>> >>>>>>>>>>>> Roland. >>>>>>>>>>> >>>>>>>> >>>>>> >>>> >> > From nils.eliasson at oracle.com Tue Jun 26 16:41:27 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 26 Jun 2018 18:41:27 +0200 Subject: RFR(S): 8205107: assert(c->Opcode() == Op_SafePoint) failed: broken outer loop In-Reply-To: References: <06ce5035-4eb9-d56f-0a46-7188c3e74b6c@oracle.com> <26c32258-1e42-01cd-fb64-0ff4cd4ff0b8@oracle.com> <185a0fd0-6876-a6e4-d647-9bde5a7f89cf@oracle.com> <5521318c-ed90-9d04-5cc2-2dbd964dcf63@oracle.com> <1e09c221-7c6e-093c-6dc8-53759eb162ea@oracle.com> <0c2b7c85-71ec-3bd5-ac31-6715f32a5c90@oracle.com> <3b5fd81c-b69e-888e-dcd6-f969ecaa5601@oracle.com> <358db601-ae00-56dc-5b02-7157ca88044d@oracle.com> Message-ID: ok, Thanks! // Nils On 2018-06-26 18:34, Vladimir Kozlov wrote: > It is old webrev. Comment did not change. > > Vladimir > > On 6/26/18 2:20 AM, Nils Eliasson wrote: >> Are you ok with the change? >> >> http://cr.openjdk.java.net/~neliasso/8205107/webrev.02 >> >> Regards, >> >> Nils >> >> >> On 2018-06-25 23:08, Nils Eliasson wrote: >>> >>> On 2018-06-21 19:26, Vladimir Kozlov wrote: >>>> On 6/21/18 7:54 AM, Nils Eliasson wrote: >>>>> >>>>> >>>>> On 2018-06-20 21:33, Vladimir Kozlov wrote: >>>>>> On 6/20/18 12:22 PM, Nils Eliasson wrote: >>>>>>> >>>>>>> >>>>>>> On 2018-06-20 18:32, Vladimir Kozlov wrote: >>>>>>>> On 6/20/18 2:01 AM, Nils Eliasson wrote: >>>>>>>>> I simplified it to: >>>>>>>>> >>>>>>>>> ?? virtual bool guaranteed_safepoint() { >>>>>>>>> ?????? // Calls to boxing methods will be expanded, and >>>>>>>>> safepoints aren't guaranteed >>>>>>>>> ?????? return !is_boxing_method(); >>>>>>>>> ?? } >>>>>>>>> >>>>>>>>> is_boxing_method() checks is_macro() that checks the >>>>>>>>> Flag_is_macro which is only set when C->eliminate_boxing() is >>>>>>>>> true. >>>>>>>> >>>>>>>> Okay. >>>>>>>> >>>>>>>>> >>>>>>>>> "(proj_out_or_null(TypeFunc::Parms) == NULL));" seems >>>>>>>>> redundant too me. What would that guard against? >>>>>>>> >>>>>>>> It checks that result of the call is not used (Box object is >>>>>>>> eliminated by EA). It is needed otherwise you will get bad graph. >>>>>>> >>>>>>> We don't need that check since we prevent an optimization for >>>>>>> happening. The graph is kept as it is. >>>>>> >>>>>> So the result is only used by Safepoint? Then how it is >>>>>> eliminated later? >>>>> >>>>> It has other uses also. I'm not sure why the call is left, I will >>>>> investigate it further and can file a seperate bug if it is >>>>> something wrong. >>>> >>>> It is not wrong to have a Call node and Safepoint in a loop. It is >>>> just not optimal - that is all. >>>> I remember that it could be cases when even if boxing call is >>>> marked as not escaping (or scalar replaceable) it may not be >>>> eliminated because of it has still have some uses left which were >>>> not removed for different reasons. >>>> I agree that it is not easy problem. >>> >>> The problem with the test is related to Xcomp. It refuses to inline >>> valueOf beacuse it isn't loaded. The output gets confusing beacuse >>> it delays the inline until the macro-expansion, and then it reports >>> "failed inital checks". Running in normal mode makes it behave as >>> expected. >>> >>>> >>>> >>>>> >>>>> For this bug the problem is that we have a strip mined loop which >>>>> must have a safepoint. That safepoint can only be removed together >>>>> with the OuterStripMinedLoop. >>>>> >>>>> I change my mind and think my webrev.02 is the best fix - make >>>>> SafePoint::Identity to never substitute a strip-mine-loop safepoint. >>>>> >>>>> http://cr.openjdk.java.net/~neliasso/8205107/webrev.02 >>>> >>>> Okay, but please extend your comment to explain when we can have a >>>> Boxing Call node which may be late removed in Macro extension phase >>>> leaving loop without safepoint. >>> >>> This change guarantees that the (OuterStripMinedLoop) safepoint >>> doesn't get removed, even though a very unlikely call is left in the >>> countedloop. >>> >>> // Nils >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> // Nils >>>>>> >>>>>> Hmm, may be check _is_scalar_replaceable instead. >>>>>> >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> This is the graph: >>>>>>> >>>>>>> Integer.valueOf >>>>>>> ???? | >>>>>>> CatchProj >>>>>>> ???? | >>>>>>> SafePoint >>>>>>> ???? | >>>>>>> OuterCountedLoopEnd >>>>>>> >>>>>>> The original problem is that the SafePoint was removed because >>>>>>> the Integer.valueOf reported that it guarantees a safepoint. >>>>>>> With the change - guaranteed_safepoint() returns false for boxes >>>>>>> - no safepoint removal is done, the graph is kept intact. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Nils >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> >>>>>>>>> New webrev here: >>>>>>>>> http://cr.openjdk.java.net/~neliasso/8205107/webrev.03/ >>>>>>>>> >>>>>>>>> Thanks for the help! >>>>>>>>> >>>>>>>>> Nils >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2018-06-19 19:18, Vladimir Kozlov wrote: >>>>>>>>>> On 6/19/18 9:01 AM, Vladimir Kozlov wrote: >>>>>>>>>>> On 6/19/18 7:22 AM, Nils Eliasson wrote: >>>>>>>>>>>> I looked at it in a bit more detail. >>>>>>>>>>>> >>>>>>>>>>>> The call is a java/lang/Integer::valueOf that is considered >>>>>>>>>>>> a macro node so it is kept around until macro expansion >>>>>>>>>>>> which happens after the place where we hit the assert. So >>>>>>>>>>>> the call will go away. >>>>>>>>>>> >>>>>>>>>>> I assume you are talking about eliminate_boxing_node() in >>>>>>>>>>> macro expansion. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> However SafepointNode::Identity does check: >>>>>>>>>>>> >>>>>>>>>>>> if( n0->is_Call() && n0->as_Call()->guaranteed_safepoint() ) { >>>>>>>>>>>> ?????? // Useless Safepoint, so remove it >>>>>>>>>>>> >>>>>>>>>>>> And CallNode::guaranteed_safepoint() is: >>>>>>>>>>>> >>>>>>>>>>>> ?? // Are we guaranteed that this node is a safepoint? Not >>>>>>>>>>>> true for leaf calls and >>>>>>>>>>>> ?? // for some macro nodes whose expansion does not have a >>>>>>>>>>>> safepoint on the fast path. >>>>>>>>>>>> ?? virtual bool guaranteed_safepoint()? { return true; } >>>>>>>>>>>> >>>>>>>>>>>> No check for call/macro-nodes is implemeted despite the >>>>>>>>>>>> comment! If I fix this the problem goes away. >>>>>>>>>>> >>>>>>>>>>> It returns false for Allocate nodes which are macro nodes. >>>>>>>>>>> That is what comment says. >>>>>>>>>>> >>>>>>>>>>> In case of boxing node I think we should add to >>>>>>>>>>> CallStaticJavaNode class >>>>>>>>>>> >>>>>>>>>>> ?? // Boxing call which is not used and will be removed. >>>>>>>>>>> ?? virtual bool??????? guaranteed_safepoint() { return >>>>>>>>>>> C->eliminate_boxing() && is_boxing_method() && >>>>>>>>>>> (proj_out_or_null(TypeFunc::Parms) == NULL); } >>>>>>>>>> >>>>>>>>>> Sorry, test should be reversed because it guarantee SP if >>>>>>>>>> call is *not* removed: >>>>>>>>>> >>>>>>>>>> virtual bool??????? guaranteed_safepoint()? { return >>>>>>>>>> !(C->eliminate_boxing() && is_boxing_method() && >>>>>>>>>> (proj_out_or_null(TypeFunc::Parms) == NULL)); } >>>>>>>>>> >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> // Nils >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2018-06-18 15:41, Roland Westrelin wrote: >>>>>>>>>>>>>> Roland, why we need to keep Safepoint in Outer loop if we >>>>>>>>>>>>>> have call? >>>>>>>>>>>>> I double checked with a simple test case and we don't keep >>>>>>>>>>>>> the safepoint >>>>>>>>>>>>> if there's a call so it's indeed strange that we would >>>>>>>>>>>>> need Nils' patch. >>>>>>>>>>>>> >>>>>>>>>>>>> Roland. >>>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >> From adinn at redhat.com Tue Jun 26 16:55:42 2018 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 26 Jun 2018 17:55:42 +0100 Subject: RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation Message-ID: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> Reviews are welcome for the following webrev webrev: http://cr.openjdk.java.net/~adinn/8205694/webrev.00/ JIRA: https://bugs.openjdk.java.net/browse/JDK-8205694 The patch: ---------- This AArch64-only patch adds tests to ensure that volatile load, store and CAS operations are either: translated to correctly replace memory barriers with combinations of acquiring loads and releasing left untransformed with all necessary memory barriers in place The test requires a debug, aarch64 vm and is disabled if graal is being used (debug is necessary because it relies on -XX:+PrintOptoAssembly to provide evidence of what is in the compiler output). The main driver test program creates subordinate JVMs to execute subordinate programs which perform: normal and unsafe volatile loads, normal and unsafe volatile stores unsafe volatile CASes in each of 5 GC configurations: G1 CMS+CondCardMark CMS-CondCardMark Parallel Serial Arguments -XXCompileCommand,compileonly and XX:+PrintOptoAssembly are used to generate Assembly listings and the driver test program parses these to ensure the correct sequences of instructions are generated (including omitted memory barriers which are flagged in the output). A few changes were made to the aarch64.ad file to ensure that the PrintOptoAssembly output accurately represented the generated code. These were necessary to ensure that the test could be sure that the generated code sequences really were what was intended. Also, some of the comments in aarch64.ad describing the code transformation were updated following feedback from Zhongwei Yao that arrived too late to get checked in with the fix for JDK-8204331. Testing: -------- The test itself passes when run on an AArch64 debug vm. It is ignored when run on an AArch64 product vm. No other testing is needed. Nothing significant in the aarch64.ad file has been modified (only comments of format sequences which have been exercised running the new test). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Tue Jun 26 17:10:54 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Jun 2018 18:10:54 +0100 Subject: RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> Message-ID: <5c631885-8516-1aad-b978-596aa32209c6@redhat.com> On 06/26/2018 05:55 PM, Andrew Dinn wrote: > webrev: http://cr.openjdk.java.net/~adinn/8205694/webrev.00/ > JIRA: https://bugs.openjdk.java.net/browse/JDK-8205694 Yowza. OK, so that wasn't a proper review. This looks great, and pretty thorough. I'm sure there are still some ways in which the logic might fail and not be caught, but this should get the obvious ones. I don't much like the assert() rathern than guarantee() for the failures in C2. Won't we just crash anyway if these asserts fail? If so, we might as well use guarantee(). -- 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 Tue Jun 26 17:23:12 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Jun 2018 10:23:12 -0700 Subject: RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> Message-ID: Hi Andrew, Small note - all files should have Copyright header. I see only main test file have one. Thanks, Vladimir On 6/26/18 9:55 AM, Andrew Dinn wrote: > Reviews are welcome for the following webrev > > webrev: http://cr.openjdk.java.net/~adinn/8205694/webrev.00/ > JIRA: https://bugs.openjdk.java.net/browse/JDK-8205694 > > The patch: > ---------- > > This AArch64-only patch adds tests to ensure that volatile load, store > and CAS operations are either: > > translated to correctly replace memory barriers with combinations of > acquiring loads and releasing > > left untransformed with all necessary memory barriers in place > > The test requires a debug, aarch64 vm and is disabled if graal is being > used (debug is necessary because it relies on -XX:+PrintOptoAssembly to > provide evidence of what is in the compiler output). > > The main driver test program creates subordinate JVMs to execute > subordinate programs which perform: > > normal and unsafe volatile loads, > normal and unsafe volatile stores > unsafe volatile CASes > > in each of 5 GC configurations: > > G1 > CMS+CondCardMark > CMS-CondCardMark > Parallel > Serial > > Arguments -XXCompileCommand,compileonly and XX:+PrintOptoAssembly are > used to generate Assembly listings and the driver test program parses > these to ensure the correct sequences of instructions are generated > (including omitted memory barriers which are flagged in the output). > > A few changes were made to the aarch64.ad file to ensure that the > PrintOptoAssembly output accurately represented the generated code. > These were necessary to ensure that the test could be sure that the > generated code sequences really were what was intended. > > Also, some of the comments in aarch64.ad describing the code > transformation were updated following feedback from Zhongwei Yao that > arrived too late to get checked in with the fix for JDK-8204331. > > Testing: > -------- > > The test itself passes when run on an AArch64 debug vm. It is ignored > when run on an AArch64 product vm. > > No other testing is needed. Nothing significant in the aarch64.ad file > has been modified (only comments of format sequences which have been > exercised running the new test). > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From vladimir.kozlov at oracle.com Tue Jun 26 18:28:20 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Jun 2018 11:28:20 -0700 Subject: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes performance regression In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A9074D8EC@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A9073FB24@ORSMSX106.amr.corp.intel.com> <04aa0928-9be8-69bc-9a40-8e0a4436b176@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A90740968@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A907415AB@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A907415DC@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A90742C0C@ORSMSX106.amr.corp.intel.com> <12e43222-4cb8-a5a0-83b6-8790a74f326c@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A9074D8EC@ORSMSX106.amr.corp.intel.com> Message-ID: <8be0f72a-d30c-13ca-120d-0953950f79ad@oracle.com> On 6/25/18 4:49 PM, Deshpande, Vivek R wrote: > Hi Vladimir > > With this fix, the unrolling is limited to the loops with the presence of subword in the loop, which is correct for Subword Analysis and avoids unrolling > for the loops with no subword operations in the loop. This fixes the regression with MPEG. > > I analyzed the workloads SPECjvm2008-SOR.small and SPECjvm2008-MonteCarlo. > On MonteCarlo, with Subword Analysis work the loop was getting unrolled because of the following condition and was seeing the performance gain as a side effect. > if (UseSubwordForMaxVector || xors_in_loop >= 4) && body_size < (uint)LoopUnrollLimit * 4) { > With the fix the condition changed to check for the presence of Subword in the loop as following. > if ((cl->is_subword_loop() || xors_in_loop >= 4) && body_size < (uint)LoopUnrollLimit * 4) { > This caused the performance on MonteCarlo to go back to before UseSubwordForMaxVector changes. I understand but it is still regression from jdk 10. UseSubwordForMaxVector was set 'true' by 8189067 in JDK 10. > > I did not notice much of a performance impact on SOR.small with Parallel GC and Parallel Old GC on Skylake server. > > For all the experiments I used single socket with membind to avoid run to run variations on skylake server. > I also used these options -XX:-TieredCompilation -Xmx25G -Xms25G -Xmn15G -XX:+UseParallelGC -XX:ParallelGCThreads=66 We ran on E5-2690 0 @ 2.90GHz (32 threads) with next flags: -XX:+UseParallelGC -XX:+UseLargePages -XX:+UseCountedLoopSafepoints -XX:+IgnoreUnrecognizedVMOptions -XX:LoopStripMiningIter=1000 Thanks, Vladimir > > Please let me know what you think. > > Regards, > Vivek > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, June 13, 2018 12:32 PM > To: Deshpande, Vivek R ; Tobias Hartmann ; hotspot-compiler-dev at openjdk.java.net compiler > Subject: Re: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes performance regression > > Hi Vivek, > > Performance testing is finished and we see regressions. > > SPECjvm2008-SOR.small with Parallel GC - 5-7% on all platfroms. > There is also 3-5% regression in MonteCarlo with G1 (we did not test with Praallel GC - it may also regress). > > Please investigate it. > > Thanks, > Vladimir > > On 6/12/18 9:51 AM, Deshpande, Vivek R wrote: >> Hi Tobias >> >> Thanks for testing it. I have changed the status to - In Progress. >> >> Regards, >> Vivek >> >> -----Original Message----- >> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] >> Sent: Tuesday, June 12, 2018 2:48 AM >> To: Deshpande, Vivek R ; Vladimir Kozlov >> ; hotspot-compiler-dev at openjdk.java.net >> compiler >> Subject: Re: RFR(S): 8194740: Fix for: UseSubwordForMaxVector causes >> performance regression >> >> Hi Vivek, >> >> On 11.06.2018 20:51, Deshpande, Vivek R wrote: >>> http://cr.openjdk.java.net/~vdeshpande/SubwordFix/webrev.01/ >> >> This looks good to me as well. I've just submitted performance testing and premature results look great (+3.17% on SpecJVM2008 MPEG). >> >> I'll let you know once the runs are completed. Please set the status of the bug to "In Progress". >> >> Best regards, >> Tobias >> From dmitrij.pochepko at bell-sw.com Tue Jun 26 18:33:40 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Tue, 26 Jun 2018 21:33:40 +0300 Subject: RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> Message-ID: Hi Andrew, Overall looks good, but I have few minor comments regarding these tests: 1. Most tests which spawn other precesses for testing purposes are launched as "@run driver ..." for optimization reasons. 2. Do we really need to ignore external vm options set in jtreg via option: -javaoptions:""? In case these tests shouldn't ignore external options, there is ProcessTools.createJavaProcessBuilder(boolean addTestVMAndJavaOptions, String... command) for that. 3. This test will fail if jdk will be built without all GCs or without C2. It probably a good idea to split it in few tests with separate GC configurations 4. In case external options are not ignored, you'll need to filter out several vm options, like skipping execution for c1 or interpreter testruns. Something like this can be added: @requires vm.compMode != "Xint" & vm.flavor == "server" & (vm.opt.TieredStopAtLevel == null | vm.opt.TieredStopAtLevel==4) Thanks, Dmitrij On 26.06.2018 19:55, Andrew Dinn wrote: > Reviews are welcome for the following webrev > > webrev: http://cr.openjdk.java.net/~adinn/8205694/webrev.00/ > JIRA: https://bugs.openjdk.java.net/browse/JDK-8205694 > > The patch: > ---------- > > This AArch64-only patch adds tests to ensure that volatile load, store > and CAS operations are either: > > translated to correctly replace memory barriers with combinations of > acquiring loads and releasing > > left untransformed with all necessary memory barriers in place > > The test requires a debug, aarch64 vm and is disabled if graal is being > used (debug is necessary because it relies on -XX:+PrintOptoAssembly to > provide evidence of what is in the compiler output). > > The main driver test program creates subordinate JVMs to execute > subordinate programs which perform: > > normal and unsafe volatile loads, > normal and unsafe volatile stores > unsafe volatile CASes > > in each of 5 GC configurations: > > G1 > CMS+CondCardMark > CMS-CondCardMark > Parallel > Serial > > Arguments -XXCompileCommand,compileonly and XX:+PrintOptoAssembly are > used to generate Assembly listings and the driver test program parses > these to ensure the correct sequences of instructions are generated > (including omitted memory barriers which are flagged in the output). > > A few changes were made to the aarch64.ad file to ensure that the > PrintOptoAssembly output accurately represented the generated code. > These were necessary to ensure that the test could be sure that the > generated code sequences really were what was intended. > > Also, some of the comments in aarch64.ad describing the code > transformation were updated following feedback from Zhongwei Yao that > arrived too late to get checked in with the fix for JDK-8204331. > > Testing: > -------- > > The test itself passes when run on an AArch64 debug vm. It is ignored > when run on an AArch64 product vm. > > No other testing is needed. Nothing significant in the aarch64.ad file > has been modified (only comments of format sequences which have been > exercised running the new test). > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From vladimir.kozlov at oracle.com Tue Jun 26 18:48:39 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Jun 2018 11:48:39 -0700 Subject: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions In-Reply-To: <6563F381B547594081EF9DE181D0791277AAF5C2@FMSMSX119.amr.corp.intel.com> References: <6563F381B547594081EF9DE181D0791277AAD1EC@FMSMSX119.amr.corp.intel.com> <6563F381B547594081EF9DE181D0791277AAD2D4@FMSMSX119.amr.corp.intel.com> <980cfd3b-a6c1-eeda-3add-3165feea4fb9@oracle.com> <6563F381B547594081EF9DE181D0791277AAF5C2@FMSMSX119.amr.corp.intel.com> Message-ID: Yes, this looks good to me. Let me test it. Thanks, Vladimir On 6/25/18 10:25 PM, Kamath, Smita wrote: > Hi Vladimir, > > Please find the updated webrev link. > > Webrev Link: http://cr.openjdk.java.net/~srukmannagar/Base64/webrev.00/ > Bug link: https://bugs.openjdk.java.net/browse/JDK-8205528 > > Please let me know if you have additional questions. > > Thanks and Regards, > Smita > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Monday, June 25, 2018 10:48 AM > To: Kamath, Smita > Cc: hotspot compiler ; core-libs-dev at openjdk.java.net; Paul Sandoz > Subject: Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions > > I forgot to reply to your answers. > > On 6/22/18 2:49 PM, Kamath, Smita wrote: >> Hi Vladimir, >> >> Please see my answers to your questions as below: >> >> 1) One question so: why you have own copy of base64 charsets and not using one in library: >> I am using vpgatherdd instruction to fetch multiple values from base64 array in a single instruction with a vector index. Vpgatherdd instruction works on 32 bit array and so I need to define base64 charset in a 32 bit array. I have given reference to gather instruction below. > > As was discussed in an other e-mail lets keep your copy. > >> >> 2) Some indents in new and old Assembler::emit_operand() are off. In new Assembler::emit_operand() is better use } else { instead of 'return' in one branch. >> I'll make the necessary changes and send an updated webrev. >> >> 3) This is first time I see that XMM register can be used for index in address. Is it true? Can you point to Intel's document which describes it. >> I am using vpgatherdd instruction which requires index vector with scale. It uses VSIB addressing where the index register is a zmm register. >> Please refer to reference manual, volume 2c, page 2211: >> https://software.intel.com/sites/default/files/managed/39/c5/325462-sd >> m-vol-1-2abcd-3abcd.pdf Also see, section 2.3.12, page 524 for VSIB >> memory addressing information. > > Got it. Thanks for document reference. > >> >> 4) Please, add tests to test/hotspot/jtreg/compiler/intrinsics/base64 (may be similar to sha or AES in compiler/codegen/aes) to make sure that all flags, intrinsic is used and it produces correct result. >> I will add test cases as per your suggestion. > > Thanks, > Vladimir > >> >> Please let me know if you have additional questions. >> >> Thanks, >> Smita >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Friday, June 22, 2018 12:29 PM >> To: Kamath, Smita >> Cc: hotspot compiler >> Subject: Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 >> Instructions >> >> Hi Smita, >> >> I CCing to Libs to review code changes in Base64.java. >> >> Looks like you changed all need place to implement intrinsic. >> One question so: why you have own copy of base64 charsets and not using one in library: >> >> private int encode0(byte[] src, int off, int end, byte[] dst) { >> char[] base64 = isURL ? toBase64URL : toBase64; >> >> Some indents in new and old Assembler::emit_operand() are off. >> >> In new Assembler::emit_operand() is better use } else { instead of 'return' in one branch. >> >> This is first time I see that XMM register can be used for index in address. Is it true? Can you point to Intel's document which describes it. >> >> What testing you did? >> >> Please, add tests to test/hotspot/jtreg/compiler/intrinsics/base64 (may be similar to sha or AES in compiler/codegen/aes) to make sure that all flags, intrinsic is used and it produces correct result. >> >> I know there is test/jdk/java/util/Base64/ tests but they may not trigger intrinsic usage. But you can use them as starting point for new tests. >> >> Thanks, >> Vladimir >> >> On 6/22/18 11:47 AM, Kamath, Smita wrote: >>> Hi Vladimir, >>> >>> I'd like to contribute an optimization for Base64 Encoding Algorithm >>> using AVX512 Instructions. This optimization shows 1.5x improvement >>> on >>> x86_64 platform(SKL). >>> >>> Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8205528 >>> >>> Link to webrev: >>> http://cr.openjdk.java.net/~vdeshpande/Base64/webrev.00/ >>> >>> For testing the implementation, I have run tests under >>> test/jdk/java/util/Base64/ and also ran >>> test/jdk/com/sun/jndi/ldap/Base64Test.java >>> >>> I have also run jtreg. >>> >>> Please review and let me know if you have any comments. >>> >>> Thanks and Regards, >>> >>> Smita >>> From doug.simon at oracle.com Tue Jun 26 18:50:32 2018 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 26 Jun 2018 20:50:32 +0200 Subject: RFR(XS): 8205703: [JVMCI] Expose all GC selection flags Message-ID: Graal now explicitly whitelists the GCs it supports[1]. This involves looping over all the -XX:Use*GC selector flags. The flag values are read from HotSpotVMConfigAccess.readFlag[2] which needs to make a VM call for each flag not in the predefined set of flags included when initializing JVMCI. By including all the GC selector flags in the predefined set, these VM calls can be avoided. https://bugs.openjdk.java.net/browse/JDK-8205703 http://cr.openjdk.java.net/~dnsimon/8205703/ -Doug [1] https://github.com/oracle/graal/blob/3ff06d1617240c5e6b7747d1305a060fd5c69369/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotGraalRuntime.java#L157 [2] http://hg.openjdk.java.net/jdk/jdk/file/0fb45c3b185e/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfigAccess.java#l277 From dean.long at oracle.com Tue Jun 26 18:55:45 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 26 Jun 2018 11:55:45 -0700 Subject: RFR(XS): 8205703: [JVMCI] Expose all GC selection flags In-Reply-To: References: Message-ID: <477da481-eb04-80a4-e65a-79a78750dc3b@oracle.com> Looks good. dl On 6/26/18 11:50 AM, Doug Simon wrote: > Graal now explicitly whitelists the GCs it supports[1]. This involves looping over all the -XX:Use*GC selector flags. The flag values are read from HotSpotVMConfigAccess.readFlag[2] which needs to make a VM call for each flag not in the predefined set of flags included when initializing JVMCI. By including all the GC selector flags in the predefined set, these VM calls can be avoided. > > https://bugs.openjdk.java.net/browse/JDK-8205703 > http://cr.openjdk.java.net/~dnsimon/8205703/ > > -Doug > > [1] https://github.com/oracle/graal/blob/3ff06d1617240c5e6b7747d1305a060fd5c69369/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotGraalRuntime.java#L157 > [2] http://hg.openjdk.java.net/jdk/jdk/file/0fb45c3b185e/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfigAccess.java#l277 > > From vladimir.kozlov at oracle.com Tue Jun 26 19:09:31 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Jun 2018 12:09:31 -0700 Subject: RFR(XS): 8205703: [JVMCI] Expose all GC selection flags In-Reply-To: References: Message-ID: <9ba4437e-b695-904a-e967-66fd3996b5ea@oracle.com> Good. Vladimir On 6/26/18 11:50 AM, Doug Simon wrote: > Graal now explicitly whitelists the GCs it supports[1]. This involves looping over all the -XX:Use*GC selector flags. The flag values are read from HotSpotVMConfigAccess.readFlag[2] which needs to make a VM call for each flag not in the predefined set of flags included when initializing JVMCI. By including all the GC selector flags in the predefined set, these VM calls can be avoided. > > https://bugs.openjdk.java.net/browse/JDK-8205703 > http://cr.openjdk.java.net/~dnsimon/8205703/ > > -Doug > > [1] https://github.com/oracle/graal/blob/3ff06d1617240c5e6b7747d1305a060fd5c69369/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotGraalRuntime.java#L157 > [2] http://hg.openjdk.java.net/jdk/jdk/file/0fb45c3b185e/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfigAccess.java#l277 > > From igor.ignatyev at oracle.com Tue Jun 26 19:51:41 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 26 Jun 2018 12:51:41 -0700 Subject: [TESTBUG] Un-quarantine vm/mlvm/indy/func/jdi/breakpointOtherStratum and breakpoint Message-ID: <6023168D-F973-434E-A1D9-E14DD7B48281@oracle.com> http://cr.openjdk.java.net/~iignatyev//8199580/webrev.00/index.html > 1 line changed: 0 ins; 1 del; 0 mod; Hi all, could you please review this fix which removes vmTestbase/vm/mlvm/indy/func/jdi/breakpointOtherStratum test from ProblemList? the test was problem-listed due to 8199578 which has been fixed long time ago. testing: : vmTestbase_vm_mlvm test group several times on linux-x64-debug webrev: http://cr.openjdk.java.net/~iignatyev//8199580/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8199580 Thanks, -- Igor From vladimir.kozlov at oracle.com Tue Jun 26 19:53:05 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Jun 2018 12:53:05 -0700 Subject: [TESTBUG] Un-quarantine vm/mlvm/indy/func/jdi/breakpointOtherStratum and breakpoint In-Reply-To: <6023168D-F973-434E-A1D9-E14DD7B48281@oracle.com> References: <6023168D-F973-434E-A1D9-E14DD7B48281@oracle.com> Message-ID: <1237e571-a63d-08c9-e489-b455a4848e9a@oracle.com> Good. I assume you ran the test. Thanks, Vladimir On 6/26/18 12:51 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8199580/webrev.00/index.html >> 1 line changed: 0 ins; 1 del; 0 mod; > > Hi all, > > could you please review this fix which removes vmTestbase/vm/mlvm/indy/func/jdi/breakpointOtherStratum test from ProblemList? the test was problem-listed due to 8199578 which has been fixed long time ago. > > testing: : vmTestbase_vm_mlvm test group several times on linux-x64-debug > webrev: http://cr.openjdk.java.net/~iignatyev//8199580/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8199580 > > Thanks, > -- Igor > From vladimir.kozlov at oracle.com Tue Jun 26 19:53:49 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Jun 2018 12:53:49 -0700 Subject: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions In-Reply-To: References: <6563F381B547594081EF9DE181D0791277AAD1EC@FMSMSX119.amr.corp.intel.com> <6563F381B547594081EF9DE181D0791277AAD2D4@FMSMSX119.amr.corp.intel.com> <980cfd3b-a6c1-eeda-3add-3165feea4fb9@oracle.com> <6563F381B547594081EF9DE181D0791277AAF5C2@FMSMSX119.amr.corp.intel.com> Message-ID: <45d26554-45e4-923f-cdfd-bbf9b289a80a@oracle.com> Hit build failure on Windows: jib > t:/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp(4556): error C2024: 'alignas' attribute applies to variables, data members and tag types only jib > t:/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp(4595): error C2024: 'alignas' attribute applies to variables, data members and tag types only jib > t:/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp(4634): error C2024: 'alignas' attribute applies to variables, data members and tag types only jib > t:/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp(4649): error C2024: 'alignas' attribute applies to variables, data members and tag types only jib > t:/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp(4664): error C2024: 'alignas' attribute applies to variables, data members and tag types only jib > t:/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp(4679): error C2024: 'alignas' attribute applies to variables, data members and tag types only jib > t:/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp(4693): error C2024: 'alignas' attribute applies to variables, data members and tag types only jib > lib/CompileJvm.gmk:149: recipe for target '/cygdrive/t/workspace/build/windows-x64/hotspot/variant-server/libjvm/objs/stubGenerator_x86_64.obj' failed Vladimir On 6/26/18 11:48 AM, Vladimir Kozlov wrote: > Yes, this looks good to me. Let me test it. > > Thanks, > Vladimir > > On 6/25/18 10:25 PM, Kamath, Smita wrote: >> Hi Vladimir, >> >> Please find the updated webrev link. >> >> Webrev Link: http://cr.openjdk.java.net/~srukmannagar/Base64/webrev.00/ >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8205528 >> >> Please let me know if you have additional questions. >> >> Thanks and Regards, >> Smita >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Monday, June 25, 2018 10:48 AM >> To: Kamath, Smita >> Cc: hotspot compiler ; >> core-libs-dev at openjdk.java.net; Paul Sandoz >> Subject: Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 >> Instructions >> >> I forgot to reply to your answers. >> >> On 6/22/18 2:49 PM, Kamath, Smita wrote: >>> Hi Vladimir, >>> >>> Please see my answers to your questions as below: >>> >>> 1) One question so: why you have own copy of base64 charsets and not >>> using one in library: >>> I am using vpgatherdd instruction to fetch multiple values from >>> base64 array in a single instruction with a vector index. Vpgatherdd >>> instruction works on 32 bit array and so I need to define base64 >>> charset in a 32 bit array. I have given reference to gather >>> instruction below. >> >> As was discussed in an other e-mail lets keep your copy. >> >>> >>> 2) Some indents in new and old Assembler::emit_operand() are off. In >>> new Assembler::emit_operand() is better use } else { instead of >>> 'return' in one branch. >>> I'll make the necessary changes and send an updated webrev. >>> >>> 3) This is first time I see that XMM register can be used for index >>> in address. Is it true? Can you point to Intel's document which >>> describes it. >>> I am using vpgatherdd instruction which requires index vector with >>> scale. It uses VSIB addressing where the index register is a zmm >>> register. >>> Please refer to reference manual, volume 2c, page 2211: >>> https://software.intel.com/sites/default/files/managed/39/c5/325462-sd >>> m-vol-1-2abcd-3abcd.pdf Also see, section 2.3.12, page 524 for VSIB >>> memory addressing information. >> >> Got it. Thanks for document reference. >> >>> >>> 4)? Please, add tests to >>> test/hotspot/jtreg/compiler/intrinsics/base64 (may be similar to sha >>> or AES in compiler/codegen/aes) to make sure that all flags, >>> intrinsic is used and it produces correct result. >>> I will add test cases as per your suggestion. >> >> Thanks, >> Vladimir >> >>> >>> Please let me know if you have additional questions. >>> >>> Thanks, >>> Smita >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Friday, June 22, 2018 12:29 PM >>> To: Kamath, Smita >>> Cc: hotspot compiler >>> Subject: Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 >>> Instructions >>> >>> Hi Smita, >>> >>> I CCing to Libs to review code changes in Base64.java. >>> >>> Looks like you changed all need place to implement intrinsic. >>> One question so: why you have own copy of base64 charsets and not >>> using one in library: >>> >>> ??????????? private int encode0(byte[] src, int off, int end, byte[] >>> dst) { >>> ??????????????? char[] base64 = isURL ? toBase64URL : toBase64; >>> >>> Some indents in new and old Assembler::emit_operand() are off. >>> >>> In new Assembler::emit_operand() is better use } else { instead of >>> 'return' in one branch. >>> >>> This is first time I see that XMM register can be used for index in >>> address. Is it true? Can you point to Intel's document which >>> describes it. >>> >>> What testing you did? >>> >>> Please, add tests to test/hotspot/jtreg/compiler/intrinsics/base64 >>> (may be similar to sha or AES in compiler/codegen/aes) to make sure >>> that all flags, intrinsic is used and it produces correct result. >>> >>> I know there is test/jdk/java/util/Base64/ tests but they may not >>> trigger intrinsic usage. But you can use them as starting point for >>> new tests. >>> >>> Thanks, >>> Vladimir >>> >>> On 6/22/18 11:47 AM, Kamath, Smita wrote: >>>> Hi Vladimir, >>>> >>>> I'd like to contribute an optimization for Base64 Encoding Algorithm >>>> using AVX512 Instructions. This optimization shows 1.5x improvement >>>> on >>>> x86_64 platform(SKL). >>>> >>>> Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8205528 >>>> >>>> Link to webrev: >>>> http://cr.openjdk.java.net/~vdeshpande/Base64/webrev.00/ >>>> >>>> For testing the implementation, I have run tests under >>>> test/jdk/java/util/Base64/ and also ran >>>> test/jdk/com/sun/jndi/ldap/Base64Test.java >>>> >>>> I have also run jtreg. >>>> >>>> Please review and let me know if you have any comments. >>>> >>>> Thanks and Regards, >>>> >>>> Smita >>>> From igor.ignatyev at oracle.com Tue Jun 26 20:56:50 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 26 Jun 2018 13:56:50 -0700 Subject: RFR(xs): 8205390: jtreg: Fix failing TestRTMSpinLoopCount on PPC64 In-Reply-To: <13b30945-b86b-5c4e-c92b-a47b7ed425d3@oracle.com> References: <13b30945-b86b-5c4e-c92b-a47b7ed425d3@oracle.com> Message-ID: <4385AD40-8851-41D1-AA48-D2F53CF9A7BA@oracle.com> +1 -- Igor > On Jun 25, 2018, at 10:21 AM, Vladimir Kozlov wrote: > > Good. > > Thanks, > Vladimir > > On 6/25/18 1:31 AM, Gustavo Romero wrote: >> Hi, >> Could the following change be reviewed please? >> bug : https://bugs.openjdk.java.net/browse/JDK-8205390 >> webrev: http://cr.openjdk.java.net/~gromero/8205390/v1/ >> It adds a new throttling sequence for PPC64 because the last value on current >> sequence does not fit on PPC64. >> By using the new sequence the following test is fixed: >> +Passed: compiler/rtm/locking/TestRTMSpinLoopCount.java >> Thank you and best regards, >> Gustavo From igor.ignatyev at oracle.com Tue Jun 26 22:59:45 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 26 Jun 2018 15:59:45 -0700 Subject: [TESTBUG] Un-quarantine vm/mlvm/indy/func/jdi/breakpointOtherStratum and breakpoint In-Reply-To: <1237e571-a63d-08c9-e489-b455a4848e9a@oracle.com> References: <6023168D-F973-434E-A1D9-E14DD7B48281@oracle.com> <1237e571-a63d-08c9-e489-b455a4848e9a@oracle.com> Message-ID: <8D56B847-6125-4CF3-A483-30CADE9ECFAD@oracle.com> Thanks Vladimir, yes I did run this test several times to make it sure it's stable enough to be reenabled. -- Igor > On Jun 26, 2018, at 12:53 PM, Vladimir Kozlov wrote: > > Good. I assume you ran the test. > > Thanks, > Vladimir > > On 6/26/18 12:51 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8199580/webrev.00/index.html >>> 1 line changed: 0 ins; 1 del; 0 mod; >> Hi all, >> could you please review this fix which removes vmTestbase/vm/mlvm/indy/func/jdi/breakpointOtherStratum test from ProblemList? the test was problem-listed due to 8199578 which has been fixed long time ago. >> testing: : vmTestbase_vm_mlvm test group several times on linux-x64-debug >> webrev: http://cr.openjdk.java.net/~iignatyev//8199580/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8199580 >> Thanks, >> -- Igor From igor.ignatyev at oracle.com Tue Jun 26 23:21:12 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 26 Jun 2018 16:21:12 -0700 Subject: RFR(S) : 8160673 : Jittester: investigate bytecode generation hangs during bytecode tests generation Message-ID: http://cr.openjdk.java.net/~iignatyev//8160673/webrev.00/index.html > 32 lines changed: 6 ins; 12 del; 14 mod; Hi all, could you please review this small fix for jit-tester library? ByteCodeVisitor loaded generated classes, so ContextDependedClassWriter::getCommonSuperClass would be able to find common supper class using regular Class methods. in some cases, bytrecode for classes isn't yet generated (and hence not loaded) when getCommonSuperClass needs to get information about them (e.g. when generating bytecode for Class1 which is using instances of Class2 and a super class of Class2), which resulted in infinity loop inside asm library. the fix changes getCommonSuperClass method to use information about classes from jit-tester maintained list of all generated and used types. JBS: https://bugs.openjdk.java.net/browse/JDK-8160673 webrev: http://cr.openjdk.java.net/~iignatyev//8160673/webrev.00/index.html testing: generated 1k tests w/ jit-tester Thanks, -- Igor From ekaterina.pavlova at oracle.com Wed Jun 27 07:29:35 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Wed, 27 Jun 2018 00:29:35 -0700 Subject: RFR(M): 8205207: Port Graal unit tests under jtreg In-Reply-To: <42868f25-ab86-628d-55f9-e81e2fec8985@oracle.com> References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com> <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com> <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com> <5116257e-472d-13f5-f800-5e42d800934d@oracle.com> <5F6B2552-C6F7-44BB-9036-847F60A0737B@oracle.com> <42868f25-ab86-628d-55f9-e81e2fec8985@oracle.com> Message-ID: On 6/26/18 9:08 AM, Ekaterina Pavlova wrote: > Hello Magnus, > > On 6/26/18 12:50 AM, Magnus Ihse Bursie wrote: >> 23 juni 2018 kl. 00:22 skrev Ekaterina Pavlova >: >> >>> Fixed and regenerated webrev at the same location: >>> http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html >> >> Better, but not done yet. >> >> In JtregGraalUnit.gmk: line 52-53 should be on a single line. > > will fix done >> The SRC list for?BUILD_VM_COMPILER_TESTS looks insane, but the root cause here is the weird layout on disk. But the .test part really surprises me, I thought we had a clear rule to have no test source in src?! > > These are not jtreg tests, these are graalunit tests which are coming as part of Graal port (from Graal ws). > We can't change this layout right now. > > >> In lib-tests.m4: Copy paste error:?AC_MSG_ERROR([You must specify the path to tonga jar]) > > ops, will fix done >> The addition in RunTests.gmk and TestCommon.gmk should be guarded by: >> ?? ifeq ($(INCLUDE_GRAAL), true) > > ok, will look well, INCLUDE_GRAAL is not defined at the time we run tests. I can try to guard by something like ifeq ($(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), $(filter $(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU),linux-x64 macosx-x64 windows-x64)) but I am not sure we should proceed this way. It looks too much complicated. It is safe to pass -e:TEST_IMAGE_GRAAL_DIR to jtreg even it will not be used. We also do similar way for example for -e:JDK8_HOME I have uploaded new webrev at the same location: http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html thanks for reviewing, -katya >> /Magnus >> >>> >>> Erik, >>> thanks again for your detailed reviews! >>> >>> -katya >>> >>> On 6/22/18 2:38 PM, Erik Joelsson wrote: >>>> Hello Katya, >>>> This looks much better, thanks! >>>> A few suggestions still: >>>> Main.gmk: instead of repeating the assignment in both if and else block: >>>> ifeq ($(INCLUDE_GRAAL), true) >>>> ? JVM_TEST_IMAGE_TARGETS += test-image-hotspot-jtreg-graal >>>> endif >>>> I think it's fine to do that without the ?= because an alternative JVM implementation is unlikely to be using graal anyway. >>>> In JtregGraalUnit.gmk: Some minor style nits: >>>> 54: align )) with first eval line as you have done with the other eval calls >>>> 118: Since 117 is a one line parameter, please move comma to 117 >>>> 133: Same as for 118 >>>> 130-132: Please indent 4 spaces for continuation >>>> /Erik >>>> On 2018-06-22 14:16, Ekaterina Pavlova wrote: >>>>> Erik, Doug, >>>>> >>>>> thank you a lot for your reviews and advises. >>>>> I fixed everything what Erik has pointed out, please see my answers inlined. >>>>> As about moving more staff in 'updategraalinopenjdk' can we consider this as next step? >>>>> I am not quite familiar with 'updategraalinopenjdk' and didn't contribute into Graal ws yet, >>>>> so I will prefer to do this improvement/refactoring as part of separate JDK issue. >>>>> >>>>> New webrev is here: >>>>> ? webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html >>>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 >>>>> ?testing: tested by building and running graal unit tests >>>>> >>>>> >>>>> On 6/19/18 2:00 PM, Erik Joelsson wrote: >>>>>> Hello, >>>>>> >>>>>> Please always include build-dev when reviewing build changes. >>>>>> >>>>>> In general this looks pretty good but there are some details that need fixing. >>>>>> >>>>>> (Aside from this particular review, I must state my reservation against all the special treatment graal is enjoying from a source and test layout and build perspective. My understanding here is that someone will have to regularly update the wrapper jtreg tests manually using the script. This in addition to having to implement this very convoluted redirection logic because the tests are in the wrong place. Wouldn't it make a lot more sense to put the complicated logic in the import procedure for graal source so that it would fit nicely into the OpenJDK source/build/test model, instead of adding more and more complicated workarounds in the OpenJDK build and test procedures?) >>>>>> >>>>>> On 2018-06-18 22:26, Ekaterina Pavlova wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> please review porting of Graal unit tests under jtreg. The main idea of this porting is to keep Graal unit tests as is >>>>>>> (located in src/jdk.internal.vm.compiler/share/classes/*.test) and run them similar way they are run in Graal project. >>>>>>> To achieve this test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java helper class has been written >>>>>>> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to run specified set of Graal unit tests. The groups of >>>>>>> Graal unit tests to run are defined in auto-generated test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests. >>>>>>> >>>>>>> New make/test/JtregGraalUnit.gmk is used to build Graal unit tests into jdk.vm.compiler.tests.jar and then install >>>>>>> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/. >>>>>>> >>>>>> GRAALUNIT_LIB is never defined (in the open). Since this is used in open makefiles, we need an open configure option to set it. >>>>> >>>>> ok, I created open/make/autoconf/lib-tests.m4 and did put Graal related staff there. >>>>> >>>>>> To make things clearer, I would rename LIB_DIR to something like LIB_OUTPUTDIR to signal that this is a location to put files in, rather than read them from. >>>>> >>>>> ok, renamed >>>>> >>>>>> >>>>>> FLATTEN has no effect in the SetupCopyFiles call since all the jar files found by wildcard can only be in one directory anyway. >>>>> >>>>> ok, removed >>>>> >>>>>> BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. Tests classes and jars should be built into $(SUPPORT_OUTPUTDIR)/test/..> Please create a suitable sub directory there for the output from this makefile. >>>>> >>>>> ok, introduced COMPILE_OUTPUTDIR := $(SUPPORT_OUTPUTDIR)/test/graalunit to be used to build graal unit test classes. >>>>> >>>>>> The all and test-image targets are never called so no need to declare them. >>>>>> >>>>>> There are some style issues too. (Please see http://openjdk.java.net/groups/build/doc/code-conventions.html for details.) >>>>>> * 43 logic indent 2 spaces >>>>>> * 52 we like to put the ending )) on a new line with ', \' at the end of the line before >>>>>> * 58 continuation indent 4 spaces >>>>>> * 88, 89 please break long lines >>>>>> * 90 continuation indent 4 spaces >>>>>> * 99 continuation indent 4 spaces >>>>>> * 120 break before )) >>>>> >>>>> I think I fixed everything >>>>> >>>>>>> make/Main.gmk adds proper dependencies for build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal. >>>>>>> >>>>>> The target build-test-hotspot-jtreg-graal only needs to depend on exploded-image-optimize. >>>>> >>>>> fixed >>>>> >>>>>> The new graal specific targets should be guarded by INCLUDE_GRAAL in Main.gmk. Otherwise those targets will silently do nothing if invoked without graal. That means adding them to JVM_TEST_IMAGE_TARGETS needs to be conditional too. >>>>> >>>>> fixed >>>>> >>>>>>> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg knows where to find Graal tests and libs. >>>>>>> >>>>>> This needs to be duplicated for make/RunTest.gmk so that these tests work with "make run-test" as well. >>>>> >>>>> added >>>>> >>>>> thanks, >>>>> -katya >>>>> >>>>>> /Erik >>>>>>> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file defines "testName -> testPrefix [requiresStatement]" mapping >>>>>>> which is used by test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to generate jtreg tests. >>>>>>> >>>>>>> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was ported from mx project without any changes. >>>>>>> >>>>>>> >>>>>>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 >>>>>>> ?webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html >>>>>>> testing: new tests were executed as part of automatic HS testing for several months. >>>>>>> >>>>>>> >>>>>>> thanks, >>>>>>> -katya >>>>>>> >>>>>>> p.s. >>>>>>> ?Igor Ignatyev volunteered to sponsor this change. >>>>>> >>>>> >>> > From Zhongwei.Yao at arm.com Wed Jun 27 07:41:41 2018 From: Zhongwei.Yao at arm.com (Zhongwei Yao) Date: Wed, 27 Jun 2018 07:41:41 +0000 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> Message-ID: Hi, Andrew, Look good to me. Just nits: the "import java.lang.reflect.Field; import jdk.internal.misc.Unsafe;" in TestVolatileLoad.java and TestVolatileStore.java are unnecessary. -- Best regards, Zhongwei ________________________________________ From: aarch64-port-dev on behalf of Andrew Dinn Sent: Wednesday, June 27, 2018 12:55 AM To: aarch64-port-dev at openjdk.java.net; hotspot compiler Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation Reviews are welcome for the following webrev webrev: http://cr.openjdk.java.net/~adinn/8205694/webrev.00/ JIRA: https://bugs.openjdk.java.net/browse/JDK-8205694 The patch: ---------- This AArch64-only patch adds tests to ensure that volatile load, store and CAS operations are either: translated to correctly replace memory barriers with combinations of acquiring loads and releasing left untransformed with all necessary memory barriers in place The test requires a debug, aarch64 vm and is disabled if graal is being used (debug is necessary because it relies on -XX:+PrintOptoAssembly to provide evidence of what is in the compiler output). The main driver test program creates subordinate JVMs to execute subordinate programs which perform: normal and unsafe volatile loads, normal and unsafe volatile stores unsafe volatile CASes in each of 5 GC configurations: G1 CMS+CondCardMark CMS-CondCardMark Parallel Serial Arguments -XXCompileCommand,compileonly and XX:+PrintOptoAssembly are used to generate Assembly listings and the driver test program parses these to ensure the correct sequences of instructions are generated (including omitted memory barriers which are flagged in the output). A few changes were made to the aarch64.ad file to ensure that the PrintOptoAssembly output accurately represented the generated code. These were necessary to ensure that the test could be sure that the generated code sequences really were what was intended. Also, some of the comments in aarch64.ad describing the code transformation were updated following feedback from Zhongwei Yao that arrived too late to get checked in with the fix for JDK-8204331. Testing: -------- The test itself passes when run on an AArch64 debug vm. It is ignored when run on an AArch64 product vm. No other testing is needed. Nothing significant in the aarch64.ad file has been modified (only comments of format sequences which have been exercised running the new test). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From adinn at redhat.com Wed Jun 27 07:56:37 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 27 Jun 2018 08:56:37 +0100 Subject: RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <5c631885-8516-1aad-b978-596aa32209c6@redhat.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> <5c631885-8516-1aad-b978-596aa32209c6@redhat.com> Message-ID: <87229b6f-4de4-037b-356a-bf28aaa6bde7@redhat.com> On 26/06/18 18:10, Andrew Haley wrote: > On 06/26/2018 05:55 PM, Andrew Dinn wrote: >> webrev: http://cr.openjdk.java.net/~adinn/8205694/webrev.00/ >> JIRA: https://bugs.openjdk.java.net/browse/JDK-8205694 > > Yowza. > > OK, so that wasn't a proper review. This looks great, and pretty > thorough. I'm sure there are still some ways in which the logic might > fail and not be caught, but this should get the obvious ones. > > I don't much like the assert() rathern than guarantee() for the > failures in C2. Won't we just crash anyway if these asserts fail? If > so, we might as well use guarantee(). We may not always crash if these asserts fail. However, we probably want to because we don't know that the translation to use ldar and stlr insns is being applied consistently. Better to crash and fix than be left trying to track down mysterious memory bugs. I'll fix this in an updated webrev. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Wed Jun 27 07:57:42 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 27 Jun 2018 08:57:42 +0100 Subject: RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> Message-ID: <5da7153e-631c-ca41-4cd8-00a0656b6d6e@redhat.com> Hi Vladimir, On 26/06/18 18:23, Vladimir Kozlov wrote: > Small note - all files should have Copyright header. I see only main > test file have one. Thanks for looking at this. I'll fix that in the next version. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Wed Jun 27 10:54:59 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 27 Jun 2018 11:54:59 +0100 Subject: RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> Message-ID: Hi Dmitrij, On 26/06/18 19:33, Dmitrij Pochepko wrote: > Overall looks good, but I have few minor comments regarding these tests: Thanks for reviewing the patch. > 1. Most tests which spawn other precesses for testing purposes are > launched as "@run driver ..." for optimization reasons. I'm using the Process API so I can retrieve and analyze the output written to the spawned JVM's stdout. Is it possible to do that using "@run driver"? > 2. Do we really need to ignore external vm options set in jtreg via > option: -javaoptions:""? In case these tests > shouldn't ignore external options, there is > ProcessTools.createJavaProcessBuilder(boolean addTestVMAndJavaOptions, > String... command) for that. Hmm, good question. I cannot see a need to pass on any extra test options to the spawned JVMs at the moment. The only reason to create the spawned process is to observe how the JIT generates code for volatile ops and, as far as I am aware, all relevant JIT and GC options that affect that aspect of its operation are specified in the test. However, I may well have overlooked something. Do you have a specific reason for thinking that certain JVM options need to be passed on? If not perhaps we could consider passing on extra javaoptions if/when a case for it arises. > 3. This test will fail if jdk will be built without all GCs or without > C2. It probably a good idea to split it in few tests with separate GC > configurations Well, I had thought about splitting out separate tests for some GCs, although I was only motivated to do so for Shenandoah and ZGC -- to cope with their potential presence/absence. The test may also eventually need to allow for future disappearance of CMS (currently deprecated). However, that event will also require changes to the JIT code to make the case handling for CMS conditional on its presence/absence -- I am inclined to postpone any such surgery on the current test until CMS goes away. However, I don't understand how splitting the tests up is going to help deal with the either of the two config omissions you are concerned about. Consider first the question of whether C2 is present. I could specify @requires vm.flavor=="server" in the header comment but I believe that would only indicate that "--server" has been passed as an argument to the jtreg test jvm. That flag could be absent and the JVM could still include a C2 compiler. However, by adding it as a requirement the result would be that the test would only get run if the test run explicitly passes "-server" i.e. it would effectively disable the test. Similarly, if I put, say, the parallel tests into a separate file I could then add @requires vm.gc = "Parallel". However, once again I believe that would only detect whether the jtreg test jvm had been started using -XX:+UseParallelGC. It would not ensure that the test would be run using a Parallel GC when some other GC was configured for jtreg. Nor would it identify whether that a Parallel GC was available into the JVM being tested. SO, once again it would disable all tests (except, perhaps, those for G1). If I have misunderstood how the @requires config works and how splitting the tests up would improve clarity of test outcomes then I'd be happy to be corrected here. Also, I am not really sure how important it is to make this test work when the config omits C2 or removes all GCs. This test is needed to make sure that the standard AArch64 build which includes C2 and all GCs is not broken. That's the critical case to validate. I'd prefer to leave this as is for now unless and until jtreg makes it possible to identify whether a specific JIT or GC is available in a JVM under test as opposed to testing what GC is configured on the jtreg command line. > 4. In case external options are not ignored, you'll need to filter out > several vm options, like skipping execution for c1 or interpreter > testruns. Something like this can be added: @requires vm.compMode != > "Xint" & vm.flavor == "server" & (vm.opt.TieredStopAtLevel == null | > vm.opt.TieredStopAtLevel==4) I don't think that is needed given that I don't intend to pass on the jtreg test options. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From dmitrij.pochepko at bell-sw.com Wed Jun 27 12:29:41 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 27 Jun 2018 15:29:41 +0300 Subject: RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> Message-ID: <20902a61-5224-ac05-88d0-445c01b78902@bell-sw.com> On 27.06.2018 13:54, Andrew Dinn wrote: > Hi Dmitrij, > > On 26/06/18 19:33, Dmitrij Pochepko wrote: >> Overall looks good, but I have few minor comments regarding these tests: > Thanks for reviewing the patch. I'm not an official reviewed though >> 1. Most tests which spawn other precesses for testing purposes are >> launched as "@run driver ..." for optimization reasons. > I'm using the Process API so I can retrieve and analyze the output > written to the spawned JVM's stdout. Is it possible to do that using > "@run driver"? yes >> 2. Do we really need to ignore external vm options set in jtreg via >> option: -javaoptions:""? In case these tests >> shouldn't ignore external options, there is >> ProcessTools.createJavaProcessBuilder(boolean addTestVMAndJavaOptions, >> String... command) for that. > Hmm, good question. I cannot see a need to pass on any extra test > options to the spawned JVMs at the moment. The only reason to create the > spawned process is to observe how the JIT generates code for volatile > ops and, as far as I am aware, all relevant JIT and GC options that > affect that aspect of its operation are specified in the test. However, > I may well have overlooked something. > > Do you have a specific reason for thinking that certain JVM options need > to be passed on? If not perhaps we could consider passing on extra > javaoptions if/when a case for it arises. Well, not particular reason for that. There are few examples thought, like launching testing with some agent, or specific heap size e.t.c. > >> 3. This test will fail if jdk will be built without all GCs or without >> C2. It probably a good idea to split it in few tests with separate GC >> configurations > Well, I had thought about splitting out separate tests for some GCs, > although I was only motivated to do so for Shenandoah and ZGC -- to cope > with their potential presence/absence. > > The test may also eventually need to allow for future disappearance of > CMS (currently deprecated). However, that event will also require > changes to the JIT code to make the case handling for CMS conditional on > its presence/absence -- I am inclined to postpone any such surgery on > the current test until CMS goes away. > > However, I don't understand how splitting the tests up is going to help > deal with the either of the two config omissions you are concerned > about. It is a test granularity question. Splitting tests will reduce time for failure diagnostic. When looking at test report it makes a difference at first glance to see: TestVolatiles.java failed or TestVolatilesG1.java failed, or all TestVolatiles*.java failed. If you think this granularity is fine, then let it be. > Consider first the question of whether C2 is present. I could > specify @requires vm.flavor=="server" in the header comment but I > believe that would only indicate that "--server" has been passed as an > argument to the jtreg test jvm. That flag could be absent and the JVM > could still include a C2 compiler. However, by adding it as a > requirement the result would be that the test would only get run if the > test run explicitly passes "-server" i.e. it would effectively disable > the test. > > Similarly, if I put, say, the parallel tests into a separate file I > could then add @requires vm.gc = "Parallel". However, once again I > believe that would only detect whether the jtreg test jvm had been > started using -XX:+UseParallelGC. It would not ensure that the test > would be run using a Parallel GC when some other GC was configured for > jtreg. Nor would it identify whether that a Parallel GC was available > into the JVM being tested. SO, once again it would disable all tests > (except, perhaps, those for G1). > > If I have misunderstood how the @requires config works and how splitting > the tests up would improve clarity of test outcomes then I'd be happy to > be corrected here. It's not like that. vm.flavor doesn't check flags. It parse vm property "java.vm.name". vm.gc.* are also not that simple. You can check how additional "requires" properties are constructed in test/jtreg-ext/requires/VMProps.java However, since you probably won't pass external options, you won't need it. Just FYI. > > Also, I am not really sure how important it is to make this test work > when the config omits C2 or removes all GCs. This test is needed to make > sure that the standard AArch64 build which includes C2 and all GCs is > not broken. That's the critical case to validate. I'd prefer to leave > this as is for now unless and until jtreg makes it possible to identify > whether a specific JIT or GC is available in a JVM under test as opposed > to testing what GC is configured on the jtreg command line. ok > >> 4. In case external options are not ignored, you'll need to filter out >> several vm options, like skipping execution for c1 or interpreter >> testruns. Something like this can be added: @requires vm.compMode != >> "Xint" & vm.flavor == "server" & (vm.opt.TieredStopAtLevel == null | >> vm.opt.TieredStopAtLevel==4) > I don't think that is needed given that I don't intend to pass on the > jtreg test options. ok > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Wed Jun 27 13:05:25 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 27 Jun 2018 14:05:25 +0100 Subject: RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <20902a61-5224-ac05-88d0-445c01b78902@bell-sw.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> <20902a61-5224-ac05-88d0-445c01b78902@bell-sw.com> Message-ID: On 27/06/18 13:29, Dmitrij Pochepko wrote: > On 27.06.2018 13:54, Andrew Dinn wrote: >> Hi Dmitrij, >> >> On 26/06/18 19:33, Dmitrij Pochepko wrote: >>> Overall looks good, but I have few minor comments regarding these tests: >> Thanks for reviewing the patch.> I'm not an official reviewed though That's ok. You don't need to be an official reviewer to offer review comments :-) >>> 1. Most tests which spawn other precesses for testing purposes are >>> launched as "@run driver ..." for optimization reasons. >> I'm using the Process API so I can retrieve and analyze the output >> written to the spawned JVM's stdout. Is it possible to do that using >> "@run driver"? > yes Well, that's good to know ;-) but still could you explain how or point at an example? >> However, I don't understand how splitting the tests up is going to help >> deal with the either of the two config omissions you are concerned >> about. > It is a test granularity question. Splitting tests will reduce time for > failure diagnostic. When looking at test report it makes a difference at > first glance to see: TestVolatiles.java failed or TestVolatilesG1.java > failed, or all TestVolatiles*.java failed. If you think this granularity > is fine, then let it be. Ok, I take your point about granularity of failure. I'll address this in the next webrev. >> If I have misunderstood how the @requires config works and how splitting >> the tests up would improve clarity of test outcomes then I'd be happy to >> be corrected here. > It's not like that. vm.flavor doesn't check flags. It parse vm property > "java.vm.name". > vm.gc.* are also not that simple. You can check how additional > "requires" properties are constructed in > test/jtreg-ext/requires/VMProps.java Ah, ok, thanks for pointing me at that. All I had been able to decipher up to now was what the jtreg code was doing. I didn't know that there was an extension package in the JVM test tree that allowed JVM capabilities to be identified. I'll use that to extend the requires predicate for the tests. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Wed Jun 27 13:06:23 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 27 Jun 2018 14:06:23 +0100 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> Message-ID: On 27/06/18 08:41, Zhongwei Yao wrote: > Look good to me. > > Just nits: the "import java.lang.reflect.Field; import jdk.internal.misc.Unsafe;" in TestVolatileLoad.java and TestVolatileStore.java are unnecessary. Thanks, Zhongwei -- I'll remove them in the next webrev :-) regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From igor.veresov at oracle.com Wed Jun 27 13:57:54 2018 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 27 Jun 2018 06:57:54 -0700 Subject: RFR(S) 8202698: Update Graal for JEP 181 - Nest-based access control Message-ID: <1E786846-D676-45E3-B126-95653ED24C7A@oracle.com> Make appropriate changes to Graal to support nestmates. The changes required at pretty small. In fact the only change required is to check the receiver type when doing an invokeinterface on a private method. See: http://hg.openjdk.java.net/jdk/jdk/diff/2f2af62dfac7/src/hotspot/share/opto/doCall.cpp The changes here are already going upstream and would be a part of the next update but this change also removes an affected test from the problem list in the jdk repo. Webrev: http://cr.openjdk.java.net/~iveresov/8202698/webrev.01/ Thanks, igor From dmitrij.pochepko at bell-sw.com Wed Jun 27 14:41:34 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 27 Jun 2018 17:41:34 +0300 Subject: RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> <20902a61-5224-ac05-88d0-445c01b78902@bell-sw.com> Message-ID: <3c2d1773-1ba1-94ad-52b8-dc6a08dfc5e3@bell-sw.com> On 27.06.2018 16:05, Andrew Dinn wrote: > On 27/06/18 13:29, Dmitrij Pochepko wrote: >> On 27.06.2018 13:54, Andrew Dinn wrote: >>> Hi Dmitrij, >>> >>> On 26/06/18 19:33, Dmitrij Pochepko wrote: >>>> Overall looks good, but I have few minor comments regarding these tests: >>> Thanks for reviewing the patch.> I'm not an official reviewed though > That's ok. You don't need to be an official reviewer to offer review > comments :-) > >>>> 1. Most tests which spawn other precesses for testing purposes are >>>> launched as "@run driver ..." for optimization reasons. >>> I'm using the Process API so I can retrieve and analyze the output >>> written to the spawned JVM's stdout. Is it possible to do that using >>> "@run driver"? >> yes > Well, that's good to know ;-) but still could you explain how or point > at an example? it's the same as for @run main. External vm options are stored by jtreg in several vm properties: test.vm.opts and test.java.opts (for -vmoptions and -javaoptions respectively), so, process tools use it in case you call createJavaProcessBuilder with first parameter == true. Here is an example how this could be done: gc/arguments/TestUseNUMAInterleaving.java > >>> However, I don't understand how splitting the tests up is going to help >>> deal with the either of the two config omissions you are concerned >>> about. >> It is a test granularity question. Splitting tests will reduce time for >> failure diagnostic. When looking at test report it makes a difference at >> first glance to see: TestVolatiles.java failed or TestVolatilesG1.java >> failed, or all TestVolatiles*.java failed. If you think this granularity >> is fine, then let it be. > Ok, I take your point about granularity of failure. I'll address this in > the next webrev. > >>> If I have misunderstood how the @requires config works and how splitting >>> the tests up would improve clarity of test outcomes then I'd be happy to >>> be corrected here. >> It's not like that. vm.flavor doesn't check flags. It parse vm property >> "java.vm.name". >> vm.gc.* are also not that simple. You can check how additional >> "requires" properties are constructed in >> test/jtreg-ext/requires/VMProps.java > Ah, ok, thanks for pointing me at that. All I had been able to decipher > up to now was what the jtreg code was doing. I didn't know that there > was an extension package in the JVM test tree that allowed JVM > capabilities to be identified. I'll use that to extend the requires > predicate for the tests. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From nils.eliasson at oracle.com Wed Jun 27 15:00:18 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 27 Jun 2018 17:00:18 +0200 Subject: RFR(S): 8204157: Compiler.sunflow hangs after JDK-8192992 Message-ID: <4d8aa04b-092d-2a08-d1a8-a094be53602c@oracle.com> Hi, I didn't fix the load scheduling properly in JDK-8192992. I introduced a loop check on phi-nodes when doing scheduling. The missing part was that non-loop-phis fell through and didn't affect the load placement at all. (Phis are not pushed on the search stack so any store happening after was not observed.) With this fix loop-phis still force the load into the block preceding the phi (so that any store in the loop can't interfere with the load from the backedge). The new part is that regular phis fall through to next block and affects the load scheduling as a normal store would have. Bug: https://bugs.openjdk.java.net/browse/JDK-8204157 Webrev: http://cr.openjdk.java.net/~neliasso/8204157/webrev.01/ Please review, Nils From adinn at redhat.com Wed Jun 27 15:03:13 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 27 Jun 2018 16:03:13 +0100 Subject: RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <3c2d1773-1ba1-94ad-52b8-dc6a08dfc5e3@bell-sw.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> <20902a61-5224-ac05-88d0-445c01b78902@bell-sw.com> <3c2d1773-1ba1-94ad-52b8-dc6a08dfc5e3@bell-sw.com> Message-ID: <46ba0968-1270-1c72-3cd4-e7c1fd6a3a92@redhat.com> On 27/06/18 15:41, Dmitrij Pochepko wrote: > On 27.06.2018 16:05, Andrew Dinn wrote: >> On 27/06/18 13:29, Dmitrij Pochepko wrote: >>> On 27.06.2018 13:54, Andrew Dinn wrote: >>>> On 26/06/18 19:33, Dmitrij Pochepko wrote: >>>>> 1. Most tests which spawn other precesses for testing purposes are >>>>> launched as "@run driver ..." for optimization reasons. >>>> I'm using the Process API so I can retrieve and analyze the output >>>> written to the spawned JVM's stdout. Is it possible to do that using >>>> "@run driver"? >>> yes >> Well, that's good to know ;-) but still could you explain how or point >> at an example? > it's the same as for @run main. External vm options are stored by jtreg > in several vm properties: test.vm.opts and test.java.opts (for > -vmoptions and -javaoptions respectively), so, process tools use it in > case you call createJavaProcessBuilder with first parameter == true. > Here is an example how this could be done: > gc/arguments/TestUseNUMAInterleaving.java I'm really not sure what you are recommending here. Are you simply saying that I need to change the @run directives so that they say @run driver compiler.c2.aarch64.TestVolatiles instead of @run main compiler.c2.aarch64.TestVolatiles If so then I can easily do that but I would really like to understand why that is better -- as you say -- 'for optimization reasons'. Could you clarify if that is all you are suggesting and if so why it improves the situation? If, instead, you are suggesting I do something more (or something else) then can you give a precise and clear explanation of what I would need to change and why? For now it would be best to base that on the original webrev just to avoid any further confusion. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From tobias.hartmann at oracle.com Wed Jun 27 15:18:51 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 27 Jun 2018 17:18:51 +0200 Subject: RFR(S): 8204157: Compiler.sunflow hangs after JDK-8192992 In-Reply-To: <4d8aa04b-092d-2a08-d1a8-a094be53602c@oracle.com> References: <4d8aa04b-092d-2a08-d1a8-a094be53602c@oracle.com> Message-ID: Hi Nils, looks good to me. Thanks, Tobias On 27.06.2018 17:00, Nils Eliasson wrote: > Hi, > > I didn't fix the load scheduling properly in JDK-8192992. I introduced a loop check on phi-nodes > when doing scheduling. The missing part was that non-loop-phis fell through and didn't affect the > load placement at all. (Phis are not pushed on the search stack so any store happening after was not > observed.) > > With this fix loop-phis still force the load into the block preceding the phi (so that any store in > the loop can't interfere with the load from the backedge). The new part is that regular phis fall > through to next block and affects the load scheduling as a normal store would have. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8204157 > > Webrev: http://cr.openjdk.java.net/~neliasso/8204157/webrev.01/ > > Please review, > > Nils > From gromero at linux.vnet.ibm.com Wed Jun 27 15:26:02 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 27 Jun 2018 12:26:02 -0300 Subject: RFR(s): 8205582: PPC64: RTM: Fix counter for aborts on nested transactions In-Reply-To: <571b4e4aa8d04c55a2c68d655aff4023@sap.com> References: <8aadb20a-fba7-0c52-04c0-015a731e60bd@linux.vnet.ibm.com> <571b4e4aa8d04c55a2c68d655aff4023@sap.com> Message-ID: <1dee4694-2136-9869-3f31-bb78b5dcb28e@linux.vnet.ibm.com> Hi Martin, On 06/25/2018 01:31 PM, Doerr, Martin wrote: > Hi Gustavo, > > thanks for addressing this issue. Thanks lot for reviewing. > I think it would be better to ignore bit 63 in the macroAssembler code and use the definition from the spec in assembler_ppc.hpp. > Somebody may want to use the definition for other purposes. Sure. > I wonder if Assembler::tm_trans_cf | Assembler::tm_non_trans_cf would be a better match for x86's description for tm_failure_bit[2]. It's also a little unfortunate to print the same bit twice as tm_failure_bit[4]. Absolutely. Matching (Assembler::tm_trans_cf | Assembler::tm_non_trans_cf) is the most correct way to address it on Power (even if jtreg tests don't seem to stress the tm_trans_cf cases). It's indeed unfortunate to generate an asm match rule for tm_failure_bit[4] twice also. I'm fixing that right now: The first idea that come up to me is to iterate over the state bits rather than over the counters. Since it was first designed on Intel counters and abort_status match 1-by-1 perfectly on x64, so iterating over counters is just fine. But on Power we can have n (state bits)-to-1 (counter), like (tm_trans_cf | Assembler::tm_non_trans_cf) -> 1 (abort type 2 counter). Iterating over state bits also avoids the unfortunate tm_failure_bit[4] double hit. I'm thinking to use a matrix like the following to track these relations: // RTM counters confl., aborts, nests, footprint // bits in TEXASR bool tm_counter[][counter::NUM_COUNTER] = {{ true , false , false, false }, // bit conflict_tm { true , false , false, false }, // bit conflict_non_tm { false, true , false, false }, // bit abort { false, false , false, true }, // bit footprint { true , false , true , false }}; // bit nested That way we can expand and adapt the relations 'state bits vs counters vs state bit size (when there is more than 1 bit to match)' easily. Best regards, Gustavo > Best regards, > Martin > > > -----Original Message----- > From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] > Sent: Montag, 25. Juni 2018 10:19 > To: Lindenmaier, Goetz ; Doerr, Martin ; hotspot-compiler-dev at openjdk.java.net > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: RFR(s): 8205582: PPC64: RTM: Fix counter for aborts on nested transactions > > Hi, > > Could the following change be reviewed please? > > bug : https://bugs.openjdk.java.net/browse/JDK-8205582 > webrev: http://cr.openjdk.java.net/~gromero/8205582/v1/ > > It fixes the RTM counter for nested aborts (rtm lock aborts type 5) by > extracting and checking bits in the Transactional Level field of TEXASR > register. > > It also fixes the memory conflict counter (rtm lock aborts type 2). Power TM > status register supports two bits to inform two different types of memory > conflict between threads: non-transactional and transactional. According to how > the jtreg RTM tests are designed the memory conflict counter counts > non-transactional conflicts: on TestPrintPreciseRTMLockingStatistics a RTM lock > is held on a static variable while another thread without any synchronization > (non-trasactional) tries to modify the same variable. Hence that small > adjustment satisfies the TestPrintPreciseRTMLockingStatistics making it pass on > Power. The memory conflict counter is not used in any other place besides by the > RTM precise statistics (no decision is made by the JVM based on that amount). > > This change partially fixes some failures in > compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java regarding the > nested and memory conflict abort counters. The remaining issue will be fixed by > aborting on calling JNI (next RFR). > > > Thank you and best regards, > Gustavo > From erik.joelsson at oracle.com Wed Jun 27 15:36:51 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 27 Jun 2018 08:36:51 -0700 Subject: RFR(M): 8205207: Port Graal unit tests under jtreg In-Reply-To: References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com> <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com> <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com> <5116257e-472d-13f5-f800-5e42d800934d@oracle.com> <5F6B2552-C6F7-44BB-9036-847F60A0737B@oracle.com> <42868f25-ab86-628d-55f9-e81e2fec8985@oracle.com> Message-ID: <8f45dc06-5c26-76b9-b7e9-ebfde0cfe320@oracle.com> On 2018-06-27 00:29, Ekaterina Pavlova wrote: > > well, INCLUDE_GRAAL is not defined at the time we run tests. > I can try to guard by something like > ?ifeq ($(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), $(filter > $(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU),linux-x64 macosx-x64 > windows-x64)) > > but I am not sure we should proceed this way. It looks too much > complicated. > It is safe to pass -e:TEST_IMAGE_GRAAL_DIR to jtreg even it will not > be used. > We also do similar way for example for -e:JDK8_HOME > I agree, no need to guard the addition of the env variable pass through. > I have uploaded new webrev at the same location: > ?http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html > Looks good to me now. (Magnus is on vacation so you probably don't want to wait for him to respond) /Erik > > thanks for reviewing, > -katya > >>> /Magnus >>> >>>> >>>> Erik, >>>> thanks again for your detailed reviews! >>>> >>>> -katya >>>> >>>> On 6/22/18 2:38 PM, Erik Joelsson wrote: >>>>> Hello Katya, >>>>> This looks much better, thanks! >>>>> A few suggestions still: >>>>> Main.gmk: instead of repeating the assignment in both if and else >>>>> block: >>>>> ifeq ($(INCLUDE_GRAAL), true) >>>>> ? JVM_TEST_IMAGE_TARGETS += test-image-hotspot-jtreg-graal >>>>> endif >>>>> I think it's fine to do that without the ?= because an alternative >>>>> JVM implementation is unlikely to be using graal anyway. >>>>> In JtregGraalUnit.gmk: Some minor style nits: >>>>> 54: align )) with first eval line as you have done with the other >>>>> eval calls >>>>> 118: Since 117 is a one line parameter, please move comma to 117 >>>>> 133: Same as for 118 >>>>> 130-132: Please indent 4 spaces for continuation >>>>> /Erik >>>>> On 2018-06-22 14:16, Ekaterina Pavlova wrote: >>>>>> Erik, Doug, >>>>>> >>>>>> thank you a lot for your reviews and advises. >>>>>> I fixed everything what Erik has pointed out, please see my >>>>>> answers inlined. >>>>>> As about moving more staff in 'updategraalinopenjdk' can we >>>>>> consider this as next step? >>>>>> I am not quite familiar with 'updategraalinopenjdk' and didn't >>>>>> contribute into Graal ws yet, >>>>>> so I will prefer to do this improvement/refactoring as part of >>>>>> separate JDK issue. >>>>>> >>>>>> New webrev is here: >>>>>> ? webrev: >>>>>> http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html >>>>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 >>>>>> ?testing: tested by building and running graal unit tests >>>>>> >>>>>> >>>>>> On 6/19/18 2:00 PM, Erik Joelsson wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please always include build-dev when reviewing build changes. >>>>>>> >>>>>>> In general this looks pretty good but there are some details >>>>>>> that need fixing. >>>>>>> >>>>>>> (Aside from this particular review, I must state my reservation >>>>>>> against all the special treatment graal is enjoying from a >>>>>>> source and test layout and build perspective. My understanding >>>>>>> here is that someone will have to regularly update the wrapper >>>>>>> jtreg tests manually using the script. This in addition to >>>>>>> having to implement this very convoluted redirection logic >>>>>>> because the tests are in the wrong place. Wouldn't it make a lot >>>>>>> more sense to put the complicated logic in the import procedure >>>>>>> for graal source so that it would fit nicely into the OpenJDK >>>>>>> source/build/test model, instead of adding more and more >>>>>>> complicated workarounds in the OpenJDK build and test procedures?) >>>>>>> >>>>>>> On 2018-06-18 22:26, Ekaterina Pavlova wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> please review porting of Graal unit tests under jtreg. The main >>>>>>>> idea of this porting is to keep Graal unit tests as is >>>>>>>> (located in src/jdk.internal.vm.compiler/share/classes/*.test) >>>>>>>> and run them similar way they are run in Graal project. >>>>>>>> To achieve this >>>>>>>> test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java >>>>>>>> helper class has been written >>>>>>>> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to >>>>>>>> run specified set of Graal unit tests. The groups of >>>>>>>> Graal unit tests to run are defined in auto-generated >>>>>>>> test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests. >>>>>>>> >>>>>>>> New make/test/JtregGraalUnit.gmk is used to build Graal unit >>>>>>>> tests into jdk.vm.compiler.tests.jar and then install >>>>>>>> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/. >>>>>>>> >>>>>>> GRAALUNIT_LIB is never defined (in the open). Since this is used >>>>>>> in open makefiles, we need an open configure option to set it. >>>>>> >>>>>> ok, I created open/make/autoconf/lib-tests.m4 and did put Graal >>>>>> related staff there. >>>>>> >>>>>>> To make things clearer, I would rename LIB_DIR to something like >>>>>>> LIB_OUTPUTDIR to signal that this is a location to put files in, >>>>>>> rather than read them from. >>>>>> >>>>>> ok, renamed >>>>>> >>>>>>> >>>>>>> FLATTEN has no effect in the SetupCopyFiles call since all the >>>>>>> jar files found by wildcard can only be in one directory anyway. >>>>>> >>>>>> ok, removed >>>>>> >>>>>>> BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. >>>>>>> Tests classes and jars should be built into >>>>>>> $(SUPPORT_OUTPUTDIR)/test/..> Please create a suitable sub >>>>>>> directory there for the output from this makefile. >>>>>> >>>>>> ok, introduced COMPILE_OUTPUTDIR := >>>>>> $(SUPPORT_OUTPUTDIR)/test/graalunit to be used to build graal >>>>>> unit test classes. >>>>>> >>>>>>> The all and test-image targets are never called so no need to >>>>>>> declare them. >>>>>>> >>>>>>> There are some style issues too. (Please see >>>>>>> http://openjdk.java.net/groups/build/doc/code-conventions.html >>>>>>> for details.) >>>>>>> * 43 logic indent 2 spaces >>>>>>> * 52 we like to put the ending )) on a new line with ', \' at >>>>>>> the end of the line before >>>>>>> * 58 continuation indent 4 spaces >>>>>>> * 88, 89 please break long lines >>>>>>> * 90 continuation indent 4 spaces >>>>>>> * 99 continuation indent 4 spaces >>>>>>> * 120 break before )) >>>>>> >>>>>> I think I fixed everything >>>>>> >>>>>>>> make/Main.gmk adds proper dependencies for >>>>>>>> build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal. >>>>>>>> >>>>>>> The target build-test-hotspot-jtreg-graal only needs to depend >>>>>>> on exploded-image-optimize. >>>>>> >>>>>> fixed >>>>>> >>>>>>> The new graal specific targets should be guarded by >>>>>>> INCLUDE_GRAAL in Main.gmk. Otherwise those targets will silently >>>>>>> do nothing if invoked without graal. That means adding them to >>>>>>> JVM_TEST_IMAGE_TARGETS needs to be conditional too. >>>>>> >>>>>> fixed >>>>>> >>>>>>>> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so >>>>>>>> jtreg knows where to find Graal tests and libs. >>>>>>>> >>>>>>> This needs to be duplicated for make/RunTest.gmk so that these >>>>>>> tests work with "make run-test" as well. >>>>>> >>>>>> added >>>>>> >>>>>> thanks, >>>>>> -katya >>>>>> >>>>>>> /Erik >>>>>>>> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file >>>>>>>> defines "testName -> testPrefix [requiresStatement]" mapping >>>>>>>> which is used by >>>>>>>> test/hotspot/jtreg/compiler/graalunit/generateTests.sh script >>>>>>>> to generate jtreg tests. >>>>>>>> >>>>>>>> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit >>>>>>>> was ported from mx project without any changes. >>>>>>>> >>>>>>>> >>>>>>>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 >>>>>>>> ?webrev: >>>>>>>> http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html >>>>>>>> testing: new tests were executed as part of automatic HS >>>>>>>> testing for several months. >>>>>>>> >>>>>>>> >>>>>>>> thanks, >>>>>>>> -katya >>>>>>>> >>>>>>>> p.s. >>>>>>>> ?Igor Ignatyev volunteered to sponsor this change. >>>>>>> >>>>>> >>>> >> > From dmitrij.pochepko at bell-sw.com Wed Jun 27 16:10:38 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 27 Jun 2018 20:10:38 +0400 Subject: RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <46ba0968-1270-1c72-3cd4-e7c1fd6a3a92@redhat.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> <20902a61-5224-ac05-88d0-445c01b78902@bell-sw.com> <3c2d1773-1ba1-94ad-52b8-dc6a08dfc5e3@bell-sw.com> <46ba0968-1270-1c72-3cd4-e7c1fd6a3a92@redhat.com> Message-ID: <5B33B6FE.7080502@bell-sw.com> 27.06.2018 19:03, Andrew Dinn ?????: > On 27/06/18 15:41, Dmitrij Pochepko wrote: >> On 27.06.2018 16:05, Andrew Dinn wrote: >>> On 27/06/18 13:29, Dmitrij Pochepko wrote: >>>> On 27.06.2018 13:54, Andrew Dinn wrote: >>>>> On 26/06/18 19:33, Dmitrij Pochepko wrote: >>>>>> 1. Most tests which spawn other precesses for testing purposes are >>>>>> launched as "@run driver ..." for optimization reasons. >>>>> I'm using the Process API so I can retrieve and analyze the output >>>>> written to the spawned JVM's stdout. Is it possible to do that using >>>>> "@run driver"? >>>> yes >>> Well, that's good to know ;-) but still could you explain how or point >>> at an example? >> it's the same as for @run main. External vm options are stored by jtreg >> in several vm properties: test.vm.opts and test.java.opts (for >> -vmoptions and -javaoptions respectively), so, process tools use it in >> case you call createJavaProcessBuilder with first parameter == true. >> Here is an example how this could be done: >> gc/arguments/TestUseNUMAInterleaving.java > > I'm really not sure what you are recommending here. Are you simply > saying that I need to change the @run directives so that they say > > @run driver compiler.c2.aarch64.TestVolatiles > > instead of > > @run main compiler.c2.aarch64.TestVolatiles > > If so then I can easily do that but I would really like to understand > why that is better -- as you say -- 'for optimization reasons'. > > Could you clarify if that is all you are suggesting and if so why it > improves the situation? Yes. It is exactly what I'm suggesting. @run driver is a specifical subform of @run main, which always run in same vm as jtreg, without spawning additional java process. Official jtreg guideline also says about driver(http://openjdk.java.net/jtreg/tag-spec.html): "Invoke the main method of the specified class, passing any arguments after the class name. Although superficially similar to @run main, this is for use when it is desirable to perform additional setup or configuration before running the class containing the actual test code, possibly in a child VM." > > If, instead, you are suggesting I do something more (or something else) > then can you give a precise and clear explanation of what I would need > to change and why? For now it would be best to base that on the original > webrev just to avoid any further confusion. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From nils.eliasson at oracle.com Wed Jun 27 16:27:06 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 27 Jun 2018 18:27:06 +0200 Subject: RFR(S): 8204157: Compiler.sunflow hangs after JDK-8192992 In-Reply-To: References: <4d8aa04b-092d-2a08-d1a8-a094be53602c@oracle.com> Message-ID: <7749f010-ac00-cc87-0771-bf9f5941ed9e@oracle.com> Thank you Tobias! //N On 2018-06-27 17:18, Tobias Hartmann wrote: > Hi Nils, > > looks good to me. > > Thanks, > Tobias > > On 27.06.2018 17:00, Nils Eliasson wrote: >> Hi, >> >> I didn't fix the load scheduling properly in JDK-8192992. I introduced a loop check on phi-nodes >> when doing scheduling. The missing part was that non-loop-phis fell through and didn't affect the >> load placement at all. (Phis are not pushed on the search stack so any store happening after was not >> observed.) >> >> With this fix loop-phis still force the load into the block preceding the phi (so that any store in >> the loop can't interfere with the load from the backedge). The new part is that regular phis fall >> through to next block and affects the load scheduling as a normal store would have. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8204157 >> >> Webrev: http://cr.openjdk.java.net/~neliasso/8204157/webrev.01/ >> >> Please review, >> >> Nils >> From adinn at redhat.com Wed Jun 27 16:28:55 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 27 Jun 2018 17:28:55 +0100 Subject: RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> Message-ID: <30a5c2f9-704d-8b9e-d947-16e6f5ec34cc@redhat.com> Here is an updated webrev which addresses all comments modulo Dmitrij's recommendation about use of @run driver for which I am still awaiting clarification. I hope the changes described below are satisfactory. webrev: http://cr.openjdk.java.net/~adinn/8205694/webrev.01 JIRA: https://bugs.openjdk.java.net/browse/JDK-8205694 Dmitirj, if you can explain what else I need to tweak then I'll be happy to update the webrev. If not please let me know if it is ok to push. Changes: Modified asserts in the aarch64.ad predicates to guarantees in all cases where they relate to expectations about the graph structure. The ones that are still left as asserts refer to expectations about what nodes should be passed as predicate arguments i.e. the former are about consistency external to the aarch64.ad file and the latter to internal consistency (I don't believe the latter merit a check in product code). Added copyright headers to all test files Turned the original test class (TestVolatiles) into a test runner which can be used to check a specific volatile op + GC config combination. Added 5 new test classes (TestVolatilesG1, TestVolatilesSerial, TestVolatilesParallel, TestVolatilesCMS, and TestVolatilesCMSCardMark) which indirect control to TestVolatiles to test each of the 5 different volatile ops with one of the relevant GC configurations. Added @require conditions to each of the 5 new tests to ensure it is run in a server GC and that the GC confguration under test is supported by the JVM. Testing: All 5 tests passed on a debug, server VM. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Wed Jun 27 16:32:37 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 27 Jun 2018 17:32:37 +0100 Subject: RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <5B33B6FE.7080502@bell-sw.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> <20902a61-5224-ac05-88d0-445c01b78902@bell-sw.com> <3c2d1773-1ba1-94ad-52b8-dc6a08dfc5e3@bell-sw.com> <46ba0968-1270-1c72-3cd4-e7c1fd6a3a92@redhat.com> <5B33B6FE.7080502@bell-sw.com> Message-ID: On 27/06/18 17:10, Dmitrij Pochepko wrote: > 27.06.2018 19:03, Andrew Dinn ?????: >> I'm really not sure what you are recommending here. Are you simply >> saying that I need to change the @run directives so that they say >> >> ?? @run driver compiler.c2.aarch64.TestVolatiles >> >> instead of >> >> ?? @run main compiler.c2.aarch64.TestVolatiles >> >> If so then I can easily do that but I would really like to understand >> why that is better -- as you say -- 'for optimization reasons'. >> >> Could you clarify if that is all you are suggesting and if so why it >> improves the situation? > Yes. It is exactly what I'm suggesting. @run driver is a specifical > subform of @run main, which always run in same vm as jtreg, without > spawning additional java process. Ok, thanks for explaining. I'll tweak the latest webrev (just posted details) so that @run main is replaced with @run driver. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From vladimir.kozlov at oracle.com Wed Jun 27 16:40:29 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Jun 2018 09:40:29 -0700 Subject: RFR(S) 8202698: Update Graal for JEP 181 - Nest-based access control In-Reply-To: <1E786846-D676-45E3-B126-95653ED24C7A@oracle.com> References: <1E786846-D676-45E3-B126-95653ED24C7A@oracle.com> Message-ID: <8f345b11-134a-09c9-d8b8-95c2e70597b0@oracle.com> Good. I see that Doug approved it already. Thanks, Vladimir On 6/27/18 6:57 AM, Igor Veresov wrote: > Make appropriate changes to Graal to support nestmates. > The changes required at pretty small. In fact the only change required is to check the receiver type when doing an invokeinterface on a private method. See: http://hg.openjdk.java.net/jdk/jdk/diff/2f2af62dfac7/src/hotspot/share/opto/doCall.cpp > > The changes here are already going upstream and would be a part of the next update but this change also removes an affected test from the problem list in the jdk repo. > > Webrev: http://cr.openjdk.java.net/~iveresov/8202698/webrev.01/ > > Thanks, > igor > From dmitrij.pochepko at bell-sw.com Wed Jun 27 16:40:50 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 27 Jun 2018 20:40:50 +0400 Subject: RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <30a5c2f9-704d-8b9e-d947-16e6f5ec34cc@redhat.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> <30a5c2f9-704d-8b9e-d947-16e6f5ec34cc@redhat.com> Message-ID: <5B33BE12.805@bell-sw.com> Hi, looks good to me(with @run main changed to @run driver) Thanks, Dmitrij 27.06.2018 20:28, Andrew Dinn wrote: > Here is an updated webrev which addresses all comments modulo Dmitrij's > recommendation about use of @run driver for which I am still awaiting > clarification. I hope the changes described below are satisfactory. > > webrev: http://cr.openjdk.java.net/~adinn/8205694/webrev.01 > JIRA: https://bugs.openjdk.java.net/browse/JDK-8205694 > > Dmitirj, if you can explain what else I need to tweak then I'll be happy > to update the webrev. If not please let me know if it is ok to push. > > Changes: > > Modified asserts in the aarch64.ad predicates to guarantees in all cases > where they relate to expectations about the graph structure. The ones > that are still left as asserts refer to expectations about what nodes > should be passed as predicate arguments i.e. the former are about > consistency external to the aarch64.ad file and the latter to internal > consistency (I don't believe the latter merit a check in product code). > > Added copyright headers to all test files > > Turned the original test class (TestVolatiles) into a test runner which > can be used to check a specific volatile op + GC config combination. > > Added 5 new test classes (TestVolatilesG1, TestVolatilesSerial, > TestVolatilesParallel, TestVolatilesCMS, and TestVolatilesCMSCardMark) > which indirect control to TestVolatiles to test each of the 5 different > volatile ops with one of the relevant GC configurations. > > Added @require conditions to each of the 5 new tests to ensure it is run > in a server GC and that the GC confguration under test is supported by > the JVM. > > Testing: > > All 5 tests passed on a debug, server VM. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From ekaterina.pavlova at oracle.com Wed Jun 27 16:51:38 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Wed, 27 Jun 2018 09:51:38 -0700 Subject: RFR(M): 8205207: Port Graal unit tests under jtreg In-Reply-To: <8f45dc06-5c26-76b9-b7e9-ebfde0cfe320@oracle.com> References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com> <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com> <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com> <5116257e-472d-13f5-f800-5e42d800934d@oracle.com> <5F6B2552-C6F7-44BB-9036-847F60A0737B@oracle.com> <42868f25-ab86-628d-55f9-e81e2fec8985@oracle.com> <8f45dc06-5c26-76b9-b7e9-ebfde0cfe320@oracle.com> Message-ID: Thanks Erik! -katya On 6/27/18 8:36 AM, Erik Joelsson wrote: > > > On 2018-06-27 00:29, Ekaterina Pavlova wrote: >> >> well, INCLUDE_GRAAL is not defined at the time we run tests. >> I can try to guard by something like >> ?ifeq ($(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), $(filter $(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU),linux-x64 macosx-x64 windows-x64)) >> >> but I am not sure we should proceed this way. It looks too much complicated. >> It is safe to pass -e:TEST_IMAGE_GRAAL_DIR to jtreg even it will not be used. >> We also do similar way for example for -e:JDK8_HOME >> > I agree, no need to guard the addition of the env variable pass through. >> I have uploaded new webrev at the same location: >> ?http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html >> > Looks good to me now. (Magnus is on vacation so you probably don't want to wait for him to respond) > > /Erik >> >> thanks for reviewing, >> -katya >> >>>> /Magnus >>>> >>>>> >>>>> Erik, >>>>> thanks again for your detailed reviews! >>>>> >>>>> -katya >>>>> >>>>> On 6/22/18 2:38 PM, Erik Joelsson wrote: >>>>>> Hello Katya, >>>>>> This looks much better, thanks! >>>>>> A few suggestions still: >>>>>> Main.gmk: instead of repeating the assignment in both if and else block: >>>>>> ifeq ($(INCLUDE_GRAAL), true) >>>>>> ? JVM_TEST_IMAGE_TARGETS += test-image-hotspot-jtreg-graal >>>>>> endif >>>>>> I think it's fine to do that without the ?= because an alternative JVM implementation is unlikely to be using graal anyway. >>>>>> In JtregGraalUnit.gmk: Some minor style nits: >>>>>> 54: align )) with first eval line as you have done with the other eval calls >>>>>> 118: Since 117 is a one line parameter, please move comma to 117 >>>>>> 133: Same as for 118 >>>>>> 130-132: Please indent 4 spaces for continuation >>>>>> /Erik >>>>>> On 2018-06-22 14:16, Ekaterina Pavlova wrote: >>>>>>> Erik, Doug, >>>>>>> >>>>>>> thank you a lot for your reviews and advises. >>>>>>> I fixed everything what Erik has pointed out, please see my answers inlined. >>>>>>> As about moving more staff in 'updategraalinopenjdk' can we consider this as next step? >>>>>>> I am not quite familiar with 'updategraalinopenjdk' and didn't contribute into Graal ws yet, >>>>>>> so I will prefer to do this improvement/refactoring as part of separate JDK issue. >>>>>>> >>>>>>> New webrev is here: >>>>>>> ? webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html >>>>>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 >>>>>>> ?testing: tested by building and running graal unit tests >>>>>>> >>>>>>> >>>>>>> On 6/19/18 2:00 PM, Erik Joelsson wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please always include build-dev when reviewing build changes. >>>>>>>> >>>>>>>> In general this looks pretty good but there are some details that need fixing. >>>>>>>> >>>>>>>> (Aside from this particular review, I must state my reservation against all the special treatment graal is enjoying from a source and test layout and build perspective. My understanding here is that someone will have to regularly update the wrapper jtreg tests manually using the script. This in addition to having to implement this very convoluted redirection logic because the tests are in the wrong place. Wouldn't it make a lot more sense to put the complicated logic in the import procedure for graal source so that it would fit nicely into the OpenJDK source/build/test model, instead of adding more and more complicated workarounds in the OpenJDK build and test procedures?) >>>>>>>> >>>>>>>> On 2018-06-18 22:26, Ekaterina Pavlova wrote: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> please review porting of Graal unit tests under jtreg. The main idea of this porting is to keep Graal unit tests as is >>>>>>>>> (located in src/jdk.internal.vm.compiler/share/classes/*.test) and run them similar way they are run in Graal project. >>>>>>>>> To achieve this test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java helper class has been written >>>>>>>>> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to run specified set of Graal unit tests. The groups of >>>>>>>>> Graal unit tests to run are defined in auto-generated test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests. >>>>>>>>> >>>>>>>>> New make/test/JtregGraalUnit.gmk is used to build Graal unit tests into jdk.vm.compiler.tests.jar and then install >>>>>>>>> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/. >>>>>>>>> >>>>>>>> GRAALUNIT_LIB is never defined (in the open). Since this is used in open makefiles, we need an open configure option to set it. >>>>>>> >>>>>>> ok, I created open/make/autoconf/lib-tests.m4 and did put Graal related staff there. >>>>>>> >>>>>>>> To make things clearer, I would rename LIB_DIR to something like LIB_OUTPUTDIR to signal that this is a location to put files in, rather than read them from. >>>>>>> >>>>>>> ok, renamed >>>>>>> >>>>>>>> >>>>>>>> FLATTEN has no effect in the SetupCopyFiles call since all the jar files found by wildcard can only be in one directory anyway. >>>>>>> >>>>>>> ok, removed >>>>>>> >>>>>>>> BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. Tests classes and jars should be built into $(SUPPORT_OUTPUTDIR)/test/..> Please create a suitable sub directory there for the output from this makefile. >>>>>>> >>>>>>> ok, introduced COMPILE_OUTPUTDIR := $(SUPPORT_OUTPUTDIR)/test/graalunit to be used to build graal unit test classes. >>>>>>> >>>>>>>> The all and test-image targets are never called so no need to declare them. >>>>>>>> >>>>>>>> There are some style issues too. (Please see http://openjdk.java.net/groups/build/doc/code-conventions.html for details.) >>>>>>>> * 43 logic indent 2 spaces >>>>>>>> * 52 we like to put the ending )) on a new line with ', \' at the end of the line before >>>>>>>> * 58 continuation indent 4 spaces >>>>>>>> * 88, 89 please break long lines >>>>>>>> * 90 continuation indent 4 spaces >>>>>>>> * 99 continuation indent 4 spaces >>>>>>>> * 120 break before )) >>>>>>> >>>>>>> I think I fixed everything >>>>>>> >>>>>>>>> make/Main.gmk adds proper dependencies for build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal. >>>>>>>>> >>>>>>>> The target build-test-hotspot-jtreg-graal only needs to depend on exploded-image-optimize. >>>>>>> >>>>>>> fixed >>>>>>> >>>>>>>> The new graal specific targets should be guarded by INCLUDE_GRAAL in Main.gmk. Otherwise those targets will silently do nothing if invoked without graal. That means adding them to JVM_TEST_IMAGE_TARGETS needs to be conditional too. >>>>>>> >>>>>>> fixed >>>>>>> >>>>>>>>> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg knows where to find Graal tests and libs. >>>>>>>>> >>>>>>>> This needs to be duplicated for make/RunTest.gmk so that these tests work with "make run-test" as well. >>>>>>> >>>>>>> added >>>>>>> >>>>>>> thanks, >>>>>>> -katya >>>>>>> >>>>>>>> /Erik >>>>>>>>> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file defines "testName -> testPrefix [requiresStatement]" mapping >>>>>>>>> which is used by test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to generate jtreg tests. >>>>>>>>> >>>>>>>>> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was ported from mx project without any changes. >>>>>>>>> >>>>>>>>> >>>>>>>>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207 >>>>>>>>> ?webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html >>>>>>>>> testing: new tests were executed as part of automatic HS testing for several months. >>>>>>>>> >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> -katya >>>>>>>>> >>>>>>>>> p.s. >>>>>>>>> ?Igor Ignatyev volunteered to sponsor this change. >>>>>>>> >>>>>>> >>>>> >>> >> > From igor.veresov at oracle.com Wed Jun 27 16:55:18 2018 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 27 Jun 2018 09:55:18 -0700 Subject: RFR(S) 8202698: Update Graal for JEP 181 - Nest-based access control In-Reply-To: <8f345b11-134a-09c9-d8b8-95c2e70597b0@oracle.com> References: <1E786846-D676-45E3-B126-95653ED24C7A@oracle.com> <8f345b11-134a-09c9-d8b8-95c2e70597b0@oracle.com> Message-ID: <25389AE5-55DB-4CB7-86A3-9563CFA55EB0@oracle.com> Yes, thanks, Vladimir! igor > On Jun 27, 2018, at 9:40 AM, Vladimir Kozlov wrote: > > Good. I see that Doug approved it already. > > Thanks, > Vladimir > > On 6/27/18 6:57 AM, Igor Veresov wrote: >> Make appropriate changes to Graal to support nestmates. >> The changes required at pretty small. In fact the only change required is to check the receiver type when doing an invokeinterface on a private method. See: http://hg.openjdk.java.net/jdk/jdk/diff/2f2af62dfac7/src/hotspot/share/opto/doCall.cpp >> The changes here are already going upstream and would be a part of the next update but this change also removes an affected test from the problem list in the jdk repo. >> Webrev: http://cr.openjdk.java.net/~iveresov/8202698/webrev.01/ >> Thanks, >> igor From vladimir.kozlov at oracle.com Wed Jun 27 17:38:22 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Jun 2018 10:38:22 -0700 Subject: RFR(S): 8204157: Compiler.sunflow hangs after JDK-8192992 In-Reply-To: References: <4d8aa04b-092d-2a08-d1a8-a094be53602c@oracle.com> Message-ID: <1ad9e38a-a106-d3be-4b50-9524f9174cd3@oracle.com> +1 Vladimir On 6/27/18 8:18 AM, Tobias Hartmann wrote: > Hi Nils, > > looks good to me. > > Thanks, > Tobias > > On 27.06.2018 17:00, Nils Eliasson wrote: >> Hi, >> >> I didn't fix the load scheduling properly in JDK-8192992. I introduced a loop check on phi-nodes >> when doing scheduling. The missing part was that non-loop-phis fell through and didn't affect the >> load placement at all. (Phis are not pushed on the search stack so any store happening after was not >> observed.) >> >> With this fix loop-phis still force the load into the block preceding the phi (so that any store in >> the loop can't interfere with the load from the backedge). The new part is that regular phis fall >> through to next block and affects the load scheduling as a normal store would have. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8204157 >> >> Webrev: http://cr.openjdk.java.net/~neliasso/8204157/webrev.01/ >> >> Please review, >> >> Nils >> From smita.kamath at intel.com Wed Jun 27 19:58:46 2018 From: smita.kamath at intel.com (Kamath, Smita) Date: Wed, 27 Jun 2018 19:58:46 +0000 Subject: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions In-Reply-To: <45d26554-45e4-923f-cdfd-bbf9b289a80a@oracle.com> References: <6563F381B547594081EF9DE181D0791277AAD1EC@FMSMSX119.amr.corp.intel.com> <6563F381B547594081EF9DE181D0791277AAD2D4@FMSMSX119.amr.corp.intel.com> <980cfd3b-a6c1-eeda-3add-3165feea4fb9@oracle.com> <6563F381B547594081EF9DE181D0791277AAF5C2@FMSMSX119.amr.corp.intel.com> <45d26554-45e4-923f-cdfd-bbf9b289a80a@oracle.com> Message-ID: <6563F381B547594081EF9DE181D0791277AB031E@FMSMSX119.amr.corp.intel.com> Hi Vladimir, Please find the updated webrev. Bug link: https://bugs.openjdk.java.net/browse/JDK-8205528 Webrev link : http://cr.openjdk.java.net/~srukmannagar/Base64/webrev.01/ Thanks, Smita -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Tuesday, June 26, 2018 12:54 PM To: Kamath, Smita Cc: hotspot compiler Subject: Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions Hit build failure on Windows: jib > t:/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp(4556): error C2024: 'alignas' attribute applies to variables, data members and tag types only jib > t:/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp(4595): error C2024: 'alignas' attribute applies to variables, data members and tag types only jib > t:/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp(4634): error C2024: 'alignas' attribute applies to variables, data members and tag types only jib > t:/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp(4649): error C2024: 'alignas' attribute applies to variables, data members and tag types only jib > t:/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp(4664): error C2024: 'alignas' attribute applies to variables, data members and tag types only jib > t:/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp(4679): error C2024: 'alignas' attribute applies to variables, data members and tag types only jib > t:/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp(4693): error C2024: 'alignas' attribute applies to variables, data members and tag types only jib > lib/CompileJvm.gmk:149: recipe for target '/cygdrive/t/workspace/build/windows-x64/hotspot/variant-server/libjvm/objs/stubGenerator_x86_64.obj' failed Vladimir On 6/26/18 11:48 AM, Vladimir Kozlov wrote: > Yes, this looks good to me. Let me test it. > > Thanks, > Vladimir > > On 6/25/18 10:25 PM, Kamath, Smita wrote: >> Hi Vladimir, >> >> Please find the updated webrev link. >> >> Webrev Link: >> http://cr.openjdk.java.net/~srukmannagar/Base64/webrev.00/ >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8205528 >> >> Please let me know if you have additional questions. >> >> Thanks and Regards, >> Smita >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Monday, June 25, 2018 10:48 AM >> To: Kamath, Smita >> Cc: hotspot compiler ; >> core-libs-dev at openjdk.java.net; Paul Sandoz >> Subject: Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 >> Instructions >> >> I forgot to reply to your answers. >> >> On 6/22/18 2:49 PM, Kamath, Smita wrote: >>> Hi Vladimir, >>> >>> Please see my answers to your questions as below: >>> >>> 1) One question so: why you have own copy of base64 charsets and not >>> using one in library: >>> I am using vpgatherdd instruction to fetch multiple values from >>> base64 array in a single instruction with a vector index. Vpgatherdd >>> instruction works on 32 bit array and so I need to define base64 >>> charset in a 32 bit array. I have given reference to gather >>> instruction below. >> >> As was discussed in an other e-mail lets keep your copy. >> >>> >>> 2) Some indents in new and old Assembler::emit_operand() are off. In >>> new Assembler::emit_operand() is better use } else { instead of >>> 'return' in one branch. >>> I'll make the necessary changes and send an updated webrev. >>> >>> 3) This is first time I see that XMM register can be used for index >>> in address. Is it true? Can you point to Intel's document which >>> describes it. >>> I am using vpgatherdd instruction which requires index vector with >>> scale. It uses VSIB addressing where the index register is a zmm >>> register. >>> Please refer to reference manual, volume 2c, page 2211: >>> https://software.intel.com/sites/default/files/managed/39/c5/325462- >>> sd m-vol-1-2abcd-3abcd.pdf Also see, section 2.3.12, page 524 for >>> VSIB memory addressing information. >> >> Got it. Thanks for document reference. >> >>> >>> 4)? Please, add tests to >>> test/hotspot/jtreg/compiler/intrinsics/base64 (may be similar to sha >>> or AES in compiler/codegen/aes) to make sure that all flags, >>> intrinsic is used and it produces correct result. >>> I will add test cases as per your suggestion. >> >> Thanks, >> Vladimir >> >>> >>> Please let me know if you have additional questions. >>> >>> Thanks, >>> Smita >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Friday, June 22, 2018 12:29 PM >>> To: Kamath, Smita >>> Cc: hotspot compiler >>> Subject: Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using >>> AVX512 Instructions >>> >>> Hi Smita, >>> >>> I CCing to Libs to review code changes in Base64.java. >>> >>> Looks like you changed all need place to implement intrinsic. >>> One question so: why you have own copy of base64 charsets and not >>> using one in library: >>> >>> ??????????? private int encode0(byte[] src, int off, int end, byte[] >>> dst) { >>> ??????????????? char[] base64 = isURL ? toBase64URL : toBase64; >>> >>> Some indents in new and old Assembler::emit_operand() are off. >>> >>> In new Assembler::emit_operand() is better use } else { instead of >>> 'return' in one branch. >>> >>> This is first time I see that XMM register can be used for index in >>> address. Is it true? Can you point to Intel's document which >>> describes it. >>> >>> What testing you did? >>> >>> Please, add tests to test/hotspot/jtreg/compiler/intrinsics/base64 >>> (may be similar to sha or AES in compiler/codegen/aes) to make sure >>> that all flags, intrinsic is used and it produces correct result. >>> >>> I know there is test/jdk/java/util/Base64/ tests but they may not >>> trigger intrinsic usage. But you can use them as starting point for >>> new tests. >>> >>> Thanks, >>> Vladimir >>> >>> On 6/22/18 11:47 AM, Kamath, Smita wrote: >>>> Hi Vladimir, >>>> >>>> I'd like to contribute an optimization for Base64 Encoding >>>> Algorithm using AVX512 Instructions. This optimization shows 1.5x >>>> improvement on >>>> x86_64 platform(SKL). >>>> >>>> Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8205528 >>>> >>>> Link to webrev: >>>> http://cr.openjdk.java.net/~vdeshpande/Base64/webrev.00/ >>>> >>>> For testing the implementation, I have run tests under >>>> test/jdk/java/util/Base64/ and also ran >>>> test/jdk/com/sun/jndi/ldap/Base64Test.java >>>> >>>> I have also run jtreg. >>>> >>>> Please review and let me know if you have any comments. >>>> >>>> Thanks and Regards, >>>> >>>> Smita >>>> From vladimir.kozlov at oracle.com Wed Jun 27 20:21:33 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Jun 2018 13:21:33 -0700 Subject: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions In-Reply-To: <6563F381B547594081EF9DE181D0791277AB031E@FMSMSX119.amr.corp.intel.com> References: <6563F381B547594081EF9DE181D0791277AAD1EC@FMSMSX119.amr.corp.intel.com> <6563F381B547594081EF9DE181D0791277AAD2D4@FMSMSX119.amr.corp.intel.com> <980cfd3b-a6c1-eeda-3add-3165feea4fb9@oracle.com> <6563F381B547594081EF9DE181D0791277AAF5C2@FMSMSX119.amr.corp.intel.com> <45d26554-45e4-923f-cdfd-bbf9b289a80a@oracle.com> <6563F381B547594081EF9DE181D0791277AB031E@FMSMSX119.amr.corp.intel.com> Message-ID: Okay. I started new testing. Thanks, Vladimir On 6/27/18 12:58 PM, Kamath, Smita wrote: > Hi Vladimir, > > Please find the updated webrev. > > Bug link: https://bugs.openjdk.java.net/browse/JDK-8205528 > Webrev link : http://cr.openjdk.java.net/~srukmannagar/Base64/webrev.01/ > > Thanks, > Smita > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Tuesday, June 26, 2018 12:54 PM > To: Kamath, Smita > Cc: hotspot compiler > Subject: Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions > > Hit build failure on Windows: > > jib > > t:/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp(4556): > error C2024: 'alignas' attribute applies to variables, data members and tag types only jib > > t:/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp(4595): > error C2024: 'alignas' attribute applies to variables, data members and tag types only jib > > t:/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp(4634): > error C2024: 'alignas' attribute applies to variables, data members and tag types only jib > > t:/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp(4649): > error C2024: 'alignas' attribute applies to variables, data members and tag types only jib > > t:/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp(4664): > error C2024: 'alignas' attribute applies to variables, data members and tag types only jib > > t:/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp(4679): > error C2024: 'alignas' attribute applies to variables, data members and tag types only jib > > t:/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp(4693): > error C2024: 'alignas' attribute applies to variables, data members and tag types only jib > lib/CompileJvm.gmk:149: recipe for target '/cygdrive/t/workspace/build/windows-x64/hotspot/variant-server/libjvm/objs/stubGenerator_x86_64.obj' > failed > > Vladimir > > On 6/26/18 11:48 AM, Vladimir Kozlov wrote: >> Yes, this looks good to me. Let me test it. >> >> Thanks, >> Vladimir >> >> On 6/25/18 10:25 PM, Kamath, Smita wrote: >>> Hi Vladimir, >>> >>> Please find the updated webrev link. >>> >>> Webrev Link: >>> http://cr.openjdk.java.net/~srukmannagar/Base64/webrev.00/ >>> Bug link: https://bugs.openjdk.java.net/browse/JDK-8205528 >>> >>> Please let me know if you have additional questions. >>> >>> Thanks and Regards, >>> Smita >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Monday, June 25, 2018 10:48 AM >>> To: Kamath, Smita >>> Cc: hotspot compiler ; >>> core-libs-dev at openjdk.java.net; Paul Sandoz >>> Subject: Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 >>> Instructions >>> >>> I forgot to reply to your answers. >>> >>> On 6/22/18 2:49 PM, Kamath, Smita wrote: >>>> Hi Vladimir, >>>> >>>> Please see my answers to your questions as below: >>>> >>>> 1) One question so: why you have own copy of base64 charsets and not >>>> using one in library: >>>> I am using vpgatherdd instruction to fetch multiple values from >>>> base64 array in a single instruction with a vector index. Vpgatherdd >>>> instruction works on 32 bit array and so I need to define base64 >>>> charset in a 32 bit array. I have given reference to gather >>>> instruction below. >>> >>> As was discussed in an other e-mail lets keep your copy. >>> >>>> >>>> 2) Some indents in new and old Assembler::emit_operand() are off. In >>>> new Assembler::emit_operand() is better use } else { instead of >>>> 'return' in one branch. >>>> I'll make the necessary changes and send an updated webrev. >>>> >>>> 3) This is first time I see that XMM register can be used for index >>>> in address. Is it true? Can you point to Intel's document which >>>> describes it. >>>> I am using vpgatherdd instruction which requires index vector with >>>> scale. It uses VSIB addressing where the index register is a zmm >>>> register. >>>> Please refer to reference manual, volume 2c, page 2211: >>>> https://software.intel.com/sites/default/files/managed/39/c5/325462- >>>> sd m-vol-1-2abcd-3abcd.pdf Also see, section 2.3.12, page 524 for >>>> VSIB memory addressing information. >>> >>> Got it. Thanks for document reference. >>> >>>> >>>> 4)? Please, add tests to >>>> test/hotspot/jtreg/compiler/intrinsics/base64 (may be similar to sha >>>> or AES in compiler/codegen/aes) to make sure that all flags, >>>> intrinsic is used and it produces correct result. >>>> I will add test cases as per your suggestion. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Please let me know if you have additional questions. >>>> >>>> Thanks, >>>> Smita >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Friday, June 22, 2018 12:29 PM >>>> To: Kamath, Smita >>>> Cc: hotspot compiler >>>> Subject: Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using >>>> AVX512 Instructions >>>> >>>> Hi Smita, >>>> >>>> I CCing to Libs to review code changes in Base64.java. >>>> >>>> Looks like you changed all need place to implement intrinsic. >>>> One question so: why you have own copy of base64 charsets and not >>>> using one in library: >>>> >>>> ??????????? private int encode0(byte[] src, int off, int end, byte[] >>>> dst) { >>>> ??????????????? char[] base64 = isURL ? toBase64URL : toBase64; >>>> >>>> Some indents in new and old Assembler::emit_operand() are off. >>>> >>>> In new Assembler::emit_operand() is better use } else { instead of >>>> 'return' in one branch. >>>> >>>> This is first time I see that XMM register can be used for index in >>>> address. Is it true? Can you point to Intel's document which >>>> describes it. >>>> >>>> What testing you did? >>>> >>>> Please, add tests to test/hotspot/jtreg/compiler/intrinsics/base64 >>>> (may be similar to sha or AES in compiler/codegen/aes) to make sure >>>> that all flags, intrinsic is used and it produces correct result. >>>> >>>> I know there is test/jdk/java/util/Base64/ tests but they may not >>>> trigger intrinsic usage. But you can use them as starting point for >>>> new tests. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/22/18 11:47 AM, Kamath, Smita wrote: >>>>> Hi Vladimir, >>>>> >>>>> I'd like to contribute an optimization for Base64 Encoding >>>>> Algorithm using AVX512 Instructions. This optimization shows 1.5x >>>>> improvement on >>>>> x86_64 platform(SKL). >>>>> >>>>> Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8205528 >>>>> >>>>> Link to webrev: >>>>> http://cr.openjdk.java.net/~vdeshpande/Base64/webrev.00/ >>>>> >>>>> For testing the implementation, I have run tests under >>>>> test/jdk/java/util/Base64/ and also ran >>>>> test/jdk/com/sun/jndi/ldap/Base64Test.java >>>>> >>>>> I have also run jtreg. >>>>> >>>>> Please review and let me know if you have any comments. >>>>> >>>>> Thanks and Regards, >>>>> >>>>> Smita >>>>> From tom.rodriguez at oracle.com Wed Jun 27 20:45:49 2018 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 27 Jun 2018 13:45:49 -0700 Subject: RFR(L) 8205824: Update Graal Message-ID: <31a49fa3-0892-736c-1835-3870ad4bb7c8@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8205824 http://cr.openjdk.java.net/~never/8205824/webrev/index.html This combines a general Graal update with the fix for https://bugs.openjdk.java.net/browse/JDK-8204855. This general Graal update also fixes JDK-8204914 and includes a few other fixes from Graal. Unfortunately the webrev is fairly noisy because of blank lines inserted because of copyright adjustment and the addition of @Override annotations in JVMCI. 8204855 is a set of changes to the JVMCI API which are required to support the libgraal effort. Primarily this is about making a strong distinction between runtime and compiler objects and state and hiding anything which lets you bridge that boundary without be careful. Mostly it doesn't change the way JVMCI works apart from some changes to the HotSpotSpeculationLog implementation and the associated changes in Graal. These changes are binary incompatible with previous versions of JVMCI. Given the limitations of webrev I can't easily provide a webrev which shows just this change. The bits were tested with mach5 builds-tier1,jdk-tier1,hs-tier1,hs-tier2,hs-tier3,hs-tier4-graal,hs-tier5-graal and hs-tier6-graal. The details are in the bug report. I'm happy to explain anything about changes the JVMCI and why they were required. The JVMCI API updates have been tested with JDK8 Graal and will land in the next few days. tom From igor.veresov at oracle.com Wed Jun 27 21:02:08 2018 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 27 Jun 2018 14:02:08 -0700 Subject: RFR(L) 8205824: Update Graal In-Reply-To: <31a49fa3-0892-736c-1835-3870ad4bb7c8@oracle.com> References: <31a49fa3-0892-736c-1835-3870ad4bb7c8@oracle.com> Message-ID: <97895366-7894-4B32-8576-5EBBA30300C3@oracle.com> Looks good to me. igor > On Jun 27, 2018, at 1:45 PM, Tom Rodriguez wrote: > > https://bugs.openjdk.java.net/browse/JDK-8205824 > http://cr.openjdk.java.net/~never/8205824/webrev/index.html > > This combines a general Graal update with the fix for https://bugs.openjdk.java.net/browse/JDK-8204855. This general Graal update also fixes JDK-8204914 and includes a few other fixes from Graal. Unfortunately the webrev is fairly noisy because of blank lines inserted because of copyright adjustment and the addition of @Override annotations in JVMCI. > > 8204855 is a set of changes to the JVMCI API which are required to support the libgraal effort. Primarily this is about making a strong distinction between runtime and compiler objects and state and hiding anything which lets you bridge that boundary without be careful. Mostly it doesn't change the way JVMCI works apart from some changes to the HotSpotSpeculationLog implementation and the associated changes in Graal. These changes are binary incompatible with previous versions of JVMCI. Given the limitations of webrev I can't easily provide a webrev which shows just this change. > > The bits were tested with mach5 builds-tier1,jdk-tier1,hs-tier1,hs-tier2,hs-tier3,hs-tier4-graal,hs-tier5-graal and hs-tier6-graal. The details are in the bug report. > > I'm happy to explain anything about changes the JVMCI and why they were required. The JVMCI API updates have been tested with JDK8 Graal and will land in the next few days. > > tom From vladimir.kozlov at oracle.com Wed Jun 27 21:10:01 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Jun 2018 14:10:01 -0700 Subject: RFR(L) 8205824: Update Graal In-Reply-To: <31a49fa3-0892-736c-1835-3870ad4bb7c8@oracle.com> References: <31a49fa3-0892-736c-1835-3870ad4bb7c8@oracle.com> Message-ID: <46aef41b-6780-6bbf-fbb9-ff9db3fed1c5@oracle.com> Tom, can you tell about removal of 'trivial' code? Why it was removed? Thank you for fixing our jtreg jvmci tests. New file should have Copyright year updated: jdk.vm.ci.common/src/jdk/vm/ci/common/NativeImageReinitialize.java Otherwise looks good to me. Thanks, Vladimir On 6/27/18 1:45 PM, Tom Rodriguez wrote: > https://bugs.openjdk.java.net/browse/JDK-8205824 > http://cr.openjdk.java.net/~never/8205824/webrev/index.html > > This combines a general Graal update with the fix for > https://bugs.openjdk.java.net/browse/JDK-8204855.? This general Graal > update also fixes JDK-8204914 and includes a few other fixes from Graal. > ?Unfortunately the webrev is fairly noisy because of blank lines > inserted because of copyright adjustment and the addition of @Override > annotations in JVMCI. > > 8204855 is a set of changes to the JVMCI API which are required to > support the libgraal effort.? Primarily this is about making a strong > distinction between runtime and compiler objects and state and hiding > anything which lets you bridge that boundary without be careful.? Mostly > it doesn't change the way JVMCI works apart from some changes to the > HotSpotSpeculationLog implementation and the associated changes in > Graal.? These changes are binary incompatible with previous versions of > JVMCI.? Given the limitations of webrev I can't easily provide a webrev > which shows just this change. > > The bits were tested with mach5 > builds-tier1,jdk-tier1,hs-tier1,hs-tier2,hs-tier3,hs-tier4-graal,hs-tier5-graal > and hs-tier6-graal.? The details are in the bug report. > > I'm happy to explain anything about changes the JVMCI and why they were > required.? The JVMCI API updates have been tested with JDK8 Graal and > will land in the next few days. > > tom From igor.ignatyev at oracle.com Wed Jun 27 22:06:54 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 27 Jun 2018 15:06:54 -0700 Subject: RFR(S) : Remove hotspot tests for javafx.* modules Message-ID: <607F7E68-FE93-471A-A5C0-0921E5D63084@oracle.com> http://cr.openjdk.java.net/~iignatyev//8202554/webrev.00/index.html > 267 lines changed: 0 ins; 267 del; 0 mod; Hi all, could you please review this small fix which removes ctw tests for javafx modules? webrev: http://cr.openjdk.java.net/~iignatyev//8202554/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8202554 Thanks, -- Igor From vladimir.kozlov at oracle.com Wed Jun 27 22:10:27 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Jun 2018 15:10:27 -0700 Subject: RFR(S) : Remove hotspot tests for javafx.* modules In-Reply-To: <607F7E68-FE93-471A-A5C0-0921E5D63084@oracle.com> References: <607F7E68-FE93-471A-A5C0-0921E5D63084@oracle.com> Message-ID: <664522f8-8260-b748-b91f-423ffd80bd37@oracle.com> Good. Thanks, Vladimir On 6/27/18 3:06 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8202554/webrev.00/index.html >> 267 lines changed: 0 ins; 267 del; 0 mod; > > Hi all, > > could you please review this small fix which removes ctw tests for javafx modules? > > webrev: http://cr.openjdk.java.net/~iignatyev//8202554/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8202554 > > Thanks, > -- Igor > From igor.ignatyev at oracle.com Wed Jun 27 22:53:39 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 27 Jun 2018 15:53:39 -0700 Subject: RFR(XS) : 8205954 : clean up hotspot ProblemList Message-ID: <808B3811-1D61-44AA-9023-DD5406FD5192@oracle.com> http://cr.openjdk.java.net/~iignatyev//8205954/webrev.00/index.html > 1 line changed: 0 ins; 1 del; 0 mod; Hi all, could you please review this clean up for hotspot problem list? JDK-8199578 has been fixed but the problem list still contains "vmTestbase/vm/mlvm/indy/func/jdi/breakpoint". testing: vmTestbase/vm/mlvm/indy/func/jdi/breakpoint multiple times webrev: http://cr.openjdk.java.net/~iignatyev//8205954/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8205954 Thanks, -- Igor From vladimir.kozlov at oracle.com Wed Jun 27 22:59:34 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Jun 2018 15:59:34 -0700 Subject: RFR(XS) : 8205954 : clean up hotspot ProblemList In-Reply-To: <808B3811-1D61-44AA-9023-DD5406FD5192@oracle.com> References: <808B3811-1D61-44AA-9023-DD5406FD5192@oracle.com> Message-ID: Good. Thanks, Vladimir On 6/27/18 3:53 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8205954/webrev.00/index.html >> 1 line changed: 0 ins; 1 del; 0 mod; > > Hi all, > > could you please review this clean up for hotspot problem list? JDK-8199578 has been fixed but the problem list still contains "vmTestbase/vm/mlvm/indy/func/jdi/breakpoint". > > testing: vmTestbase/vm/mlvm/indy/func/jdi/breakpoint multiple times > webrev: http://cr.openjdk.java.net/~iignatyev//8205954/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8205954 > > Thanks, > -- Igor > From igor.veresov at oracle.com Wed Jun 27 23:39:46 2018 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 27 Jun 2018 16:39:46 -0700 Subject: RFR(S) : 8160673 : Jittester: investigate bytecode generation hangs during bytecode tests generation In-Reply-To: References: Message-ID: <585E51FF-0DC0-4A4D-B66D-C777DF339B5A@oracle.com> Looks fine. igor > On Jun 26, 2018, at 4:21 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8160673/webrev.00/index.html >> 32 lines changed: 6 ins; 12 del; 14 mod; > > Hi all, > > could you please review this small fix for jit-tester library? > > ByteCodeVisitor loaded generated classes, so ContextDependedClassWriter::getCommonSuperClass would be able to find common supper class using regular Class methods. in some cases, bytrecode for classes isn't yet generated (and hence not loaded) when getCommonSuperClass needs to get information about them (e.g. when generating bytecode for Class1 which is using instances of Class2 and a super class of Class2), which resulted in infinity loop inside asm library. > > the fix changes getCommonSuperClass method to use information about classes from jit-tester maintained list of all generated and used types. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8160673 > webrev: http://cr.openjdk.java.net/~iignatyev//8160673/webrev.00/index.html > testing: generated 1k tests w/ jit-tester > > Thanks, > -- Igor From tom.rodriguez at oracle.com Wed Jun 27 23:48:19 2018 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 27 Jun 2018 16:48:19 -0700 Subject: RFR(L) 8205824: Update Graal In-Reply-To: <46aef41b-6780-6bbf-fbb9-ff9db3fed1c5@oracle.com> References: <31a49fa3-0892-736c-1835-3870ad4bb7c8@oracle.com> <46aef41b-6780-6bbf-fbb9-ff9db3fed1c5@oracle.com> Message-ID: Vladimir Kozlov wrote on 6/27/18 2:10 PM: > Tom, can you tell about removal of 'trivial' code? Why it was removed? It was somewhat ugly hack when originally done and it was supplanted by the much nicer adjustCompilationLevel callback so it hasn't been in use by Graal for almost two years. Since we were breaking binary compatibility it seemed like a good time to remove it. > > Thank you for fixing our jtreg jvmci tests. > > New file should have Copyright year updated: > jdk.vm.ci.common/src/jdk/vm/ci/common/NativeImageReinitialize.java I'll update it. > > Otherwise looks good to me. Thanks! tom > > Thanks, > Vladimir > > On 6/27/18 1:45 PM, Tom Rodriguez wrote: >> https://bugs.openjdk.java.net/browse/JDK-8205824 >> http://cr.openjdk.java.net/~never/8205824/webrev/index.html >> >> This combines a general Graal update with the fix for >> https://bugs.openjdk.java.net/browse/JDK-8204855. This general Graal >> update also fixes JDK-8204914 and includes a few other fixes from >> Graal. Unfortunately the webrev is fairly noisy because of blank >> lines inserted because of copyright adjustment and the addition of >> @Override annotations in JVMCI. >> >> 8204855 is a set of changes to the JVMCI API which are required to >> support the libgraal effort. Primarily this is about making a strong >> distinction between runtime and compiler objects and state and hiding >> anything which lets you bridge that boundary without be careful. >> Mostly it doesn't change the way JVMCI works apart from some changes >> to the HotSpotSpeculationLog implementation and the associated changes >> in Graal. These changes are binary incompatible with previous >> versions of JVMCI. Given the limitations of webrev I can't easily >> provide a webrev which shows just this change. >> >> The bits were tested with mach5 >> builds-tier1,jdk-tier1,hs-tier1,hs-tier2,hs-tier3,hs-tier4-graal,hs-tier5-graal >> and hs-tier6-graal. The details are in the bug report. >> >> I'm happy to explain anything about changes the JVMCI and why they >> were required. The JVMCI API updates have been tested with JDK8 Graal >> and will land in the next few days. >> >> tom From tom.rodriguez at oracle.com Wed Jun 27 23:48:28 2018 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 27 Jun 2018 16:48:28 -0700 Subject: RFR(L) 8205824: Update Graal In-Reply-To: <97895366-7894-4B32-8576-5EBBA30300C3@oracle.com> References: <31a49fa3-0892-736c-1835-3870ad4bb7c8@oracle.com> <97895366-7894-4B32-8576-5EBBA30300C3@oracle.com> Message-ID: Thanks! tom Igor Veresov wrote on 6/27/18 2:02 PM: > Looks good to me. > > igor > >> On Jun 27, 2018, at 1:45 PM, Tom Rodriguez wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8205824 >> http://cr.openjdk.java.net/~never/8205824/webrev/index.html >> >> This combines a general Graal update with the fix for https://bugs.openjdk.java.net/browse/JDK-8204855. This general Graal update also fixes JDK-8204914 and includes a few other fixes from Graal. Unfortunately the webrev is fairly noisy because of blank lines inserted because of copyright adjustment and the addition of @Override annotations in JVMCI. >> >> 8204855 is a set of changes to the JVMCI API which are required to support the libgraal effort. Primarily this is about making a strong distinction between runtime and compiler objects and state and hiding anything which lets you bridge that boundary without be careful. Mostly it doesn't change the way JVMCI works apart from some changes to the HotSpotSpeculationLog implementation and the associated changes in Graal. These changes are binary incompatible with previous versions of JVMCI. Given the limitations of webrev I can't easily provide a webrev which shows just this change. >> >> The bits were tested with mach5 builds-tier1,jdk-tier1,hs-tier1,hs-tier2,hs-tier3,hs-tier4-graal,hs-tier5-graal and hs-tier6-graal. The details are in the bug report. >> >> I'm happy to explain anything about changes the JVMCI and why they were required. The JVMCI API updates have been tested with JDK8 Graal and will land in the next few days. >> >> tom > From vladimir.kozlov at oracle.com Wed Jun 27 23:50:50 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Jun 2018 16:50:50 -0700 Subject: RFR(L) 8205824: Update Graal In-Reply-To: References: <31a49fa3-0892-736c-1835-3870ad4bb7c8@oracle.com> <46aef41b-6780-6bbf-fbb9-ff9db3fed1c5@oracle.com> Message-ID: On 6/27/18 4:48 PM, Tom Rodriguez wrote: > > > Vladimir Kozlov wrote on 6/27/18 2:10 PM: >> Tom, can you tell about removal of 'trivial' code? Why it was removed? > > It was somewhat ugly hack when originally done and it was supplanted by > the much nicer adjustCompilationLevel callback so it hasn't been in use > by Graal for almost two years.? Since we were breaking binary > compatibility it seemed like a good time to remove it. Good. Thanks, Vladimir > >> >> Thank you for fixing our jtreg jvmci tests. >> >> New file should have Copyright year updated: >> jdk.vm.ci.common/src/jdk/vm/ci/common/NativeImageReinitialize.java > > I'll update it. > >> >> Otherwise looks good to me. > > Thanks! > > tom > >> >> Thanks, >> Vladimir >> >> On 6/27/18 1:45 PM, Tom Rodriguez wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8205824 >>> http://cr.openjdk.java.net/~never/8205824/webrev/index.html >>> >>> This combines a general Graal update with the fix for >>> https://bugs.openjdk.java.net/browse/JDK-8204855.? This general Graal >>> update also fixes JDK-8204914 and includes a few other fixes from >>> Graal.?? Unfortunately the webrev is fairly noisy because of blank >>> lines inserted because of copyright adjustment and the addition of >>> @Override annotations in JVMCI. >>> >>> 8204855 is a set of changes to the JVMCI API which are required to >>> support the libgraal effort.? Primarily this is about making a strong >>> distinction between runtime and compiler objects and state and hiding >>> anything which lets you bridge that boundary without be careful. >>> Mostly it doesn't change the way JVMCI works apart from some changes >>> to the HotSpotSpeculationLog implementation and the associated >>> changes in Graal.? These changes are binary incompatible with >>> previous versions of JVMCI.? Given the limitations of webrev I can't >>> easily provide a webrev which shows just this change. >>> >>> The bits were tested with mach5 >>> builds-tier1,jdk-tier1,hs-tier1,hs-tier2,hs-tier3,hs-tier4-graal,hs-tier5-graal >>> and hs-tier6-graal.? The details are in the bug report. >>> >>> I'm happy to explain anything about changes the JVMCI and why they >>> were required.? The JVMCI API updates have been tested with JDK8 >>> Graal and will land in the next few days. >>> >>> tom From igor.ignatyev at oracle.com Thu Jun 28 00:00:13 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 27 Jun 2018 17:00:13 -0700 Subject: RFR(S) : 8160673 : Jittester: investigate bytecode generation hangs during bytecode tests generation In-Reply-To: <585E51FF-0DC0-4A4D-B66D-C777DF339B5A@oracle.com> References: <585E51FF-0DC0-4A4D-B66D-C777DF339B5A@oracle.com> Message-ID: <2F64AA1C-A9A3-43F1-B0E4-FE645CFB7C73@oracle.com> Hi Igor, thanks for your review. -- Igor > On Jun 27, 2018, at 4:39 PM, Igor Veresov wrote: > > Looks fine. > > igor > >> On Jun 26, 2018, at 4:21 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev//8160673/webrev.00/index.html >>> 32 lines changed: 6 ins; 12 del; 14 mod; >> >> Hi all, >> >> could you please review this small fix for jit-tester library? >> >> ByteCodeVisitor loaded generated classes, so ContextDependedClassWriter::getCommonSuperClass would be able to find common supper class using regular Class methods. in some cases, bytrecode for classes isn't yet generated (and hence not loaded) when getCommonSuperClass needs to get information about them (e.g. when generating bytecode for Class1 which is using instances of Class2 and a super class of Class2), which resulted in infinity loop inside asm library. >> >> the fix changes getCommonSuperClass method to use information about classes from jit-tester maintained list of all generated and used types. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8160673 >> webrev: http://cr.openjdk.java.net/~iignatyev//8160673/webrev.00/index.html >> testing: generated 1k tests w/ jit-tester >> >> Thanks, >> -- Igor > From ekaterina.pavlova at oracle.com Thu Jun 28 00:16:50 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Wed, 27 Jun 2018 17:16:50 -0700 Subject: RFR(XS) : 8195630: vmTestbase/nsk/jvmti/AttachOnDemand/attach024/TestDescription.java fails with Graal Message-ID: Hi all, vmTestbase/nsk/jvmti/AttachOnDemand/attach024/TestDescription.java fails with Graal because java.util.ServiceConfigurationError used by the test has been already loaded by Graal. The fix removes java.util.ServiceConfigurationError and uses java.util.TooManyListenersException instead. Tested by checking that "java -Xcomp -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.Compiler=graal -verbose:class -version" doesn't load TooManyListenersException class and run vmTestbase/nsk/jvmti/AttachOnDemand/attach024/TestDescription.java with Graal flags. JBS: https://bugs.openjdk.java.net/browse/JDK-8195630 webrev: http://cr.openjdk.java.net/~epavlova//8195630/webrev.00/index.html thanks, -katya p.s. Igor Ignatyev volunteered to sponsor this change. From vladimir.kozlov at oracle.com Thu Jun 28 00:29:12 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Jun 2018 17:29:12 -0700 Subject: RFR(XS) : 8195630: vmTestbase/nsk/jvmti/AttachOnDemand/attach024/TestDescription.java fails with Graal In-Reply-To: References: Message-ID: Seems fine. Thanks, Vladimir On 6/27/18 5:16 PM, Ekaterina Pavlova wrote: > Hi all, > > vmTestbase/nsk/jvmti/AttachOnDemand/attach024/TestDescription.java fails > with Graal because > java.util.ServiceConfigurationError used by the test has been already > loaded by Graal. > The fix removes java.util.ServiceConfigurationError and uses > java.util.TooManyListenersException instead. > > Tested by checking that > "java -Xcomp -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI > -XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.Compiler=graal > -verbose:class -version" > doesn't load TooManyListenersException class and run > vmTestbase/nsk/jvmti/AttachOnDemand/attach024/TestDescription.java with > Graal flags. > > ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8195630 > webrev: http://cr.openjdk.java.net/~epavlova//8195630/webrev.00/index.html > > thanks, > -katya > > p.s. > ?Igor Ignatyev volunteered to sponsor this change. From igor.ignatyev at oracle.com Thu Jun 28 06:26:59 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 27 Jun 2018 23:26:59 -0700 Subject: RFR(xs): 8205578: jtreg: Fix failing TestRTMAbortRatio on PPC64 In-Reply-To: <37227b8b-7977-349a-249c-f7613d06d64f@linux.vnet.ibm.com> References: <37227b8b-7977-349a-249c-f7613d06d64f@linux.vnet.ibm.com> Message-ID: Hi Gustavo, looks fine to me. Thanks, -- Igor > On Jun 25, 2018, at 1:29 AM, Gustavo Romero wrote: > > Hi, > > Could the following simple change be reviewed please? > > bug : https://bugs.openjdk.java.net/browse/JDK-8205578 > webrev: http://cr.openjdk.java.net/~gromero/8205578/v1/ > > Currently native method pageSize() is used to cause deliberate transactional > aborts. However in test TestRTMAbortRatio pageSize() is not marked to be > compilable and as a consequence it's never called through the code path of > SharedRuntime::generate_native_wrapper(). As that code path is never exercised > no 'tabort' on JNI call is executed and the test fails on Power because of fewer > aborts than expected by the test. > > I can't say for sure why that test is getting the correct number of aborts on > x86. Nonetheless I can confirm that even on x86 the aborts do not come from the > native wrapper, i.e. from 'xabort' in SharedRuntime::generate_native_wrapper(). > I suspect the aborts on x86 are occurring a bit latter when the native function > is called and a "Far Call" is executed in the native method by chance and not in > a controlled way. As far as I know there is no way to inspect the exact address > when a transaction failed on Intel as it's possible on Power. > > Anyway, marking pageSize() as compilable does not cause any regression on Intel > (at the same time it starts to exercise the generate_native_wrapper code path) > and makes the test pass on Power as expected. > > So it fixes the following test on Power: > > +Passed: compiler/rtm/locking/TestRTMAbortRatio.java > > > Thank you and best regards, > Gustavo > From Zhongwei.Yao at arm.com Thu Jun 28 09:21:10 2018 From: Zhongwei.Yao at arm.com (Zhongwei Yao) Date: Thu, 28 Jun 2018 09:21:10 +0000 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <5B33BE12.805@bell-sw.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> <30a5c2f9-704d-8b9e-d947-16e6f5ec34cc@redhat.com>,<5B33BE12.805@bell-sw.com> Message-ID: Hi, Andrew, Sorry for my separate comment, but I have a question about "storestore" barrier eliding in StoreCM node. In http://cr.openjdk.java.net/~adinn/8205694/webrev.01/test/hotspot/jtreg/compiler/c2/aarch64/TestVolatiles.java.html line: 301, when "storestore" barrier is elided, is following sequence still ordered?: stlrw strb To my knowledge, strb could be reordered in above sequence. But "stlrw; stlrb" will be ordered as following said. And I see some discrepancy in the comment of aarch64.ad (without your patch applied, line: 1483 to 1484), storeCM is translated to: dmb ishst strlb But actually, it is translated to: dmb ishst strb So either the comment should be updated, or the code generated is not correct. -- Best regards, Zhongwei ________________________________________ From: aarch64-port-dev on behalf of Dmitrij Pochepko Sent: Thursday, June 28, 2018 12:40:50 AM To: Andrew Dinn Cc: hotspot compiler; aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation Hi, looks good to me(with @run main changed to @run driver) Thanks, Dmitrij 27.06.2018 20:28, Andrew Dinn wrote: > Here is an updated webrev which addresses all comments modulo Dmitrij's > recommendation about use of @run driver for which I am still awaiting > clarification. I hope the changes described below are satisfactory. > > webrev: http://cr.openjdk.java.net/~adinn/8205694/webrev.01 > JIRA: https://bugs.openjdk.java.net/browse/JDK-8205694 > > Dmitirj, if you can explain what else I need to tweak then I'll be happy > to update the webrev. If not please let me know if it is ok to push. > > Changes: > > Modified asserts in the aarch64.ad predicates to guarantees in all cases > where they relate to expectations about the graph structure. The ones > that are still left as asserts refer to expectations about what nodes > should be passed as predicate arguments i.e. the former are about > consistency external to the aarch64.ad file and the latter to internal > consistency (I don't believe the latter merit a check in product code). > > Added copyright headers to all test files > > Turned the original test class (TestVolatiles) into a test runner which > can be used to check a specific volatile op + GC config combination. > > Added 5 new test classes (TestVolatilesG1, TestVolatilesSerial, > TestVolatilesParallel, TestVolatilesCMS, and TestVolatilesCMSCardMark) > which indirect control to TestVolatiles to test each of the 5 different > volatile ops with one of the relevant GC configurations. > > Added @require conditions to each of the 5 new tests to ensure it is run > in a server GC and that the GC confguration under test is supported by > the JVM. > > Testing: > > All 5 tests passed on a debug, server VM. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From tobias.hartmann at oracle.com Thu Jun 28 10:39:19 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 28 Jun 2018 12:39:19 +0200 Subject: [11] RFR(S): 8205499: C1 temporary code buffers are not removed with -XX:+UseDynamicNumberOfCompilerThreads Message-ID: <2f5ee49c-93f3-8732-be04-3ee8ec592ea9@oracle.com> Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8205499 http://cr.openjdk.java.net/~thartmann/8205499/webrev.00/ The problem is that with -XX:+UseDynamicNumberOfCompilerThreads, compiler threads are dynamically created and removed but the C1 temporary code buffers are not deallocated. As a result, the code cache fills up with long running applications, disabling compilation. I was able to reproduce this by slightly modifying the code such that compiler threads are aggressively added and removed. The code cache quickly fills up and we get the expected warning [1]. I was not able to create a stable regression test because that would require to alternate between generating compilation tasks and waiting for compiler threads to become idle and get removed (i.e., the test would be long running). The fix is to deallocate the code buffers in the thread destructor. I've verified that this solves the issue. Thanks, Tobias [1] Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled. Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize= CodeCache: size=51200Kb used=50978Kb max_used=50990Kb free=221Kb bounds [0x00007fd068e00000, 0x00007fd06c000000, 0x00007fd06c000000] total_blobs=1284 nmethods=237 adapters=787 compilation: disabled (not enough contiguous free space left) stopped_count=1, restarted_count=0 full_count=0 Java HotSpot(TM) 64-Bit Server VM warning: Initialization of C1 CompilerThread3 thread failed (no space to run compilers) Java HotSpot(TM) 64-Bit Server VM warning: Initialization of C1 CompilerThread5 thread failed (no space to run compilers) Java HotSpot(TM) 64-Bit Server VM warning: Initialization of C1 CompilerThread4 thread failed (no space to run compilers) From adinn at redhat.com Thu Jun 28 10:54:26 2018 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 28 Jun 2018 11:54:26 +0100 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> <30a5c2f9-704d-8b9e-d947-16e6f5ec34cc@redhat.com> <5B33BE12.805@bell-sw.com> Message-ID: <2378c5e0-aac0-c2b0-ce2c-0da2788dd27d@redhat.com> Hi Zhongwei, Thanks very much for looking at this. On 28/06/18 10:21, Zhongwei Yao wrote: > Sorry for my separate comment, but I have a question about > "storestore" barrier eliding in StoreCM node. > > In http://cr.openjdk.java.net/~adinn/8205694/webrev.01/test/hotspot/jtreg/compiler/c2/aarch64/TestVolatiles.java.html > line: 301, when "storestore" barrier is elided, is following sequence > still ordered?: > stlrw > strb > > To my knowledge, strb could be reordered in above sequence. But "stlrw; > stlrb" will be ordered as following said. This was discussed some time ago when the original change was made and I believe it is correct. G1 and CMS both insert a StoreCM node into the node graph to model at an abstract level the card mark that should follow a StoreP/N (volatile or non-volatile). The other two standard GCs (Parallel, Serial) simply insert a StoreB. The purpose of the StoreCM is to allow non-TSO architectures to generate a StoreStore barrier between the str generated for the StoreP/N and the strb generated for the StoreCM i.e. ensure they are correctly ordered. For Aarch64, that would mean planting something like 1) normal 2) volatile 3) volatile via stlr via barriers dmb ish str stlr str . . . . . . . . . dmb ishst dmb ishst dmb ishst . . . . . . . . . strb strb strb dmb ish where the ... might be replaced with other instructions generated in accordance with the GC barrier. First, notice that in case 2 the StoreStore barrier is always redundant because the StoreP/N has been translated to stlr. This guarantees that the field write is visible before the card mark. So, we can always omit the dmb ishst if we know we are translating a volatile store. However, the predicate for unnecessary_storestore also optimizes two further cases. For G1, the GC barrier plants a card mark membar_volatile between the StoreP/N and the StoreCM. So, for this case if we generated a storestore barrier we would see this 1) normal 2) volatile 3) volatile via stlr via barriers dmb ish str stlr str . . . . . . . . . dmb ish dmb ish dmb ish . . . . . . . . . dmb ishst dmb ishst dmb ishst . . . . . . . . . strb strb strb dmb ish Clearly, the dmb ishst is not needed for G1. The same thing applies when using CMS with +UseCondCardMark. The GC barrier for this case introduces a card mark membar_volatile between the str/stlr and strb as with G1. So, this makes the dmb ishst redundant in all 3 cases. CMS with -UseCondCardMark does not introduce a card mark membar_volatile. So, in that case that we need to introduce the dmb ishst in cases 1 and 3. If we have case 2 i.e. we know we have a volatile store and are not relying on barriers it can be omitted. I believe the checks in the predicate test for precisely these conditions. > And I see some discrepancy in the comment of aarch64.ad (without > your patch applied, line: 1483 to 1484), storeCM is translated to: > dmb ishst > strlb > > But actually, it is translated to: > dmb ishst > strb Yes, that comment is wrong. It should say strb. I am afraid I have already pushed the fix. Perhaps we can sneak a patch to the comment into a later fix. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From gromero at linux.vnet.ibm.com Thu Jun 28 13:13:56 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 28 Jun 2018 10:13:56 -0300 Subject: RFR(xs): 8205578: jtreg: Fix failing TestRTMAbortRatio on PPC64 In-Reply-To: References: <37227b8b-7977-349a-249c-f7613d06d64f@linux.vnet.ibm.com> Message-ID: Hi Igor, On 06/28/2018 03:26 AM, Igor Ignatyev wrote: > Hi Gustavo, > > looks fine to me. Thanks! Could I get a second review please? Regards, Gustavo > Thanks, > -- Igor > >> On Jun 25, 2018, at 1:29 AM, Gustavo Romero wrote: >> >> Hi, >> >> Could the following simple change be reviewed please? >> >> bug : https://bugs.openjdk.java.net/browse/JDK-8205578 >> webrev: http://cr.openjdk.java.net/~gromero/8205578/v1/ >> >> Currently native method pageSize() is used to cause deliberate transactional >> aborts. However in test TestRTMAbortRatio pageSize() is not marked to be >> compilable and as a consequence it's never called through the code path of >> SharedRuntime::generate_native_wrapper(). As that code path is never exercised >> no 'tabort' on JNI call is executed and the test fails on Power because of fewer >> aborts than expected by the test. >> >> I can't say for sure why that test is getting the correct number of aborts on >> x86. Nonetheless I can confirm that even on x86 the aborts do not come from the >> native wrapper, i.e. from 'xabort' in SharedRuntime::generate_native_wrapper(). >> I suspect the aborts on x86 are occurring a bit latter when the native function >> is called and a "Far Call" is executed in the native method by chance and not in >> a controlled way. As far as I know there is no way to inspect the exact address >> when a transaction failed on Intel as it's possible on Power. >> >> Anyway, marking pageSize() as compilable does not cause any regression on Intel >> (at the same time it starts to exercise the generate_native_wrapper code path) >> and makes the test pass on Power as expected. >> >> So it fixes the following test on Power: >> >> +Passed: compiler/rtm/locking/TestRTMAbortRatio.java >> >> >> Thank you and best regards, >> Gustavo >> > From rwestrel at redhat.com Thu Jun 28 14:40:10 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 28 Jun 2018 16:40:10 +0200 Subject: RFR(S): 8205515: assert(opcode == Op_RangeCheck) failed: no other if variant here Message-ID: http://cr.openjdk.java.net/~roland/8205515/webrev.00/ Profile predicates try to apply predication to a CountedLoopNodeEnd that's produced as a result of peeling (so it's no longer a true end of loop node). I added the same check that regular predication performs. Also, I noticed I forgot to check for Reason_profile_predicate in dominated_by() methods. I couldn't get a test case that would fail because of that (I can get a load node that doesn't depend on the right predicate anymore but the load node is scheduled too late for the test to fail). I included the fix here. Or do I need another bug for this? Roland. From tobias.hartmann at oracle.com Thu Jun 28 14:53:25 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 28 Jun 2018 16:53:25 +0200 Subject: RFR(S): 8205515: assert(opcode == Op_RangeCheck) failed: no other if variant here In-Reply-To: References: Message-ID: <553c925f-7a4a-ed75-0cda-9c64a2b3e699@oracle.com> Hi Roland, this looks good to me. I don't think a separate bug is required. I'll run that through some extended testing. Thanks, Tobias On 28.06.2018 16:40, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8205515/webrev.00/ > > Profile predicates try to apply predication to a CountedLoopNodeEnd > that's produced as a result of peeling (so it's no longer a true end of > loop node). I added the same check that regular predication performs. > > Also, I noticed I forgot to check for Reason_profile_predicate in > dominated_by() methods. I couldn't get a test case that would fail > because of that (I can get a load node that doesn't depend on the right > predicate anymore but the load node is scheduled too late for the test > to fail). I included the fix here. Or do I need another bug for this? > > Roland. > From nils.eliasson at oracle.com Thu Jun 28 15:48:41 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 28 Jun 2018 17:48:41 +0200 Subject: [11] RFR(S): 8205499: C1 temporary code buffers are not removed with -XX:+UseDynamicNumberOfCompilerThreads In-Reply-To: <2f5ee49c-93f3-8732-be04-3ee8ec592ea9@oracle.com> References: <2f5ee49c-93f3-8732-be04-3ee8ec592ea9@oracle.com> Message-ID: <3b80ed53-7478-a5d1-272d-6d43f1740547@oracle.com> Nice catch! Looks good. // Nils On 2018-06-28 12:39, Tobias Hartmann wrote: > Hi, > > please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8205499 > http://cr.openjdk.java.net/~thartmann/8205499/webrev.00/ > > The problem is that with -XX:+UseDynamicNumberOfCompilerThreads, compiler threads are dynamically > created and removed but the C1 temporary code buffers are not deallocated. As a result, the code > cache fills up with long running applications, disabling compilation. > > I was able to reproduce this by slightly modifying the code such that compiler threads are > aggressively added and removed. The code cache quickly fills up and we get the expected warning [1]. > I was not able to create a stable regression test because that would require to alternate between > generating compilation tasks and waiting for compiler threads to become idle and get removed (i.e., > the test would be long running). > > The fix is to deallocate the code buffers in the thread destructor. I've verified that this solves > the issue. > > Thanks, > Tobias > > [1] Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled. > Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using > -XX:ReservedCodeCacheSize= > CodeCache: size=51200Kb used=50978Kb max_used=50990Kb free=221Kb > bounds [0x00007fd068e00000, 0x00007fd06c000000, 0x00007fd06c000000] > total_blobs=1284 nmethods=237 adapters=787 > compilation: disabled (not enough contiguous free space left) > stopped_count=1, restarted_count=0 > full_count=0 > Java HotSpot(TM) 64-Bit Server VM warning: Initialization of C1 CompilerThread3 thread failed (no > space to run compilers) > Java HotSpot(TM) 64-Bit Server VM warning: Initialization of C1 CompilerThread5 thread failed (no > space to run compilers) > Java HotSpot(TM) 64-Bit Server VM warning: Initialization of C1 CompilerThread4 thread failed (no > space to run compilers) From tobias.hartmann at oracle.com Thu Jun 28 15:50:46 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 28 Jun 2018 17:50:46 +0200 Subject: [11] RFR(S): 8205940: LoadNode::find_previous_arraycopy fails with "broken allocation" assert Message-ID: Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8205940 http://cr.openjdk.java.net/~thartmann/8205940/webrev.00/ We assert in LoadNode::find_previous_arraycopy(..) when trying to find an arraycopy that initializes the memory read by a LoadNode. The problem is that the arraycopy destination array allocation is hidden behind a PhiNode and therefore AllocateNode::Ideal_allocation(..) returns NULL. I think what happened is that there is an AllocateArray + ArrayCopy combination in a loop exit that was emitted for the clone intrinsic. Then the loop invariant ArrayCopy is moved out of the loop but the AllocateArray is not because it is loop dependent. During loop unswitching, we create a phi node to merge the AllocateArray results from the exits of two different loop versions. The assert is too strong and should be removed. Unfortunately, I was only able to reproduce this with replay compilation and the patch attached to the bug. Thanks, Tobias From tobias.hartmann at oracle.com Thu Jun 28 15:51:29 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 28 Jun 2018 17:51:29 +0200 Subject: [11] RFR(S): 8205499: C1 temporary code buffers are not removed with -XX:+UseDynamicNumberOfCompilerThreads In-Reply-To: <3b80ed53-7478-a5d1-272d-6d43f1740547@oracle.com> References: <2f5ee49c-93f3-8732-be04-3ee8ec592ea9@oracle.com> <3b80ed53-7478-a5d1-272d-6d43f1740547@oracle.com> Message-ID: <1eb45c90-c8df-b7e2-98a5-a0b1248d44f3@oracle.com> Thanks Nils! Best regards, Tobias On 28.06.2018 17:48, Nils Eliasson wrote: > Nice catch! > > Looks good. > > // Nils > > > On 2018-06-28 12:39, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> https://bugs.openjdk.java.net/browse/JDK-8205499 >> http://cr.openjdk.java.net/~thartmann/8205499/webrev.00/ >> >> The problem is that with -XX:+UseDynamicNumberOfCompilerThreads, compiler threads are dynamically >> created and removed but the C1 temporary code buffers are not deallocated. As a result, the code >> cache fills up with long running applications, disabling compilation. >> >> I was able to reproduce this by slightly modifying the code such that compiler threads are >> aggressively added and removed. The code cache quickly fills up and we get the expected warning [1]. >> I was not able to create a stable regression test because that would require to alternate between >> generating compilation tasks and waiting for compiler threads to become idle and get removed (i.e., >> the test would be long running). >> >> The fix is to deallocate the code buffers in the thread destructor. I've verified that this solves >> the issue. >> >> Thanks, >> Tobias >> >> [1] Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled. >> Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using >> -XX:ReservedCodeCacheSize= >> CodeCache: size=51200Kb used=50978Kb max_used=50990Kb free=221Kb >> ? bounds [0x00007fd068e00000, 0x00007fd06c000000, 0x00007fd06c000000] >> ? total_blobs=1284 nmethods=237 adapters=787 >> ? compilation: disabled (not enough contiguous free space left) >> ?????????????? stopped_count=1, restarted_count=0 >> ? full_count=0 >> Java HotSpot(TM) 64-Bit Server VM warning: Initialization of C1 CompilerThread3 thread failed (no >> space to run compilers) >> Java HotSpot(TM) 64-Bit Server VM warning: Initialization of C1 CompilerThread5 thread failed (no >> space to run compilers) >> Java HotSpot(TM) 64-Bit Server VM warning: Initialization of C1 CompilerThread4 thread failed (no >> space to run compilers) > From rwestrel at redhat.com Thu Jun 28 15:58:26 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 28 Jun 2018 17:58:26 +0200 Subject: [11] RFR(S): 8205940: LoadNode::find_previous_arraycopy fails with "broken allocation" assert In-Reply-To: References: Message-ID: > http://cr.openjdk.java.net/~thartmann/8205940/webrev.00/ That looks good to me. Roland. From vladimir.kozlov at oracle.com Thu Jun 28 17:22:53 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 28 Jun 2018 10:22:53 -0700 Subject: [11] RFR(S): 8205499: C1 temporary code buffers are not removed with -XX:+UseDynamicNumberOfCompilerThreads In-Reply-To: <2f5ee49c-93f3-8732-be04-3ee8ec592ea9@oracle.com> References: <2f5ee49c-93f3-8732-be04-3ee8ec592ea9@oracle.com> Message-ID: Looks good. Thanks, Vladimir On 6/28/18 3:39 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8205499 > http://cr.openjdk.java.net/~thartmann/8205499/webrev.00/ > > The problem is that with -XX:+UseDynamicNumberOfCompilerThreads, compiler threads are dynamically > created and removed but the C1 temporary code buffers are not deallocated. As a result, the code > cache fills up with long running applications, disabling compilation. > > I was able to reproduce this by slightly modifying the code such that compiler threads are > aggressively added and removed. The code cache quickly fills up and we get the expected warning [1]. > I was not able to create a stable regression test because that would require to alternate between > generating compilation tasks and waiting for compiler threads to become idle and get removed (i.e., > the test would be long running). > > The fix is to deallocate the code buffers in the thread destructor. I've verified that this solves > the issue. > > Thanks, > Tobias > > [1] Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled. > Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using > -XX:ReservedCodeCacheSize= > CodeCache: size=51200Kb used=50978Kb max_used=50990Kb free=221Kb > bounds [0x00007fd068e00000, 0x00007fd06c000000, 0x00007fd06c000000] > total_blobs=1284 nmethods=237 adapters=787 > compilation: disabled (not enough contiguous free space left) > stopped_count=1, restarted_count=0 > full_count=0 > Java HotSpot(TM) 64-Bit Server VM warning: Initialization of C1 CompilerThread3 thread failed (no > space to run compilers) > Java HotSpot(TM) 64-Bit Server VM warning: Initialization of C1 CompilerThread5 thread failed (no > space to run compilers) > Java HotSpot(TM) 64-Bit Server VM warning: Initialization of C1 CompilerThread4 thread failed (no > space to run compilers) > From igor.ignatyev at oracle.com Thu Jun 28 17:42:10 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 28 Jun 2018 10:42:10 -0700 Subject: RFR(S) : 8149729 : [jittester] Replace all 'path1 +"/" + path2' with Paths::get Message-ID: http://cr.openjdk.java.net/~iignatyev//8149729/webrev.00/index.html > 24 lines changed: 10 ins; 3 del; 11 mod; Hi all, could you please review this clean up patch for jit-tester library? webrev: http://cr.openjdk.java.net/~iignatyev//8149729/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8149729 Thanks, -- Igor From vladimir.kozlov at oracle.com Thu Jun 28 17:43:09 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 28 Jun 2018 10:43:09 -0700 Subject: RFR(xs): 8205578: jtreg: Fix failing TestRTMAbortRatio on PPC64 In-Reply-To: References: <37227b8b-7977-349a-249c-f7613d06d64f@linux.vnet.ibm.com> Message-ID: <25dba6c8-067d-3d3f-c4f3-dca19a34d70b@oracle.com> Looks good. Thanks, Vladimir On 6/28/18 6:13 AM, Gustavo Romero wrote: > Hi Igor, > > On 06/28/2018 03:26 AM, Igor Ignatyev wrote: >> Hi Gustavo, >> >> looks fine to me. > > Thanks! > > Could I get a second review please? > > > Regards, > Gustavo > >> Thanks, >> -- Igor >> >>> On Jun 25, 2018, at 1:29 AM, Gustavo Romero >>> wrote: >>> >>> Hi, >>> >>> Could the following simple change be reviewed please? >>> >>> bug?? : https://bugs.openjdk.java.net/browse/JDK-8205578 >>> webrev: http://cr.openjdk.java.net/~gromero/8205578/v1/ >>> >>> Currently native method pageSize() is used to cause deliberate >>> transactional >>> aborts. However in test TestRTMAbortRatio pageSize() is not marked to be >>> compilable and as a consequence it's never called through the code >>> path of >>> SharedRuntime::generate_native_wrapper(). As that code path is never >>> exercised >>> no 'tabort' on JNI call is executed and the test fails on Power >>> because of fewer >>> aborts than expected by the test. >>> >>> I can't say for sure why that test is getting the correct number of >>> aborts on >>> x86. Nonetheless I can confirm that even on x86 the aborts do not >>> come from the >>> native wrapper, i.e. from 'xabort' in >>> SharedRuntime::generate_native_wrapper(). >>> I suspect the aborts on x86 are occurring a bit latter when the >>> native function >>> is called and a "Far Call" is executed in the native method by chance >>> and not in >>> a controlled way. As far as I know there is no way to inspect the >>> exact address >>> when a transaction failed on Intel as it's possible on Power. >>> >>> Anyway, marking pageSize() as compilable does not cause any >>> regression on Intel >>> (at the same time it starts to exercise the generate_native_wrapper >>> code path) >>> and makes the test pass on Power as expected. >>> >>> So it fixes the following test on Power: >>> >>> +Passed: compiler/rtm/locking/TestRTMAbortRatio.java >>> >>> >>> Thank you and best regards, >>> Gustavo >>> >> > From vladimir.kozlov at oracle.com Thu Jun 28 17:56:39 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 28 Jun 2018 10:56:39 -0700 Subject: RFR(S): 8205515: assert(opcode == Op_RangeCheck) failed: no other if variant here In-Reply-To: References: Message-ID: <10e9f03b-5ee7-5e87-6892-dc2192ac2514@oracle.com> Looks like this change cause an other crash for example in gc/stress/gcbasher/TestGCBasherWithG1.java (no special flags are needed - only ones in the test) # Internal Error (t:/workspace/open/src/hotspot/share/opto/loopnode.cpp:4244), pid=7124, tid=10384 # assert(is_dominator(early, c)) failed: least != early so we can move up the dominator tree Current CompileTask: C2: 16468 914 4 Decompiler:: (169 bytes) Stack: [0x000000012b801000,0x000000012b901000], sp=0x000000012b8fc3a0, free space=1004k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.dylib+0xc39b71] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x609 V [libjvm.dylib+0xc3a229] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x47 V [libjvm.dylib+0x459d6b] report_vm_error(char const*, int, char const*, char const*, ...)+0xcc V [libjvm.dylib+0x8eb337] PhaseIdealLoop::build_loop_late_post(Node*)+0x6e5 V [libjvm.dylib+0x8e79f0] PhaseIdealLoop::build_loop_late(VectorSet&, Node_List&, Node_Stack&)+0x2a2 V [libjvm.dylib+0x8e6865] PhaseIdealLoop::build_and_optimize(bool, bool, bool)+0x5ef V [libjvm.dylib+0x3cb84e] Compile::Optimize()+0xb5c Vladimir On 6/28/18 7:40 AM, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8205515/webrev.00/ > > Profile predicates try to apply predication to a CountedLoopNodeEnd > that's produced as a result of peeling (so it's no longer a true end of > loop node). I added the same check that regular predication performs. > > Also, I noticed I forgot to check for Reason_profile_predicate in > dominated_by() methods. I couldn't get a test case that would fail > because of that (I can get a load node that doesn't depend on the right > predicate anymore but the load node is scheduled too late for the test > to fail). I included the fix here. Or do I need another bug for this? > > Roland. > From gromero at linux.vnet.ibm.com Thu Jun 28 18:00:10 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 28 Jun 2018 15:00:10 -0300 Subject: RFR(xs): 8205578: jtreg: Fix failing TestRTMAbortRatio on PPC64 In-Reply-To: <25dba6c8-067d-3d3f-c4f3-dca19a34d70b@oracle.com> References: <37227b8b-7977-349a-249c-f7613d06d64f@linux.vnet.ibm.com> <25dba6c8-067d-3d3f-c4f3-dca19a34d70b@oracle.com> Message-ID: <76020dfc-81b1-897e-f04e-5ac5cd021418@linux.vnet.ibm.com> Hi Vladimir, On 06/28/2018 02:43 PM, Vladimir Kozlov wrote: > Looks good. Thanks a lot for reviewing it. :) Regards, Gustavo > Thanks, > Vladimir > > On 6/28/18 6:13 AM, Gustavo Romero wrote: >> Hi Igor, >> >> On 06/28/2018 03:26 AM, Igor Ignatyev wrote: >>> Hi Gustavo, >>> >>> looks fine to me. >> >> Thanks! >> >> Could I get a second review please? >> >> >> Regards, >> Gustavo >> >>> Thanks, >>> -- Igor >>> >>>> On Jun 25, 2018, at 1:29 AM, Gustavo Romero wrote: >>>> >>>> Hi, >>>> >>>> Could the following simple change be reviewed please? >>>> >>>> bug?? : https://bugs.openjdk.java.net/browse/JDK-8205578 >>>> webrev: http://cr.openjdk.java.net/~gromero/8205578/v1/ >>>> >>>> Currently native method pageSize() is used to cause deliberate transactional >>>> aborts. However in test TestRTMAbortRatio pageSize() is not marked to be >>>> compilable and as a consequence it's never called through the code path of >>>> SharedRuntime::generate_native_wrapper(). As that code path is never exercised >>>> no 'tabort' on JNI call is executed and the test fails on Power because of fewer >>>> aborts than expected by the test. >>>> >>>> I can't say for sure why that test is getting the correct number of aborts on >>>> x86. Nonetheless I can confirm that even on x86 the aborts do not come from the >>>> native wrapper, i.e. from 'xabort' in SharedRuntime::generate_native_wrapper(). >>>> I suspect the aborts on x86 are occurring a bit latter when the native function >>>> is called and a "Far Call" is executed in the native method by chance and not in >>>> a controlled way. As far as I know there is no way to inspect the exact address >>>> when a transaction failed on Intel as it's possible on Power. >>>> >>>> Anyway, marking pageSize() as compilable does not cause any regression on Intel >>>> (at the same time it starts to exercise the generate_native_wrapper code path) >>>> and makes the test pass on Power as expected. >>>> >>>> So it fixes the following test on Power: >>>> >>>> +Passed: compiler/rtm/locking/TestRTMAbortRatio.java >>>> >>>> >>>> Thank you and best regards, >>>> Gustavo >>>> >>> >> > From vladimir.kozlov at oracle.com Thu Jun 28 18:02:22 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 28 Jun 2018 11:02:22 -0700 Subject: RFR(S) : 8149729 : [jittester] Replace all 'path1 +"/" + path2' with Paths::get In-Reply-To: References: Message-ID: Looks good Thanks, Vladimir On 6/28/18 10:42 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8149729/webrev.00/index.html >> 24 lines changed: 10 ins; 3 del; 11 mod; > > Hi all, > > could you please review this clean up patch for jit-tester library? > > webrev: http://cr.openjdk.java.net/~iignatyev//8149729/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8149729 > > Thanks, > -- Igor > From rahul.v.raghavan at oracle.com Fri Jun 29 07:15:12 2018 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Fri, 29 Jun 2018 12:45:12 +0530 Subject: RFR(XXXS): 8203504: [Graal] org.graalvm.compiler.debug.test.DebugContextTest fails with java.util.ServiceConfigurationError Message-ID: <36e025bf-4249-04e5-e691-e2b80e3305d8@oracle.com> Hi, JBS - https://bugs.openjdk.java.net/browse/JDK-8203504 webrev.00- http://cr.openjdk.java.net/~rraghavan/8203504/webrev.00/ Please review this patch to add missing 'uses' statement in module-info.java + uses org.graalvm.compiler.debug.DebugHandlersFactory; Thanks, Rahul From tobias.hartmann at oracle.com Fri Jun 29 07:46:14 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 29 Jun 2018 09:46:14 +0200 Subject: [11] RFR(S): 8205940: LoadNode::find_previous_arraycopy fails with "broken allocation" assert In-Reply-To: References: Message-ID: <29a67714-7b79-4f9f-efcd-b470ed92d32f@oracle.com> Thanks, Roland. Best regards, Tobias On 28.06.2018 17:58, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~thartmann/8205940/webrev.00/ > > That looks good to me. > > Roland. > From tobias.hartmann at oracle.com Fri Jun 29 07:46:28 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 29 Jun 2018 09:46:28 +0200 Subject: [11] RFR(S): 8205499: C1 temporary code buffers are not removed with -XX:+UseDynamicNumberOfCompilerThreads In-Reply-To: References: <2f5ee49c-93f3-8732-be04-3ee8ec592ea9@oracle.com> Message-ID: Thanks, Vladimir. Best regards, Tobias On 28.06.2018 19:22, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 6/28/18 3:39 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> https://bugs.openjdk.java.net/browse/JDK-8205499 >> http://cr.openjdk.java.net/~thartmann/8205499/webrev.00/ >> >> The problem is that with -XX:+UseDynamicNumberOfCompilerThreads, compiler threads are dynamically >> created and removed but the C1 temporary code buffers are not deallocated. As a result, the code >> cache fills up with long running applications, disabling compilation. >> >> I was able to reproduce this by slightly modifying the code such that compiler threads are >> aggressively added and removed. The code cache quickly fills up and we get the expected warning [1]. >> I was not able to create a stable regression test because that would require to alternate between >> generating compilation tasks and waiting for compiler threads to become idle and get removed (i.e., >> the test would be long running). >> >> The fix is to deallocate the code buffers in the thread destructor. I've verified that this solves >> the issue. >> >> Thanks, >> Tobias >> >> [1] Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled. >> Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using >> -XX:ReservedCodeCacheSize= >> CodeCache: size=51200Kb used=50978Kb max_used=50990Kb free=221Kb >> ? bounds [0x00007fd068e00000, 0x00007fd06c000000, 0x00007fd06c000000] >> ? total_blobs=1284 nmethods=237 adapters=787 >> ? compilation: disabled (not enough contiguous free space left) >> ?????????????? stopped_count=1, restarted_count=0 >> ? full_count=0 >> Java HotSpot(TM) 64-Bit Server VM warning: Initialization of C1 CompilerThread3 thread failed (no >> space to run compilers) >> Java HotSpot(TM) 64-Bit Server VM warning: Initialization of C1 CompilerThread5 thread failed (no >> space to run compilers) >> Java HotSpot(TM) 64-Bit Server VM warning: Initialization of C1 CompilerThread4 thread failed (no >> space to run compilers) >> From martin.doerr at sap.com Fri Jun 29 08:07:18 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 29 Jun 2018 08:07:18 +0000 Subject: [11] RFR(S): 8205499: C1 temporary code buffers are not removed with -XX:+UseDynamicNumberOfCompilerThreads In-Reply-To: References: <2f5ee49c-93f3-8732-be04-3ee8ec592ea9@oracle.com> Message-ID: <4734b304ef784e36a8c15932e6d40a89@sap.com> Hi Tobias, thank you for fixing this issue. Looks good. Best regards, Martin -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Tobias Hartmann Sent: Freitag, 29. Juni 2018 09:46 To: Vladimir Kozlov ; hotspot compiler Subject: Re: [11] RFR(S): 8205499: C1 temporary code buffers are not removed with -XX:+UseDynamicNumberOfCompilerThreads Thanks, Vladimir. Best regards, Tobias On 28.06.2018 19:22, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 6/28/18 3:39 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> https://bugs.openjdk.java.net/browse/JDK-8205499 >> http://cr.openjdk.java.net/~thartmann/8205499/webrev.00/ >> >> The problem is that with -XX:+UseDynamicNumberOfCompilerThreads, compiler threads are dynamically >> created and removed but the C1 temporary code buffers are not deallocated. As a result, the code >> cache fills up with long running applications, disabling compilation. >> >> I was able to reproduce this by slightly modifying the code such that compiler threads are >> aggressively added and removed. The code cache quickly fills up and we get the expected warning [1]. >> I was not able to create a stable regression test because that would require to alternate between >> generating compilation tasks and waiting for compiler threads to become idle and get removed (i.e., >> the test would be long running). >> >> The fix is to deallocate the code buffers in the thread destructor. I've verified that this solves >> the issue. >> >> Thanks, >> Tobias >> >> [1] Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled. >> Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using >> -XX:ReservedCodeCacheSize= >> CodeCache: size=51200Kb used=50978Kb max_used=50990Kb free=221Kb >> ? bounds [0x00007fd068e00000, 0x00007fd06c000000, 0x00007fd06c000000] >> ? total_blobs=1284 nmethods=237 adapters=787 >> ? compilation: disabled (not enough contiguous free space left) >> ?????????????? stopped_count=1, restarted_count=0 >> ? full_count=0 >> Java HotSpot(TM) 64-Bit Server VM warning: Initialization of C1 CompilerThread3 thread failed (no >> space to run compilers) >> Java HotSpot(TM) 64-Bit Server VM warning: Initialization of C1 CompilerThread5 thread failed (no >> space to run compilers) >> Java HotSpot(TM) 64-Bit Server VM warning: Initialization of C1 CompilerThread4 thread failed (no >> space to run compilers) >> From tobias.hartmann at oracle.com Fri Jun 29 08:09:08 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 29 Jun 2018 10:09:08 +0200 Subject: [11] RFR(S): 8205499: C1 temporary code buffers are not removed with -XX:+UseDynamicNumberOfCompilerThreads In-Reply-To: <4734b304ef784e36a8c15932e6d40a89@sap.com> References: <2f5ee49c-93f3-8732-be04-3ee8ec592ea9@oracle.com> <4734b304ef784e36a8c15932e6d40a89@sap.com> Message-ID: <5efbfdaa-62a4-7acd-013e-247b568fa9d8@oracle.com> Thanks, Martin. Best regards, Tobias On 29.06.2018 10:07, Doerr, Martin wrote: > Hi Tobias, > > thank you for fixing this issue. Looks good. > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Tobias Hartmann > Sent: Freitag, 29. Juni 2018 09:46 > To: Vladimir Kozlov ; hotspot compiler > Subject: Re: [11] RFR(S): 8205499: C1 temporary code buffers are not removed with -XX:+UseDynamicNumberOfCompilerThreads > > Thanks, Vladimir. > > Best regards, > Tobias > > On 28.06.2018 19:22, Vladimir Kozlov wrote: >> Looks good. >> >> Thanks, >> Vladimir >> >> On 6/28/18 3:39 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch: >>> https://bugs.openjdk.java.net/browse/JDK-8205499 >>> http://cr.openjdk.java.net/~thartmann/8205499/webrev.00/ >>> >>> The problem is that with -XX:+UseDynamicNumberOfCompilerThreads, compiler threads are dynamically >>> created and removed but the C1 temporary code buffers are not deallocated. As a result, the code >>> cache fills up with long running applications, disabling compilation. >>> >>> I was able to reproduce this by slightly modifying the code such that compiler threads are >>> aggressively added and removed. The code cache quickly fills up and we get the expected warning [1]. >>> I was not able to create a stable regression test because that would require to alternate between >>> generating compilation tasks and waiting for compiler threads to become idle and get removed (i.e., >>> the test would be long running). >>> >>> The fix is to deallocate the code buffers in the thread destructor. I've verified that this solves >>> the issue. >>> >>> Thanks, >>> Tobias >>> >>> [1] Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled. >>> Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using >>> -XX:ReservedCodeCacheSize= >>> CodeCache: size=51200Kb used=50978Kb max_used=50990Kb free=221Kb >>> ? bounds [0x00007fd068e00000, 0x00007fd06c000000, 0x00007fd06c000000] >>> ? total_blobs=1284 nmethods=237 adapters=787 >>> ? compilation: disabled (not enough contiguous free space left) >>> ?????????????? stopped_count=1, restarted_count=0 >>> ? full_count=0 >>> Java HotSpot(TM) 64-Bit Server VM warning: Initialization of C1 CompilerThread3 thread failed (no >>> space to run compilers) >>> Java HotSpot(TM) 64-Bit Server VM warning: Initialization of C1 CompilerThread5 thread failed (no >>> space to run compilers) >>> Java HotSpot(TM) 64-Bit Server VM warning: Initialization of C1 CompilerThread4 thread failed (no >>> space to run compilers) >>> From rwestrel at redhat.com Fri Jun 29 08:14:50 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 29 Jun 2018 10:14:50 +0200 Subject: RFR(S): 8205515: assert(opcode == Op_RangeCheck) failed: no other if variant here In-Reply-To: <10e9f03b-5ee7-5e87-6892-dc2192ac2514@oracle.com> References: <10e9f03b-5ee7-5e87-6892-dc2192ac2514@oracle.com> Message-ID: Hi Vladimir, > Looks like this change cause an other crash for example in > gc/stress/gcbasher/TestGCBasherWithG1.java (no special flags are needed > - only ones in the test) Thanks for testing. Here is an updated webrev: http://cr.openjdk.java.net/~roland/8205515/webrev.01/ We have a block of regular predicates, followed by a block of profile predicates. For a data node that's above a loop, the logic tries to set its control as high as possible above the predicates. The current logic looks for the profile predicate added at parse time then possibly for the predicate added at parse time and set the control of the data node above. So with: predicate added at parse time (with Opaque1 node) profile predicate added at parse time (with Opaque1 node) the data node would have control set above both predicates. With: some predicate hoisted by loop predication some predicate hoisted by loop predication predicate added at parse time (with Opaque1 node) profile predicate added at parse time (with Opaque1 node) the data node would have control set right above the predicate added at parse time. And with: some predicate hoisted by loop predication some predicate hoisted by loop predication predicate added at parse time (with Opaque1 node) some profile predicate hoisted by loop predication some profile predicate hoisted by loop predication profile predicate added at parse time (with Opaque1 node) the data node have control set right above the profile predicate added at parse time. The problem is that sometimes, we have something like: predicate added at parse time (with Opaque1 node) if (a == null) { unc; } //some predicate hoisted by loop predication a = cast_not_null(a); //data node control dependent on hoisted predicate profile predicate added at parse time (with Opaque1 node) then the compiler finds a dominating if (a == null) checks so the predicate can be removed but dominated_by() prevents the cast from moving up: predicate added at parse time (with Opaque1 node) a = cast_not_null(a); profile predicate added at parse time (with Opaque1 node) The current logic tries to set control of the cast above the first predicate which is incorrect. Roland. From tobias.hartmann at oracle.com Fri Jun 29 09:01:27 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 29 Jun 2018 11:01:27 +0200 Subject: [11] RFR(XS): 8206100: Problem list org.graalvm.compiler.hotspot.test.CheckGraalIntrinsics Message-ID: <7b5cfde3-72d4-5448-7abb-c0ea18e4e8fc@oracle.com> Hi, please review the following patch that problem lists CheckGraalIntrinsics until 8206093 is fixed: https://bugs.openjdk.java.net/browse/JDK-8206100 http://cr.openjdk.java.net/~thartmann/8206100/webrev.00/ Thanks, Tobias From doug.simon at oracle.com Fri Jun 29 10:15:39 2018 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 29 Jun 2018 12:15:39 +0200 Subject: [11] RFR(XS): 8206100: Problem list org.graalvm.compiler.hotspot.test.CheckGraalIntrinsics In-Reply-To: <7b5cfde3-72d4-5448-7abb-c0ea18e4e8fc@oracle.com> References: <7b5cfde3-72d4-5448-7abb-c0ea18e4e8fc@oracle.com> Message-ID: <46795B4C-91D6-4065-AB5E-0FF2B898598E@oracle.com> I would recommend just spot fixing CheckGraalIntrinsics instead: @@ -371,6 +371,7 @@ public class CheckGraalIntrinsics extends GraalTest { if (isJDK11OrHigher()) { // Relevant for Java flight recorder add(toBeInvestigated, + "java/util/Base64$Encoder.encodeBlock([BII[BIZ)V", "jdk/jfr/internal/JVM.getEventWriter()Ljava/lang/Object;"); } -Doug > On 29 Jun 2018, at 11:01, Tobias Hartmann wrote: > > Hi, > > please review the following patch that problem lists CheckGraalIntrinsics until 8206093 is fixed: > https://bugs.openjdk.java.net/browse/JDK-8206100 > http://cr.openjdk.java.net/~thartmann/8206100/webrev.00/ > > Thanks, > Tobias From tobias.hartmann at oracle.com Fri Jun 29 10:17:44 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 29 Jun 2018 12:17:44 +0200 Subject: [11] RFR(XS): 8206100: Problem list org.graalvm.compiler.hotspot.test.CheckGraalIntrinsics In-Reply-To: <46795B4C-91D6-4065-AB5E-0FF2B898598E@oracle.com> References: <7b5cfde3-72d4-5448-7abb-c0ea18e4e8fc@oracle.com> <46795B4C-91D6-4065-AB5E-0FF2B898598E@oracle.com> Message-ID: <029387d9-bfc2-234c-4d4e-37fb2e9b5234@oracle.com> Hi Doug, okay, I'll do that. Will send a new review for 8206093. Thanks, Tobias On 29.06.2018 12:15, Doug Simon wrote: > I would recommend just spot fixing CheckGraalIntrinsics instead: > > @@ -371,6 +371,7 @@ public class CheckGraalIntrinsics extends GraalTest { > if (isJDK11OrHigher()) { > // Relevant for Java flight recorder > add(toBeInvestigated, > + "java/util/Base64$Encoder.encodeBlock([BII[BIZ)V", > "jdk/jfr/internal/JVM.getEventWriter()Ljava/lang/Object;"); > } > > > -Doug > >> On 29 Jun 2018, at 11:01, Tobias Hartmann wrote: >> >> Hi, >> >> please review the following patch that problem lists CheckGraalIntrinsics until 8206093 is fixed: >> https://bugs.openjdk.java.net/browse/JDK-8206100 >> http://cr.openjdk.java.net/~thartmann/8206100/webrev.00/ >> >> Thanks, >> Tobias > From doug.simon at oracle.com Fri Jun 29 10:18:42 2018 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 29 Jun 2018 12:18:42 +0200 Subject: RFR(XXXS): 8203504: [Graal] org.graalvm.compiler.debug.test.DebugContextTest fails with java.util.ServiceConfigurationError In-Reply-To: <36e025bf-4249-04e5-e691-e2b80e3305d8@oracle.com> References: <36e025bf-4249-04e5-e691-e2b80e3305d8@oracle.com> Message-ID: <1EB692E5-C45E-464A-A794-23AACF7C9196@oracle.com> Looks good to me. > On 29 Jun 2018, at 09:15, Rahul Raghavan wrote: > > Hi, > > JBS - https://bugs.openjdk.java.net/browse/JDK-8203504 > webrev.00- http://cr.openjdk.java.net/~rraghavan/8203504/webrev.00/ > > > Please review this patch to add missing 'uses' statement in module-info.java > > + uses org.graalvm.compiler.debug.DebugHandlersFactory; > > > Thanks, > Rahul From tobias.hartmann at oracle.com Fri Jun 29 10:24:08 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 29 Jun 2018 12:24:08 +0200 Subject: [11] RFR(XS): 8206093: compiler/graalunit/HotspotTest.java fails in CheckGraalIntrinsics Message-ID: <4dc3c1a7-42c4-0e00-e763-b569af663177@oracle.com> Hi, please review the following patch that ignores the java/util/Base64$Encoder.encodeBlock intrinsic which is not (yet) implemented in Graal: https://bugs.openjdk.java.net/browse/JDK-8206093 http://cr.openjdk.java.net/~thartmann/8206093/webrev.00/ Thanks, Tobias From nils.eliasson at oracle.com Fri Jun 29 13:40:00 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 29 Jun 2018 15:40:00 +0200 Subject: RFR(L) 8205824: Update Graal In-Reply-To: <31a49fa3-0892-736c-1835-3870ad4bb7c8@oracle.com> References: <31a49fa3-0892-736c-1835-3870ad4bb7c8@oracle.com> Message-ID: On 2018-06-27 22:45, Tom Rodriguez wrote: > https://bugs.openjdk.java.net/browse/JDK-8205824 > http://cr.openjdk.java.net/~never/8205824/webrev/index.html > > This combines a general Graal update with the fix for > https://bugs.openjdk.java.net/browse/JDK-8204855.? This general Graal > update also fixes JDK-8204914 and includes a few other fixes from > Graal. ?Unfortunately the webrev is fairly noisy because of blank > lines inserted because of copyright adjustment and the addition of > @Override annotations in JVMCI. > > 8204855 is a set of changes to the JVMCI API which are required to > support the libgraal effort.? Primarily this is about making a strong > distinction between runtime and compiler objects and state and hiding > anything which lets you bridge that boundary without be careful.? > Mostly it doesn't change the way JVMCI works apart from some changes > to the HotSpotSpeculationLog implementation and the associated changes > in Graal.? These changes are binary incompatible with previous > versions of JVMCI.? Given the limitations of webrev I can't easily > provide a webrev which shows just this change. There have been several examples of incremental webrevs for large changes recently. It's impossible to have an opinion on the jvmci changes given this webrev. // Nils > > The bits were tested with mach5 > builds-tier1,jdk-tier1,hs-tier1,hs-tier2,hs-tier3,hs-tier4-graal,hs-tier5-graal > and hs-tier6-graal.? The details are in the bug report. > > I'm happy to explain anything about changes the JVMCI and why they > were required.? The JVMCI API updates have been tested with JDK8 Graal > and will land in the next few days. > > tom From cthalinger at twitter.com Fri Jun 29 15:16:18 2018 From: cthalinger at twitter.com (Christian Thalinger) Date: Fri, 29 Jun 2018 11:16:18 -0400 Subject: [11] RTM tests fail In-Reply-To: <70dca568-53b3-695d-f135-ac6e1f152529@linux.vnet.ibm.com> References: <515395B7-31C9-4502-A9A1-323DB768280C@twitter.com> <25bbc06005eb4e929f2bcd697618e3f8@sap.com> <8f31a45d24f84732ae7915f22aae61a5@sap.com> <26e36040-4b08-8293-21d8-ca770b945f57@linux.vnet.ibm.com> <70dca568-53b3-695d-f135-ac6e1f152529@linux.vnet.ibm.com> Message-ID: > On Jun 25, 2018, at 5:32 PM, Gustavo Romero wrote: > > Hi Christian, > > On 06/25/2018 09:54 AM, Christian Thalinger wrote: >>> On Jun 25, 2018, at 8:49 AM, Gustavo Romero wrote: >>> >>> On 06/25/2018 09:46 AM, Lindenmaier, Goetz wrote: >>>>>> Did you check with or without these fixes? >>>>> >>>>> Without, unfortunately. Are all of the failures fixed now (in jdk-11+19)? >>>> I don't know, our machines do not have RTM, only our Power ones do. >>>> But I think Gustavo Romero from IBM claimed so. >>> >>> Yup, after the three fixes Goetz mentioned all RTM tests must pass on Intel. >> Ok, I?ll get back to you? > > Yes, please let me know if all went fine :) I did not forget but we can?t merge in jdk-11+19 because of https://bugs.openjdk.java.net/browse/JDK-8205616 We have to wait until jdk-11+20 is tagged. > > I checked again the current state on Intel (jdk/jdk tip) and all tests passed. > After applying the fixes it's good to verify if there isn't a stale ./JTwork by > deleting it. If that helps, find below some information about the system: > > gromero at moog:~/hg/jdk/jdk$ uname -a > Linux moog 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux > gromero at moog:~/hg/jdk/jdk$ lscpu | egrep "rtm|Model" > Model: 94 > Model name: Intel(R) Xeon(R) CPU E3-1280 v5 @ 3.70GHz > Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb invpcid_single intel_pt retpoline kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp > > gromero at moog:~/hg/jdk/jdk$ JT_JAVA=/usr/lib/jvm/java-8-openjdk-amd64 /home/gromero/jtreg/bin/jtreg -v1 -conc:20 -jdk:./build/linux-x86_64-normal-server-release/jdk/ ./test/hotspot/jtreg/compiler/rtm > Passed: compiler/rtm/cli/TestRTMLockingThresholdOption.java > Passed: compiler/rtm/cli/TestRTMLockingCalculationDelayOption.java > Passed: compiler/rtm/cli/TestUseRTMXendForLockBusyOption.java > Passed: compiler/rtm/cli/TestRTMRetryCountOption.java > Passed: compiler/rtm/cli/TestRTMAbortThresholdOption.java > Passed: compiler/rtm/cli/TestRTMSpinLoopCountOption.java > Passed: compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java > Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java > Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java > Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java > Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java > Passed: compiler/rtm/locking/TestUseRTMAfterLockInflation.java > Passed: compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java > Passed: compiler/rtm/locking/TestUseRTMForInflatedLocks.java > Passed: compiler/rtm/locking/TestUseRTMForStackLocks.java > Passed: compiler/rtm/locking/TestRTMLockingCalculationDelay.java > Passed: compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java > Passed: compiler/rtm/locking/TestUseRTMDeopt.java > Passed: compiler/rtm/method_options/TestUseRTMLockElidingOption.java > Passed: compiler/rtm/method_options/TestNoRTMLockElidingOption.java > Passed: compiler/rtm/locking/TestRTMAbortThreshold.java > Passed: compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java > Passed: compiler/rtm/locking/TestRTMTotalCountIncrRate.java > Passed: compiler/rtm/locking/TestRTMAbortRatio.java > Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java > Passed: compiler/rtm/locking/TestRTMRetryCount.java > Passed: compiler/rtm/locking/TestRTMLockingThreshold.java > Passed: compiler/rtm/locking/TestRTMSpinLoopCount.java > Passed: compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java > Passed: compiler/rtm/locking/TestUseRTMXendForLockBusy.java > Test results: passed: 30 > > > I also ran it with -conc:1: > > gromero at moog:~/hg/jdk/jdk$ JT_JAVA=/usr/lib/jvm/java-8-openjdk-amd64 /home/gromero/jtreg/bin/jtreg -v1 -conc:1 -jdk:./build/linux-x86_64-normal-server-release/jdk/ ./test/hotspot/jtreg/compiler/rtm > Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java > Passed: compiler/rtm/cli/TestRTMAbortThresholdOption.java > Passed: compiler/rtm/cli/TestRTMLockingCalculationDelayOption.java > Passed: compiler/rtm/cli/TestRTMLockingThresholdOption.java > Passed: compiler/rtm/cli/TestRTMRetryCountOption.java > Passed: compiler/rtm/cli/TestRTMSpinLoopCountOption.java > Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java > Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java > Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java > Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java > Passed: compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java > Passed: compiler/rtm/cli/TestUseRTMXendForLockBusyOption.java > Passed: compiler/rtm/locking/TestRTMAbortRatio.java > Passed: compiler/rtm/locking/TestRTMAbortThreshold.java > Passed: compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java > Passed: compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java > Passed: compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java > Passed: compiler/rtm/locking/TestRTMLockingCalculationDelay.java > Passed: compiler/rtm/locking/TestRTMLockingThreshold.java > Passed: compiler/rtm/locking/TestRTMRetryCount.java > Passed: compiler/rtm/locking/TestRTMSpinLoopCount.java > Passed: compiler/rtm/locking/TestRTMTotalCountIncrRate.java > Passed: compiler/rtm/locking/TestUseRTMAfterLockInflation.java > Passed: compiler/rtm/locking/TestUseRTMDeopt.java > Passed: compiler/rtm/locking/TestUseRTMForInflatedLocks.java > Passed: compiler/rtm/locking/TestUseRTMForStackLocks.java > Passed: compiler/rtm/locking/TestUseRTMXendForLockBusy.java > Passed: compiler/rtm/method_options/TestNoRTMLockElidingOption.java > Passed: compiler/rtm/method_options/TestUseRTMLockElidingOption.java > Passed: compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java > Test results: passed: 30 > > > Regards, > Gustavo > >>> >>> >>> Regards, >>> Gustavo >>> >>>> Best regards, >>>> Goetz. >>>>> >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- >>>>>>> bounces at openjdk.java.net] On Behalf Of Christian Thalinger >>>>>>> Sent: Montag, 25. Juni 2018 14:17 >>>>>>> To: hotspot compiler >>>>>>> Subject: [11] RTM tests fail >>>>>>> >>>>>>> Hi! Is anyone running the compiler/rtm/ tests on a machine that actually >>>>>>> supports RTM? >>>>>>> >>>>>>> Every time one of our nightly jobs ends up on a machine that supports >>>>> RTM a >>>>>>> bunch of locking tests and the print test fail: >>>>>>> >>>>>>> ? compiler/rtm/locking/TestRTMAbortRatio.java.TestRTMAbortRatio >>>>>>> ? >>>>>>> >>>>> compiler/rtm/locking/TestRTMAbortThreshold.java.TestRTMAbortThreshold >>>>>>> ? >>>>>>> >>>>> compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java.TestRTMAfterNonR >>>>>>> TMDeopt >>>>>>> ? >>>>>>> >>>>> compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java.TestRTMDeopt >>>>>>> OnHighAbortRatio >>>>>>> ? >>>>>>> >>>>> compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java.TestRTMDeopt >>>>>>> OnLowAbortRatio >>>>>>> ? >>>>>>> >>>>> compiler/rtm/locking/TestRTMLockingThreshold.java.TestRTMLockingThresh >>>>>>> old >>>>>>> ? >>>>>>> >>>>> compiler/rtm/locking/TestUseRTMXendForLockBusy.java.TestUseRTMXend >>>>>>> ForLockBusy >>>>>>> ? >>>>>>> >>>>> compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java.TestPrintPreci >>>>>>> seRTMLockingStatistics >>>>>>> >>>>>>> Exceptions look like this (for all the failures above in order): >>>>>>> >>>>>>> java.lang.RuntimeException: Actual abort ratio (10000) should lower or >>>>> equal >>>>>>> to specified (100).: expected that 10000 <= 100 >>>>>>> >>>>>>> java.lang.RuntimeException: Expected that method with rtm lock elision >>>>> was >>>>>>> deoptimized after 1 lock attempts: expected 3320 to equal 1 >>>>>>> >>>>>>> java.lang.RuntimeException: Two uncommon traps with reason >>>>>>> rtm_state_change should be fired.: expected 0 to equal 2 >>>>>>> >>>>>>> java.lang.RuntimeException: Expected to get only one deoptimization due >>>>> to >>>>>>> rtm state change: expected 0 to equal 1 >>>>>>> >>>>>>> java.lang.RuntimeException: Expected to get only one deoptimization due >>>>> to >>>>>>> rtm state change: expected 0 to equal 1 >>>>>>> >>>>>>> java.lang.RuntimeException: There should be exactly one statistics entry >>>>>>> corresponding to ProfileRTM state.: expected null to not equal null >>>>>>> >>>>>>> java.lang.RuntimeException: VM output should contain exactly one rtm >>>>>>> locking statistics entry for method compiler.testlibrary.rtm.BusyLock::test: >>>>>>> expected 0 to equal 1 >>>>>>> >>>>>>> java.lang.RuntimeException: RTM locking statistics should contain non >>>>> zero >>>>>>> aborts count for abort reason 0: expected 0 > 0 >>>>>>> >>>>>>> Since these tests are not excluded I have to assume that either (a) they >>>>> work >>>>>>> for you (really?) or (b) that Oracle (or someone else) doesn?t have >>>>> machines >>>>>>> that support RTM. >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gromero at linux.vnet.ibm.com Fri Jun 29 15:23:43 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 29 Jun 2018 12:23:43 -0300 Subject: [11] RTM tests fail In-Reply-To: References: <515395B7-31C9-4502-A9A1-323DB768280C@twitter.com> <25bbc06005eb4e929f2bcd697618e3f8@sap.com> <8f31a45d24f84732ae7915f22aae61a5@sap.com> <26e36040-4b08-8293-21d8-ca770b945f57@linux.vnet.ibm.com> <70dca568-53b3-695d-f135-ac6e1f152529@linux.vnet.ibm.com> Message-ID: <6d445449-2082-d2c4-ad2d-76d7bf46e108@linux.vnet.ibm.com> Hi Christian, On 06/29/2018 12:16 PM, Christian Thalinger wrote: > > >> On Jun 25, 2018, at 5:32 PM, Gustavo Romero > wrote: >> >> Hi Christian, >> >> On 06/25/2018 09:54 AM, Christian Thalinger wrote: >>>> On Jun 25, 2018, at 8:49 AM, Gustavo Romero > wrote: >>>> >>>> On 06/25/2018 09:46 AM, Lindenmaier, Goetz wrote: >>>>>>> Did you check with or without these fixes? >>>>>> >>>>>> Without, unfortunately. ?Are all of the failures fixed now (in jdk-11+19)? >>>>> I don't know, our machines do not have RTM, only our Power ones do. >>>>> But I think Gustavo Romero from IBM claimed so. >>>> >>>> Yup, after the three fixes Goetz mentioned all RTM tests must pass on Intel. >>> Ok, I?ll get back to you? >> >> Yes, please let me know if all went fine :) > > I did not forget but we can?t merge in jdk-11+19 because of https://bugs.openjdk.java.net/browse/JDK-8205616 > > We have to wait until jdk-11+20 is tagged. Sure! Cheers, Gustavo From vladimir.kozlov at oracle.com Fri Jun 29 17:19:57 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Jun 2018 10:19:57 -0700 Subject: RFR(XXXS): 8203504: [Graal] org.graalvm.compiler.debug.test.DebugContextTest fails with java.util.ServiceConfigurationError In-Reply-To: <36e025bf-4249-04e5-e691-e2b80e3305d8@oracle.com> References: <36e025bf-4249-04e5-e691-e2b80e3305d8@oracle.com> Message-ID: <81dbb61e-21ca-2bff-f949-d3da19869d8e@oracle.com> Good. Thanks, Vladimir On 6/29/18 12:15 AM, Rahul Raghavan wrote: > Hi, > > JBS????? - https://bugs.openjdk.java.net/browse/JDK-8203504 > webrev.00- http://cr.openjdk.java.net/~rraghavan/8203504/webrev.00/ > > > Please review this patch to add missing 'uses' statement in > module-info.java > > +??? uses org.graalvm.compiler.debug.DebugHandlersFactory; > > > Thanks, > Rahul From vladimir.kozlov at oracle.com Fri Jun 29 17:50:51 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Jun 2018 10:50:51 -0700 Subject: [11] RFR(XS): 8206093: compiler/graalunit/HotspotTest.java fails in CheckGraalIntrinsics In-Reply-To: <4dc3c1a7-42c4-0e00-e763-b569af663177@oracle.com> References: <4dc3c1a7-42c4-0e00-e763-b569af663177@oracle.com> Message-ID: <78a57e9c-d342-156a-fd35-37b8a143bcd4@oracle.com> Good. So the problem was that I run tier3 (which ran Graal) before latest Graal update. And for pre-push I ran only tier1,tier2. Thanks, Vladimir On 6/29/18 3:24 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch that ignores the java/util/Base64$Encoder.encodeBlock intrinsic > which is not (yet) implemented in Graal: > https://bugs.openjdk.java.net/browse/JDK-8206093 > http://cr.openjdk.java.net/~thartmann/8206093/webrev.00/ > > Thanks, > Tobias > From vladimir.kozlov at oracle.com Fri Jun 29 18:00:02 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Jun 2018 11:00:02 -0700 Subject: RFR(S): 8205515: assert(opcode == Op_RangeCheck) failed: no other if variant here In-Reply-To: References: <10e9f03b-5ee7-5e87-6892-dc2192ac2514@oracle.com> Message-ID: Thank you, Roland Explanation and changes seems reasonable. Let me test it. Thanks, Vladimir On 6/29/18 1:14 AM, Roland Westrelin wrote: > > Hi Vladimir, > >> Looks like this change cause an other crash for example in >> gc/stress/gcbasher/TestGCBasherWithG1.java (no special flags are needed >> - only ones in the test) > > Thanks for testing. Here is an updated webrev: > > http://cr.openjdk.java.net/~roland/8205515/webrev.01/ > > We have a block of regular predicates, followed by a block of profile > predicates. For a data node that's above a loop, the logic tries to set > its control as high as possible above the predicates. > > The current logic looks for the profile predicate added at parse time > then possibly for the predicate added at parse time and set the control > of the data node above. > > So with: > > predicate added at parse time (with Opaque1 node) > > profile predicate added at parse time (with Opaque1 node) > > the data node would have control set above both predicates. With: > > some predicate hoisted by loop predication > some predicate hoisted by loop predication > predicate added at parse time (with Opaque1 node) > > profile predicate added at parse time (with Opaque1 node) > > the data node would have control set right above the predicate added at > parse time. And with: > > some predicate hoisted by loop predication > some predicate hoisted by loop predication > predicate added at parse time (with Opaque1 node) > > some profile predicate hoisted by loop predication > some profile predicate hoisted by loop predication > profile predicate added at parse time (with Opaque1 node) > > the data node have control set right above the profile predicate added > at parse time. > > The problem is that sometimes, we have something like: > > predicate added at parse time (with Opaque1 node) > > if (a == null) { unc; } //some predicate hoisted by loop predication > a = cast_not_null(a); //data node control dependent on hoisted predicate > profile predicate added at parse time (with Opaque1 node) > > then the compiler finds a dominating if (a == null) checks so the > predicate can be removed but dominated_by() prevents the cast from > moving up: > > predicate added at parse time (with Opaque1 node) > > a = cast_not_null(a); > > profile predicate added at parse time (with Opaque1 node) > > The current logic tries to set control of the cast above the first > predicate which is incorrect. > > Roland. > From tom.rodriguez at oracle.com Fri Jun 29 18:28:58 2018 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 29 Jun 2018 11:28:58 -0700 Subject: RFR(L) 8205824: Update Graal In-Reply-To: References: <31a49fa3-0892-736c-1835-3870ad4bb7c8@oracle.com> Message-ID: <27e460d4-d573-152f-4fcd-b4a922c36c41@oracle.com> >> 8204855 is a set of changes to the JVMCI API which are required to >> support the libgraal effort. Primarily this is about making a strong >> distinction between runtime and compiler objects and state and hiding >> anything which lets you bridge that boundary without be careful. >> Mostly it doesn't change the way JVMCI works apart from some changes >> to the HotSpotSpeculationLog implementation and the associated changes >> in Graal. These changes are binary incompatible with previous >> versions of JVMCI. Given the limitations of webrev I can't easily >> provide a webrev which shows just this change. > > There have been several examples of incremental webrevs for large > changes recently. It's impossible to have an opinion on the jvmci > changes given this webrev. I would have preferred to have a simpler webrev for review. Originally this change was going to be just the JVMCI API update but at the last minute a full Graal update was added on top so I wasn't able to do that. Given the single changeset requirements of pushes it wasn't really possible to keep them separate anymore. Single commit pushes and webrev don't make it easy to provide a good reviewing experience for complex changes. The changes to jdk.vm.ci are the JVMCI API update itself so it's only the adjustments required by Graal for the API that are mixed in with other Graal updates. A slightly out of date webrev of the original change is at http://cr.openjdk.java.net/~never/8204855/webrev if you wish to see those. They are generally speaking fairly trivial. They will also be directly visible as a merge changeset in the Graal sources when those changes officially land, probably on Monday. tom > > // Nils > >> >> The bits were tested with mach5 >> builds-tier1,jdk-tier1,hs-tier1,hs-tier2,hs-tier3,hs-tier4-graal,hs-tier5-graal >> and hs-tier6-graal. The details are in the bug report. >> >> I'm happy to explain anything about changes the JVMCI and why they >> were required. The JVMCI API updates have been tested with JDK8 Graal >> and will land in the next few days. >> >> tom > From igor.ignatyev at oracle.com Fri Jun 29 18:32:50 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 29 Jun 2018 11:32:50 -0700 Subject: RFR(XXS) : 8204517 : [Graal] org.graalvm.compiler.debug.test.VersionsTest fails with InvalidPathException on windows Message-ID: <0E485573-95EC-4C98-9FA4-38A1CA56C524@oracle.com> http://cr.openjdk.java.net/~iignatyev//8204517/webrev.00/index.html > 7 lines changed: 2 ins; 1 del; 4 mod; Hi all, could you please review this tiny fix for graal unit test? the patch has been approved and upstreamed to graal. webrev: http://cr.openjdk.java.net/~iignatyev//8204517/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8204517 testing: affected test on windows and other platforms Thanks, -- Igor From vladimir.kozlov at oracle.com Fri Jun 29 18:35:05 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Jun 2018 11:35:05 -0700 Subject: RFR(S): 8205515: assert(opcode == Op_RangeCheck) failed: no other if variant here In-Reply-To: References: <10e9f03b-5ee7-5e87-6892-dc2192ac2514@oracle.com> Message-ID: <5af5a8d9-b6e0-e072-7b6b-bd0f01661795@oracle.com> Tobias already started testing and I see new crashes. It was Kitchensink test running with ZGC. # Internal Error (/scratch/workspace/open/src/hotspot/share/opto/loopnode.cpp:3826), pid=1305, tid=1382 # assert(!had_error) failed: bad dominance Current CompileTask: C2: 910563 14019 4 org.sunflow.core.ParameterList::clear (96 bytes) V [libjvm.so+0xb4e310] report_vm_error(char const*, int, char const*, char const*, ...)+0x100 V [libjvm.so+0x128b3cb] PhaseIdealLoop::compute_lca_of_uses(Node*, Node*, bool)+0x32b I attached output and hs_err to bug report. Vladimir On 6/29/18 11:00 AM, Vladimir Kozlov wrote: > Thank you, Roland > > Explanation and changes seems reasonable. Let me test it. > > Thanks, > Vladimir > > On 6/29/18 1:14 AM, Roland Westrelin wrote: >> >> Hi Vladimir, >> >>> Looks like this change cause an other crash for example in >>> gc/stress/gcbasher/TestGCBasherWithG1.java (no special flags are needed >>> - only ones in the test) >> >> Thanks for testing. Here is an updated webrev: >> >> http://cr.openjdk.java.net/~roland/8205515/webrev.01/ >> >> We have a block of regular predicates, followed by a block of profile >> predicates. For a data node that's above a loop, the logic tries to set >> its control as high as possible above the predicates. >> >> The current logic looks for the profile predicate added at parse time >> then possibly for the predicate added at parse time and set the control >> of the data node above. >> >> So with: >> >> predicate added at parse time (with Opaque1 node) >> >> profile predicate added at parse time (with Opaque1 node) >> >> the data node would have control set above both predicates. With: >> >> some predicate hoisted by loop predication >> some predicate hoisted by loop predication >> predicate added at parse time (with Opaque1 node) >> >> profile predicate added at parse time (with Opaque1 node) >> >> the data node would have control set right above the predicate added at >> parse time. And with: >> >> some predicate hoisted by loop predication >> some predicate hoisted by loop predication >> predicate added at parse time (with Opaque1 node) >> >> some profile predicate hoisted by loop predication >> some profile predicate hoisted by loop predication >> profile predicate added at parse time (with Opaque1 node) >> >> the data node have control set right above the profile predicate added >> at parse time. >> >> The problem is that sometimes, we have something like: >> >> predicate added at parse time (with Opaque1 node) >> >> if (a == null) { unc; } //some predicate hoisted by loop predication >> a = cast_not_null(a);?? //data node control? dependent on hoisted >> predicate >> profile predicate added at parse time (with Opaque1 node) >> >> then the compiler finds a dominating if (a == null) checks so the >> predicate can be removed but dominated_by() prevents the cast from >> moving up: >> >> predicate added at parse time (with Opaque1 node) >> >> a = cast_not_null(a); >> >> profile predicate added at parse time (with Opaque1 node) >> >> The current logic tries to set control of the cast above the first >> predicate which is incorrect. >> >> Roland. >> From igor.ignatyev at oracle.com Fri Jun 29 18:35:09 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 29 Jun 2018 11:35:09 -0700 Subject: RFR(XS) : 8204355 : [Graal] org.graalvm.compiler.debug.test.CSVUtilTest fails on Windows due to improper line separator used Message-ID: <40428E79-A74C-404A-95A5-9A9433961358@oracle.com> http://cr.openjdk.java.net/~iignatyev//8204355/webrev.00/index.html > 2 lines changed: 0 ins; 0 del; 2 mod; Hi all, could you please review this tiny patch for graal test? the patch has been approved and upstreamed to graal repo. webrev: http://cr.openjdk.java.net/~iignatyev//8204355/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8204355 testing: affected test on windows and other platforms Thanks, -- Igor From vladimir.kozlov at oracle.com Fri Jun 29 18:51:26 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Jun 2018 11:51:26 -0700 Subject: RFR(XS) : 8204355 : [Graal] org.graalvm.compiler.debug.test.CSVUtilTest fails on Windows due to improper line separator used In-Reply-To: <40428E79-A74C-404A-95A5-9A9433961358@oracle.com> References: <40428E79-A74C-404A-95A5-9A9433961358@oracle.com> Message-ID: Reviewed. Thanks, Vladimir On 6/29/18 11:35 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8204355/webrev.00/index.html >> 2 lines changed: 0 ins; 0 del; 2 mod; > > Hi all, > > could you please review this tiny patch for graal test? the patch has been approved and upstreamed to graal repo. > > webrev: http://cr.openjdk.java.net/~iignatyev//8204355/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8204355 > testing: affected test on windows and other platforms > > Thanks, > -- Igor > From igor.ignatyev at oracle.com Fri Jun 29 19:25:16 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 29 Jun 2018 12:25:16 -0700 Subject: RFR(S) : 8206117 : failed to get JDK properties for JVM w/o JVMCI Message-ID: <501E9895-80C7-4CE1-AAB0-9E5B19420844@oracle.com> http://cr.openjdk.java.net/~iignatyev//8204517/webrev.00/index.html > 39 lines changed: 0 ins; 0 del; 39 mod; Hi all, could you please review this small fix? if JVM has been build w/o JVMCI, it won't have EnableJVMCI flag, as a result jtreg-ext/requires/VMProps will throw NPE trying to set 'vm.opt.final.EnableJVMC' property. w/ this fix, we will get 'null' value for nonexistent flags. compiler/graalunit/graalunit/generateTests.sh has been updated to generate tests which can handle such values, compiler/graalunit/ tests have been regenerated. webrev: http://cr.openjdk.java.net/~iignatyev//8204517/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8206117 testing: compiler/graalunit tests on builds w/ and w/o JVMCI Thanks, -- Igor From vladimir.kozlov at oracle.com Fri Jun 29 19:34:00 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Jun 2018 12:34:00 -0700 Subject: RFR(S) : 8206117 : failed to get JDK properties for JVM w/o JVMCI In-Reply-To: <501E9895-80C7-4CE1-AAB0-9E5B19420844@oracle.com> References: <501E9895-80C7-4CE1-AAB0-9E5B19420844@oracle.com> Message-ID: <793b7ff3-3407-a8df-105f-ac59754da04c@oracle.com> Why not to check for 'null' in VMProps.java and assign 'false' value in such case? Thanks, Vladimir On 6/29/18 12:25 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8204517/webrev.00/index.html >> 39 lines changed: 0 ins; 0 del; 39 mod; > > Hi all, > > could you please review this small fix? if JVM has been build w/o JVMCI, it won't have EnableJVMCI flag, as a result jtreg-ext/requires/VMProps will throw NPE trying to set 'vm.opt.final.EnableJVMC' property. w/ this fix, we will get 'null' value for nonexistent flags. compiler/graalunit/graalunit/generateTests.sh has been updated to generate tests which can handle such values, compiler/graalunit/ tests have been regenerated. > > webrev: http://cr.openjdk.java.net/~iignatyev//8204517/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8206117 > testing: compiler/graalunit tests on builds w/ and w/o JVMCI > > Thanks, > -- Igor > From igor.ignatyev at oracle.com Fri Jun 29 19:51:09 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 29 Jun 2018 12:51:09 -0700 Subject: RFR(S) : 8206117 : failed to get JDK properties for JVM w/o JVMCI In-Reply-To: <793b7ff3-3407-a8df-105f-ac59754da04c@oracle.com> References: <501E9895-80C7-4CE1-AAB0-9E5B19420844@oracle.com> <793b7ff3-3407-a8df-105f-ac59754da04c@oracle.com> Message-ID: I ain't sure setting 'false' to nonexistent flags would the right choice in all cases, and I don't want real 'false' and 'false' from nonexistent flags to be mixed up. -- Igor > On Jun 29, 2018, at 12:34 PM, Vladimir Kozlov wrote: > > Why not to check for 'null' in VMProps.java and assign 'false' value in such case? > > Thanks, > Vladimir > > On 6/29/18 12:25 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8204517/webrev.00/index.html >>> 39 lines changed: 0 ins; 0 del; 39 mod; >> Hi all, >> could you please review this small fix? if JVM has been build w/o JVMCI, it won't have EnableJVMCI flag, as a result jtreg-ext/requires/VMProps will throw NPE trying to set 'vm.opt.final.EnableJVMC' property. w/ this fix, we will get 'null' value for nonexistent flags. compiler/graalunit/graalunit/generateTests.sh has been updated to generate tests which can handle such values, compiler/graalunit/ tests have been regenerated. >> webrev: http://cr.openjdk.java.net/~iignatyev//8204517/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8206117 >> testing: compiler/graalunit tests on builds w/ and w/o JVMCI >> Thanks, >> -- Igor From vladimir.kozlov at oracle.com Fri Jun 29 19:56:57 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Jun 2018 12:56:57 -0700 Subject: RFR(S) : 8206117 : failed to get JDK properties for JVM w/o JVMCI In-Reply-To: References: <501E9895-80C7-4CE1-AAB0-9E5B19420844@oracle.com> <793b7ff3-3407-a8df-105f-ac59754da04c@oracle.com> Message-ID: <64e5f211-0e59-2917-3784-d1d6e348f2c1@oracle.com> Okay. thanks, Vladimir On 6/29/18 12:51 PM, Igor Ignatyev wrote: > I ain't sure setting 'false' to nonexistent flags would the right choice in all cases, and I don't want real 'false' and 'false' from nonexistent flags to be mixed up. > > -- Igor > >> On Jun 29, 2018, at 12:34 PM, Vladimir Kozlov wrote: >> >> Why not to check for 'null' in VMProps.java and assign 'false' value in such case? >> >> Thanks, >> Vladimir >> >> On 6/29/18 12:25 PM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8204517/webrev.00/index.html >>>> 39 lines changed: 0 ins; 0 del; 39 mod; >>> Hi all, >>> could you please review this small fix? if JVM has been build w/o JVMCI, it won't have EnableJVMCI flag, as a result jtreg-ext/requires/VMProps will throw NPE trying to set 'vm.opt.final.EnableJVMC' property. w/ this fix, we will get 'null' value for nonexistent flags. compiler/graalunit/graalunit/generateTests.sh has been updated to generate tests which can handle such values, compiler/graalunit/ tests have been regenerated. >>> webrev: http://cr.openjdk.java.net/~iignatyev//8204517/webrev.00/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8206117 >>> testing: compiler/graalunit tests on builds w/ and w/o JVMCI >>> Thanks, >>> -- Igor > From igor.ignatyev at oracle.com Fri Jun 29 20:15:54 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 29 Jun 2018 13:15:54 -0700 Subject: RFR(S) : 8206117 : failed to get JDK properties for JVM w/o JVMCI In-Reply-To: <501E9895-80C7-4CE1-AAB0-9E5B19420844@oracle.com> References: <501E9895-80C7-4CE1-AAB0-9E5B19420844@oracle.com> Message-ID: for the sake of history, the right webrev is http://cr.openjdk.java.net/~iignatyev//8206117/webrev.00/index.html -- Igor > On Jun 29, 2018, at 12:25 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8204517/webrev.00/index.html >> 39 lines changed: 0 ins; 0 del; 39 mod; > > Hi all, > > could you please review this small fix? if JVM has been build w/o JVMCI, it won't have EnableJVMCI flag, as a result jtreg-ext/requires/VMProps will throw NPE trying to set 'vm.opt.final.EnableJVMC' property. w/ this fix, we will get 'null' value for nonexistent flags. compiler/graalunit/graalunit/generateTests.sh has been updated to generate tests which can handle such values, compiler/graalunit/ tests have been regenerated. > > webrev: http://cr.openjdk.java.net/~iignatyev//8204517/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8206117 > testing: compiler/graalunit tests on builds w/ and w/o JVMCI > > Thanks, > -- Igor From vladimir.kozlov at oracle.com Fri Jun 29 20:24:06 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Jun 2018 13:24:06 -0700 Subject: RFR(XXS) : 8204517 : [Graal] org.graalvm.compiler.debug.test.VersionsTest fails with InvalidPathException on windows In-Reply-To: <0E485573-95EC-4C98-9FA4-38A1CA56C524@oracle.com> References: <0E485573-95EC-4C98-9FA4-38A1CA56C524@oracle.com> Message-ID: Looks good. Vladimir On 6/29/18 11:32 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8204517/webrev.00/index.html >> 7 lines changed: 2 ins; 1 del; 4 mod; > > Hi all, > > could you please review this tiny fix for graal unit test? the patch has been approved and upstreamed to graal. > > webrev: http://cr.openjdk.java.net/~iignatyev//8204517/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8204517 > testing: affected test on windows and other platforms > > Thanks, > -- Igor > From mikhailo.seledtsov at oracle.com Fri Jun 1 01:43:55 2018 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Fri, 01 Jun 2018 01:43:55 -0000 Subject: RFR(L) : 8202812 : [TESTBUG] Open source VM testbase compiler tests In-Reply-To: References: Message-ID: <5B10A4D4.5000206@oracle.com> Looks good to me. One comment though: http://cr.openjdk.java.net/~iignatyev//8202812/webrev.00/test/hotspot/jtreg/vmTestbase/jit/graph/js_CGT.testlist.html - copyright header needs to be updated please update the copyright statement prior to integration; no need for a new webrev Thank you, Misha On 5/18/18, 10:50 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8202812/webrev.00/index.html >> 56733 lines changed: 56732 ins; 0 del; 1 mod; 1 > Hi all, > > could you please review the patch which open sources compiler tests from vm testbase? these tests were developed in different time to cover different parts of JITs. > > As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8202812 > webrev: http://cr.openjdk.java.net/~iignatyev/8202812/webrev.00/index.html > testing: :vmTestbase_vm_compiler test group > > Thanks, > -- Igor