From david.holmes at oracle.com Fri Jan 1 07:19:05 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Jan 2021 17:19:05 +1000 Subject: RFR: 8252049: Native memory leak in ciMethodData ctor [v5] In-Reply-To: References: Message-ID: <10a5c017-30c3-80a4-0452-32c0fb196a65@oracle.com> On 31/12/2020 8:13 pm, John Paul Adrian Glaubitz wrote: > On Wed, 30 Dec 2020 22:43:46 GMT, John Paul Adrian Glaubitz wrote: > >>> Thanks for the reviews, Kim, Coleen, and David. >> >> The change in 044616bd71ab82f0f67670152cecbabfee83d00c breaks the build on m68k which uses a native alignment of 16 bits despite being a 32-bit architecture as a result of the m68k SysV ABI. >> >> In file included from /<>/src/hotspot/share/ci/ciEnv.hpp:35, >> from /<>/src/hotspot/share/ci/compilerInterface.hpp:32, >> from /<>/src/hotspot/share/compiler/abstractCompiler.hpp:28, >> from /<>/src/hotspot/share/compiler/abstractCompiler.cpp:25: >> /<>/src/hotspot/share/oops/methodData.hpp: In constructor 'MethodData::CompilerCounters::CompilerCounters()': >> /<>/src/hotspot/share/oops/methodData.hpp:1987:55: error: static assertion failed: align >> 1987 | static_assert(sizeof(_trap_hist) % HeapWordSize == 0, "align"); >> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ >> gmake[4]: *** [lib/CompileJvm.gmk:143: /<>/build/hotspot/variant-zero/libjvm/objs/abstractCompiler.o] Error 1 >> gmake[3]: *** [make/Main.gmk:252: hotspot-zero-libs] Error 2 >> gmake[3]: *** Waiting for unfinished jobs.... >> >> Full log: https://buildd.debian.org/status/fetch.php?pkg=openjdk-16&arch=m68k&ver=16%7E29-1&stamp=1609359094&raw=0 >> >> Any suggestion on a quick fix (before I start digging myself)? > >> Isn't m68K a zero-only platform? In which case why are these files even part of the build let alone runtime? > > Yes, it's a Zero port. But apparently the files are being used anyway. Perhaps someone from compiler team can explain why. Maybe there is scope for excluding them. David ----- >> Exclude the assertion in a zero build? > > Thanks, I'll do that. I wasn't sure whether the code was relevant for Zero or not. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1478 > From bulasevich at openjdk.java.net Fri Jan 1 12:14:06 2021 From: bulasevich at openjdk.java.net (Boris Ulasevich) Date: Fri, 1 Jan 2021 12:14:06 GMT Subject: Withdrawn: 8249893: AARCH64: optimize the construction of the value from the bits of the other two In-Reply-To: References: Message-ID: <-2gv_7tJ4ThNurozFAS2Bzl80wa9Nod2FZ8YqCrd3aE=.9785f6ef-0afb-4cd1-811a-aede40593c33@github.com> On Mon, 5 Oct 2020 17:36:14 GMT, Boris Ulasevich wrote: > Let me revive the change request [3] to C2 and AArch64 that applies Bitfield Insert instruction in the expression "(v1 & 0xFF) | ((v2 & 0xFF) << 8)". > > Compared to the last round of review [2] I updated the transformation to apply BFI in more cases and added a jtreg test. > > As before, compared to the original patch [1], the transformation logic is now in the common C2 code: a new BitfieldInsert node has been introduced to replace Or+Shift+And sequence when possible, on AARCH a single BFI instruction is emitted for the new node. > > [1] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-July/039161.html > [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-August/039653.html > [3] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-August/039792.html This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/511 From ysuenaga at openjdk.java.net Sun Jan 3 04:52:04 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sun, 3 Jan 2021 04:52:04 GMT Subject: RFR: 8259035: Comments for load order of hsdis should be updated Message-ID: Load order for hsdis is described in both src/utils/hsdis/README and src/hotspot/share/compiler/disassembler.cpp. README has been updated in [JDK-8215977](https://bugs.openjdk.java.net/browse/JDK-8215977), however disassembler.cpp has not been updated yet. ------------- Commit messages: - 8259035: Comments for load order of hsdis should be updated Changes: https://git.openjdk.java.net/jdk/pull/1919/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1919&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259035 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1919.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1919/head:pull/1919 PR: https://git.openjdk.java.net/jdk/pull/1919 From github.com+10482586+therealeliu at openjdk.java.net Mon Jan 4 02:00:56 2021 From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu) Date: Mon, 4 Jan 2021 02:00:56 GMT Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift register value In-Reply-To: References: Message-ID: <8bFPyc33jjtDCZ3teQf14B6SmFJ1ifdD3DGp2ClHIk4=.4b861d50-8333-4fe9-b9d7-d28599e91831@github.com> On Mon, 21 Dec 2020 10:10:10 GMT, Eric Liu wrote: > This patch transforms '(x >>> rshift) + (x << lshift)' into > 'RotateRight(x, rshift)' during GVN phase when both the shift exponents > are constants and their sum equals to the number of bits for the type > of shift base. > > This patch implements some new match rules for AArch64 instructions > which can take ROR as the optional shift. Such instructions are 'and', > 'or', 'eor', 'eon', 'bic' and 'orn'. > > ror w11, w2, #5 > eor w0, w1, w11 > > With this patch, above code could be optimized to below: > > eor w0, w1, w2, ror #5 > > Finally, the patch refactors TestRotate.java[1][2]. > > Tested jtreg TestRotate.java, hotspot::hotspot_all_no_apps, > jdk::jdk_core, langtools::tier1. > > [1] https://bugs.openjdk.java.net/browse/JDK-8252776 > [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039911.html Could anyone help to take a look at this PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/1858 From xgong at openjdk.java.net Mon Jan 4 02:09:10 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Mon, 4 Jan 2021 02:09:10 GMT Subject: RFR: 8258813: [TESTBUG] Fix incorrect Vector API test output message Message-ID: <5sX7KaIfqVM3R1oMVcnKYjnwcq-Vm-tGUgu43Q1Rr00=.c90cc99c-65fd-47ac-9746-b63530eb1e26@github.com> Some vector api tests have incorrect output messages if assertion fails. The root cause is the improper use of `"org.testng.Assert.assertEqual()"`, whose definition with int type is: assertEquals(int actual, int expected, String message); The method needs the actual value be used as the first argument and expected value as the second one. But in some vector api tests, the two arguments are swapped. For example, here is part of the fail log in VectorReshapeTests we met: expect: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16] output: [1, 2, 3, 4, 5, 6, 7, 8, 1, 0, 0, 0, 0, 0, 0, 0] test VectorReshapeTests.testRebracket128(byte(i)): failure java.lang.AssertionError: arrays differ firstly at element [8]; expected value is <1> but was <9>. at org.testng.Assert.fail(Assert.java:94) at org.testng.Assert.assertEquals(Assert.java:774) ... The assertion error should be `"...expected value is <9> but was <1>."` This does not influence on the test effectiveness. However, the incorrect message is confusing which might mislead people. The simple fix is just to swap the arguments back. This patch also adjusts the arguments order of all the assertion methods to make the actual values used as the first one. Besides, it also removes two unused assertion methods. ------------- Commit messages: - 8258813: [TESTBUG] Fix incorrect Vector API test output message Changes: https://git.openjdk.java.net/jdk/pull/1922/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1922&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258813 Stats: 7796 lines in 108 files changed: 0 ins; 682 del; 7114 mod Patch: https://git.openjdk.java.net/jdk/pull/1922.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1922/head:pull/1922 PR: https://git.openjdk.java.net/jdk/pull/1922 From dongbo at openjdk.java.net Mon Jan 4 06:29:10 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Mon, 4 Jan 2021 06:29:10 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp Message-ID: This patch optimizes vectorial Min/Max reduction of two floating-point numbers on aarch64 with NEON instructions `fmaxp` and `fminp`. Passed jtreg tier1-3 tests with `linux-aarch64-server-fastdebug` build. Tests under `test/jdk/jdk/incubator/vector/` runned specially for the correctness and passed. Introduced a JMH micro `test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java` is used for performance test. Witnessed abount `37%` performance improvements on Kunpeng916. The JMH Results: Benchmark (COUNT) (seed) Mode Cnt Score Error Units # Kunpeng 916, default VectorReduction.maxRedD 512 0 avgt 10 678.126 ? 0.815 ns/op VectorReduction.maxRedF 512 0 avgt 10 242.958 ? 0.212 ns/op VectorReduction.minRedD 512 0 avgt 10 678.554 ? 0.824 ns/op VectorReduction.minRedF 512 0 avgt 10 243.368 ? 0.205 ns/op # Kunpeng 916, with fmaxp/fminp VectorReduction.maxRedD 512 0 avgt 10 430.201 ? 0.353 ns/op => 36.56% VectorReduction.maxRedF 512 0 avgt 10 243.404 ? 0.297 ns/op VectorReduction.minRedD 512 0 avgt 10 427.805 ? 0.528 ns/op => 36.89% VectorReduction.minRedF 512 0 avgt 10 242.963 ? 0.210 ns/op ------------- Commit messages: - Update copyright - 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp Changes: https://git.openjdk.java.net/jdk/pull/1925/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1925&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258932 Stats: 647 lines in 7 files changed: 223 ins; 92 del; 332 mod Patch: https://git.openjdk.java.net/jdk/pull/1925.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1925/head:pull/1925 PR: https://git.openjdk.java.net/jdk/pull/1925 From thartmann at openjdk.java.net Mon Jan 4 07:19:56 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 4 Jan 2021 07:19:56 GMT Subject: RFR: 8258946: Fix optimization-unstable code involving signed integer overflow In-Reply-To: References: Message-ID: <9U4p3sYZ6bnuC-TzEGJLxRGYr0vq0wZzGhvLMupBM4Y=.238b6093-5f52-4f47-80f7-66df63ea01c7@github.com> On Mon, 28 Dec 2020 10:34:30 GMT, Hao Sun wrote: > Optimization-unstable code refers to code that is unexpectedly discarded > by compiler optimizations due to undefined behavior in the program. > > We applied a static checker called STACK (prototype from SOSP'13 paper > [1]) to OpenJDK source code and found the following six sites of > potential unstable code involving signed integer overflow. > > Removing undefined behaviors would make the code stable. > > [1] https://css.csail.mit.edu/stack/ > > ----- > Note that we tested locally Jtreg tests ( tier1 and jdk::tier3) were passed on Linux x86/aarch64 machines after apply this patch. Looks good to me. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1900 From thartmann at openjdk.java.net Mon Jan 4 07:23:57 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 4 Jan 2021 07:23:57 GMT Subject: RFR: 8258961: devirtualize SafePointNode::jvms() and hide out set_jvms() In-Reply-To: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> Message-ID: <3ETfgMZjD6Raek1gMbHa_hCCyFMgyoCLS7FwFcAsWfE=.3d5b7811-85e7-48d5-a6f3-fe8654b91fdd@github.com> On Mon, 28 Dec 2020 09:48:29 GMT, Xin Liu wrote: > SafePointNode::jvms() declares virtual but has never been overridden. It seems unnecessary. > The member variable _jvms declares 'JVMState* const', but set_jvms() updates its value anyway. > Geting rid of the const qualifier and hides if out using protected. Changes requested by thartmann (Reviewer). src/hotspot/share/opto/callnode.hpp line 336: > 334: JVMState* _jvms; // Pointer to list of JVM State objects > 335: void set_jvms(JVMState* s) { > 336: _jvms = s; // override const attribute in the accessor The comment should be adjusted since `_jvms` is not const anymore. ------------- PR: https://git.openjdk.java.net/jdk/pull/1899 From thartmann at openjdk.java.net Mon Jan 4 07:37:54 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 4 Jan 2021 07:37:54 GMT Subject: RFR: 8258751: Improve ExceptionHandlerTable dump In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 10:16:29 GMT, Hao Sun wrote: > In addition to PC offset, print the real PC as well if available when > dumping the ExceptionHandlerTable, as it's more convenient and readable > for debugging or other activities. > > Note that compilers might dump the ExceptionHandlerTable before method > registered. See functions emit_code_body() and fill_buffer(). However, > real PC is not ready yet during these phases since the generated code is > not installed. In such scenarios, the real PC is not printed. > > The example below shows how the dump information would be changed after > applying this patch. > BEFORE: > ExceptionHandlerTable (size = 40 bytes) > catch_pco = 392 (2 entries) > bci 8 at scope depth 0 -> pco 184 > bci 19 at scope depth 0 -> pco 124 > AFTER: > ExceptionHandlerTable (size = 40 bytes) > catch_pco = 392 (pc=0x0000ffff818f13c8, 2 entries) > bci 8 at scope depth 0 -> pco 184 (pc=0x0000ffff818f12f8) > bci 19 at scope depth 0 -> pco 124 (pc=0x0000ffff818f12bc) Looks good to me. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1877 From thartmann at openjdk.java.net Mon Jan 4 09:45:00 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 4 Jan 2021 09:45:00 GMT Subject: [jdk16] RFR: 8258619: -XX:CompileCommand=blackhole, * should only accept empty static methods In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 17:58:12 GMT, Aleksey Shipilev wrote: > In JDK-8257827 CSR, a further comment was raised about changing the semantics of the method. This allegedly introduces the conformance problem. While it is still an open question where the conformance problem is real, we can sidestep the entire issue by allowing only empty static methods to be blackholed. This eliminates any behavioral difference: empty methods have no side effects, and static methods do not need any null checks. > > This change eliminates a lot of new code added by original JDK-8252505 push, mostly now-useless testing code. It adds two more tests that verify that non-empty and non-static methods are properly rejected. Copyrights should be updated to 2021. Otherwise looks good to me. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/45 From whuang at openjdk.java.net Mon Jan 4 09:45:09 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Mon, 4 Jan 2021 09:45:09 GMT Subject: [jdk16] RFR: =?UTF-8?B?ODI1OTA0NO+8mg==?= JVM lacks data type qualifier when using -XX:+PrintAssembly with AArch64-Neon backend Message-ID: For instace: in the implentation of VectorMaskCmp & VectorStoreMask : $jtreg -vmoptions:"-XX:+PrintAssembly" ./Int128VectorTests.java before fixing ----------------- 0dc ldrq V17,[R10, #16] # vector (128 bits) 0e0 cmeq V16, V16, V17 # vector cmp (4I) 0e4 xtn V16, V16 # 4S to 4H xtn V16, V16 # 4H to 4B negr V16, V16 # store mask (4S to 4B) ----------------- Here? the output lacks data type qualifiers like T4S in `cmeq V16, V16, V17`. Expect: ----------------- 0dc ldrq V16,[R10, #16] # vector (128 bits) 0e0 cmeq V16, T4S, V16, V18 # vector cmp (4I) 0e4 xtn V16, T4H, V16, T4S # 4S to 4H xtn V16, T8B, V16, T8H # 4H to 4B negr V16, T8B, V16 # store mask (4S to 4B) ----------------- ------------- Commit messages: - 8259044: JVM lacks data type qualifier when using -XX:+PrintAssembly with AArch64-Neon backend Changes: https://git.openjdk.java.net/jdk16/pull/77/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=77&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259044 Stats: 197 lines in 2 files changed: 0 ins; 0 del; 197 mod Patch: https://git.openjdk.java.net/jdk16/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/77/head:pull/77 PR: https://git.openjdk.java.net/jdk16/pull/77 From chagedorn at openjdk.java.net Mon Jan 4 09:46:57 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 4 Jan 2021 09:46:57 GMT Subject: RFR: 8258751: Improve ExceptionHandlerTable dump In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 10:16:29 GMT, Hao Sun wrote: > In addition to PC offset, print the real PC as well if available when > dumping the ExceptionHandlerTable, as it's more convenient and readable > for debugging or other activities. > > Note that compilers might dump the ExceptionHandlerTable before method > registered. See functions emit_code_body() and fill_buffer(). However, > real PC is not ready yet during these phases since the generated code is > not installed. In such scenarios, the real PC is not printed. > > The example below shows how the dump information would be changed after > applying this patch. > BEFORE: > ExceptionHandlerTable (size = 40 bytes) > catch_pco = 392 (2 entries) > bci 8 at scope depth 0 -> pco 184 > bci 19 at scope depth 0 -> pco 124 > AFTER: > ExceptionHandlerTable (size = 40 bytes) > catch_pco = 392 (pc=0x0000ffff818f13c8, 2 entries) > bci 8 at scope depth 0 -> pco 184 (pc=0x0000ffff818f12f8) > bci 19 at scope depth 0 -> pco 124 (pc=0x0000ffff818f12bc) Otherwise, looks good to me! src/hotspot/share/code/exceptionHandlerTable.cpp line 2: > 1: /* > 2: * Copyright (c) 1998, 2020, Oracle and/or its affiliates. All rights reserved. Should be 2021 now. src/hotspot/share/code/exceptionHandlerTable.hpp line 2: > 1: /* > 2: * Copyright (c) 1998, 2020, Oracle and/or its affiliates. All rights reserved. Should be 2021 now. ------------- Marked as reviewed by chagedorn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1877 From shade at openjdk.java.net Mon Jan 4 10:11:57 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 4 Jan 2021 10:11:57 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 In-Reply-To: References: Message-ID: On Fri, 25 Dec 2020 10:11:13 GMT, Hao Sun wrote: > From the error log we can see the root cause is that, develop_pd flag > 'pd_CICompileOSR' is undeclared in zero build. > > Where this flag is used? > Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77 > of 'compiler_globals.hpp' and further line 86 of 'globals_shared.hpp'. > > Where this flag can be declared? > Header files 'c1_globals.hpp' or 'c2_globals.hpp' would be included if > VM is built with compiler1 or compiler2. See lines 30 to 38 of > 'complier_globals.hpp'. And further, flag 'pd_CICompileOSR' may get > declared in the header files for specific arch, e.g., > 'c1_globals_aarch64.hpp', 'c2_globals_aarch64.hpp'. > However, regarding zero build (without compiler1 and compiler2 and > jvmci) , this flag is undelcared. Hence, this patch gets header file > 'compiler/compiler_globals_pd.hpp' included where this flag is declared > for the case when neither COMPILER1 nor COMPILER2 are defined and > INCLUDE_JVMCI is inactive. > > Note that 'compiler/compiler_globals_pd.hpp' already includes > 'runtime/globals_shared.hpp'. > > Note that zero build with PCH succeeds because 'runtime/globals.hpp' is > included in 'precompiled.hpp', and further 'compiler_globals_pd.hpp' is > included in 'runtime/globals.hpp'. It is unclear to me why the original change in JDK-8258074 included `compiler_globals_pd.hpp` in `globals.hpp` at all, @iklam? It seems what @shqking proposes is sound. I believe we should additionally change the `#include compiler/compiler_globals_pd.hpp` to `#include compiler/compiler_globals.hpp` in `globals.hpp`? @shqking, please go to https://github.com/shqking/jdk/actions -- and enable GH Actions, then trigger the workflow manually on your branch to get this tested. ------------- Changes requested by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1894 From chagedorn at openjdk.java.net Mon Jan 4 11:12:09 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 4 Jan 2021 11:12:09 GMT Subject: RFR: 8259049: Uninitialized variable after JDK-8257513 Message-ID: Fixing missing initialization to prevent possible compiler warnings. The initialization is not required for correctness, though. Thanks, Christian ------------- Commit messages: - 8259049: Uninitialized variable after JDK-8257513 Changes: https://git.openjdk.java.net/jdk/pull/1930/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1930&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259049 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1930.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1930/head:pull/1930 PR: https://git.openjdk.java.net/jdk/pull/1930 From vlivanov at openjdk.java.net Mon Jan 4 11:37:59 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 4 Jan 2021 11:37:59 GMT Subject: [jdk16] RFR: 8258989: JVM is failed to inline in jdk.internal.vm.vector.VectorSupport::convert In-Reply-To: References: Message-ID: On Thu, 31 Dec 2020 01:47:00 GMT, Wang Huang wrote: > $java --add-modules=jdk.incubator.vector -Xcomp -XX:CompileCommand=compileonly,TestCast16BTo2D::* -XX:+UnlockDiagnosticVMOptions -XX:+PrintIntrinsics TestCast16BTo2D > before fixing: > ** not supported: arity=1 op=cast/5 vlen2=2 etype1=byte ismask=0 > @ 3 jdk.internal.util.Preconditions::checkIndex (18 bytes) (intrinsic) > @ 101 java.lang.Object::getClass (0 bytes) (intrinsic) > @ 109 java.lang.Object::getClass (0 bytes) (intrinsic) > @ 3 jdk.internal.util.Preconditions::checkIndex (18 bytes) (intrinsic) > @ 31 jdk.internal.vm.vector.VectorSupport::load (38 bytes) (intrinsic) > @ 128 jdk.internal.vm.vector.VectorSupport::convert (39 bytes) failed to inline (intrinsic) > @ 42 jdk.internal.vm.vector.VectorSupport::store (38 bytes) (intrinsic) > Expect: > @ 3 jdk.internal.util.Preconditions::checkIndex (18 bytes) (intrinsic) > @ 101 java.lang.Object::getClass (0 bytes) (intrinsic) > @ 109 java.lang.Object::getClass (0 bytes) (intrinsic) > @ 3 jdk.internal.util.Preconditions::checkIndex (18 bytes) (intrinsic) > @ 31 jdk.internal.vm.vector.VectorSupport::load (38 bytes) (intrinsic) > @ 128 jdk.internal.vm.vector.VectorSupport::convert (39 bytes) (intrinsic) > @ 42 jdk.internal.vm.vector.VectorSupport::store (38 bytes) (intrinsic) Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/74 From thartmann at openjdk.java.net Mon Jan 4 15:05:04 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 4 Jan 2021 15:05:04 GMT Subject: [jdk16] RFR: 8258989: JVM is failed to inline in jdk.internal.vm.vector.VectorSupport::convert In-Reply-To: References: Message-ID: On Thu, 31 Dec 2020 01:47:00 GMT, Wang Huang wrote: > $java --add-modules=jdk.incubator.vector -Xcomp -XX:CompileCommand=compileonly,TestCast16BTo2D::* -XX:+UnlockDiagnosticVMOptions -XX:+PrintIntrinsics TestCast16BTo2D > before fixing: > ** not supported: arity=1 op=cast/5 vlen2=2 etype1=byte ismask=0 > @ 3 jdk.internal.util.Preconditions::checkIndex (18 bytes) (intrinsic) > @ 101 java.lang.Object::getClass (0 bytes) (intrinsic) > @ 109 java.lang.Object::getClass (0 bytes) (intrinsic) > @ 3 jdk.internal.util.Preconditions::checkIndex (18 bytes) (intrinsic) > @ 31 jdk.internal.vm.vector.VectorSupport::load (38 bytes) (intrinsic) > @ 128 jdk.internal.vm.vector.VectorSupport::convert (39 bytes) failed to inline (intrinsic) > @ 42 jdk.internal.vm.vector.VectorSupport::store (38 bytes) (intrinsic) > Expect: > @ 3 jdk.internal.util.Preconditions::checkIndex (18 bytes) (intrinsic) > @ 101 java.lang.Object::getClass (0 bytes) (intrinsic) > @ 109 java.lang.Object::getClass (0 bytes) (intrinsic) > @ 3 jdk.internal.util.Preconditions::checkIndex (18 bytes) (intrinsic) > @ 31 jdk.internal.vm.vector.VectorSupport::load (38 bytes) (intrinsic) > @ 128 jdk.internal.vm.vector.VectorSupport::convert (39 bytes) (intrinsic) > @ 42 jdk.internal.vm.vector.VectorSupport::store (38 bytes) (intrinsic) Looks good to me too. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/74 From iklam at openjdk.java.net Mon Jan 4 17:43:08 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 4 Jan 2021 17:43:08 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 10:09:23 GMT, Aleksey Shipilev wrote: > It is unclear to me why the original change in JDK-8258074 included `compiler_globals_pd.hpp` in `globals.hpp` at all, @iklam? The reason is, for historical reasons, some PD flags related to the compiler, such as `BackgroundCompilation`, are declared in `globals.hpp`. As a result, `globals.hpp` must include `compiler_globals_pd.hpp`, which provides the platform-specific default value for `BackgroundCompilation`. This should eventually be fixed by moving the declaration of these flags to compiler_globals.hpp instead. > I believe we should additionally change the `#include compiler/compiler_globals_pd.hpp` to `#include compiler/compiler_globals.hpp` in `globals.hpp`? This is not necessary. `globals.hpp` does not use anything declared in `compiler_globals.hpp` ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From iklam at openjdk.java.net Mon Jan 4 17:43:01 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 4 Jan 2021 17:43:01 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 In-Reply-To: References: Message-ID: On Fri, 25 Dec 2020 10:11:13 GMT, Hao Sun wrote: > From the error log we can see the root cause is that, develop_pd flag > 'pd_CICompileOSR' is undeclared in zero build. > > Where this flag is used? > Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77 > of 'compiler_globals.hpp' and further line 86 of 'globals_shared.hpp'. > > Where this flag can be declared? > Header files 'c1_globals.hpp' or 'c2_globals.hpp' would be included if > VM is built with compiler1 or compiler2. See lines 30 to 38 of > 'complier_globals.hpp'. And further, flag 'pd_CICompileOSR' may get > declared in the header files for specific arch, e.g., > 'c1_globals_aarch64.hpp', 'c2_globals_aarch64.hpp'. > However, regarding zero build (without compiler1 and compiler2 and > jvmci) , this flag is undelcared. Hence, this patch gets header file > 'compiler/compiler_globals_pd.hpp' included where this flag is declared > for the case when neither COMPILER1 nor COMPILER2 are defined and > INCLUDE_JVMCI is inactive. > > Note that 'compiler/compiler_globals_pd.hpp' already includes > 'runtime/globals_shared.hpp'. > > Note that zero build with PCH succeeds because 'runtime/globals.hpp' is > included in 'precompiled.hpp', and further 'compiler_globals_pd.hpp' is > included in 'runtime/globals.hpp'. Changes requested by iklam (Reviewer). src/hotspot/share/compiler/compiler_globals.hpp line 29: > 27: > 28: #include "compiler/compiler_globals_pd.hpp" > 29: #ifdef COMPILER1 `#include "runtime/globals_shared.hpp"` should not be removed. compiler_globals.hpp uses the `DECLARE_FLAGS` macro, which is defined by globals_shared.hpp. ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From shade at openjdk.java.net Mon Jan 4 18:15:25 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 4 Jan 2021 18:15:25 GMT Subject: RFR: 8251944: Add Shenandoah test config to compiler/gcbarriers/UnsafeIntrinsicsTest.java [v3] In-Reply-To: References: Message-ID: > There used to be failures in Shenandoah CAS handling code like that were caught by this test. Those were fixed in JDK-8255401. This change turns the test into regression test for it. > > Additional testing: > - [x] Affected test on `x86_64` fastdebug, release > - [x] Affected test on `x86_32` fastdebug > - [x] Affected test on `aarch64` fastdebug Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into JDK-8251944-shenandoah-test-unsafe - Merge branch 'master' into JDK-8251944-shenandoah-test-unsafe - Mention 8255401 in @bug - Make test pass in release - 8251944: Add Shenandoah test config to compiler/gcbarriers/UnsafeIntrinsicsTest.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1693/files - new: https://git.openjdk.java.net/jdk/pull/1693/files/073e166c..899b899c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1693&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1693&range=01-02 Stats: 40014 lines in 1320 files changed: 27859 ins; 8021 del; 4134 mod Patch: https://git.openjdk.java.net/jdk/pull/1693.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1693/head:pull/1693 PR: https://git.openjdk.java.net/jdk/pull/1693 From kvn at openjdk.java.net Mon Jan 4 18:30:56 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 4 Jan 2021 18:30:56 GMT Subject: RFR: 8258946: Fix optimization-unstable code involving signed integer overflow In-Reply-To: References: Message-ID: On Mon, 28 Dec 2020 10:34:30 GMT, Hao Sun wrote: > Optimization-unstable code refers to code that is unexpectedly discarded > by compiler optimizations due to undefined behavior in the program. > > We applied a static checker called STACK (prototype from SOSP'13 paper > [1]) to OpenJDK source code and found the following six sites of > potential unstable code involving signed integer overflow. > > Removing undefined behaviors would make the code stable. > > [1] https://css.csail.mit.edu/stack/ > > ----- > Note that we tested locally Jtreg tests ( tier1 and jdk::tier3) were passed on Linux x86-64/aarch64 machines after apply this patch. Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1900 From psandoz at openjdk.java.net Mon Jan 4 18:47:03 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 4 Jan 2021 18:47:03 GMT Subject: RFR: 8258813: [TESTBUG] Fix incorrect Vector API test output message In-Reply-To: <5sX7KaIfqVM3R1oMVcnKYjnwcq-Vm-tGUgu43Q1Rr00=.c90cc99c-65fd-47ac-9746-b63530eb1e26@github.com> References: <5sX7KaIfqVM3R1oMVcnKYjnwcq-Vm-tGUgu43Q1Rr00=.c90cc99c-65fd-47ac-9746-b63530eb1e26@github.com> Message-ID: On Mon, 4 Jan 2021 02:03:13 GMT, Xiaohong Gong wrote: > Some vector api tests have incorrect output messages if assertion fails. The root cause is the improper use of `"org.testng.Assert.assertEqual()"`, whose definition with int type is: > assertEquals(int actual, int expected, String message); > > The method needs the actual value be used as the first argument and expected value as the second one. But in some vector api tests, the two arguments are swapped. > > For example, here is part of the fail log in VectorReshapeTests we met: > expect: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16] > output: [1, 2, 3, 4, 5, 6, 7, 8, 1, 0, 0, 0, 0, 0, 0, 0] > test VectorReshapeTests.testRebracket128(byte(i)): failure > java.lang.AssertionError: arrays differ firstly at element [8]; expected value is <1> but was <9>. > at org.testng.Assert.fail(Assert.java:94) > at org.testng.Assert.assertEquals(Assert.java:774) > ... > > The assertion error should be `"...expected value is <9> but was <1>."` > > This does not influence on the test effectiveness. However, the incorrect message is confusing which might mislead people. The simple fix is just to swap the arguments back. > > This patch also adjusts the arguments order of all the assertion methods to make the actual values used as the first one. Besides, it also removes two unused assertion methods. Thank you for fixing this. So easy to get mixed up between TestNG and JUnit! It's tempting to change the parameter names of the assert methods to be named `expected` and `accepted`, i'll consider doing that rather than impose that on you. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1922 From kvn at openjdk.java.net Mon Jan 4 18:47:55 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 4 Jan 2021 18:47:55 GMT Subject: RFR: 8259049: Uninitialized variable after JDK-8257513 In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 11:07:14 GMT, Christian Hagedorn wrote: > Fixing missing initialization to prevent possible compiler warnings. The initialization is not required for correctness, though. > > Thanks, > Christian Trivial. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1930 From kvn at openjdk.java.net Mon Jan 4 18:45:56 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 4 Jan 2021 18:45:56 GMT Subject: RFR: 8258961: devirtualize SafePointNode::jvms() and hide out set_jvms() In-Reply-To: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> Message-ID: On Mon, 28 Dec 2020 09:48:29 GMT, Xin Liu wrote: > SafePointNode::jvms() declares virtual but has never been overridden. It seems unnecessary. > The member variable _jvms declares 'JVMState* const', but set_jvms() updates its value anyway. > Geting rid of the const qualifier and hides if out using protected. Also update last copyright year in changed files. src/hotspot/share/runtime/vmStructs.cpp line 945: > 943: \ > 944: c2_nonstatic_field(SafePointNode, _jvms, JVMState* const) \ > 945: \ Don't remove it. It is referenced from HotSpot Servicability agent: https://github.com/openjdk/jdk/blob/master/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/SafePointNode.java#L45 ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1899 From kvn at openjdk.java.net Mon Jan 4 18:57:59 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 4 Jan 2021 18:57:59 GMT Subject: [jdk16] RFR: 8258703: Incorrect 512-bit vector registers restore on x86_32 In-Reply-To: References: Message-ID: <3iuHaytq5uSeE0dN1A1gobUcCZ_-grilK2UkRy8HiBM=.ca462a1c-7faa-44e6-8ae9-6e64f9c42ab8@github.com> On Wed, 23 Dec 2020 09:06:00 GMT, Jie Fu wrote: > Hi all, > > Following tests fail on our AVX512 machines with x86_32: > - compiler/runtime/Test7196199.java > - compiler/runtime/safepoints/TestRegisterRestoring.java > - compiler/vectorization/TestVectorsNotSavedAtSafepoint.java > > The reason is that 512-bit registers (zmm0 ~ zmm7) are restored incorrectly. > > Current restore logic for 512-bit registers includes: > 1) restore zmm[511..256] [1] > 2) restore zmm[255..128] [2] <-- Wrong on AVX512 with avx512vl > > On our AVX512 machine, Assembler::vinsertf128 [3] was called in step 2). > According to the Intel instruction set reference, vinsertf128 just copies the lower half of zmm, which lost the upper half of zmm. > VINSERTF128 (VEX encoded version) > TEMP[255:0] <- SRC1[255:0] > CASE (imm8[0]) OF > 0: TEMP[127:0] <- SRC2[127:0] > 1: TEMP[255:128] <- SRC2[127:0] > ESAC > DEST <- TEMP > > The fix just changes the order of the restore logic for 512-bit registers: > 1) restore zmm[255..128] > 2) restore zmm[511..256] > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk16/blob/master/src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp#L320 > [2] https://github.com/openjdk/jdk16/blob/master/src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp#L326 > [3] https://github.com/openjdk/jdk16/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.hpp#L1463 Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/64 From github.com+7991079+danlemmond at openjdk.java.net Mon Jan 4 19:34:04 2021 From: github.com+7991079+danlemmond at openjdk.java.net (Dan) Date: Mon, 4 Jan 2021 19:34:04 GMT Subject: RFR: 8255216: ciEnv::_break_at_compile isn't in use Message-ID: _break_at_compile is no longer in use and can be safely removed. No new code, and Tier1 tests succeed after code is removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 ------------- Commit messages: - 8255216: ciEnv::_break_at_compile isn't in use Changes: https://git.openjdk.java.net/jdk/pull/1806/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1806&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255216 Stats: 11 lines in 3 files changed: 0 ins; 11 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1806.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1806/head:pull/1806 PR: https://git.openjdk.java.net/jdk/pull/1806 From robilad at openjdk.java.net Mon Jan 4 19:34:05 2021 From: robilad at openjdk.java.net (Dalibor Topic) Date: Mon, 4 Jan 2021 19:34:05 GMT Subject: RFR: 8255216: ciEnv::_break_at_compile isn't in use In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 18:38:37 GMT, Dan wrote: > _break_at_compile is no longer in use and can be safely removed. > No new code, and Tier1 tests succeed after code is removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 Please send an e-mail to dalibor.topic at oracle.com so that I can mark your account as verified. ------------- PR: https://git.openjdk.java.net/jdk/pull/1806 From xliu at openjdk.java.net Mon Jan 4 19:34:05 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Mon, 4 Jan 2021 19:34:05 GMT Subject: RFR: 8255216: ciEnv::_break_at_compile isn't in use In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 18:38:37 GMT, Dan wrote: > _break_at_compile is no longer in use and can be safely removed. > No new code, and Tier1 tests succeed after code is removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 src/hotspot/share/compiler/compileBroker.cpp line 2227: > 2225: } > 2226: > 2227: should_break = directive->BreakAtExecuteOption || task->check_break_at_flags(); CompileTask::check_break_at_flags is dead code too, and CIBreakAtOSR, CIBreakAt they are all defunct right now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1806 From github.com+7991079+danlemmond at openjdk.java.net Mon Jan 4 19:34:06 2021 From: github.com+7991079+danlemmond at openjdk.java.net (Dan) Date: Mon, 4 Jan 2021 19:34:06 GMT Subject: RFR: 8255216: ciEnv::_break_at_compile isn't in use In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 21:06:20 GMT, Xin Liu wrote: >> _break_at_compile is no longer in use and can be safely removed. >> No new code, and Tier1 tests succeed after code is removed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 > > src/hotspot/share/compiler/compileBroker.cpp line 2227: > >> 2225: } >> 2226: >> 2227: should_break = directive->BreakAtExecuteOption || task->check_break_at_flags(); > > CompileTask::check_break_at_flags is dead code too, and CIBreakAtOSR, CIBreakAt > they are all defunct right now. I wasn't sure whether or not we wanted to roll the removal of all dead code into this issue or just _break_at_compile. The JBS issue specifically mentions _break_at_compile so that's what I removed here - can expand to do other stuff if you think it's a good idea. ------------- PR: https://git.openjdk.java.net/jdk/pull/1806 From jiefu at openjdk.java.net Mon Jan 4 23:41:54 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 4 Jan 2021 23:41:54 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 17:19:44 GMT, Ioi Lam wrote: > `#include "runtime/globals_shared.hpp"` should not be removed. compiler_globals.hpp uses the `DECLARE_FLAGS` macro, which is defined by globals_shared.hpp. Since globals_shared.hpp is included in compiler_globals_pd.hpp, I think it's fine to remove it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From jiefu at openjdk.java.net Mon Jan 4 23:44:57 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 4 Jan 2021 23:44:57 GMT Subject: [jdk16] RFR: 8258703: Incorrect 512-bit vector registers restore on x86_32 In-Reply-To: <3iuHaytq5uSeE0dN1A1gobUcCZ_-grilK2UkRy8HiBM=.ca462a1c-7faa-44e6-8ae9-6e64f9c42ab8@github.com> References: <3iuHaytq5uSeE0dN1A1gobUcCZ_-grilK2UkRy8HiBM=.ca462a1c-7faa-44e6-8ae9-6e64f9c42ab8@github.com> Message-ID: On Mon, 4 Jan 2021 18:55:20 GMT, Vladimir Kozlov wrote: >> Hi all, >> >> Following tests fail on our AVX512 machines with x86_32: >> - compiler/runtime/Test7196199.java >> - compiler/runtime/safepoints/TestRegisterRestoring.java >> - compiler/vectorization/TestVectorsNotSavedAtSafepoint.java >> >> The reason is that 512-bit registers (zmm0 ~ zmm7) are restored incorrectly. >> >> Current restore logic for 512-bit registers includes: >> 1) restore zmm[511..256] [1] >> 2) restore zmm[255..128] [2] <-- Wrong on AVX512 with avx512vl >> >> On our AVX512 machine, Assembler::vinsertf128 [3] was called in step 2). >> According to the Intel instruction set reference, vinsertf128 just copies the lower half of zmm, which lost the upper half of zmm. >> VINSERTF128 (VEX encoded version) >> TEMP[255:0] <- SRC1[255:0] >> CASE (imm8[0]) OF >> 0: TEMP[127:0] <- SRC2[127:0] >> 1: TEMP[255:128] <- SRC2[127:0] >> ESAC >> DEST <- TEMP >> >> The fix just changes the order of the restore logic for 512-bit registers: >> 1) restore zmm[255..128] >> 2) restore zmm[511..256] >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk16/blob/master/src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp#L320 >> [2] https://github.com/openjdk/jdk16/blob/master/src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp#L326 >> [3] https://github.com/openjdk/jdk16/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.hpp#L1463 > > Good. Thanks @vnkozlov for your review. ------------- PR: https://git.openjdk.java.net/jdk16/pull/64 From jiefu at openjdk.java.net Mon Jan 4 23:44:58 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 4 Jan 2021 23:44:58 GMT Subject: [jdk16] Integrated: 8258703: Incorrect 512-bit vector registers restore on x86_32 In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 09:06:00 GMT, Jie Fu wrote: > Hi all, > > Following tests fail on our AVX512 machines with x86_32: > - compiler/runtime/Test7196199.java > - compiler/runtime/safepoints/TestRegisterRestoring.java > - compiler/vectorization/TestVectorsNotSavedAtSafepoint.java > > The reason is that 512-bit registers (zmm0 ~ zmm7) are restored incorrectly. > > Current restore logic for 512-bit registers includes: > 1) restore zmm[511..256] [1] > 2) restore zmm[255..128] [2] <-- Wrong on AVX512 with avx512vl > > On our AVX512 machine, Assembler::vinsertf128 [3] was called in step 2). > According to the Intel instruction set reference, vinsertf128 just copies the lower half of zmm, which lost the upper half of zmm. > VINSERTF128 (VEX encoded version) > TEMP[255:0] <- SRC1[255:0] > CASE (imm8[0]) OF > 0: TEMP[127:0] <- SRC2[127:0] > 1: TEMP[255:128] <- SRC2[127:0] > ESAC > DEST <- TEMP > > The fix just changes the order of the restore logic for 512-bit registers: > 1) restore zmm[255..128] > 2) restore zmm[511..256] > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk16/blob/master/src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp#L320 > [2] https://github.com/openjdk/jdk16/blob/master/src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp#L326 > [3] https://github.com/openjdk/jdk16/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.hpp#L1463 This pull request has now been integrated. Changeset: 216c2ec0 Author: Jie Fu URL: https://git.openjdk.java.net/jdk16/commit/216c2ec0 Stats: 12 lines in 1 file changed: 6 ins; 5 del; 1 mod 8258703: Incorrect 512-bit vector registers restore on x86_32 Reviewed-by: kvn, sviswanathan ------------- PR: https://git.openjdk.java.net/jdk16/pull/64 From iklam at openjdk.java.net Tue Jan 5 00:15:57 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 5 Jan 2021 00:15:57 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 23:39:18 GMT, Jie Fu wrote: >> src/hotspot/share/compiler/compiler_globals.hpp line 29: >> >>> 27: >>> 28: #include "compiler/compiler_globals_pd.hpp" >>> 29: #ifdef COMPILER1 >> >> `#include "runtime/globals_shared.hpp"` should not be removed. compiler_globals.hpp uses the `DECLARE_FLAGS` macro, which is defined by globals_shared.hpp. > >> `#include "runtime/globals_shared.hpp"` should not be removed. compiler_globals.hpp uses the `DECLARE_FLAGS` macro, which is defined by globals_shared.hpp. > > Since globals_shared.hpp is included in compiler_globals_pd.hpp, I think it's fine to remove it. We should not rely on indirect inclusion. Otherwise, compiler_globals.hpp will break if compiler_globals_pd.hpp is changed to not include globals_shared.hpp. In fact, I have been fixing a lot of such problems when restructuring the header files. See https://github.com/openjdk/jdk/pull/1610 -- the vast majority of the 59 files changed in that PR were caused by relying on indirect inclusion of stubRoutines.hpp. ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From github.com+16932759+shqking at openjdk.java.net Tue Jan 5 01:44:58 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Tue, 5 Jan 2021 01:44:58 GMT Subject: RFR: 8258751: Improve ExceptionHandlerTable dump In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 09:35:59 GMT, Christian Hagedorn wrote: >> In addition to PC offset, print the real PC as well if available when >> dumping the ExceptionHandlerTable, as it's more convenient and readable >> for debugging or other activities. >> >> Note that compilers might dump the ExceptionHandlerTable before method >> registered. See functions emit_code_body() and fill_buffer(). However, >> real PC is not ready yet during these phases since the generated code is >> not installed. In such scenarios, the real PC is not printed. >> >> The example below shows how the dump information would be changed after >> applying this patch. >> BEFORE: >> ExceptionHandlerTable (size = 40 bytes) >> catch_pco = 392 (2 entries) >> bci 8 at scope depth 0 -> pco 184 >> bci 19 at scope depth 0 -> pco 124 >> AFTER: >> ExceptionHandlerTable (size = 40 bytes) >> catch_pco = 392 (pc=0x0000ffff818f13c8, 2 entries) >> bci 8 at scope depth 0 -> pco 184 (pc=0x0000ffff818f12f8) >> bci 19 at scope depth 0 -> pco 124 (pc=0x0000ffff818f12bc) > > src/hotspot/share/code/exceptionHandlerTable.cpp line 2: > >> 1: /* >> 2: * Copyright (c) 1998, 2020, Oracle and/or its affiliates. All rights reserved. > > Should be 2021 now. Thanks for your reminding. Will update it. > src/hotspot/share/code/exceptionHandlerTable.hpp line 2: > >> 1: /* >> 2: * Copyright (c) 1998, 2020, Oracle and/or its affiliates. All rights reserved. > > Should be 2021 now. Thanks for your reminding. Will update it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1877 From github.com+16932759+shqking at openjdk.java.net Tue Jan 5 02:46:11 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Tue, 5 Jan 2021 02:46:11 GMT Subject: RFR: 8257137: Revise smov and umov in aarch64 assembler [v2] In-Reply-To: References: Message-ID: > 1. Both smov and umov lack of checking the register type validity. > Register type must be 'B', 'H' or 'S' for smov [1]. > Register type can NOT be 'Q' for umov [2]. > Such checks are added. > > 2. smov and umov have different explanations on 'Q' field, i.e. bit 30 > of the insturction, but current assembler implementation mixed it up. > For umov, 'Q' field can only be set when register type 'D' is given > [2]. However, this field of smov must be set for register type 'S' > [1], that is, 'Q' field can be optional for register type 'B' or 'H'. > > Current implementation only took the umov scenario into account. As a > result, runtime error ILL_ILLOPN would occur if 'smov(Register, > FloatRegister, S, index)' is used. > > We put them into two separate functions and make 'Q' field always set > for smov. That means 'SMOVX' (64-bit register variant) is generated > for all cases since it's compatible with our current usages of 'SMOVW'. > Existing usages of smov have been double checked and this patch does > not affect them. > > 3. Smoke tests are also added. > > [1]. https://developer.arm.com/docs/ddi0602/f/simd-and-floating-point-instructions-alphabetic-order/smov-signed-move-vector-element-to-general-purpose-register > [2]. https://developer.arm.com/docs/ddi0602/f/simd-and-floating-point-instructions-alphabetic-order/umov-unsigned-move-vector-element-to-general-purpose-register > > > Note that Jtreg tier1 and jdk::tier3 have been tested and all tests passed without new failures. Hao Sun has updated the pull request incrementally with one additional commit since the last revision: Update the copyright notice to 2021 Update the copyright notice to 2021. Change-Id: I7fe485e768ccac45a4861cd3c061aedc13fef579 CustomizedGitHooks: yes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1586/files - new: https://git.openjdk.java.net/jdk/pull/1586/files/a40c0d88..3f84aaa5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1586&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1586&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1586.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1586/head:pull/1586 PR: https://git.openjdk.java.net/jdk/pull/1586 From njian at openjdk.java.net Tue Jan 5 02:50:58 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 5 Jan 2021 02:50:58 GMT Subject: [jdk16] RFR: =?UTF-8?B?ODI1OTA0NO+8mg==?= JVM lacks data type qualifier when using -XX:+PrintAssembly with AArch64-Neon backend In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 09:37:33 GMT, Wang Huang wrote: > For instace: in the implentation of VectorMaskCmp & VectorStoreMask : > > $jtreg -vmoptions:"-XX:+PrintAssembly" ./Int128VectorTests.java > > before fixing > ----------------- > 0dc ldrq V17,[R10, #16] # vector (128 bits) > 0e0 cmeq V16, V16, V17 # vector cmp (4I) > 0e4 xtn V16, V16 # 4S to 4H > xtn V16, V16 # 4H to 4B > negr V16, V16 # store mask (4S to 4B) > ----------------- > Here? the output lacks data type qualifiers like T4S in `cmeq V16, V16, V17`. > > Expect: > ----------------- > 0dc ldrq V16,[R10, #16] # vector (128 bits) > 0e0 cmeq V16, T4S, V16, V18 # vector cmp (4I) > 0e4 xtn V16, T4H, V16, T4S # 4S to 4H > xtn V16, T8B, V16, T8H # 4H to 4B > negr V16, T8B, V16 # store mask (4S to 4B) > ----------------- This looks good to me. But should this P4 enhancement go to https://github.com/openjdk/jdk instead of here? ------------- PR: https://git.openjdk.java.net/jdk16/pull/77 From github.com+16932759+shqking at openjdk.java.net Tue Jan 5 02:54:09 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Tue, 5 Jan 2021 02:54:09 GMT Subject: RFR: 8258751: Improve ExceptionHandlerTable dump [v2] In-Reply-To: References: Message-ID: <42hRavCMVS6Mq3CVTiZ4mlI69kOGxvE4OxeEWqx6KMs=.454dc16b-f161-4f1e-bf9f-f409845afccd@github.com> > In addition to PC offset, print the real PC as well if available when > dumping the ExceptionHandlerTable, as it's more convenient and readable > for debugging or other activities. > > Note that compilers might dump the ExceptionHandlerTable before method > registered. See functions emit_code_body() and fill_buffer(). However, > real PC is not ready yet during these phases since the generated code is > not installed. In such scenarios, the real PC is not printed. > > The example below shows how the dump information would be changed after > applying this patch. > BEFORE: > ExceptionHandlerTable (size = 40 bytes) > catch_pco = 392 (2 entries) > bci 8 at scope depth 0 -> pco 184 > bci 19 at scope depth 0 -> pco 124 > AFTER: > ExceptionHandlerTable (size = 40 bytes) > catch_pco = 392 (pc=0x0000ffff818f13c8, 2 entries) > bci 8 at scope depth 0 -> pco 184 (pc=0x0000ffff818f12f8) > bci 19 at scope depth 0 -> pco 124 (pc=0x0000ffff818f12bc) Hao Sun has updated the pull request incrementally with one additional commit since the last revision: Update the copyright notice to 2021 Upate the copyright notice to 2021. Change-Id: I442d1e3e1774488c2806c6cc21c2db7c4db08b8f CustomizedGitHooks: yes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1877/files - new: https://git.openjdk.java.net/jdk/pull/1877/files/018252b5..68c25c52 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1877&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1877&range=00-01 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1877.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1877/head:pull/1877 PR: https://git.openjdk.java.net/jdk/pull/1877 From njian at openjdk.java.net Tue Jan 5 02:57:15 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 5 Jan 2021 02:57:15 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests [v2] In-Reply-To: References: Message-ID: <9XtCnqp4eKcBDXlXSm18R6tUIH9mCPZUZJE3Htio2Bs=.606bf77d-fec8-434a-b1e9-6cb5484605a1@github.com> > After applying [1], some Vector API tests fail with SIGILL on SVE > system. The SIGILL was triggered by verify_ptrue before c2 compiled > function returns, which means that the preserved p7 register (as ptrue) > has been clobbered before returning to c2 compiled code. (p7 is not > preserved cross function calls, and system calls [2]). > > Currently we try to reinitialize ptrue at each entrypoint of returning > from non-c2 compiled code, which indicating possible C or system calls. > However, there's still one entrypoint missing, exception handling, as > we may jump to c2 compiled code for exception handler. See > OptoRuntime::generate_exception_blob(). > > Adding reinitialize_ptrue before jumping back to c2 compiled code in > generate_exception_blob() could solve those Vector API test failures. > Actually I had that in my initial test patch [3], I don't know why I > missed that in final patch... I reran tests with the same approach of > [3] and found that there's still something missing, the > nmethod_entry_barrier() in c2 function prolog. The barrier may call to > runtime code (see generate_method_entry_barrier()). To reduce the risk > of missing such reinitialize_ptrue in newly added code in future, I > think it would be better to do the reinitialize in > pop_call_clobbered_registers(). > > P.S. the SIGILL message is also not clear, it should print detailed > message as indicated by MacroAssembler::stop() call. This is caused by > JDK-8255711 removing the message printing code. This patch also adds it > back, so that it could print detailed message for abort. > > Tested with tier1-3 on SVE hardware. Also verified with the same > approach of patch [3] with jtreg tests hotspot_all_no_apps and > jdk:tier1-3 passed without incorrect ptrue value assertion failure. > > [1] https://github.com/openjdk/jdk/pull/1621 > [2] https://github.com/torvalds/linux/blob/master/Documentation/arm64/sve.rst > [3] http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision: Update copyright year to 2021. ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/50/files - new: https://git.openjdk.java.net/jdk16/pull/50/files/a5754c7d..873c2506 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=50&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=50&range=00-01 Stats: 12 lines in 7 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk16/pull/50.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/50/head:pull/50 PR: https://git.openjdk.java.net/jdk16/pull/50 From xgong at openjdk.java.net Tue Jan 5 03:12:15 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Tue, 5 Jan 2021 03:12:15 GMT Subject: RFR: 8258813: [TESTBUG] Fix incorrect Vector API test output message [v2] In-Reply-To: <5sX7KaIfqVM3R1oMVcnKYjnwcq-Vm-tGUgu43Q1Rr00=.c90cc99c-65fd-47ac-9746-b63530eb1e26@github.com> References: <5sX7KaIfqVM3R1oMVcnKYjnwcq-Vm-tGUgu43Q1Rr00=.c90cc99c-65fd-47ac-9746-b63530eb1e26@github.com> Message-ID: > Some vector api tests have incorrect output messages if assertion fails. The root cause is the improper use of `"org.testng.Assert.assertEqual()"`, whose definition with int type is: > assertEquals(int actual, int expected, String message); > > The method needs the actual value be used as the first argument and expected value as the second one. But in some vector api tests, the two arguments are swapped. > > For example, here is part of the fail log in VectorReshapeTests we met: > expect: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16] > output: [1, 2, 3, 4, 5, 6, 7, 8, 1, 0, 0, 0, 0, 0, 0, 0] > test VectorReshapeTests.testRebracket128(byte(i)): failure > java.lang.AssertionError: arrays differ firstly at element [8]; expected value is <1> but was <9>. > at org.testng.Assert.fail(Assert.java:94) > at org.testng.Assert.assertEquals(Assert.java:774) > ... > > The assertion error should be `"...expected value is <9> but was <1>."` > > This does not influence on the test effectiveness. However, the incorrect message is confusing which might mislead people. The simple fix is just to swap the arguments back. > > This patch also adjusts the arguments order of all the assertion methods to make the actual values used as the first one. Besides, it also removes two unused assertion methods. Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: Update copyright year to 2021 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1922/files - new: https://git.openjdk.java.net/jdk/pull/1922/files/c3fb2986..71190c9f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1922&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1922&range=00-01 Stats: 64 lines in 64 files changed: 0 ins; 0 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/1922.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1922/head:pull/1922 PR: https://git.openjdk.java.net/jdk/pull/1922 From xgong at openjdk.java.net Tue Jan 5 03:15:54 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Tue, 5 Jan 2021 03:15:54 GMT Subject: RFR: 8258813: [TESTBUG] Fix incorrect Vector API test output message [v2] In-Reply-To: References: <5sX7KaIfqVM3R1oMVcnKYjnwcq-Vm-tGUgu43Q1Rr00=.c90cc99c-65fd-47ac-9746-b63530eb1e26@github.com> Message-ID: On Mon, 4 Jan 2021 18:44:00 GMT, Paul Sandoz wrote: > Thank you for fixing this. So easy to get mixed up between TestNG and JUnit! > > It's tempting to change the parameter names of the assert methods to be named `expected` and `accepted`, i'll consider doing that rather than impose that on you. Hi @PaulSandoz, thanks so much for looking at this PR. And I'm so sorry that I forgot to update the copyright to the new year. I'v committed one more patch to fix them. Do you mind having a looking at it again? Many thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/1922 From whuang at openjdk.java.net Tue Jan 5 03:20:59 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 5 Jan 2021 03:20:59 GMT Subject: [jdk16] RFR: =?UTF-8?B?ODI1OTA0NO+8mg==?= JVM lacks data type qualifier when using -XX:+PrintAssembly with AArch64-Neon backend In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 02:48:13 GMT, Ningsheng Jian wrote: > This looks good to me. But should this P4 enhancement go to https://github.com/openjdk/jdk instead of here? OK. I will post a PR against jdk/jdk ASAP. ------------- PR: https://git.openjdk.java.net/jdk16/pull/77 From whuang at openjdk.java.net Tue Jan 5 03:39:03 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 5 Jan 2021 03:39:03 GMT Subject: RFR: 8259044: JVM lacks data type qualifier when using -XX:+PrintAssembly with AArch64-Neon backend Message-ID: For instace: in the implentation of VectorMaskCmp & VectorStoreMask : $jtreg -vmoptions:"-XX:+PrintAssembly" ./Int128VectorTests.java Before fixing: ----------------- 0dc ldrq V17,[R10, #16] # vector (128 bits) 0e0 cmeq V16, V16, V17 # vector cmp (4I) 0e4 xtn V16, V16 # 4S to 4H xtn V16, V16 # 4H to 4B negr V16, V16 # store mask (4S to 4B) ----------------- Here? the output lacks data type qualifiers like T4S in `cmeq V16, V16, V17`. Expect: ----------------- 0dc ldrq V16,[R10, #16] # vector (128 bits) 0e0 cmeq V16, T4S, V16, V18 # vector cmp (4I) 0e4 xtn V16, T4H, V16, T4S # 4S to 4H xtn V16, T8B, V16, T8H # 4H to 4B negr V16, T8B, V16 # store mask (4S to 4B) ----------------- ------------- Commit messages: - 8259044: JVM lacks data type qualifier when using -XX:+PrintAssembly with AArch64-Neon backend Changes: https://git.openjdk.java.net/jdk/pull/1941/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1941&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259044 Stats: 197 lines in 2 files changed: 0 ins; 0 del; 197 mod Patch: https://git.openjdk.java.net/jdk/pull/1941.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1941/head:pull/1941 PR: https://git.openjdk.java.net/jdk/pull/1941 From dongbo at openjdk.java.net Tue Jan 5 03:43:15 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Tue, 5 Jan 2021 03:43:15 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v2] In-Reply-To: References: Message-ID: > This patch optimizes vectorial Min/Max reduction of two floating-point numbers on aarch64 with NEON instructions `fmaxp` and `fminp`. > > Passed jtreg tier1-3 tests with `linux-aarch64-server-fastdebug` build. > Tests under `test/jdk/jdk/incubator/vector/` runned specially for the correctness and passed. > > Introduced a new JMH micro `test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java` for performance test. > Witnessed abount `37%` performance improvements on Kunpeng916. The JMH Results: > Benchmark (COUNT) (seed) Mode Cnt Score Error Units > # Kunpeng 916, default > VectorReduction.maxRedD 512 0 avgt 10 678.126 ? 0.815 ns/op > VectorReduction.maxRedF 512 0 avgt 10 242.958 ? 0.212 ns/op > VectorReduction.minRedD 512 0 avgt 10 678.554 ? 0.824 ns/op > VectorReduction.minRedF 512 0 avgt 10 243.368 ? 0.205 ns/op > > # Kunpeng 916, with fmaxp/fminp > VectorReduction.maxRedD 512 0 avgt 10 430.201 ? 0.353 ns/op => 36.56% > VectorReduction.maxRedF 512 0 avgt 10 243.404 ? 0.297 ns/op > VectorReduction.minRedD 512 0 avgt 10 427.805 ? 0.528 ns/op => 36.89% > VectorReduction.minRedF 512 0 avgt 10 242.963 ? 0.210 ns/op Dong Bo has updated the pull request incrementally with one additional commit since the last revision: rebase the .m4 entry ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1925/files - new: https://git.openjdk.java.net/jdk/pull/1925/files/71048b82..876939b9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1925&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1925&range=00-01 Stats: 16 lines in 1 file changed: 2 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/1925.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1925/head:pull/1925 PR: https://git.openjdk.java.net/jdk/pull/1925 From njian at openjdk.java.net Tue Jan 5 03:54:56 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 5 Jan 2021 03:54:56 GMT Subject: RFR: 8258751: Improve ExceptionHandlerTable dump [v2] In-Reply-To: <42hRavCMVS6Mq3CVTiZ4mlI69kOGxvE4OxeEWqx6KMs=.454dc16b-f161-4f1e-bf9f-f409845afccd@github.com> References: <42hRavCMVS6Mq3CVTiZ4mlI69kOGxvE4OxeEWqx6KMs=.454dc16b-f161-4f1e-bf9f-f409845afccd@github.com> Message-ID: On Tue, 5 Jan 2021 02:54:09 GMT, Hao Sun wrote: >> In addition to PC offset, print the real PC as well if available when >> dumping the ExceptionHandlerTable, as it's more convenient and readable >> for debugging or other activities. >> >> Note that compilers might dump the ExceptionHandlerTable before method >> registered. See functions emit_code_body() and fill_buffer(). However, >> real PC is not ready yet during these phases since the generated code is >> not installed. In such scenarios, the real PC is not printed. >> >> The example below shows how the dump information would be changed after >> applying this patch. >> BEFORE: >> ExceptionHandlerTable (size = 40 bytes) >> catch_pco = 392 (2 entries) >> bci 8 at scope depth 0 -> pco 184 >> bci 19 at scope depth 0 -> pco 124 >> AFTER: >> ExceptionHandlerTable (size = 40 bytes) >> catch_pco = 392 (pc=0x0000ffff818f13c8, 2 entries) >> bci 8 at scope depth 0 -> pco 184 (pc=0x0000ffff818f12f8) >> bci 19 at scope depth 0 -> pco 124 (pc=0x0000ffff818f12bc) > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Update the copyright notice to 2021 > > Upate the copyright notice to 2021. > > Change-Id: I442d1e3e1774488c2806c6cc21c2db7c4db08b8f > CustomizedGitHooks: yes Marked as reviewed by njian (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1877 From github.com+16932759+shqking at openjdk.java.net Tue Jan 5 04:56:56 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Tue, 5 Jan 2021 04:56:56 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 In-Reply-To: References: Message-ID: <7HjOk0EQl7wbAMcB-YPrZL_MzPxuexKLtWm9uxi6JFg=.cb37f275-30d7-4b82-8bcb-ea772202d967@github.com> On Mon, 4 Jan 2021 17:19:48 GMT, Ioi Lam wrote: >> From the error log we can see the root cause is that, develop_pd flag >> 'pd_CICompileOSR' is undeclared in zero build. >> >> Where this flag is used? >> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77 >> of 'compiler_globals.hpp' and further line 86 of 'globals_shared.hpp'. >> >> Where this flag can be declared? >> Header files 'c1_globals.hpp' or 'c2_globals.hpp' would be included if >> VM is built with compiler1 or compiler2. See lines 30 to 38 of >> 'complier_globals.hpp'. And further, flag 'pd_CICompileOSR' may get >> declared in the header files for specific arch, e.g., >> 'c1_globals_aarch64.hpp', 'c2_globals_aarch64.hpp'. >> However, regarding zero build (without compiler1 and compiler2 and >> jvmci) , this flag is undelcared. Hence, this patch gets header file >> 'compiler/compiler_globals_pd.hpp' included where this flag is declared >> for the case when neither COMPILER1 nor COMPILER2 are defined and >> INCLUDE_JVMCI is inactive. >> >> Note that 'compiler/compiler_globals_pd.hpp' already includes >> 'runtime/globals_shared.hpp'. >> >> Note that zero build with PCH succeeds because 'runtime/globals.hpp' is >> included in 'precompiled.hpp', and further 'compiler_globals_pd.hpp' is >> included in 'runtime/globals.hpp'. > > Changes requested by iklam (Reviewer). > It is unclear to me why the original change in JDK-8258074 included `compiler_globals_pd.hpp` in `globals.hpp` at all, @iklam? It seems what @shqking proposes is sound. > > I believe we should additionally change the `#include compiler/compiler_globals_pd.hpp` to `#include compiler/compiler_globals.hpp` in `globals.hpp`? > > @shqking, please go to https://github.com/shqking/jdk/actions -- and enable GH Actions, then trigger the workflow manually on your branch to get this tested. Thanks for your comment. @shipilev The tests were finished but one of them failed. I found that this failure existed for several days and I suppose it's not related to our patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From njian at openjdk.java.net Tue Jan 5 05:46:59 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 5 Jan 2021 05:46:59 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 07:11:11 GMT, Ningsheng Jian wrote: > After applying [1], some Vector API tests fail with SIGILL on SVE > system. The SIGILL was triggered by verify_ptrue before c2 compiled > function returns, which means that the preserved p7 register (as ptrue) > has been clobbered before returning to c2 compiled code. (p7 is not > preserved cross function calls, and system calls [2]). > > Currently we try to reinitialize ptrue at each entrypoint of returning > from non-c2 compiled code, which indicating possible C or system calls. > However, there's still one entrypoint missing, exception handling, as > we may jump to c2 compiled code for exception handler. See > OptoRuntime::generate_exception_blob(). > > Adding reinitialize_ptrue before jumping back to c2 compiled code in > generate_exception_blob() could solve those Vector API test failures. > Actually I had that in my initial test patch [3], I don't know why I > missed that in final patch... I reran tests with the same approach of > [3] and found that there's still something missing, the > nmethod_entry_barrier() in c2 function prolog. The barrier may call to > runtime code (see generate_method_entry_barrier()). To reduce the risk > of missing such reinitialize_ptrue in newly added code in future, I > think it would be better to do the reinitialize in > pop_call_clobbered_registers(). > > P.S. the SIGILL message is also not clear, it should print detailed > message as indicated by MacroAssembler::stop() call. This is caused by > JDK-8255711 removing the message printing code. This patch also adds it > back, so that it could print detailed message for abort. > > Tested with tier1-3 on SVE hardware. Also verified with the same > approach of patch [3] with jtreg tests hotspot_all_no_apps and > jdk:tier1-3 passed without incorrect ptrue value assertion failure. > > [1] https://github.com/openjdk/jdk/pull/1621 > [2] https://github.com/torvalds/linux/blob/master/Documentation/arm64/sve.rst > [3] http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch Can I get a review for jdk16 please? I think the x86 pre-submit test failure is not related to this patch, which looks like the issue fixed by: https://github.com/openjdk/jdk16/pull/64 ------------- PR: https://git.openjdk.java.net/jdk16/pull/50 From github.com+16932759+shqking at openjdk.java.net Tue Jan 5 07:19:12 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Tue, 5 Jan 2021 07:19:12 GMT Subject: RFR: 8258946: Fix optimization-unstable code involving signed integer overflow [v2] In-Reply-To: References: Message-ID: > Optimization-unstable code refers to code that is unexpectedly discarded > by compiler optimizations due to undefined behavior in the program. > > We applied a static checker called STACK (prototype from SOSP'13 paper > [1]) to OpenJDK source code and found the following six sites of > potential unstable code involving signed integer overflow. > > Removing undefined behaviors would make the code stable. > > [1] https://css.csail.mit.edu/stack/ > > ----- > Note that we tested locally Jtreg tests ( tier1 and jdk::tier3) were passed on Linux x86-64/aarch64 machines after apply this patch. Hao Sun has updated the pull request incrementally with one additional commit since the last revision: Update the copyright year to 2021 Update the copyright year to 2021. Change-Id: If1c44ff5e88accb96367bec64aa58449a97a36e5 CustomizedGitHooks: yes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1900/files - new: https://git.openjdk.java.net/jdk/pull/1900/files/1df6f7cd..c3ceef68 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1900&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1900&range=00-01 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1900.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1900/head:pull/1900 PR: https://git.openjdk.java.net/jdk/pull/1900 From njian at openjdk.java.net Tue Jan 5 08:21:13 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 5 Jan 2021 08:21:13 GMT Subject: RFR: 8258813: [TESTBUG] Fix incorrect Vector API test output message [v2] In-Reply-To: References: <5sX7KaIfqVM3R1oMVcnKYjnwcq-Vm-tGUgu43Q1Rr00=.c90cc99c-65fd-47ac-9746-b63530eb1e26@github.com> Message-ID: On Tue, 5 Jan 2021 03:12:15 GMT, Xiaohong Gong wrote: >> Some vector api tests have incorrect output messages if assertion fails. The root cause is the improper use of `"org.testng.Assert.assertEqual()"`, whose definition with int type is: >> assertEquals(int actual, int expected, String message); >> >> The method needs the actual value be used as the first argument and expected value as the second one. But in some vector api tests, the two arguments are swapped. >> >> For example, here is part of the fail log in VectorReshapeTests we met: >> expect: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16] >> output: [1, 2, 3, 4, 5, 6, 7, 8, 1, 0, 0, 0, 0, 0, 0, 0] >> test VectorReshapeTests.testRebracket128(byte(i)): failure >> java.lang.AssertionError: arrays differ firstly at element [8]; expected value is <1> but was <9>. >> at org.testng.Assert.fail(Assert.java:94) >> at org.testng.Assert.assertEquals(Assert.java:774) >> ... >> >> The assertion error should be `"...expected value is <9> but was <1>."` >> >> This does not influence on the test effectiveness. However, the incorrect message is confusing which might mislead people. The simple fix is just to swap the arguments back. >> >> This patch also adjusts the arguments order of all the assertion methods to make the actual values used as the first one. Besides, it also removes two unused assertion methods. > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year to 2021 Looks good to me. ------------- Marked as reviewed by njian (Committer). PR: https://git.openjdk.java.net/jdk/pull/1922 From github.com+16932759+shqking at openjdk.java.net Tue Jan 5 08:21:58 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Tue, 5 Jan 2021 08:21:58 GMT Subject: RFR: 8258946: Fix optimization-unstable code involving signed integer overflow [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 18:28:23 GMT, Vladimir Kozlov wrote: >> Hao Sun has updated the pull request incrementally with one additional commit since the last revision: >> >> Update the copyright year to 2021 >> >> Update the copyright year to 2021. >> >> Change-Id: If1c44ff5e88accb96367bec64aa58449a97a36e5 >> CustomizedGitHooks: yes > > Good. Thanks for your review. @vnkozlov and @TobiHartmann Since the new commit only updates the copyright year and the pre-submits tests were passed for the first commit (See https://github.com/shqking/jdk/actions/runs/460991763/workflow), I suppose it's ready to merge now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1900 From github.com+16932759+shqking at openjdk.java.net Tue Jan 5 08:22:00 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Tue, 5 Jan 2021 08:22:00 GMT Subject: Integrated: 8258946: Fix optimization-unstable code involving signed integer overflow In-Reply-To: References: Message-ID: On Mon, 28 Dec 2020 10:34:30 GMT, Hao Sun wrote: > Optimization-unstable code refers to code that is unexpectedly discarded > by compiler optimizations due to undefined behavior in the program. > > We applied a static checker called STACK (prototype from SOSP'13 paper > [1]) to OpenJDK source code and found the following six sites of > potential unstable code involving signed integer overflow. > > Removing undefined behaviors would make the code stable. > > [1] https://css.csail.mit.edu/stack/ > > ----- > Note that we tested locally Jtreg tests ( tier1 and jdk::tier3) were passed on Linux x86-64/aarch64 machines after apply this patch. This pull request has now been integrated. Changeset: dd8996c5 Author: Hao Sun Committer: Ningsheng Jian URL: https://git.openjdk.java.net/jdk/commit/dd8996c5 Stats: 10 lines in 3 files changed: 0 ins; 0 del; 10 mod 8258946: Fix optimization-unstable code involving signed integer overflow Reviewed-by: thartmann, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/1900 From github.com+16932759+shqking at openjdk.java.net Tue Jan 5 08:22:58 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Tue, 5 Jan 2021 08:22:58 GMT Subject: RFR: 8258751: Improve ExceptionHandlerTable dump [v2] In-Reply-To: References: <42hRavCMVS6Mq3CVTiZ4mlI69kOGxvE4OxeEWqx6KMs=.454dc16b-f161-4f1e-bf9f-f409845afccd@github.com> Message-ID: On Tue, 5 Jan 2021 08:00:50 GMT, Christian Hagedorn wrote: >> Hao Sun has updated the pull request incrementally with one additional commit since the last revision: >> >> Update the copyright notice to 2021 >> >> Upate the copyright notice to 2021. >> >> Change-Id: I442d1e3e1774488c2806c6cc21c2db7c4db08b8f >> CustomizedGitHooks: yes > > Marked as reviewed by chagedorn (Reviewer). The pre-submit tests failed due to one GC problem, which seems not related to this patch. I suppose it's ready to merge now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1877 From chagedorn at openjdk.java.net Tue Jan 5 08:22:57 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 5 Jan 2021 08:22:57 GMT Subject: RFR: 8258751: Improve ExceptionHandlerTable dump [v2] In-Reply-To: <42hRavCMVS6Mq3CVTiZ4mlI69kOGxvE4OxeEWqx6KMs=.454dc16b-f161-4f1e-bf9f-f409845afccd@github.com> References: <42hRavCMVS6Mq3CVTiZ4mlI69kOGxvE4OxeEWqx6KMs=.454dc16b-f161-4f1e-bf9f-f409845afccd@github.com> Message-ID: On Tue, 5 Jan 2021 02:54:09 GMT, Hao Sun wrote: >> In addition to PC offset, print the real PC as well if available when >> dumping the ExceptionHandlerTable, as it's more convenient and readable >> for debugging or other activities. >> >> Note that compilers might dump the ExceptionHandlerTable before method >> registered. See functions emit_code_body() and fill_buffer(). However, >> real PC is not ready yet during these phases since the generated code is >> not installed. In such scenarios, the real PC is not printed. >> >> The example below shows how the dump information would be changed after >> applying this patch. >> BEFORE: >> ExceptionHandlerTable (size = 40 bytes) >> catch_pco = 392 (2 entries) >> bci 8 at scope depth 0 -> pco 184 >> bci 19 at scope depth 0 -> pco 124 >> AFTER: >> ExceptionHandlerTable (size = 40 bytes) >> catch_pco = 392 (pc=0x0000ffff818f13c8, 2 entries) >> bci 8 at scope depth 0 -> pco 184 (pc=0x0000ffff818f12f8) >> bci 19 at scope depth 0 -> pco 124 (pc=0x0000ffff818f12bc) > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Update the copyright notice to 2021 > > Upate the copyright notice to 2021. > > Change-Id: I442d1e3e1774488c2806c6cc21c2db7c4db08b8f > CustomizedGitHooks: yes Marked as reviewed by chagedorn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1877 From njian at openjdk.java.net Tue Jan 5 08:21:05 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 5 Jan 2021 08:21:05 GMT Subject: RFR: 8259044: JVM lacks data type qualifier when using -XX:+PrintAssembly with AArch64-Neon backend In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 03:32:44 GMT, Wang Huang wrote: > For instace: in the implentation of VectorMaskCmp & VectorStoreMask : > > $jtreg -vmoptions:"-XX:+PrintAssembly" ./Int128VectorTests.java > > Before fixing: > ----------------- > 0dc ldrq V17,[R10, #16] # vector (128 bits) > 0e0 cmeq V16, V16, V17 # vector cmp (4I) > 0e4 xtn V16, V16 # 4S to 4H > xtn V16, V16 # 4H to 4B > negr V16, V16 # store mask (4S to 4B) > ----------------- > Here? the output lacks data type qualifiers like T4S in `cmeq V16, V16, V17`. > > Expect: > ----------------- > 0dc ldrq V16,[R10, #16] # vector (128 bits) > 0e0 cmeq V16, T4S, V16, V18 # vector cmp (4I) > 0e4 xtn V16, T4H, V16, T4S # 4S to 4H > xtn V16, T8B, V16, T8H # 4H to 4B > negr V16, T8B, V16 # store mask (4S to 4B) > ----------------- Looks good to me. ------------- Marked as reviewed by njian (Committer). PR: https://git.openjdk.java.net/jdk/pull/1941 From shade at openjdk.java.net Tue Jan 5 08:29:00 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 5 Jan 2021 08:29:00 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 In-Reply-To: References: Message-ID: <07IGEyNdiB87CZXchlzhoXiv0m36gM8yc7cehVHW2t0=.41b95205-bbba-4e6f-979b-eb07fb8dfdec@github.com> On Tue, 5 Jan 2021 00:12:58 GMT, Ioi Lam wrote: >>> `#include "runtime/globals_shared.hpp"` should not be removed. compiler_globals.hpp uses the `DECLARE_FLAGS` macro, which is defined by globals_shared.hpp. >> >> Since globals_shared.hpp is included in compiler_globals_pd.hpp, I think it's fine to remove it. > > We should not rely on indirect inclusion. Otherwise, compiler_globals.hpp will break if compiler_globals_pd.hpp is changed to not include globals_shared.hpp. > > In fact, I have been fixing a lot of such problems when restructuring the header files. See https://github.com/openjdk/jdk/pull/1610 -- the vast majority of the 59 files changed in that PR were caused by relying on indirect inclusion of stubRoutines.hpp. Yes, if something is using the definitions from the header, that header should be included directly. So, the patch is just adding the `#include "compiler/compiler_globals_pd.hpp"` then, right? ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From shade at openjdk.java.net Tue Jan 5 08:28:58 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 5 Jan 2021 08:28:58 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 In-Reply-To: <7HjOk0EQl7wbAMcB-YPrZL_MzPxuexKLtWm9uxi6JFg=.cb37f275-30d7-4b82-8bcb-ea772202d967@github.com> References: <7HjOk0EQl7wbAMcB-YPrZL_MzPxuexKLtWm9uxi6JFg=.cb37f275-30d7-4b82-8bcb-ea772202d967@github.com> Message-ID: <1wQ-ufsSql4wIrUZSBnIwKQfyFYtoo3cKc8zHDEy7eo=.962cab85-5a7b-40ce-8e47-e730a679e2c9@github.com> On Tue, 5 Jan 2021 04:54:32 GMT, Hao Sun wrote: > The tests were finished but one of them failed. I found that this failure existed for several days (in other PRs) and I suppose it's not related to our patch. Yes, the failure you caught does not look related to this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From njian at openjdk.java.net Tue Jan 5 08:32:58 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 5 Jan 2021 08:32:58 GMT Subject: RFR: 8258751: Improve ExceptionHandlerTable dump [v2] In-Reply-To: References: <42hRavCMVS6Mq3CVTiZ4mlI69kOGxvE4OxeEWqx6KMs=.454dc16b-f161-4f1e-bf9f-f409845afccd@github.com> Message-ID: On Tue, 5 Jan 2021 08:20:33 GMT, Hao Sun wrote: > The pre-submit tests failed due to one GC problem, which seems not related to this patch. I think that's JDK-8258481. ------------- PR: https://git.openjdk.java.net/jdk/pull/1877 From github.com+16932759+shqking at openjdk.java.net Tue Jan 5 08:33:00 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Tue, 5 Jan 2021 08:33:00 GMT Subject: Integrated: 8258751: Improve ExceptionHandlerTable dump In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 10:16:29 GMT, Hao Sun wrote: > In addition to PC offset, print the real PC as well if available when > dumping the ExceptionHandlerTable, as it's more convenient and readable > for debugging or other activities. > > Note that compilers might dump the ExceptionHandlerTable before method > registered. See functions emit_code_body() and fill_buffer(). However, > real PC is not ready yet during these phases since the generated code is > not installed. In such scenarios, the real PC is not printed. > > The example below shows how the dump information would be changed after > applying this patch. > BEFORE: > ExceptionHandlerTable (size = 40 bytes) > catch_pco = 392 (2 entries) > bci 8 at scope depth 0 -> pco 184 > bci 19 at scope depth 0 -> pco 124 > AFTER: > ExceptionHandlerTable (size = 40 bytes) > catch_pco = 392 (pc=0x0000ffff818f13c8, 2 entries) > bci 8 at scope depth 0 -> pco 184 (pc=0x0000ffff818f12f8) > bci 19 at scope depth 0 -> pco 124 (pc=0x0000ffff818f12bc) This pull request has now been integrated. Changeset: 17d1645e Author: Hao Sun Committer: Ningsheng Jian URL: https://git.openjdk.java.net/jdk/commit/17d1645e Stats: 21 lines in 3 files changed: 10 ins; 0 del; 11 mod 8258751: Improve ExceptionHandlerTable dump Reviewed-by: thartmann, chagedorn, njian ------------- PR: https://git.openjdk.java.net/jdk/pull/1877 From shade at openjdk.java.net Tue Jan 5 08:39:53 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 5 Jan 2021 08:39:53 GMT Subject: Integrated: 8251944: Add Shenandoah test config to compiler/gcbarriers/UnsafeIntrinsicsTest.java In-Reply-To: References: Message-ID: <9o8BbtcVezKGIMDLxEYE1UfSjRHvgTtdlvBS3qykk4w=.bc09e436-3596-459f-8511-9298e3cf3f60@github.com> On Tue, 8 Dec 2020 10:42:08 GMT, Aleksey Shipilev wrote: > There used to be failures in Shenandoah CAS handling code like that were caught by this test. Those were fixed in JDK-8255401. This change turns the test into regression test for it. > > Additional testing: > - [x] Affected test on `x86_64` fastdebug, release > - [x] Affected test on `x86_32` fastdebug > - [x] Affected test on `aarch64` fastdebug This pull request has now been integrated. Changeset: db6f3930 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/db6f3930 Stats: 24 lines in 1 file changed: 22 ins; 0 del; 2 mod 8251944: Add Shenandoah test config to compiler/gcbarriers/UnsafeIntrinsicsTest.java Reviewed-by: rkennke, adityam ------------- PR: https://git.openjdk.java.net/jdk/pull/1693 From thartmann at openjdk.java.net Tue Jan 5 08:59:55 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 5 Jan 2021 08:59:55 GMT Subject: RFR: 8259049: Uninitialized variable after JDK-8257513 In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 11:07:14 GMT, Christian Hagedorn wrote: > Fixing missing initialization to prevent possible compiler warnings. The initialization is not required for correctness, though. > > Thanks, > Christian Marked as reviewed by thartmann (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1930 From thartmann at openjdk.java.net Tue Jan 5 09:03:04 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 5 Jan 2021 09:03:04 GMT Subject: RFR: 8255216: ciEnv::_break_at_compile isn't in use In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 18:35:53 GMT, Dan wrote: >> src/hotspot/share/compiler/compileBroker.cpp line 2227: >> >>> 2225: } >>> 2226: >>> 2227: should_break = directive->BreakAtExecuteOption || task->check_break_at_flags(); >> >> CompileTask::check_break_at_flags is dead code too, and CIBreakAtOSR, CIBreakAt >> they are all defunct right now. > > I wasn't sure whether or not we wanted to roll the removal of all dead code into this issue or just _break_at_compile. The JBS issue specifically mentions _break_at_compile so that's what I removed here - can expand to do other stuff if you think it's a good idea. I think it's fine to remove all that dead code with this issue ------------- PR: https://git.openjdk.java.net/jdk/pull/1806 From chagedorn at openjdk.java.net Tue Jan 5 09:52:00 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 5 Jan 2021 09:52:00 GMT Subject: [jdk16] RFR: 8258619: -XX:CompileCommand=blackhole, * should only accept empty static methods In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 17:58:12 GMT, Aleksey Shipilev wrote: > In JDK-8257827 CSR, a further comment was raised about changing the semantics of the method. This allegedly introduces the conformance problem. While it is still an open question where the conformance problem is real, we can sidestep the entire issue by allowing only empty static methods to be blackholed. This eliminates any behavioral difference: empty methods have no side effects, and static methods do not need any null checks. > > This change eliminates a lot of new code added by original JDK-8252505 push, mostly now-useless testing code. It adds two more tests that verify that non-empty and non-static methods are properly rejected. Looks good to me! ------------- Marked as reviewed by chagedorn (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/45 From chagedorn at openjdk.java.net Tue Jan 5 09:57:55 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 5 Jan 2021 09:57:55 GMT Subject: RFR: 8259049: Uninitialized variable after JDK-8257513 In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 18:45:30 GMT, Vladimir Kozlov wrote: >> Fixing missing initialization to prevent possible compiler warnings. The initialization is not required for correctness, though. >> >> Thanks, >> Christian > > Trivial. Thanks @vnkozlov and @TobiHartmann ! ------------- PR: https://git.openjdk.java.net/jdk/pull/1930 From chagedorn at openjdk.java.net Tue Jan 5 09:57:56 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 5 Jan 2021 09:57:56 GMT Subject: Integrated: 8259049: Uninitialized variable after JDK-8257513 In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 11:07:14 GMT, Christian Hagedorn wrote: > Fixing missing initialization to prevent possible compiler warnings. The initialization is not required for correctness, though. > > Thanks, > Christian This pull request has now been integrated. Changeset: 9f151649 Author: Christian Hagedorn URL: https://git.openjdk.java.net/jdk/commit/9f151649 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8259049: Uninitialized variable after JDK-8257513 Reviewed-by: kvn, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/1930 From xliu at openjdk.java.net Tue Jan 5 10:11:11 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 5 Jan 2021 10:11:11 GMT Subject: RFR: 8258961: devirtualize SafePointNode::jvms() and hide out set_jvms() [v2] In-Reply-To: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> Message-ID: > SafePointNode::jvms() declares virtual but has never been overridden. It seems unnecessary. > The member variable _jvms declares 'JVMState* const', but set_jvms() updates its value anyway. > Geting rid of the const qualifier and hides if out using protected. Xin Liu has updated the pull request incrementally with one additional commit since the last revision: 8258961: devirtualize SafePointNode::jvms() and hide out set_jvms() devirtualize SafePointNode::jvms(). We can't hide the member variable _jvms because it is exposed to HotSpot Servicability agent. keeping the qualifier const for the same resaon. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1899/files - new: https://git.openjdk.java.net/jdk/pull/1899/files/bdbeda12..b42b4689 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1899&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1899&range=00-01 Stats: 33 lines in 5 files changed: 11 ins; 13 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/1899.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1899/head:pull/1899 PR: https://git.openjdk.java.net/jdk/pull/1899 From xliu at openjdk.java.net Tue Jan 5 10:16:04 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 5 Jan 2021 10:16:04 GMT Subject: RFR: 8258961: devirtualize SafePointNode::jvms() and hide out set_jvms() [v2] In-Reply-To: <3ETfgMZjD6Raek1gMbHa_hCCyFMgyoCLS7FwFcAsWfE=.3d5b7811-85e7-48d5-a6f3-fe8654b91fdd@github.com> References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> <3ETfgMZjD6Raek1gMbHa_hCCyFMgyoCLS7FwFcAsWfE=.3d5b7811-85e7-48d5-a6f3-fe8654b91fdd@github.com> Message-ID: On Mon, 4 Jan 2021 07:19:55 GMT, Tobias Hartmann wrote: >> Xin Liu has updated the pull request incrementally with one additional commit since the last revision: >> >> 8258961: devirtualize SafePointNode::jvms() and hide out set_jvms() >> >> devirtualize SafePointNode::jvms(). We can't hide the member variable _jvms >> because it is exposed to HotSpot Servicability agent. keeping the qualifier >> const for the same resaon. > > src/hotspot/share/opto/callnode.hpp line 336: > >> 334: JVMState* _jvms; // Pointer to list of JVM State objects >> 335: void set_jvms(JVMState* s) { >> 336: _jvms = s; // override const attribute in the accessor > > The comment should be adjusted since `_jvms` is not const anymore. thank you for reviewing this. Vladimir helped me to understand the hotspot Servicability agent thing, which needs to access this field. I have to revert this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/1899 From xliu at openjdk.java.net Tue Jan 5 10:16:01 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 5 Jan 2021 10:16:01 GMT Subject: RFR: 8258961: devirtualize SafePointNode::jvms() and hide out set_jvms() [v2] In-Reply-To: References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> Message-ID: On Mon, 4 Jan 2021 18:39:17 GMT, Vladimir Kozlov wrote: >> Xin Liu has updated the pull request incrementally with one additional commit since the last revision: >> >> 8258961: devirtualize SafePointNode::jvms() and hide out set_jvms() >> >> devirtualize SafePointNode::jvms(). We can't hide the member variable _jvms >> because it is exposed to HotSpot Servicability agent. keeping the qualifier >> const for the same resaon. > > src/hotspot/share/runtime/vmStructs.cpp line 945: > >> 943: \ >> 944: c2_nonstatic_field(SafePointNode, _jvms, JVMState* const) \ >> 945: \ > > Don't remove it. It is referenced from HotSpot Servicability agent: > https://github.com/openjdk/jdk/blob/master/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/SafePointNode.java#L45 Thank you for pointing out this. I wasn't aware of this agent thing. It turns out I can neither move SafePointNode::_jvms to the protected zone nor take off its const qualifier. so I revert my changes except removing "virtual" for the SafePointNode::jvms(). ------------- PR: https://git.openjdk.java.net/jdk/pull/1899 From adinn at openjdk.java.net Tue Jan 5 10:43:55 2021 From: adinn at openjdk.java.net (Andrew Dinn) Date: Tue, 5 Jan 2021 10:43:55 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 05:44:36 GMT, Ningsheng Jian wrote: >> After applying [1], some Vector API tests fail with SIGILL on SVE >> system. The SIGILL was triggered by verify_ptrue before c2 compiled >> function returns, which means that the preserved p7 register (as ptrue) >> has been clobbered before returning to c2 compiled code. (p7 is not >> preserved cross function calls, and system calls [2]). >> >> Currently we try to reinitialize ptrue at each entrypoint of returning >> from non-c2 compiled code, which indicating possible C or system calls. >> However, there's still one entrypoint missing, exception handling, as >> we may jump to c2 compiled code for exception handler. See >> OptoRuntime::generate_exception_blob(). >> >> Adding reinitialize_ptrue before jumping back to c2 compiled code in >> generate_exception_blob() could solve those Vector API test failures. >> Actually I had that in my initial test patch [3], I don't know why I >> missed that in final patch... I reran tests with the same approach of >> [3] and found that there's still something missing, the >> nmethod_entry_barrier() in c2 function prolog. The barrier may call to >> runtime code (see generate_method_entry_barrier()). To reduce the risk >> of missing such reinitialize_ptrue in newly added code in future, I >> think it would be better to do the reinitialize in >> pop_call_clobbered_registers(). >> >> P.S. the SIGILL message is also not clear, it should print detailed >> message as indicated by MacroAssembler::stop() call. This is caused by >> JDK-8255711 removing the message printing code. This patch also adds it >> back, so that it could print detailed message for abort. >> >> Tested with tier1-3 on SVE hardware. Also verified with the same >> approach of patch [3] with jtreg tests hotspot_all_no_apps and >> jdk:tier1-3 passed without incorrect ptrue value assertion failure. >> >> [1] https://github.com/openjdk/jdk/pull/1621 >> [2] https://github.com/torvalds/linux/blob/master/Documentation/arm64/sve.rst >> [3] http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch > > Can I get a review for jdk16 please? > > I think the x86 pre-submit test failure is not related to this patch, which looks like the issue fixed by: https://github.com/openjdk/jdk16/pull/64 Hi Ningsheng, The SVE changes look ok. I'm just unsure about restoring the exit in the signal handler. ------------- PR: https://git.openjdk.java.net/jdk16/pull/50 From adinn at openjdk.java.net Tue Jan 5 10:43:58 2021 From: adinn at openjdk.java.net (Andrew Dinn) Date: Tue, 5 Jan 2021 10:43:58 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests [v2] In-Reply-To: <9XtCnqp4eKcBDXlXSm18R6tUIH9mCPZUZJE3Htio2Bs=.606bf77d-fec8-434a-b1e9-6cb5484605a1@github.com> References: <9XtCnqp4eKcBDXlXSm18R6tUIH9mCPZUZJE3Htio2Bs=.606bf77d-fec8-434a-b1e9-6cb5484605a1@github.com> Message-ID: <4wsrcJIZMSQcI-bEYswi7vI4MznlHMCuYkxCFjzY6S4=.ec088b95-496c-4ecc-98a7-e239c7247348@github.com> On Tue, 5 Jan 2021 02:57:15 GMT, Ningsheng Jian wrote: >> After applying [1], some Vector API tests fail with SIGILL on SVE >> system. The SIGILL was triggered by verify_ptrue before c2 compiled >> function returns, which means that the preserved p7 register (as ptrue) >> has been clobbered before returning to c2 compiled code. (p7 is not >> preserved cross function calls, and system calls [2]). >> >> Currently we try to reinitialize ptrue at each entrypoint of returning >> from non-c2 compiled code, which indicating possible C or system calls. >> However, there's still one entrypoint missing, exception handling, as >> we may jump to c2 compiled code for exception handler. See >> OptoRuntime::generate_exception_blob(). >> >> Adding reinitialize_ptrue before jumping back to c2 compiled code in >> generate_exception_blob() could solve those Vector API test failures. >> Actually I had that in my initial test patch [3], I don't know why I >> missed that in final patch... I reran tests with the same approach of >> [3] and found that there's still something missing, the >> nmethod_entry_barrier() in c2 function prolog. The barrier may call to >> runtime code (see generate_method_entry_barrier()). To reduce the risk >> of missing such reinitialize_ptrue in newly added code in future, I >> think it would be better to do the reinitialize in >> pop_call_clobbered_registers(). >> >> P.S. the SIGILL message is also not clear, it should print detailed >> message as indicated by MacroAssembler::stop() call. This is caused by >> JDK-8255711 removing the message printing code. This patch also adds it >> back, so that it could print detailed message for abort. >> >> Tested with tier1-3 on SVE hardware. Also verified with the same >> approach of patch [3] with jtreg tests hotspot_all_no_apps and >> jdk:tier1-3 passed without incorrect ptrue value assertion failure. >> >> [1] https://github.com/openjdk/jdk/pull/1621 >> [2] https://github.com/torvalds/linux/blob/master/Documentation/arm64/sve.rst >> [3] http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch > > Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year to 2021. src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp line 252: > 250: pc, info, NULL, NULL, 0, 0); > 251: va_end(detail_args); > 252: } I'm not sure it is ok to revert this code. The fix this is part of (for JDK-8255711) was provided explicitly to re-organize the flow of control for handling of fatal errors. Reverting this code appears to undermine the goal of that issue. I would like to get Thomas Stuefe's (@tstuefe) opinion on whether it is appropriate to abort the JVM here vs returning false before accepting this specific change. ------------- PR: https://git.openjdk.java.net/jdk16/pull/50 From njian at openjdk.java.net Tue Jan 5 10:50:56 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 5 Jan 2021 10:50:56 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests In-Reply-To: References: Message-ID: <8c_83PwGl5YuRXbdHF2x0M9UrZocHav7peSPbQzPwuQ=.e8badd95-09ca-46c4-95e3-6479cab080c8@github.com> On Tue, 5 Jan 2021 10:41:40 GMT, Andrew Dinn wrote: > Hi Ningsheng, > > The SVE changes look ok. I'm just unsure about restoring the exit in the signal handler. Thank you @adinn for the review! @tstuefe would you mind helping to review the lines @adinn mentioned? Thanks! ------------- PR: https://git.openjdk.java.net/jdk16/pull/50 From aph at openjdk.java.net Tue Jan 5 11:21:57 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 5 Jan 2021 11:21:57 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 03:43:15 GMT, Dong Bo wrote: >> This patch optimizes vectorial Min/Max reduction of two floating-point numbers on aarch64 with NEON instructions `fmaxp` and `fminp`. >> >> Passed jtreg tier1-3 tests with `linux-aarch64-server-fastdebug` build. >> Tests under `test/jdk/jdk/incubator/vector/` runned specially for the correctness and passed. >> >> Introduced a new JMH micro `test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java` for performance test. >> Witnessed abount `37%` performance improvements on Kunpeng916. The JMH Results: >> Benchmark (COUNT) (seed) Mode Cnt Score Error Units >> # Kunpeng 916, default >> VectorReduction.maxRedD 512 0 avgt 10 678.126 ? 0.815 ns/op >> VectorReduction.maxRedF 512 0 avgt 10 242.958 ? 0.212 ns/op >> VectorReduction.minRedD 512 0 avgt 10 678.554 ? 0.824 ns/op >> VectorReduction.minRedF 512 0 avgt 10 243.368 ? 0.205 ns/op >> >> # Kunpeng 916, with fmaxp/fminp >> VectorReduction.maxRedD 512 0 avgt 10 430.201 ? 0.353 ns/op => 36.56% >> VectorReduction.maxRedF 512 0 avgt 10 243.404 ? 0.297 ns/op >> VectorReduction.minRedD 512 0 avgt 10 427.805 ? 0.528 ns/op => 36.89% >> VectorReduction.minRedF 512 0 avgt 10 242.963 ? 0.210 ns/op > > Dong Bo has updated the pull request incrementally with one additional commit since the last revision: > > rebase the .m4 entry This all looks reasonable. With the assembler change I think we should be good to go. src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 2451: > 2449: #undef INSN > 2450: > 2451: #define INSN(NAME, opc) \ This should be in an "AdvSIMD scalar pairwise" instruction group with faddp. ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From thartmann at openjdk.java.net Tue Jan 5 11:59:59 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 5 Jan 2021 11:59:59 GMT Subject: [jdk16] RFR: 8258393: Shenandoah: "graph should be schedulable" assert failure In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 08:20:20 GMT, Roland Westrelin wrote: > This is a shenandoah bug but the fix is in shared code. > > At barrier expansion time, we need the raw memory state for the > control at which the barrier is expanded. Before expansion, the memory > graph is traversed and memory state for each control is recorded. In > that process, if opportunities to improve the memory graph are found, > the graph is modified. In the case of the failure, a raw memory load > was assigned a call projection as control but for that control, no > memory state was recorded and the fall back is to use the call's input > memory state. As a consequence the load's memory input is updated to a > wrong memory state. This causes the assert failure. > > The call has 2 memory projections: one for the fallthrough and one for > the exception path. One projection is the memory state for the > CatchProj for the fallthrough, the other one for the CatchProj of the > exception path. For the control projection out of the call, there's no > memory state that makes sense and assigning the control projection of > the call as control for the load is the root cause of the > problem. This happens because anti-dependence analysis is too > conservative: a memory Phi that merges states from the exception and > fallthrough path is considered a dependency and that pushed the load > right after the call. > > I propose to be less conservative in anti-dependence analysis for > Phis. For a Phi, when computing the LCA, I think it's sufficient to > only consider region's inputs that we actually reach by following the > memory edges and that's what I propose here. Otherwise looks reasonable to me. test/hotspot/jtreg/gc/shenandoah/compiler/TestBadRawMemoryAfterCall.java line 26: > 24: /** > 25: * @test > 26: * Missing `@requires vm.gc.Shenandoah` test/hotspot/jtreg/gc/shenandoah/compiler/TestBadRawMemoryAfterCall.java line 2: > 1: /* > 2: * Copyright (c) 2020, Red Hat, Inc. All rights reserved. Copyright should be updated to 2021. src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp line 2465: > 2463: #ifdef ASSERT > 2464: if ((ctrl->is_Proj() && ctrl->in(0)->is_Call()) || > 2465: (ctrl->is_Catch() && ctrl->in(0)->in(0)->is_Call())){ Indentation is wrong and whitespace is missing here `))){` src/hotspot/share/opto/loopnode.cpp line 5023: > 5021: Node* in = s->in(j); > 5022: Node* r_in = r->in(j); > 5023: if (worklist.member(in) && is_dominator(early, r_in)) { Above we check for `!sctrl->is_top()`, do we need the same check for `r_in`? ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/41 From jiefu at openjdk.java.net Tue Jan 5 12:06:19 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 5 Jan 2021 12:06:19 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 12:03:39 GMT, Hao Sun wrote: >> From the error log we can see the root cause is that, develop_pd flag >> 'pd_CICompileOSR' is undeclared in zero build. >> >> Where this flag is used? >> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77 >> of 'compiler_globals.hpp' and further line 86 of 'globals_shared.hpp'. >> >> Where this flag can be declared? >> Header files 'c1_globals.hpp' or 'c2_globals.hpp' would be included if >> VM is built with compiler1 or compiler2. See lines 30 to 38 of >> 'complier_globals.hpp'. And further, flag 'pd_CICompileOSR' may get >> declared in the header files for specific arch, e.g., >> 'c1_globals_aarch64.hpp', 'c2_globals_aarch64.hpp'. >> However, regarding zero build (without compiler1 and compiler2 and >> jvmci) , this flag is undelcared. Hence, this patch gets header file >> 'compiler/compiler_globals_pd.hpp' included where this flag is declared >> for the case when neither COMPILER1 nor COMPILER2 are defined and >> INCLUDE_JVMCI is inactive. >> >> Note that 'compiler/compiler_globals_pd.hpp' already includes >> 'runtime/globals_shared.hpp'. >> >> Note that zero build with PCH succeeds because 'runtime/globals.hpp' is >> included in 'precompiled.hpp', and further 'compiler_globals_pd.hpp' is >> included in 'runtime/globals.hpp'. > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Header 'runtime/globals_shared.hpp' should be kept > > Header 'runtime/globals_shared.hpp' is kept even though > 'compiler/compiler_globals_pd.hpp' already includes it, because > 'compiler_globals.hpp' uses the DECLARE_FLAGS macro, which is defined by > 'runtime/globals_shared.hpp', and it should be included directly. > > Besides, update the copyright year to 2021. > > Change-Id: Ia355f3b6e98b495dc265093e71b2d1fec1ca45ca > CustomizedGitHooks: yes Marked as reviewed by jiefu (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From github.com+16932759+shqking at openjdk.java.net Tue Jan 5 12:06:18 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Tue, 5 Jan 2021 12:06:18 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 [v2] In-Reply-To: References: Message-ID: > From the error log we can see the root cause is that, develop_pd flag > 'pd_CICompileOSR' is undeclared in zero build. > > Where this flag is used? > Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77 > of 'compiler_globals.hpp' and further line 86 of 'globals_shared.hpp'. > > Where this flag can be declared? > Header files 'c1_globals.hpp' or 'c2_globals.hpp' would be included if > VM is built with compiler1 or compiler2. See lines 30 to 38 of > 'complier_globals.hpp'. And further, flag 'pd_CICompileOSR' may get > declared in the header files for specific arch, e.g., > 'c1_globals_aarch64.hpp', 'c2_globals_aarch64.hpp'. > However, regarding zero build (without compiler1 and compiler2 and > jvmci) , this flag is undelcared. Hence, this patch gets header file > 'compiler/compiler_globals_pd.hpp' included where this flag is declared > for the case when neither COMPILER1 nor COMPILER2 are defined and > INCLUDE_JVMCI is inactive. > > Note that 'compiler/compiler_globals_pd.hpp' already includes > 'runtime/globals_shared.hpp'. > > Note that zero build with PCH succeeds because 'runtime/globals.hpp' is > included in 'precompiled.hpp', and further 'compiler_globals_pd.hpp' is > included in 'runtime/globals.hpp'. Hao Sun has updated the pull request incrementally with one additional commit since the last revision: Header 'runtime/globals_shared.hpp' should be kept Header 'runtime/globals_shared.hpp' is kept even though 'compiler/compiler_globals_pd.hpp' already includes it, because 'compiler_globals.hpp' uses the DECLARE_FLAGS macro, which is defined by 'runtime/globals_shared.hpp', and it should be included directly. Besides, update the copyright year to 2021. Change-Id: Ia355f3b6e98b495dc265093e71b2d1fec1ca45ca CustomizedGitHooks: yes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1894/files - new: https://git.openjdk.java.net/jdk/pull/1894/files/0cc564bd..f3cd5181 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1894&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1894&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1894.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1894/head:pull/1894 PR: https://git.openjdk.java.net/jdk/pull/1894 From github.com+16932759+shqking at openjdk.java.net Tue Jan 5 12:09:56 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Tue, 5 Jan 2021 12:09:56 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 00:12:58 GMT, Ioi Lam wrote: >>> `#include "runtime/globals_shared.hpp"` should not be removed. compiler_globals.hpp uses the `DECLARE_FLAGS` macro, which is defined by globals_shared.hpp. >> >> Since globals_shared.hpp is included in compiler_globals_pd.hpp, I think it's fine to remove it. > > We should not rely on indirect inclusion. Otherwise, compiler_globals.hpp will break if compiler_globals_pd.hpp is changed to not include globals_shared.hpp. > > In fact, I have been fixing a lot of such problems when restructuring the header files. See https://github.com/openjdk/jdk/pull/1610 -- the vast majority of the 59 files changed in that PR were caused by relying on indirect inclusion of stubRoutines.hpp. Patch is updated: 1) keeping `runtime/globals_shared.hpp' included directly and 2) updating the copyright year to 2021. Could you please help to review it? @iklam @shipilev Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From iklam at openjdk.java.net Tue Jan 5 12:17:02 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 5 Jan 2021 12:17:02 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 12:06:18 GMT, Hao Sun wrote: >> From the error log we can see the root cause is that, develop_pd flag >> 'pd_CICompileOSR' is undeclared in zero build. >> >> Where this flag is used? >> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77 >> of 'compiler_globals.hpp' and further line 86 of 'globals_shared.hpp'. >> >> Where this flag can be declared? >> Header files 'c1_globals.hpp' or 'c2_globals.hpp' would be included if >> VM is built with compiler1 or compiler2. See lines 30 to 38 of >> 'complier_globals.hpp'. And further, flag 'pd_CICompileOSR' may get >> declared in the header files for specific arch, e.g., >> 'c1_globals_aarch64.hpp', 'c2_globals_aarch64.hpp'. >> However, regarding zero build (without compiler1 and compiler2 and >> jvmci) , this flag is undelcared. Hence, this patch gets header file >> 'compiler/compiler_globals_pd.hpp' included where this flag is declared >> for the case when neither COMPILER1 nor COMPILER2 are defined and >> INCLUDE_JVMCI is inactive. >> >> Note that 'compiler/compiler_globals_pd.hpp' already includes >> 'runtime/globals_shared.hpp'. >> >> Note that zero build with PCH succeeds because 'runtime/globals.hpp' is >> included in 'precompiled.hpp', and further 'compiler_globals_pd.hpp' is >> included in 'runtime/globals.hpp'. > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Header 'runtime/globals_shared.hpp' should be kept > > Header 'runtime/globals_shared.hpp' is kept even though > 'compiler/compiler_globals_pd.hpp' already includes it, because > 'compiler_globals.hpp' uses the DECLARE_FLAGS macro, which is defined by > 'runtime/globals_shared.hpp', and it should be included directly. > > Besides, update the copyright year to 2021. > > Change-Id: Ia355f3b6e98b495dc265093e71b2d1fec1ca45ca > CustomizedGitHooks: yes LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1894 From shade at openjdk.java.net Tue Jan 5 12:17:01 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 5 Jan 2021 12:17:01 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 12:06:18 GMT, Hao Sun wrote: >> From the error log we can see the root cause is that, develop_pd flag >> 'pd_CICompileOSR' is undeclared in zero build. >> >> Where this flag is used? >> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77 >> of 'compiler_globals.hpp' and further line 86 of 'globals_shared.hpp'. >> >> Where this flag can be declared? >> Header files 'c1_globals.hpp' or 'c2_globals.hpp' would be included if >> VM is built with compiler1 or compiler2. See lines 30 to 38 of >> 'complier_globals.hpp'. And further, flag 'pd_CICompileOSR' may get >> declared in the header files for specific arch, e.g., >> 'c1_globals_aarch64.hpp', 'c2_globals_aarch64.hpp'. >> However, regarding zero build (without compiler1 and compiler2 and >> jvmci) , this flag is undelcared. Hence, this patch gets header file >> 'compiler/compiler_globals_pd.hpp' included where this flag is declared >> for the case when neither COMPILER1 nor COMPILER2 are defined and >> INCLUDE_JVMCI is inactive. >> >> Note that 'compiler/compiler_globals_pd.hpp' already includes >> 'runtime/globals_shared.hpp'. >> >> Note that zero build with PCH succeeds because 'runtime/globals.hpp' is >> included in 'precompiled.hpp', and further 'compiler_globals_pd.hpp' is >> included in 'runtime/globals.hpp'. > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Header 'runtime/globals_shared.hpp' should be kept > > Header 'runtime/globals_shared.hpp' is kept even though > 'compiler/compiler_globals_pd.hpp' already includes it, because > 'compiler_globals.hpp' uses the DECLARE_FLAGS macro, which is defined by > 'runtime/globals_shared.hpp', and it should be included directly. > > Besides, update the copyright year to 2021. > > Change-Id: Ia355f3b6e98b495dc265093e71b2d1fec1ca45ca > CustomizedGitHooks: yes This looks fine to me, but @iklam should approve. ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From shade at openjdk.java.net Tue Jan 5 12:19:57 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 5 Jan 2021 12:19:57 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 [v2] In-Reply-To: References: Message-ID: <4rHg312dxhxqEjOcUre5nFomMw6LKC_5IzXJCa6rTYM=.6f73c059-dc04-4b31-98f7-6e2b102db4bf@github.com> On Tue, 5 Jan 2021 12:06:18 GMT, Hao Sun wrote: >> From the error log we can see the root cause is that, develop_pd flag >> 'pd_CICompileOSR' is undeclared in zero build. >> >> Where this flag is used? >> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77 >> of 'compiler_globals.hpp' and further line 86 of 'globals_shared.hpp'. >> >> Where this flag can be declared? >> Header files 'c1_globals.hpp' or 'c2_globals.hpp' would be included if >> VM is built with compiler1 or compiler2. See lines 30 to 38 of >> 'complier_globals.hpp'. And further, flag 'pd_CICompileOSR' may get >> declared in the header files for specific arch, e.g., >> 'c1_globals_aarch64.hpp', 'c2_globals_aarch64.hpp'. >> However, regarding zero build (without compiler1 and compiler2 and >> jvmci) , this flag is undelcared. Hence, this patch gets header file >> 'compiler/compiler_globals_pd.hpp' included where this flag is declared >> for the case when neither COMPILER1 nor COMPILER2 are defined and >> INCLUDE_JVMCI is inactive. >> >> Note that 'compiler/compiler_globals_pd.hpp' already includes >> 'runtime/globals_shared.hpp'. >> >> Note that zero build with PCH succeeds because 'runtime/globals.hpp' is >> included in 'precompiled.hpp', and further 'compiler_globals_pd.hpp' is >> included in 'runtime/globals.hpp'. > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Header 'runtime/globals_shared.hpp' should be kept > > Header 'runtime/globals_shared.hpp' is kept even though > 'compiler/compiler_globals_pd.hpp' already includes it, because > 'compiler_globals.hpp' uses the DECLARE_FLAGS macro, which is defined by > 'runtime/globals_shared.hpp', and it should be included directly. > > Besides, update the copyright year to 2021. > > Change-Id: Ia355f3b6e98b495dc265093e71b2d1fec1ca45ca > CustomizedGitHooks: yes Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From roland at openjdk.java.net Tue Jan 5 12:42:58 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Tue, 5 Jan 2021 12:42:58 GMT Subject: [jdk16] RFR: 8258393: Shenandoah: "graph should be schedulable" assert failure In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 11:54:07 GMT, Tobias Hartmann wrote: >> This is a shenandoah bug but the fix is in shared code. >> >> At barrier expansion time, we need the raw memory state for the >> control at which the barrier is expanded. Before expansion, the memory >> graph is traversed and memory state for each control is recorded. In >> that process, if opportunities to improve the memory graph are found, >> the graph is modified. In the case of the failure, a raw memory load >> was assigned a call projection as control but for that control, no >> memory state was recorded and the fall back is to use the call's input >> memory state. As a consequence the load's memory input is updated to a >> wrong memory state. This causes the assert failure. >> >> The call has 2 memory projections: one for the fallthrough and one for >> the exception path. One projection is the memory state for the >> CatchProj for the fallthrough, the other one for the CatchProj of the >> exception path. For the control projection out of the call, there's no >> memory state that makes sense and assigning the control projection of >> the call as control for the load is the root cause of the >> problem. This happens because anti-dependence analysis is too >> conservative: a memory Phi that merges states from the exception and >> fallthrough path is considered a dependency and that pushed the load >> right after the call. >> >> I propose to be less conservative in anti-dependence analysis for >> Phis. For a Phi, when computing the LCA, I think it's sufficient to >> only consider region's inputs that we actually reach by following the >> memory edges and that's what I propose here. > > src/hotspot/share/opto/loopnode.cpp line 5023: > >> 5021: Node* in = s->in(j); >> 5022: Node* r_in = r->in(j); >> 5023: if (worklist.member(in) && is_dominator(early, r_in)) { > > Above we check for `!sctrl->is_top()`, do we need the same check for `r_in`? I don't think a Region can have a top input at this point (previous IGVN should have taken care of it). ------------- PR: https://git.openjdk.java.net/jdk16/pull/41 From roland at openjdk.java.net Tue Jan 5 13:00:10 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Tue, 5 Jan 2021 13:00:10 GMT Subject: [jdk16] RFR: 8258393: Shenandoah: "graph should be schedulable" assert failure [v2] In-Reply-To: References: Message-ID: > This is a shenandoah bug but the fix is in shared code. > > At barrier expansion time, we need the raw memory state for the > control at which the barrier is expanded. Before expansion, the memory > graph is traversed and memory state for each control is recorded. In > that process, if opportunities to improve the memory graph are found, > the graph is modified. In the case of the failure, a raw memory load > was assigned a call projection as control but for that control, no > memory state was recorded and the fall back is to use the call's input > memory state. As a consequence the load's memory input is updated to a > wrong memory state. This causes the assert failure. > > The call has 2 memory projections: one for the fallthrough and one for > the exception path. One projection is the memory state for the > CatchProj for the fallthrough, the other one for the CatchProj of the > exception path. For the control projection out of the call, there's no > memory state that makes sense and assigning the control projection of > the call as control for the load is the root cause of the > problem. This happens because anti-dependence analysis is too > conservative: a memory Phi that merges states from the exception and > fallthrough path is considered a dependency and that pushed the load > right after the call. > > I propose to be less conservative in anti-dependence analysis for > Phis. For a Phi, when computing the LCA, I think it's sufficient to > only consider region's inputs that we actually reach by following the > memory edges and that's what I propose here. Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - review - test & fix ------------- Changes: https://git.openjdk.java.net/jdk16/pull/41/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=41&range=01 Stats: 114 lines in 3 files changed: 107 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk16/pull/41.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/41/head:pull/41 PR: https://git.openjdk.java.net/jdk16/pull/41 From thartmann at openjdk.java.net Tue Jan 5 13:05:57 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 5 Jan 2021 13:05:57 GMT Subject: [jdk16] RFR: 8258393: Shenandoah: "graph should be schedulable" assert failure [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 13:00:10 GMT, Roland Westrelin wrote: >> This is a shenandoah bug but the fix is in shared code. >> >> At barrier expansion time, we need the raw memory state for the >> control at which the barrier is expanded. Before expansion, the memory >> graph is traversed and memory state for each control is recorded. In >> that process, if opportunities to improve the memory graph are found, >> the graph is modified. In the case of the failure, a raw memory load >> was assigned a call projection as control but for that control, no >> memory state was recorded and the fall back is to use the call's input >> memory state. As a consequence the load's memory input is updated to a >> wrong memory state. This causes the assert failure. >> >> The call has 2 memory projections: one for the fallthrough and one for >> the exception path. One projection is the memory state for the >> CatchProj for the fallthrough, the other one for the CatchProj of the >> exception path. For the control projection out of the call, there's no >> memory state that makes sense and assigning the control projection of >> the call as control for the load is the root cause of the >> problem. This happens because anti-dependence analysis is too >> conservative: a memory Phi that merges states from the exception and >> fallthrough path is considered a dependency and that pushed the load >> right after the call. >> >> I propose to be less conservative in anti-dependence analysis for >> Phis. For a Phi, when computing the LCA, I think it's sufficient to >> only consider region's inputs that we actually reach by following the >> memory edges and that's what I propose here. > > Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - review > - test & fix Thanks for updating, looks good to me. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/41 From roland at openjdk.java.net Tue Jan 5 13:05:58 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Tue, 5 Jan 2021 13:05:58 GMT Subject: [jdk16] RFR: 8258393: Shenandoah: "graph should be schedulable" assert failure [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 11:57:18 GMT, Tobias Hartmann wrote: > Otherwise looks reasonable to me. Thanks for the review. I took care of your comments (except for the is_top() check that I don't think is needed). ------------- PR: https://git.openjdk.java.net/jdk16/pull/41 From roland at openjdk.java.net Tue Jan 5 13:10:59 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Tue, 5 Jan 2021 13:10:59 GMT Subject: [jdk16] RFR: 8258393: Shenandoah: "graph should be schedulable" assert failure [v2] In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 15:31:35 GMT, Roman Kennke wrote: > As far as I can tell, the change looks good. I'm not very familiar with the code, it would be good to have somebody else check it too. > I verified that the tests that failed before are passing now and also have run some additional tests. thanks for the review and running tests. ------------- PR: https://git.openjdk.java.net/jdk16/pull/41 From roland at openjdk.java.net Tue Jan 5 13:11:02 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Tue, 5 Jan 2021 13:11:02 GMT Subject: [jdk16] Integrated: 8258393: Shenandoah: "graph should be schedulable" assert failure In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 08:20:20 GMT, Roland Westrelin wrote: > This is a shenandoah bug but the fix is in shared code. > > At barrier expansion time, we need the raw memory state for the > control at which the barrier is expanded. Before expansion, the memory > graph is traversed and memory state for each control is recorded. In > that process, if opportunities to improve the memory graph are found, > the graph is modified. In the case of the failure, a raw memory load > was assigned a call projection as control but for that control, no > memory state was recorded and the fall back is to use the call's input > memory state. As a consequence the load's memory input is updated to a > wrong memory state. This causes the assert failure. > > The call has 2 memory projections: one for the fallthrough and one for > the exception path. One projection is the memory state for the > CatchProj for the fallthrough, the other one for the CatchProj of the > exception path. For the control projection out of the call, there's no > memory state that makes sense and assigning the control projection of > the call as control for the load is the root cause of the > problem. This happens because anti-dependence analysis is too > conservative: a memory Phi that merges states from the exception and > fallthrough path is considered a dependency and that pushed the load > right after the call. > > I propose to be less conservative in anti-dependence analysis for > Phis. For a Phi, when computing the LCA, I think it's sufficient to > only consider region's inputs that we actually reach by following the > memory edges and that's what I propose here. This pull request has now been integrated. Changeset: 6775113c Author: Roland Westrelin URL: https://git.openjdk.java.net/jdk16/commit/6775113c Stats: 114 lines in 3 files changed: 107 ins; 2 del; 5 mod 8258393: Shenandoah: "graph should be schedulable" assert failure Reviewed-by: rkennke, thartmann ------------- PR: https://git.openjdk.java.net/jdk16/pull/41 From dongbo at openjdk.java.net Tue Jan 5 13:42:21 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Tue, 5 Jan 2021 13:42:21 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: > This patch optimizes vectorial Min/Max reduction of two floating-point numbers on aarch64 with NEON instructions `fmaxp` and `fminp`. > > Passed jtreg tier1-3 tests with `linux-aarch64-server-fastdebug` build. > Tests under `test/jdk/jdk/incubator/vector/` runned specially for the correctness and passed. > > Introduced a new JMH micro `test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java` for performance test. > Witnessed abount `37%` performance improvements on Kunpeng916. The JMH Results: > Benchmark (COUNT) (seed) Mode Cnt Score Error Units > # Kunpeng 916, default > VectorReduction.maxRedD 512 0 avgt 10 678.126 ? 0.815 ns/op > VectorReduction.maxRedF 512 0 avgt 10 242.958 ? 0.212 ns/op > VectorReduction.minRedD 512 0 avgt 10 678.554 ? 0.824 ns/op > VectorReduction.minRedF 512 0 avgt 10 243.368 ? 0.205 ns/op > > # Kunpeng 916, with fmaxp/fminp > VectorReduction.maxRedD 512 0 avgt 10 430.201 ? 0.353 ns/op => 36.56% > VectorReduction.maxRedF 512 0 avgt 10 243.404 ? 0.297 ns/op > VectorReduction.minRedD 512 0 avgt 10 427.805 ? 0.528 ns/op => 36.89% > VectorReduction.minRedF 512 0 avgt 10 242.963 ? 0.210 ns/op Dong Bo has updated the pull request incrementally with one additional commit since the last revision: put faddp/fmaxp/fminp together in a group ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1925/files - new: https://git.openjdk.java.net/jdk/pull/1925/files/876939b9..c0c6f51f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1925&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1925&range=01-02 Stats: 27 lines in 1 file changed: 6 ins; 14 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1925.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1925/head:pull/1925 PR: https://git.openjdk.java.net/jdk/pull/1925 From dongbo at openjdk.java.net Tue Jan 5 13:45:56 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Tue, 5 Jan 2021 13:45:56 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 11:10:17 GMT, Andrew Haley wrote: >> Dong Bo has updated the pull request incrementally with one additional commit since the last revision: >> >> rebase the .m4 entry > > src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 2451: > >> 2449: #undef INSN >> 2450: >> 2451: #define INSN(NAME, opc) \ > > This should be in an "AdvSIMD scalar pairwise" instruction group with faddp. Done. The instructions `faddp`, `fmax` and `fmin` are put together in one group now. Re-run the `test/jdk/jdk/incubator/vector/` tests and passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From github.com+16932759+shqking at openjdk.java.net Tue Jan 5 14:30:55 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Tue, 5 Jan 2021 14:30:55 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 12:03:05 GMT, Jie Fu wrote: >> Hao Sun has updated the pull request incrementally with one additional commit since the last revision: >> >> Header 'runtime/globals_shared.hpp' should be kept >> >> Header 'runtime/globals_shared.hpp' is kept even though >> 'compiler/compiler_globals_pd.hpp' already includes it, because >> 'compiler_globals.hpp' uses the DECLARE_FLAGS macro, which is defined by >> 'runtime/globals_shared.hpp', and it should be included directly. >> >> Besides, update the copyright year to 2021. >> >> Change-Id: Ia355f3b6e98b495dc265093e71b2d1fec1ca45ca >> CustomizedGitHooks: yes > > Marked as reviewed by jiefu (Committer). Thanks for your reviews! @DamonFool @iklam @shipilev The pre-submit tests were passed except the GC one which is not related to this patch. I suppose this patch is ready to be merged now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From redestad at openjdk.java.net Tue Jan 5 15:17:59 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 5 Jan 2021 15:17:59 GMT Subject: RFR: 8259236: C2 compilation fails with assert(is_power_of_2(value)) failed: value must be a power of 2: 8000000000000000 Message-ID: log2i_exact does not accept 0x8000000000000000 if the type is signed, which log2_long used before JDK-8257815 did. This adds a cast to julong, similar to what was previously done in btsL_mem_imm Ran the test 10+ times in our CI without hitting the assert. ------------- Commit messages: - Assertion in testing: Cast to unsigned to allow 0x8000... Changes: https://git.openjdk.java.net/jdk/pull/1944/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1944&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259236 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1944.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1944/head:pull/1944 PR: https://git.openjdk.java.net/jdk/pull/1944 From psandoz at openjdk.java.net Tue Jan 5 15:20:57 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 5 Jan 2021 15:20:57 GMT Subject: RFR: 8258813: [TESTBUG] Fix incorrect Vector API test output message [v2] In-Reply-To: References: <5sX7KaIfqVM3R1oMVcnKYjnwcq-Vm-tGUgu43Q1Rr00=.c90cc99c-65fd-47ac-9746-b63530eb1e26@github.com> Message-ID: On Tue, 5 Jan 2021 08:18:44 GMT, Ningsheng Jian wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year to 2021 > > Looks good to me. > > Thank you for fixing this. So easy to get mixed up between TestNG and JUnit! > > It's tempting to change the parameter names of the assert methods to be named `expected` and `accepted`, i'll consider doing that rather than impose that on you. > > Hi @PaulSandoz, thanks so much for looking at this PR. And I'm so sorry that I forgot to update the copyright to the new year. I'v committed one more patch to fix them. Do you mind having a looking at it again? Many thanks! Copyright changes look good. ------------- PR: https://git.openjdk.java.net/jdk/pull/1922 From thartmann at openjdk.java.net Tue Jan 5 15:51:57 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 5 Jan 2021 15:51:57 GMT Subject: RFR: 8259236: C2 compilation fails with assert(is_power_of_2(value)) failed: value must be a power of 2: 8000000000000000 In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 15:12:31 GMT, Claes Redestad wrote: > log2i_exact does not accept 0x8000000000000000 if the type is signed, which log2_long used before JDK-8257815 did. This adds a cast to julong, similar to what was previously done in btsL_mem_imm > > Ran the test 10+ times in our CI without hitting the assert. Looks good and trivial. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1944 From github.com+16932759+shqking at openjdk.java.net Tue Jan 5 16:30:58 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Tue, 5 Jan 2021 16:30:58 GMT Subject: Integrated: 8258857: Zero: non-PCH release build fails after JDK-8258074 In-Reply-To: References: Message-ID: On Fri, 25 Dec 2020 10:11:13 GMT, Hao Sun wrote: > From the error log we can see the root cause is that, develop_pd flag > 'pd_CICompileOSR' is undeclared in zero build. > > Where this flag is used? > Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77 > of 'compiler_globals.hpp' and further line 86 of 'globals_shared.hpp'. > > Where this flag can be declared? > Header files 'c1_globals.hpp' or 'c2_globals.hpp' would be included if > VM is built with compiler1 or compiler2. See lines 30 to 38 of > 'complier_globals.hpp'. And further, flag 'pd_CICompileOSR' may get > declared in the header files for specific arch, e.g., > 'c1_globals_aarch64.hpp', 'c2_globals_aarch64.hpp'. > However, regarding zero build (without compiler1 and compiler2 and > jvmci) , this flag is undelcared. Hence, this patch gets header file > 'compiler/compiler_globals_pd.hpp' included where this flag is declared > for the case when neither COMPILER1 nor COMPILER2 are defined and > INCLUDE_JVMCI is inactive. > > Note that 'compiler/compiler_globals_pd.hpp' already includes > 'runtime/globals_shared.hpp'. > > Note that zero build with PCH succeeds because 'runtime/globals.hpp' is > included in 'precompiled.hpp', and further 'compiler_globals_pd.hpp' is > included in 'runtime/globals.hpp'. This pull request has now been integrated. Changeset: 82bdbfd7 Author: Hao Sun Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/82bdbfd7 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8258857: Zero: non-PCH release build fails after JDK-8258074 Reviewed-by: jiefu, shade, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From shade at openjdk.java.net Tue Jan 5 16:30:56 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 5 Jan 2021 16:30:56 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 14:28:14 GMT, Hao Sun wrote: >> Marked as reviewed by jiefu (Committer). > > Thanks for your reviews! @DamonFool @iklam @shipilev > > The pre-submit tests were passed except the GC one which is not related to this patch. I suppose this patch is ready to be merged now. Sponsoring to unbreak current jdk/jdk CI for me. ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From redestad at openjdk.java.net Tue Jan 5 16:44:56 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 5 Jan 2021 16:44:56 GMT Subject: RFR: 8259236: C2 compilation fails with assert(is_power_of_2(value)) failed: value must be a power of 2: 8000000000000000 In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 15:49:21 GMT, Tobias Hartmann wrote: >> log2i_exact does not accept 0x8000000000000000 if the type is signed, which log2_long used before JDK-8257815 did. This adds a cast to julong, similar to what was previously done in btsL_mem_imm >> >> Ran the test 10+ times in our CI without hitting the assert. > > Looks good and trivial. Thanks @TobiHartmann! ------------- PR: https://git.openjdk.java.net/jdk/pull/1944 From redestad at openjdk.java.net Tue Jan 5 16:44:57 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 5 Jan 2021 16:44:57 GMT Subject: Integrated: 8259236: C2 compilation fails with assert(is_power_of_2(value)) failed: value must be a power of 2: 8000000000000000 In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 15:12:31 GMT, Claes Redestad wrote: > log2i_exact does not accept 0x8000000000000000 if the type is signed, which log2_long used before JDK-8257815 did. This adds a cast to julong, similar to what was previously done in btsL_mem_imm > > Ran the test 10+ times in our CI without hitting the assert. This pull request has now been integrated. Changeset: d5aa49d1 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/d5aa49d1 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8259236: C2 compilation fails with assert(is_power_of_2(value)) failed: value must be a power of 2: 8000000000000000 Reviewed-by: thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/1944 From kvn at openjdk.java.net Tue Jan 5 16:50:56 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 5 Jan 2021 16:50:56 GMT Subject: [jdk16] RFR: 8258619: -XX:CompileCommand=blackhole, * should only accept empty static methods In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 17:58:12 GMT, Aleksey Shipilev wrote: > In JDK-8257827 CSR, a further comment was raised about changing the semantics of the method. This allegedly introduces the conformance problem. While it is still an open question where the conformance problem is real, we can sidestep the entire issue by allowing only empty static methods to be blackholed. This eliminates any behavioral difference: empty methods have no side effects, and static methods do not need any null checks. > > This change eliminates a lot of new code added by original JDK-8252505 push, mostly now-useless testing code. It adds two more tests that verify that non-empty and non-static methods are properly rejected. I agree with these changes for JDK 16. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/45 From kvn at openjdk.java.net Tue Jan 5 16:51:58 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 5 Jan 2021 16:51:58 GMT Subject: RFR: 8258961: devirtualize SafePointNode::jvms() and hide out set_jvms() [v2] In-Reply-To: References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> Message-ID: <20vLJN4hQGRFCYYV6TeIFfC3tNPlNBIV7-cizHLMo50=.c2780d75-060d-4a43-840e-86de2c43c664@github.com> On Tue, 5 Jan 2021 10:11:11 GMT, Xin Liu wrote: >> SafePointNode::jvms() declares virtual but has never been overridden. It seems unnecessary. >> The member variable _jvms declares 'JVMState* const', but set_jvms() updates its value anyway. >> Geting rid of the const qualifier and hides if out using protected. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > 8258961: devirtualize SafePointNode::jvms() and hide out set_jvms() > > devirtualize SafePointNode::jvms(). We can't hide the member variable _jvms > because it is exposed to HotSpot Servicability agent. keeping the qualifier > const for the same resaon. Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1899 From xliu at openjdk.java.net Tue Jan 5 19:58:05 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 5 Jan 2021 19:58:05 GMT Subject: RFR: 8258961: devirtualize SafePointNode::jvms() and hide out set_jvms() [v2] In-Reply-To: <20vLJN4hQGRFCYYV6TeIFfC3tNPlNBIV7-cizHLMo50=.c2780d75-060d-4a43-840e-86de2c43c664@github.com> References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> <20vLJN4hQGRFCYYV6TeIFfC3tNPlNBIV7-cizHLMo50=.c2780d75-060d-4a43-840e-86de2c43c664@github.com> Message-ID: On Tue, 5 Jan 2021 16:49:25 GMT, Vladimir Kozlov wrote: >> Xin Liu has updated the pull request incrementally with one additional commit since the last revision: >> >> 8258961: devirtualize SafePointNode::jvms() and hide out set_jvms() >> >> devirtualize SafePointNode::jvms(). We can't hide the member variable _jvms >> because it is exposed to HotSpot Servicability agent. keeping the qualifier >> const for the same resaon. > > Good. I investigate the 3 failures on x86 host. they have been fixed in JDK-8258703 (committed yesterday). Presumably, the regression tests are clear. /integrate. ------------- PR: https://git.openjdk.java.net/jdk/pull/1899 From dlong at openjdk.java.net Tue Jan 5 22:23:04 2021 From: dlong at openjdk.java.net (Dean Long) Date: Tue, 5 Jan 2021 22:23:04 GMT Subject: RFR: 8255216: ciEnv::_break_at_compile isn't in use In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 09:00:37 GMT, Tobias Hartmann wrote: >> I wasn't sure whether or not we wanted to roll the removal of all dead code into this issue or just _break_at_compile. The JBS issue specifically mentions _break_at_compile so that's what I removed here - can expand to do other stuff if you think it's a good idea. > > I think it's fine to remove all that dead code with this issue Should CIBreakAtOSR and CIBreakAt be removed too, or is it a bug that these flags are ignored? ------------- PR: https://git.openjdk.java.net/jdk/pull/1806 From sandhya.viswanathan at intel.com Tue Jan 5 23:40:09 2021 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Tue, 5 Jan 2021 23:40:09 +0000 Subject: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions In-Reply-To: References: Message-ID: Hi Christoph, Thanks a lot for considering this. It is just a performance improvement for our latest x86 64-bit platform with no side for others. The optimization has been out for about a quarter as part of JDK 15. Best Regards, Sandhya -----Original Message----- From: Langer, Christoph Sent: Wednesday, December 23, 2020 5:10 AM To: Viswanathan, Sandhya ; Doerr, Martin ; Lindenmaier, Goetz ; Andrew Haley Cc: Vladimir Kozlov ; jdk-updates-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Subject: RE: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions Hi, as we should be cautious about backports to an LTS release if something is not just a bugfix, I'm not sure whether this backport for a performance enhancement is good to go. Generally, if it can be proven that it's really just a potential performance improvement without side effects to other scenarios, I would be fine with it. But as I'm not an expert in this area, I'd prefer if it there was some further endorsement (or disapproval)... @Andrew Haley; @Lindenmaier, Goetz; @Doerr, Martin, what's your assessment? Thanks Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Viswanathan, Sandhya > Sent: Freitag, 11. Dezember 2020 00:47 > To: Vladimir Kozlov ; jdk-updates- > dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net > Subject: RE: [11u] RFR 8245512: CRC32 optimization using AVX512 > instructions > > Thanks a lot Vladimir for review and link to the process. I requested > the backport in JBS. > > Best Regards, > Sandhya > > -----Original Message----- > From: Vladimir Kozlov > Sent: Thursday, December 10, 2020 3:07 PM > To: Viswanathan, Sandhya ; jdk-updates- > dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net > Subject: Re: [11u] RFR 8245512: CRC32 optimization using AVX512 > instructions > > Changes are fine but you need to follow process: > > http://openjdk.java.net/projects/jdk-updates/approval.html > > Also it is performance improvement which may not be accepted. > > Regards, > Vladimi > > On 12/10/20 1:00 PM, Viswanathan, Sandhya wrote: > > I would like to backport the CRC32 optimization using AVX512 > > instructions > to JDK 11u. > > This optimization was introduced in JDK 15. > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8245512 > > Webrev: http://cr.openjdk.java.net/~sviswanathan/8245512/webrev.00/ > > > > Only one change was needed to the original patch in > src/hotspot/cpu/x86/assembler_x86.cpp. > > > > The following in Assembler::blendvpb(), line 7908: > > > > emit_int24(0x4C, (0xC0 | encode), (0xF0 & src2_enc << 4)); was > > replaced by equivalent: > > emit_int8((unsigned char)0x4C); > > emit_int8((unsigned char)(0xC0 | encode)); emit_int8((unsigned > > char)(0xF0 & src2_enc<<4)); > > > > The patch applies cleanly otherwise. > > > > Please review this backport to 11u. > > > > Best Regards, > > Sandhya > > From xgong at openjdk.java.net Wed Jan 6 01:43:55 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Wed, 6 Jan 2021 01:43:55 GMT Subject: Integrated: 8258813: [TESTBUG] Fix incorrect Vector API test output message In-Reply-To: <5sX7KaIfqVM3R1oMVcnKYjnwcq-Vm-tGUgu43Q1Rr00=.c90cc99c-65fd-47ac-9746-b63530eb1e26@github.com> References: <5sX7KaIfqVM3R1oMVcnKYjnwcq-Vm-tGUgu43Q1Rr00=.c90cc99c-65fd-47ac-9746-b63530eb1e26@github.com> Message-ID: On Mon, 4 Jan 2021 02:03:13 GMT, Xiaohong Gong wrote: > Some vector api tests have incorrect output messages if assertion fails. The root cause is the improper use of `"org.testng.Assert.assertEqual()"`, whose definition with int type is: > assertEquals(int actual, int expected, String message); > > The method needs the actual value be used as the first argument and expected value as the second one. But in some vector api tests, the two arguments are swapped. > > For example, here is part of the fail log in VectorReshapeTests we met: > expect: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16] > output: [1, 2, 3, 4, 5, 6, 7, 8, 1, 0, 0, 0, 0, 0, 0, 0] > test VectorReshapeTests.testRebracket128(byte(i)): failure > java.lang.AssertionError: arrays differ firstly at element [8]; expected value is <1> but was <9>. > at org.testng.Assert.fail(Assert.java:94) > at org.testng.Assert.assertEquals(Assert.java:774) > ... > > The assertion error should be `"...expected value is <9> but was <1>."` > > This does not influence on the test effectiveness. However, the incorrect message is confusing which might mislead people. The simple fix is just to swap the arguments back. > > This patch also adjusts the arguments order of all the assertion methods to make the actual values used as the first one. Besides, it also removes two unused assertion methods. This pull request has now been integrated. Changeset: 52d3feec Author: Xiaohong Gong Committer: Ningsheng Jian URL: https://git.openjdk.java.net/jdk/commit/52d3feec Stats: 7860 lines in 108 files changed: 0 ins; 682 del; 7178 mod 8258813: [TESTBUG] Fix incorrect Vector API test output message Reviewed-by: psandoz, njian ------------- PR: https://git.openjdk.java.net/jdk/pull/1922 From whuang at openjdk.java.net Wed Jan 6 01:51:57 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Wed, 6 Jan 2021 01:51:57 GMT Subject: [jdk16] Integrated: 8258989: JVM is failed to inline in jdk.internal.vm.vector.VectorSupport::convert In-Reply-To: References: Message-ID: On Thu, 31 Dec 2020 01:47:00 GMT, Wang Huang wrote: > $java --add-modules=jdk.incubator.vector -Xcomp -XX:CompileCommand=compileonly,TestCast16BTo2D::* -XX:+UnlockDiagnosticVMOptions -XX:+PrintIntrinsics TestCast16BTo2D > before fixing: > ** not supported: arity=1 op=cast/5 vlen2=2 etype1=byte ismask=0 > @ 3 jdk.internal.util.Preconditions::checkIndex (18 bytes) (intrinsic) > @ 101 java.lang.Object::getClass (0 bytes) (intrinsic) > @ 109 java.lang.Object::getClass (0 bytes) (intrinsic) > @ 3 jdk.internal.util.Preconditions::checkIndex (18 bytes) (intrinsic) > @ 31 jdk.internal.vm.vector.VectorSupport::load (38 bytes) (intrinsic) > @ 128 jdk.internal.vm.vector.VectorSupport::convert (39 bytes) failed to inline (intrinsic) > @ 42 jdk.internal.vm.vector.VectorSupport::store (38 bytes) (intrinsic) > Expect: > @ 3 jdk.internal.util.Preconditions::checkIndex (18 bytes) (intrinsic) > @ 101 java.lang.Object::getClass (0 bytes) (intrinsic) > @ 109 java.lang.Object::getClass (0 bytes) (intrinsic) > @ 3 jdk.internal.util.Preconditions::checkIndex (18 bytes) (intrinsic) > @ 31 jdk.internal.vm.vector.VectorSupport::load (38 bytes) (intrinsic) > @ 128 jdk.internal.vm.vector.VectorSupport::convert (39 bytes) (intrinsic) > @ 42 jdk.internal.vm.vector.VectorSupport::store (38 bytes) (intrinsic) This pull request has now been integrated. Changeset: 554e60c4 Author: Wang Huang Committer: Fei Yang URL: https://git.openjdk.java.net/jdk16/commit/554e60c4 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8258989: JVM is failed to inline in jdk.internal.vm.vector.VectorSupport::convert Co-authored-by: He Xuejin Reviewed-by: vlivanov, thartmann ------------- PR: https://git.openjdk.java.net/jdk16/pull/74 From xliu at openjdk.java.net Wed Jan 6 02:19:04 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 6 Jan 2021 02:19:04 GMT Subject: RFR: 8259287: AbstractCompiler marks const in wrong position for is_c1/is_c2/is_jvmci Message-ID: I think the intention is to have constant member functions. ------------- Commit messages: - 8259287: AbstractCompiler marks const in wrong position for is_c1/is_c2/is_jvmci Changes: https://git.openjdk.java.net/jdk/pull/1953/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1953&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259287 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1953.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1953/head:pull/1953 PR: https://git.openjdk.java.net/jdk/pull/1953 From thartmann at openjdk.java.net Wed Jan 6 06:58:58 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 6 Jan 2021 06:58:58 GMT Subject: RFR: 8258961: devirtualize SafePointNode::jvms() and hide out set_jvms() [v2] In-Reply-To: References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> Message-ID: On Tue, 5 Jan 2021 10:11:11 GMT, Xin Liu wrote: >> SafePointNode::jvms() declares virtual but has never been overridden. It seems unnecessary. >> The member variable _jvms declares 'JVMState* const', but set_jvms() updates its value anyway. >> Geting rid of the const qualifier and hides if out using protected. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > 8258961: devirtualize SafePointNode::jvms() and hide out set_jvms() > > devirtualize SafePointNode::jvms(). We can't hide the member variable _jvms > because it is exposed to HotSpot Servicability agent. keeping the qualifier > const for the same resaon. Marked as reviewed by thartmann (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1899 From thartmann at openjdk.java.net Wed Jan 6 07:01:56 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 6 Jan 2021 07:01:56 GMT Subject: RFR: 8255216: ciEnv::_break_at_compile isn't in use In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 22:20:14 GMT, Dean Long wrote: >> I think it's fine to remove all that dead code with this issue > > Should CIBreakAtOSR and CIBreakAt be removed too, or is it a bug that these flags are ignored? I think the fact that these flags are not working proves that no one is using them and therefore they should be removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1806 From thartmann at openjdk.java.net Wed Jan 6 07:59:54 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 6 Jan 2021 07:59:54 GMT Subject: RFR: 8259287: AbstractCompiler marks const in wrong position for is_c1/is_c2/is_jvmci In-Reply-To: References: Message-ID: <50vuEMO5ruxr0b8lgAsQYXP_cYxBo2gMZSp1nrqIeV8=.b7f13fa9-cfc5-436f-b1ac-b772d9ee8c16@github.com> On Wed, 6 Jan 2021 02:14:19 GMT, Xin Liu wrote: > I think the intention is to have constant member functions. Looks good and trivial. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1953 From chagedorn at openjdk.java.net Wed Jan 6 07:59:55 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Wed, 6 Jan 2021 07:59:55 GMT Subject: RFR: 8259287: AbstractCompiler marks const in wrong position for is_c1/is_c2/is_jvmci In-Reply-To: References: Message-ID: <3jZAa8TpOvpo7TzlAlEAcogfFkPLWSwwiQXrZcuj0rQ=.d512814f-7673-44d0-a5bf-fbda8a46dcb5@github.com> On Wed, 6 Jan 2021 02:14:19 GMT, Xin Liu wrote: > I think the intention is to have constant member functions. Marked as reviewed by chagedorn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1953 From xliu at openjdk.java.net Wed Jan 6 08:59:56 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 6 Jan 2021 08:59:56 GMT Subject: RFR: 8258961: devirtualize SafePointNode::jvms() and hide out set_jvms() [v2] In-Reply-To: References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> Message-ID: On Tue, 5 Jan 2021 10:10:57 GMT, Xin Liu wrote: >> src/hotspot/share/runtime/vmStructs.cpp line 945: >> >>> 943: \ >>> 944: c2_nonstatic_field(SafePointNode, _jvms, JVMState* const) \ >>> 945: \ >> >> Don't remove it. It is referenced from HotSpot Servicability agent: >> https://github.com/openjdk/jdk/blob/master/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/SafePointNode.java#L45 > > Thank you for pointing out this. I wasn't aware of this agent thing. > It turns out I can neither move SafePointNode::_jvms to the protected zone nor take off its const qualifier. > so I revert my changes except removing "virtual" for the SafePointNode::jvms(). I reverted files which need to update copyright years. ------------- PR: https://git.openjdk.java.net/jdk/pull/1899 From xliu at openjdk.java.net Wed Jan 6 09:04:17 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 6 Jan 2021 09:04:17 GMT Subject: RFR: 8258961: devirtualize SafePointNode::jvms() and hide out set_jvms() [v3] In-Reply-To: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> Message-ID: > SafePointNode::jvms() declares virtual but has never been overridden. It seems unnecessary. > The member variable _jvms declares 'JVMState* const', but set_jvms() updates its value anyway. > Geting rid of the const qualifier and hides if out using protected. Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8258961 - 8258961: devirtualize SafePointNode::jvms() and hide out set_jvms() devirtualize SafePointNode::jvms(). We can't hide the member variable _jvms because it is exposed to HotSpot Servicability agent. keeping the qualifier const for the same resaon. - 8258961: devirtualize SafePointNode::jvms() and hide out set_jvms() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1899/files - new: https://git.openjdk.java.net/jdk/pull/1899/files/b42b4689..f393855d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1899&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1899&range=01-02 Stats: 5467 lines in 499 files changed: 1261 ins; 3170 del; 1036 mod Patch: https://git.openjdk.java.net/jdk/pull/1899.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1899/head:pull/1899 PR: https://git.openjdk.java.net/jdk/pull/1899 From thartmann at openjdk.java.net Wed Jan 6 09:17:57 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 6 Jan 2021 09:17:57 GMT Subject: RFR: 8258961: devirtualize SafePointNode::jvms() and hide out set_jvms() In-Reply-To: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> Message-ID: <08g7HiFIZyPHlhan7KLe4_w9_BGQZPpnoDxtnzraj_s=.161392a6-49d6-4d40-9b56-cb188bafad82@github.com> On Mon, 28 Dec 2020 09:48:29 GMT, Xin Liu wrote: > SafePointNode::jvms() declares virtual but has never been overridden. It seems unnecessary. > The member variable _jvms declares 'JVMState* const', but set_jvms() updates its value anyway. > Geting rid of the const qualifier and hides if out using protected. @navyxliu There is a title mismatch between the PR and the JBS issue that you need to fix before integration. ------------- PR: https://git.openjdk.java.net/jdk/pull/1899 From xliu at openjdk.java.net Wed Jan 6 09:32:57 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 6 Jan 2021 09:32:57 GMT Subject: RFR: 8258961: devirtualize SafePointNode::jvms() In-Reply-To: <08g7HiFIZyPHlhan7KLe4_w9_BGQZPpnoDxtnzraj_s=.161392a6-49d6-4d40-9b56-cb188bafad82@github.com> References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> <08g7HiFIZyPHlhan7KLe4_w9_BGQZPpnoDxtnzraj_s=.161392a6-49d6-4d40-9b56-cb188bafad82@github.com> Message-ID: On Wed, 6 Jan 2021 09:15:24 GMT, Tobias Hartmann wrote: >> SafePointNode::jvms() declares virtual but has never been overridden. It seems unnecessary. >> The member variable _jvms declares 'JVMState* const', but set_jvms() updates its value anyway. >> Geting rid of the const qualifier and hides if out using protected. > > @navyxliu There is a title mismatch between the PR and the JBS issue that you need to fix before integration. yes, I did modify the JBS title. I found it's hard to hide out ------------- PR: https://git.openjdk.java.net/jdk/pull/1899 From shade at openjdk.java.net Wed Jan 6 09:48:54 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 6 Jan 2021 09:48:54 GMT Subject: RFR: 8259287: AbstractCompiler marks const in wrong position for is_c1/is_c2/is_jvmci In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 02:14:19 GMT, Xin Liu wrote: > I think the intention is to have constant member functions. Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1953 From shade at openjdk.java.net Wed Jan 6 09:53:54 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 6 Jan 2021 09:53:54 GMT Subject: RFR: 8259287: AbstractCompiler marks const in wrong position for is_c1/is_c2/is_jvmci In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 09:46:01 GMT, Aleksey Shipilev wrote: >> I think the intention is to have constant member functions. > > Marked as reviewed by shade (Reviewer). This shows up in my code scans too, Clang-Tidy says e.g. "Return type 'const CompilerType' is 'const'-qualified at the top level, which may reduce code readability without improving const". Introduced by JDK-8166377. ------------- PR: https://git.openjdk.java.net/jdk/pull/1953 From xliu at openjdk.java.net Wed Jan 6 09:53:55 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 6 Jan 2021 09:53:55 GMT Subject: Integrated: 8259287: AbstractCompiler marks const in wrong position for is_c1/is_c2/is_jvmci In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 02:14:19 GMT, Xin Liu wrote: > I think the intention is to have constant member functions. This pull request has now been integrated. Changeset: e3b9da14 Author: Xin Liu Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/e3b9da14 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8259287: AbstractCompiler marks const in wrong position for is_c1/is_c2/is_jvmci Reviewed-by: thartmann, chagedorn, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/1953 From aph at redhat.com Wed Jan 6 09:57:29 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jan 2021 09:57:29 +0000 Subject: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions In-Reply-To: References: Message-ID: On 12/23/20 1:09 PM, Langer, Christoph wrote: > > as we should be cautious about backports to an LTS release if something is not just a bugfix, I'm not sure whether this backport for a performance enhancement is good to go. Generally, if it can be proven that it's really just a potential performance improvement without side effects to other scenarios, I would be fine with it. But as I'm not an expert in this area, I'd prefer if it there was some further endorsement (or disapproval)... > > @Andrew Haley; @Lindenmaier, Goetz; @Doerr, Martin, what's your assessment? We could backport for a significant performance bottleneck, but I'm leaning toward the idea that JDK 11 is done: we're keeping it going by fixing bugs and adapting to changing environments, but that should be all. However, there are exceptions to every rule! There is a social problem in that maintainers get very demotivated because non-LTS releases are "never used" so people's work doesn't appear in production for years. I'm not sure exactly how to address that, except to say that using the OpenJDK release stream shouldn't be so very scary. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at openjdk.java.net Wed Jan 6 14:28:21 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 6 Jan 2021 14:28:21 GMT Subject: [jdk16] Withdrawn: 8258619: -XX:CompileCommand=blackhole, * should only accept empty static methods In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 17:58:12 GMT, Aleksey Shipilev wrote: > In JDK-8257827 CSR, a further comment was raised about changing the semantics of the method. This allegedly introduces the conformance problem. While it is still an open question where the conformance problem is real, we can sidestep the entire issue by allowing only empty static methods to be blackholed. This eliminates any behavioral difference: empty methods have no side effects, and static methods do not need any null checks. > > This change eliminates a lot of new code added by original JDK-8252505 push, mostly now-useless testing code. It adds two more tests that verify that non-empty and non-static methods are properly rejected. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk16/pull/45 From chagedorn at openjdk.java.net Wed Jan 6 14:30:09 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Wed, 6 Jan 2021 14:30:09 GMT Subject: [jdk16] RFR: 8259227: C2 crashes with SIGFPE due to a division that floats above its zero check Message-ID: This bug is very similar to [JDK-8257822](https://bugs.openjdk.java.net/browse/JDK-8257822). In this testcase, a `Div` node has no longer its zero check as direct control input and is later moved before the zero check by `IfNode::dominated_by()` which updates all data nodes to a dominating `If` (in JDK-8257822 it was done by `PhaseIdealLoop::dominated_by()`) . I suggest to use the same fix for `IfNode::dominated_by()` as for `PhaseIdealLoop::dominated_by()` in JDK-8257822 to only move data nodes to the dominating `If` if it is not a `Div` or `Mod` node that could have a zero divisor (i.e. a zero check). Thanks, Christian ------------- Commit messages: - 8259227: C2 crashes with SIGFPE due to a division that floats above its zero check Changes: https://git.openjdk.java.net/jdk16/pull/89/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=89&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259227 Stats: 124 lines in 6 files changed: 99 ins; 22 del; 3 mod Patch: https://git.openjdk.java.net/jdk16/pull/89.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/89/head:pull/89 PR: https://git.openjdk.java.net/jdk16/pull/89 From thartmann at openjdk.java.net Wed Jan 6 17:43:04 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 6 Jan 2021 17:43:04 GMT Subject: RFR: 8259339: AllocateUninitializedArray C2 intrinsic fails with void.class input Message-ID: Since [JDK-8150465](https://bugs.openjdk.java.net/browse/JDK-8150465), `LibraryCallKit::inline_unsafe_newArray` is also used by the `_allocateUninitializedArray` intrinsic. To handle a `void.class` input, a runtime (slow) call to the intrinsified method is emitted. We hit a guarantee in `generate_method_call_static` because a wrong intrinsic id is passed. Also, the call to `Unsafe.allocateUninitializedArray0` should be virtual. I found this when running Valhalla stress testing with `-XX:PerMethodTrapLimit=0` but it easily reproduces without (see modified test). Thanks, Tobias ------------- Commit messages: - Updated copyright date - 8259339: AllocateUninitializedArray C2 intrinsic fails with void.class input Changes: https://git.openjdk.java.net/jdk/pull/1965/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1965&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259339 Stats: 20 lines in 2 files changed: 16 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1965.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1965/head:pull/1965 PR: https://git.openjdk.java.net/jdk/pull/1965 From kvn at openjdk.java.net Wed Jan 6 17:46:58 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 6 Jan 2021 17:46:58 GMT Subject: RFR: 8255216: ciEnv::_break_at_compile isn't in use In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 18:38:37 GMT, Dan wrote: > _break_at_compile is no longer in use and can be safely removed. > No new code, and Tier1 tests succeed after code is removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 Changes requested by kvn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1806 From kvn at openjdk.java.net Wed Jan 6 18:10:59 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 6 Jan 2021 18:10:59 GMT Subject: RFR: 8255216: ciEnv::_break_at_compile isn't in use In-Reply-To: References: Message-ID: <5q-Tvy6wwLlLJi1MM86hCS-eW2OGg0FDCYh_hW2LyhY=.2cddf2b1-369d-493a-b1d5-cbf37f10b423@github.com> On Wed, 16 Dec 2020 18:38:37 GMT, Dan wrote: > _break_at_compile is no longer in use and can be safely removed. > No new code, and Tier1 tests succeed after code is removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 To clarify about my comment about task->check_break_at_flags(). The easier fix I think is instead of removing ciEnv code use env()->break_at_compile() in compile.cpp instead of directive->BreakAtCompileOption ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1806 From kvn at openjdk.java.net Wed Jan 6 18:11:55 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 6 Jan 2021 18:11:55 GMT Subject: RFR: 8259339: AllocateUninitializedArray C2 intrinsic fails with void.class input In-Reply-To: References: Message-ID: <-KTp0-ukOgFyc0kAXlCWYTZU5G-QucduLfIXHccGbpI=.0f05f809-663e-453b-9782-2928bb5490d1@github.com> On Wed, 6 Jan 2021 17:38:00 GMT, Tobias Hartmann wrote: > Since [JDK-8150465](https://bugs.openjdk.java.net/browse/JDK-8150465), `LibraryCallKit::inline_unsafe_newArray` is also used by the `_allocateUninitializedArray` intrinsic. To handle a `void.class` input, a runtime (slow) call to the intrinsified method is emitted. We hit a guarantee in `generate_method_call_static` because a wrong intrinsic id is passed. Also, the call to `Unsafe.allocateUninitializedArray0` should be virtual. > > I found this when running Valhalla stress testing with `-XX:PerMethodTrapLimit=0` but it easily reproduces without (see modified test). > > Thanks, > Tobias Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1965 From kvn at openjdk.java.net Wed Jan 6 18:14:59 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 6 Jan 2021 18:14:59 GMT Subject: [jdk16] RFR: 8259227: C2 crashes with SIGFPE due to a division that floats above its zero check In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 13:43:17 GMT, Christian Hagedorn wrote: > This bug is very similar to [JDK-8257822](https://bugs.openjdk.java.net/browse/JDK-8257822). In this testcase, a `Div` node has no longer its zero check as direct control input and is later moved before the zero check by `IfNode::dominated_by()` which updates all data nodes to a dominating `If` (in JDK-8257822 it was done by `PhaseIdealLoop::dominated_by()`) . > > I suggest to use the same fix for `IfNode::dominated_by()` as for `PhaseIdealLoop::dominated_by()` in JDK-8257822 to only move data nodes to the dominating `If` if it is not a `Div` or `Mod` node that could have a zero divisor (i.e. a zero check). > > Thanks, > Christian Looks good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/89 From sandhya.viswanathan at intel.com Wed Jan 6 18:49:16 2021 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Wed, 6 Jan 2021 18:49:16 +0000 Subject: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions In-Reply-To: References: Message-ID: Hi Andrew, I understand the dilemma. We see ~2x performance gain which is significant, and the patch is very self-contained with no impact on other architectures. CRC calculation is prevalent in big Java frameworks, so the request here. I hope exception can be made for this request. This is my first performance backport request for JDK 11. We do understand the balance that you need to maintain in accepting such requests. Best Regards, Sandhya -----Original Message----- From: Andrew Haley Sent: Wednesday, January 06, 2021 1:57 AM To: Langer, Christoph ; Viswanathan, Sandhya ; Doerr, Martin ; Lindenmaier, Goetz Cc: Vladimir Kozlov ; jdk-updates-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Subject: Re: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions On 12/23/20 1:09 PM, Langer, Christoph wrote: > > as we should be cautious about backports to an LTS release if something is not just a bugfix, I'm not sure whether this backport for a performance enhancement is good to go. Generally, if it can be proven that it's really just a potential performance improvement without side effects to other scenarios, I would be fine with it. But as I'm not an expert in this area, I'd prefer if it there was some further endorsement (or disapproval)... > > @Andrew Haley; @Lindenmaier, Goetz; @Doerr, Martin, what's your assessment? We could backport for a significant performance bottleneck, but I'm leaning toward the idea that JDK 11 is done: we're keeping it going by fixing bugs and adapting to changing environments, but that should be all. However, there are exceptions to every rule! There is a social problem in that maintainers get very demotivated because non-LTS releases are "never used" so people's work doesn't appear in production for years. I'm not sure exactly how to address that, except to say that using the OpenJDK release stream shouldn't be so very scary. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dongbo at openjdk.java.net Thu Jan 7 01:53:59 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Thu, 7 Jan 2021 01:53:59 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v2] In-Reply-To: References: Message-ID: <1uesqHOGE6FbsMN6jcbfiVWT1nYVFpfBqXfrBMTwCIk=.b94cc813-e88f-4cf0-9fe4-474e0911b01d@github.com> On Tue, 5 Jan 2021 11:19:08 GMT, Andrew Haley wrote: >> Dong Bo has updated the pull request incrementally with one additional commit since the last revision: >> >> rebase the .m4 entry > > This all looks reasonable. With the assembler change I think we should be good to go. @theRealAph Hi, is there any further suggestions? :) ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From pli at openjdk.java.net Thu Jan 7 03:06:57 2021 From: pli at openjdk.java.net (Pengfei Li) Date: Thu, 7 Jan 2021 03:06:57 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 13:42:21 GMT, Dong Bo wrote: >> This patch optimizes vectorial Min/Max reduction of two floating-point numbers on aarch64 with NEON instructions `fmaxp` and `fminp`. >> >> Passed jtreg tier1-3 tests with `linux-aarch64-server-fastdebug` build. >> Tests under `test/jdk/jdk/incubator/vector/` runned specially for the correctness and passed. >> >> Introduced a new JMH micro `test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java` for performance test. >> Witnessed abount `37%` performance improvements on Kunpeng916. The JMH Results: >> Benchmark (COUNT) (seed) Mode Cnt Score Error Units >> # Kunpeng 916, default >> VectorReduction.maxRedD 512 0 avgt 10 678.126 ? 0.815 ns/op >> VectorReduction.maxRedF 512 0 avgt 10 242.958 ? 0.212 ns/op >> VectorReduction.minRedD 512 0 avgt 10 678.554 ? 0.824 ns/op >> VectorReduction.minRedF 512 0 avgt 10 243.368 ? 0.205 ns/op >> >> # Kunpeng 916, with fmaxp/fminp >> VectorReduction.maxRedD 512 0 avgt 10 430.201 ? 0.353 ns/op => 36.56% >> VectorReduction.maxRedF 512 0 avgt 10 243.404 ? 0.297 ns/op >> VectorReduction.minRedD 512 0 avgt 10 427.805 ? 0.528 ns/op => 36.89% >> VectorReduction.minRedF 512 0 avgt 10 242.963 ? 0.210 ns/op > > Dong Bo has updated the pull request incrementally with one additional commit since the last revision: > > put faddp/fmaxp/fminp together in a group test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java line 2: > 1: /* > 2: * Copyright (c) 2021, Huawei Technologies Co., Ltd. All rights reserved. Should each new source file also include Oracle copyright? ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From dongbo at openjdk.java.net Thu Jan 7 03:29:12 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Thu, 7 Jan 2021 03:29:12 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v4] In-Reply-To: References: Message-ID: > This patch optimizes vectorial Min/Max reduction of two floating-point numbers on aarch64 with NEON instructions `fmaxp` and `fminp`. > > Passed jtreg tier1-3 tests with `linux-aarch64-server-fastdebug` build. > Tests under `test/jdk/jdk/incubator/vector/` runned specially for the correctness and passed. > > Introduced a new JMH micro `test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java` for performance test. > Witnessed abount `37%` performance improvements on Kunpeng916. The JMH Results: > Benchmark (COUNT) (seed) Mode Cnt Score Error Units > # Kunpeng 916, default > VectorReduction.maxRedD 512 0 avgt 10 678.126 ? 0.815 ns/op > VectorReduction.maxRedF 512 0 avgt 10 242.958 ? 0.212 ns/op > VectorReduction.minRedD 512 0 avgt 10 678.554 ? 0.824 ns/op > VectorReduction.minRedF 512 0 avgt 10 243.368 ? 0.205 ns/op > > # Kunpeng 916, with fmaxp/fminp > VectorReduction.maxRedD 512 0 avgt 10 430.201 ? 0.353 ns/op => 36.56% > VectorReduction.maxRedF 512 0 avgt 10 243.404 ? 0.297 ns/op > VectorReduction.minRedD 512 0 avgt 10 427.805 ? 0.528 ns/op => 36.89% > VectorReduction.minRedF 512 0 avgt 10 242.963 ? 0.210 ns/op Dong Bo has updated the pull request incrementally with one additional commit since the last revision: include Oracle copyright in VectorReductionFloatingMinMax.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1925/files - new: https://git.openjdk.java.net/jdk/pull/1925/files/c0c6f51f..96dc92f8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1925&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1925&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1925.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1925/head:pull/1925 PR: https://git.openjdk.java.net/jdk/pull/1925 From dongbo at openjdk.java.net Thu Jan 7 03:31:58 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Thu, 7 Jan 2021 03:31:58 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 03:03:31 GMT, Pengfei Li wrote: >> Dong Bo has updated the pull request incrementally with one additional commit since the last revision: >> >> put faddp/fmaxp/fminp together in a group > > test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java line 2: > >> 1: /* >> 2: * Copyright (c) 2021, Huawei Technologies Co., Ltd. All rights reserved. > > Should each new source file also include Oracle copyright? Fixed, thank you for mentioning this. ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From jiefu at openjdk.java.net Thu Jan 7 03:55:56 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 7 Jan 2021 03:55:56 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 03:29:34 GMT, Dong Bo wrote: >> test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2021, Huawei Technologies Co., Ltd. All rights reserved. >> >> Should each new source file also include Oracle copyright? > > Fixed, thank you for mentioning this. > Should each new source file also include Oracle copyright? I'm not sure. But there are already some files which don't contain Oracle copyright. @dholmes-ora , what do you think of this question? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From thartmann at openjdk.java.net Thu Jan 7 07:21:57 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 7 Jan 2021 07:21:57 GMT Subject: RFR: 8259339: AllocateUninitializedArray C2 intrinsic fails with void.class input In-Reply-To: <-KTp0-ukOgFyc0kAXlCWYTZU5G-QucduLfIXHccGbpI=.0f05f809-663e-453b-9782-2928bb5490d1@github.com> References: <-KTp0-ukOgFyc0kAXlCWYTZU5G-QucduLfIXHccGbpI=.0f05f809-663e-453b-9782-2928bb5490d1@github.com> Message-ID: On Wed, 6 Jan 2021 18:09:30 GMT, Vladimir Kozlov wrote: >> Since [JDK-8150465](https://bugs.openjdk.java.net/browse/JDK-8150465), `LibraryCallKit::inline_unsafe_newArray` is also used by the `_allocateUninitializedArray` intrinsic. To handle a `void.class` input, a runtime (slow) call to the intrinsified method is emitted. We hit a guarantee in `generate_method_call_static` because a wrong intrinsic id is passed. Also, the call to `Unsafe.allocateUninitializedArray0` should be virtual. >> >> I found this when running Valhalla stress testing with `-XX:PerMethodTrapLimit=0` but it easily reproduces without (see modified test). >> >> Thanks, >> Tobias > > Good. Thanks Vladimir! ------------- PR: https://git.openjdk.java.net/jdk/pull/1965 From github.com+10482586+therealeliu at openjdk.java.net Thu Jan 7 08:13:07 2021 From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu) Date: Thu, 7 Jan 2021 08:13:07 GMT Subject: RFR: 8255339: CodeBuffer::_last_insn is only used on AArch64 Message-ID: CodeBuffer::_last_insn was used to merge consecutive memory barriers and adjacent load/store on AArch64. This patch marks it as AArch64 only so that 8 bytes could be dropped from CodeBuffer on other architectures. ------------- Commit messages: - 8255339: CodeBuffer::_last_insn is only used on AArch64 Changes: https://git.openjdk.java.net/jdk/pull/1971/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1971&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255339 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1971.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1971/head:pull/1971 PR: https://git.openjdk.java.net/jdk/pull/1971 From rcastanedalo at openjdk.java.net Thu Jan 7 08:30:56 2021 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 7 Jan 2021 08:30:56 GMT Subject: RFR: 8256535: C2: randomize CCP processing order for stress testing In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 19:48:32 GMT, Roberto Casta?eda Lozano wrote: >> Tested on hs-tier1-3 with `-XX:+StressCCP -XX:+LogCompilation -XX:RepeatCompilation=20` as requested by @TobiHartmann. All 76 failures have been traced to test code not handling `LogCompilation`, `RepeatCompilation` (for example [JDK-8258682](https://bugs.openjdk.java.net/browse/JDK-8258682)), or both. No failure could be attributed to `StressCCP` itself. Requesting integration. > > Postponing integration until I am back from holidays. Back from holidays, please sponsor. ------------- PR: https://git.openjdk.java.net/jdk/pull/1765 From rcastanedalo at openjdk.java.net Thu Jan 7 08:34:55 2021 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 7 Jan 2021 08:34:55 GMT Subject: RFR: 8257146: C2: extend the scope of StressGCM In-Reply-To: <6GcibhtqhAk99Woc8TYvJA-H-vbemipbzcAC4SJt8TI=.1ddf5895-ac11-4357-bbd8-4b6e71fa5af9@github.com> References: <6GcibhtqhAk99Woc8TYvJA-H-vbemipbzcAC4SJt8TI=.1ddf5895-ac11-4357-bbd8-4b6e71fa5af9@github.com> Message-ID: On Wed, 2 Dec 2020 08:14:32 GMT, Roberto Casta?eda Lozano wrote: >> I agree with deferring it to JDK 17. Meanwhile I suggest to investigate failing cases and file separate bug for them (which can be fixed in JDK 16). > >> I agree with deferring it to JDK 17. Meanwhile I suggest to investigate failing cases and file separate bug for them (which can be fixed in JDK 16). > > OK, thanks for the feedback Aleksey, Vladimir, and Tobias! I will put this PR on hold. This is a comment just to prevent the bot from closing the PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/1469 From rcastanedalo at openjdk.java.net Thu Jan 7 09:35:55 2021 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 7 Jan 2021 09:35:55 GMT Subject: RFR: 8256535: C2: randomize CCP processing order for stress testing In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 08:28:09 GMT, Roberto Casta?eda Lozano wrote: >> Postponing integration until I am back from holidays. > > Back from holidays, please sponsor. I just realized the headers of the touched files need to be update with the current copyright year. Withdrawing request for integration again, sorry for going back and forth. ------------- PR: https://git.openjdk.java.net/jdk/pull/1765 From rcastanedalo at openjdk.java.net Thu Jan 7 09:38:53 2021 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 7 Jan 2021 09:38:53 GMT Subject: RFR: 8258772: Some runtime/cds tests fail with +LogCompilation or +StressX In-Reply-To: References: <9xocwLfdmD9SYuxkUdHE7zVQ71czLjM-gDE4_ySGDZo=.04b6794c-8a24-48d0-87a6-222c4ee7d304@github.com> Message-ID: On Tue, 22 Dec 2020 19:33:06 GMT, Roberto Casta?eda Lozano wrote: >> Good. > >> Good. > > Thanks for the review, Vladimir! > > I will postpone my request for integration until I am back from holidays. I just realized the headers of the touched files need to be update with the current copyright year. Withdrawing request for integration again, sorry for going back and forth. ------------- PR: https://git.openjdk.java.net/jdk/pull/1863 From rcastanedalo at openjdk.java.net Thu Jan 7 10:06:26 2021 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 7 Jan 2021 10:06:26 GMT Subject: RFR: 8258772: Some runtime/cds tests fail with +LogCompilation or +StressX [v2] In-Reply-To: References: Message-ID: > Emit warning about TraceDependencies results in `ClassHierarchyWalker::count_find_witness_calls()` only if `TraceDependencies` is actually enabled. Use standard `warning()` function instead of ad hoc printing. Remove warning about using `Stress(LCM|GCM|IGVN)` without `LogCompilation` in `Compile::Compile()`, and add the information to the description of the `StressSeed` option instead. These changes prevent false test failures when using `LogCompilation` or `Stress(LCM|GCM|IGVN)`. Roberto Casta?eda Lozano has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Update copyright year - Merge branch 'master' into JDK-8258772 - 8258772: Some runtime/cds tests fail with +LogCompilation or +StressX Emit warning about TraceDependencies results in ClassHierarchyWalker::count_find_witness_calls() only if TraceDependencies is actually enabled. Use standard warning() function instead of ad hoc printing. Remove warning about using Stress(LCM|GCM|IGVN) without LogCompilation in Compile::Compile(), and add the information to the description of the StressSeed option instead. These changes prevent false test failures when using LogCompilation or Stress(LCM|GCM|IGVN). ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1863/files - new: https://git.openjdk.java.net/jdk/pull/1863/files/4ef1e830..0ab88cfb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1863&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1863&range=00-01 Stats: 17423 lines in 769 files changed: 3550 ins; 5003 del; 8870 mod Patch: https://git.openjdk.java.net/jdk/pull/1863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1863/head:pull/1863 PR: https://git.openjdk.java.net/jdk/pull/1863 From rcastanedalo at openjdk.java.net Thu Jan 7 10:09:55 2021 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 7 Jan 2021 10:09:55 GMT Subject: RFR: 8258772: Some runtime/cds tests fail with +LogCompilation or +StressX [v2] In-Reply-To: References: <9xocwLfdmD9SYuxkUdHE7zVQ71czLjM-gDE4_ySGDZo=.04b6794c-8a24-48d0-87a6-222c4ee7d304@github.com> Message-ID: On Thu, 7 Jan 2021 09:35:57 GMT, Roberto Casta?eda Lozano wrote: >>> Good. >> >> Thanks for the review, Vladimir! >> >> I will postpone my request for integration until I am back from holidays. > > I just realized the headers of the touched files need to be update with the current copyright year. Withdrawing request for integration again, sorry for going back and forth. Ready for review after updating copyright headers. ------------- PR: https://git.openjdk.java.net/jdk/pull/1863 From thartmann at openjdk.java.net Thu Jan 7 10:16:10 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 7 Jan 2021 10:16:10 GMT Subject: RFR: 8258772: Some runtime/cds tests fail with +LogCompilation or +StressX [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 10:06:26 GMT, Roberto Casta?eda Lozano wrote: >> Emit warning about TraceDependencies results in `ClassHierarchyWalker::count_find_witness_calls()` only if `TraceDependencies` is actually enabled. Use standard `warning()` function instead of ad hoc printing. Remove warning about using `Stress(LCM|GCM|IGVN)` without `LogCompilation` in `Compile::Compile()`, and add the information to the description of the `StressSeed` option instead. These changes prevent false test failures when using `LogCompilation` or `Stress(LCM|GCM|IGVN)`. > > Roberto Casta?eda Lozano has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Update copyright year > - Merge branch 'master' into JDK-8258772 > - 8258772: Some runtime/cds tests fail with +LogCompilation or +StressX > > Emit warning about TraceDependencies results in > ClassHierarchyWalker::count_find_witness_calls() only if TraceDependencies is > actually enabled. Use standard warning() function instead of ad hoc printing. > Remove warning about using Stress(LCM|GCM|IGVN) without LogCompilation in > Compile::Compile(), and add the information to the description of the StressSeed > option instead. These changes prevent false test failures when using > LogCompilation or Stress(LCM|GCM|IGVN). Marked as reviewed by thartmann (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1863 From chagedorn at openjdk.java.net Thu Jan 7 10:16:06 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Thu, 7 Jan 2021 10:16:06 GMT Subject: RFR: 8258772: Some runtime/cds tests fail with +LogCompilation or +StressX [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 10:06:26 GMT, Roberto Casta?eda Lozano wrote: >> Emit warning about TraceDependencies results in `ClassHierarchyWalker::count_find_witness_calls()` only if `TraceDependencies` is actually enabled. Use standard `warning()` function instead of ad hoc printing. Remove warning about using `Stress(LCM|GCM|IGVN)` without `LogCompilation` in `Compile::Compile()`, and add the information to the description of the `StressSeed` option instead. These changes prevent false test failures when using `LogCompilation` or `Stress(LCM|GCM|IGVN)`. > > Roberto Casta?eda Lozano has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Update copyright year > - Merge branch 'master' into JDK-8258772 > - 8258772: Some runtime/cds tests fail with +LogCompilation or +StressX > > Emit warning about TraceDependencies results in > ClassHierarchyWalker::count_find_witness_calls() only if TraceDependencies is > actually enabled. Use standard warning() function instead of ad hoc printing. > Remove warning about using Stress(LCM|GCM|IGVN) without LogCompilation in > Compile::Compile(), and add the information to the description of the StressSeed > option instead. These changes prevent false test failures when using > LogCompilation or Stress(LCM|GCM|IGVN). Marked as reviewed by chagedorn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1863 From chagedorn at openjdk.java.net Thu Jan 7 10:16:05 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Thu, 7 Jan 2021 10:16:05 GMT Subject: [jdk16] RFR: 8259227: C2 crashes with SIGFPE due to a division that floats above its zero check In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 18:11:55 GMT, Vladimir Kozlov wrote: >> This bug is very similar to [JDK-8257822](https://bugs.openjdk.java.net/browse/JDK-8257822). In this testcase, a `Div` node has no longer its zero check as direct control input and is later moved before the zero check by `IfNode::dominated_by()` which updates all data nodes to a dominating `If` (in JDK-8257822 it was done by `PhaseIdealLoop::dominated_by()`) . >> >> I suggest to use the same fix for `IfNode::dominated_by()` as for `PhaseIdealLoop::dominated_by()` in JDK-8257822 to only move data nodes to the dominating `If` if it is not a `Div` or `Mod` node that could have a zero divisor (i.e. a zero check). >> >> Thanks, >> Christian > > Looks good. Thanks for your review Vladimir! ------------- PR: https://git.openjdk.java.net/jdk16/pull/89 From martin.doerr at sap.com Thu Jan 7 10:26:23 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 7 Jan 2021 10:26:23 +0000 Subject: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions In-Reply-To: References: Message-ID: Hello everybody, I think 2x performance improvement for CRC32 computations is a good argument. The original change is tested for quite some time and didn't cause follow-up issues. Backport is simple and was already reviewed. So I'd vote for taking it after running it through testing. Best regards, Martin > -----Original Message----- > From: Viswanathan, Sandhya > Sent: Mittwoch, 6. Januar 2021 19:49 > To: Andrew Haley ; Langer, Christoph > ; Doerr, Martin ; > Lindenmaier, Goetz > Cc: Vladimir Kozlov ; jdk-updates- > dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net > Subject: RE: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions > > Hi Andrew, > > I understand the dilemma. > We see ~2x performance gain which is significant, and the patch is very self- > contained with no impact on other architectures. > CRC calculation is prevalent in big Java frameworks, so the request here. > I hope exception can be made for this request. > > This is my first performance backport request for JDK 11. We do understand > the balance that you need to maintain in accepting such requests. > > Best Regards, > Sandhya > > -----Original Message----- > From: Andrew Haley > Sent: Wednesday, January 06, 2021 1:57 AM > To: Langer, Christoph ; Viswanathan, Sandhya > ; Doerr, Martin > ; Lindenmaier, Goetz > > Cc: Vladimir Kozlov ; jdk-updates- > dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net > Subject: Re: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions > > On 12/23/20 1:09 PM, Langer, Christoph wrote: > > > > as we should be cautious about backports to an LTS release if something is > not just a bugfix, I'm not sure whether this backport for a performance > enhancement is good to go. Generally, if it can be proven that it's really just a > potential performance improvement without side effects to other scenarios, > I would be fine with it. But as I'm not an expert in this area, I'd prefer if it > there was some further endorsement (or disapproval)... > > > > @Andrew Haley; @Lindenmaier, Goetz; @Doerr, Martin, what's your > assessment? > > We could backport for a significant performance bottleneck, but I'm leaning > toward the idea that JDK 11 is done: we're keeping it going by fixing bugs and > adapting to changing environments, but that should be all. > > However, there are exceptions to every rule! > > There is a social problem in that maintainers get very demotivated because > non-LTS releases are "never used" so people's work doesn't appear in > production for years. I'm not sure exactly how to address that, except to say > that using the OpenJDK release stream shouldn't be so very scary. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thartmann at openjdk.java.net Thu Jan 7 11:01:02 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 7 Jan 2021 11:01:02 GMT Subject: [jdk16] RFR: 8259227: C2 crashes with SIGFPE due to a division that floats above its zero check In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 13:43:17 GMT, Christian Hagedorn wrote: > This bug is very similar to [JDK-8257822](https://bugs.openjdk.java.net/browse/JDK-8257822). In this testcase, a `Div` node has no longer its zero check as direct control input and is later moved before the zero check by `IfNode::dominated_by()` which updates all data nodes to a dominating `If` (in JDK-8257822 it was done by `PhaseIdealLoop::dominated_by()`) . > > I suggest to use the same fix for `IfNode::dominated_by()` as for `PhaseIdealLoop::dominated_by()` in JDK-8257822 to only move data nodes to the dominating `If` if it is not a `Div` or `Mod` node that could have a zero divisor (i.e. a zero check). > > Thanks, > Christian Otherwise looks good to me. test/hotspot/jtreg/compiler/loopopts/TestDivZeroDominatedBy.java line 31: > 29: * @requires vm.compiler2.enabled > 30: * @run main/othervm -Xcomp -XX:-TieredCompilation -XX:CompileOnly=compiler/loopopts/TestDivZeroDominatedBy::test > 31: * -XX:+UnlockDiagnosticVMOptions -XX:+StressGCM -XX:StressSeed=917280111 compiler.loopopts.TestDivZeroDominatedBy Just wondering if the `StressSeed` should really be hardcoded? If things change in the VM, this seed might not longer reproduce the issue. Maybe add another `@run `with no fixed seed? ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/89 From aph at redhat.com Thu Jan 7 11:16:40 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Jan 2021 11:16:40 +0000 Subject: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions In-Reply-To: References: Message-ID: <47c6e7c8-beb1-64ed-b134-6e276f781088@redhat.com> On 1/7/21 10:26 AM, Doerr, Martin wrote: > I think 2x performance improvement for CRC32 computations is a > good argument. It's not 2x for everybody, just the relatively small number of AVX-512 users, and as we've seen AVX 512 throttling can slow down other operations. That 2x isn't free: it is accompanied by increased power consumption. We don't know the future of AVX-512. Rumours say it's not going to be included in Alder Lake-S, Intel?s first 10nm mainstream desktop processor. I don't think the 10900K Comet Lake supports it either. But I admit it does look like Xeons are going to support AVX-512 for some time, so perhaps. The question is this: is it appropriate to backport a special-case accelerator for CRC32C that works on a smallish segment of deployed systems to an LTS release of OpenJDK? I could go either way. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at openjdk.java.net Thu Jan 7 11:21:57 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 7 Jan 2021 11:21:57 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 13:42:21 GMT, Dong Bo wrote: >> This patch optimizes vectorial Min/Max reduction of two floating-point numbers on aarch64 with NEON instructions `fmaxp` and `fminp`. >> >> Passed jtreg tier1-3 tests with `linux-aarch64-server-fastdebug` build. >> Tests under `test/jdk/jdk/incubator/vector/` runned specially for the correctness and passed. >> >> Introduced a new JMH micro `test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java` for performance test. >> Witnessed abount `37%` performance improvements on Kunpeng916. The JMH Results: >> Benchmark (COUNT) (seed) Mode Cnt Score Error Units >> # Kunpeng 916, default >> VectorReduction.maxRedD 512 0 avgt 10 678.126 ? 0.815 ns/op >> VectorReduction.maxRedF 512 0 avgt 10 242.958 ? 0.212 ns/op >> VectorReduction.minRedD 512 0 avgt 10 678.554 ? 0.824 ns/op >> VectorReduction.minRedF 512 0 avgt 10 243.368 ? 0.205 ns/op >> >> # Kunpeng 916, with fmaxp/fminp >> VectorReduction.maxRedD 512 0 avgt 10 430.201 ? 0.353 ns/op => 36.56% >> VectorReduction.maxRedF 512 0 avgt 10 243.404 ? 0.297 ns/op >> VectorReduction.minRedD 512 0 avgt 10 427.805 ? 0.528 ns/op => 36.89% >> VectorReduction.minRedF 512 0 avgt 10 242.963 ? 0.210 ns/op > > Dong Bo has updated the pull request incrementally with one additional commit since the last revision: > > put faddp/fmaxp/fminp together in a group Changes requested by aph (Reviewer). test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java line 67: > 65: for (int i = 0; i < COUNT; i++) { > 66: max = Math.max(max, floatsA[i] - floatsB[i]); > 67: } This test code looks a bit contrived. If you're looking for the smallest delta it'd be Math.max(max, Math.abs(floatsA[i] - floatsB[i])); and if you're looking for the smallest value it'd probably be Math.max(max, floatsA[i]); Do we gain any advantage with these? ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From thartmann at openjdk.java.net Thu Jan 7 12:19:02 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 7 Jan 2021 12:19:02 GMT Subject: RFR: 8259339: AllocateUninitializedArray C2 intrinsic fails with void.class input In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 12:14:14 GMT, Christian Hagedorn wrote: >> Since [JDK-8150465](https://bugs.openjdk.java.net/browse/JDK-8150465), `LibraryCallKit::inline_unsafe_newArray` is also used by the `_allocateUninitializedArray` intrinsic. To handle a `void.class` input, a runtime (slow) call to the intrinsified method is emitted. We hit a guarantee in `generate_method_call_static` because a wrong intrinsic id is passed. Also, the call to `Unsafe.allocateUninitializedArray0` should be virtual. >> >> I found this when running Valhalla stress testing with `-XX:PerMethodTrapLimit=0` but it easily reproduces without (see modified test). >> >> Thanks, >> Tobias > > Looks good! Thanks Christian! ------------- PR: https://git.openjdk.java.net/jdk/pull/1965 From thartmann at openjdk.java.net Thu Jan 7 12:19:03 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 7 Jan 2021 12:19:03 GMT Subject: Integrated: 8259339: AllocateUninitializedArray C2 intrinsic fails with void.class input In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 17:38:00 GMT, Tobias Hartmann wrote: > Since [JDK-8150465](https://bugs.openjdk.java.net/browse/JDK-8150465), `LibraryCallKit::inline_unsafe_newArray` is also used by the `_allocateUninitializedArray` intrinsic. To handle a `void.class` input, a runtime (slow) call to the intrinsified method is emitted. We hit a guarantee in `generate_method_call_static` because a wrong intrinsic id is passed. Also, the call to `Unsafe.allocateUninitializedArray0` should be virtual. > > I found this when running Valhalla stress testing with `-XX:PerMethodTrapLimit=0` but it easily reproduces without (see modified test). > > Thanks, > Tobias This pull request has now been integrated. Changeset: 0e6de4eb Author: Tobias Hartmann URL: https://git.openjdk.java.net/jdk/commit/0e6de4eb Stats: 20 lines in 2 files changed: 16 ins; 0 del; 4 mod 8259339: AllocateUninitializedArray C2 intrinsic fails with void.class input Reviewed-by: kvn, chagedorn ------------- PR: https://git.openjdk.java.net/jdk/pull/1965 From chagedorn at openjdk.java.net Thu Jan 7 12:19:02 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Thu, 7 Jan 2021 12:19:02 GMT Subject: RFR: 8259339: AllocateUninitializedArray C2 intrinsic fails with void.class input In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 17:38:00 GMT, Tobias Hartmann wrote: > Since [JDK-8150465](https://bugs.openjdk.java.net/browse/JDK-8150465), `LibraryCallKit::inline_unsafe_newArray` is also used by the `_allocateUninitializedArray` intrinsic. To handle a `void.class` input, a runtime (slow) call to the intrinsified method is emitted. We hit a guarantee in `generate_method_call_static` because a wrong intrinsic id is passed. Also, the call to `Unsafe.allocateUninitializedArray0` should be virtual. > > I found this when running Valhalla stress testing with `-XX:PerMethodTrapLimit=0` but it easily reproduces without (see modified test). > > Thanks, > Tobias Looks good! ------------- Marked as reviewed by chagedorn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1965 From fweimer at redhat.com Thu Jan 7 12:24:44 2021 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 07 Jan 2021 13:24:44 +0100 Subject: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions In-Reply-To: <47c6e7c8-beb1-64ed-b134-6e276f781088@redhat.com> (Andrew Haley's message of "Thu, 7 Jan 2021 11:16:40 +0000") References: <47c6e7c8-beb1-64ed-b134-6e276f781088@redhat.com> Message-ID: <875z490wab.fsf@oldenburg2.str.redhat.com> * Andrew Haley: > We don't know the future of AVX-512. Rumours say it's not going > to be included in Alder Lake-S, Intel?s first 10nm mainstream > desktop processor. I don't think the 10900K Comet Lake supports > it either. But I admit it does look like Xeons are going to > support AVX-512 for some time, so perhaps. AVX-512 support has started to appear in non-server CPUs with Tiger Lake: There certainly were issues around power consumption and the internal turbo license for previous implementations of AVX-512. But that's largely a question for mainline defaults: If the change is not generally beneficial and only looks good in certain micro-benchmarks, it's probably not appropriate for mainline either, at least not by default. I don't know to what extent it is necessary to reconsider mainline optimization choices in a backport. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill From shade at openjdk.java.net Thu Jan 7 13:45:15 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 7 Jan 2021 13:45:15 GMT Subject: RFR: 8259368: Zero: UseCompressedClassPointers does not depend on UseCompressedOops Message-ID: JDK-8241825 decoupled `UseCompressedClassPointers` and `UseCompressedOops`, and introduced `COMPRESSED_CLASS_POINTERS_DEPENDS_ON_COMPRESSED_OOPS` that platforms can set to say if their generated code is ready for this decoupling. Zero defaults to `true` for that flag, meaning the flags are still coupled. But there is not actual coupling: Zero delegates all this work to VM code, which handles everything correctly. This makes at least one test fail with Zero: $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=runtime/CompressedOops/CompressedClassPointers.java java.lang.RuntimeException: 'Narrow klass base: 0x0000000000000000' missing from stdout/stderr ... Additional testing: - [x] Linux x86_64 Zero `runtime/CompressedOops/` tests ------------- Commit messages: - 8259368: Zero: UseCompressedClassPointers does not depend on UseCompressedOops Changes: https://git.openjdk.java.net/jdk/pull/1973/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1973&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259368 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1973.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1973/head:pull/1973 PR: https://git.openjdk.java.net/jdk/pull/1973 From hohensee at amazon.com Thu Jan 7 14:12:55 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 7 Jan 2021 14:12:55 +0000 Subject: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions Message-ID: If AVX512 support were to be removed, the addition of this patch would not make removal more difficult. I agree with Martin: given that the patch is small, well tested, and of limited scope, I'm in favor of accepting it. Thanks, Paul ?-----Original Message----- From: hotspot-compiler-dev on behalf of Florian Weimer Date: Thursday, January 7, 2021 at 4:25 AM To: Andrew Haley Cc: "Doerr, Martin" , "Viswanathan, Sandhya" , "Langer, Christoph" , "Lindenmaier, Goetz" , Vladimir Kozlov , "jdk-updates-dev at openjdk.java.net" , "hotspot-compiler-dev at openjdk.java.net" Subject: RE: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions * Andrew Haley: > We don't know the future of AVX-512. Rumours say it's not going > to be included in Alder Lake-S, Intel?s first 10nm mainstream > desktop processor. I don't think the 10900K Comet Lake supports > it either. But I admit it does look like Xeons are going to > support AVX-512 for some time, so perhaps. AVX-512 support has started to appear in non-server CPUs with Tiger Lake: There certainly were issues around power consumption and the internal turbo license for previous implementations of AVX-512. But that's largely a question for mainline defaults: If the change is not generally beneficial and only looks good in certain micro-benchmarks, it's probably not appropriate for mainline either, at least not by default. I don't know to what extent it is necessary to reconsider mainline optimization choices in a backport. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill From christoph.langer at sap.com Thu Jan 7 14:18:13 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 7 Jan 2021 14:18:13 +0000 Subject: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions In-Reply-To: References: Message-ID: Hi, with the discussion/information so far I also tend to accept it. Andrew, please make the final call ?? Best regards Christoph > -----Original Message----- > From: Hohensee, Paul > Sent: Donnerstag, 7. Januar 2021 15:13 > To: Florian Weimer ; Andrew Haley > > Cc: Doerr, Martin ; Viswanathan, Sandhya > ; Langer, Christoph > ; Lindenmaier, Goetz > ; Vladimir Kozlov > ; jdk-updates-dev at openjdk.java.net; > hotspot-compiler-dev at openjdk.java.net > Subject: Re: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions > > If AVX512 support were to be removed, the addition of this patch would not > make removal more difficult. I agree with Martin: given that the patch is > small, well tested, and of limited scope, I'm in favor of accepting it. > > Thanks, > Paul > > ?-----Original Message----- > From: hotspot-compiler-dev retn at openjdk.java.net> on behalf of Florian Weimer > > Date: Thursday, January 7, 2021 at 4:25 AM > To: Andrew Haley > Cc: "Doerr, Martin" , "Viswanathan, Sandhya" > , "Langer, Christoph" > , "Lindenmaier, Goetz" > , Vladimir Kozlov > , "jdk-updates-dev at openjdk.java.net" updates-dev at openjdk.java.net>, "hotspot-compiler- > dev at openjdk.java.net" > Subject: RE: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions > > * Andrew Haley: > > > We don't know the future of AVX-512. Rumours say it's not going > > to be included in Alder Lake-S, Intel?s first 10nm mainstream > > desktop processor. I don't think the 10900K Comet Lake supports > > it either. But I admit it does look like Xeons are going to > > support AVX-512 for some time, so perhaps. > > AVX-512 support has started to appear in non-server CPUs with Tiger > Lake: > > core-i3-1125g4-processor-8m-cache-up-to-3-70-ghz.html> > > There certainly were issues around power consumption and the internal > turbo license for previous implementations of AVX-512. But that's > largely a question for mainline defaults: If the change is not generally > beneficial and only looks good in certain micro-benchmarks, it's > probably not appropriate for mainline either, at least not by default. > I don't know to what extent it is necessary to reconsider mainline > optimization choices in a backport. > > Thanks, > Florian > -- > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael > O'Neill > From thartmann at openjdk.java.net Thu Jan 7 14:56:21 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 7 Jan 2021 14:56:21 GMT Subject: [jdk16] RFR: 8259227: C2 crashes with SIGFPE due to a division that floats above its zero check [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 14:53:26 GMT, Christian Hagedorn wrote: >> This bug is very similar to [JDK-8257822](https://bugs.openjdk.java.net/browse/JDK-8257822). In this testcase, a `Div` node has no longer its zero check as direct control input and is later moved before the zero check by `IfNode::dominated_by()` which updates all data nodes to a dominating `If` (in JDK-8257822 it was done by `PhaseIdealLoop::dominated_by()`) . >> >> I suggest to use the same fix for `IfNode::dominated_by()` as for `PhaseIdealLoop::dominated_by()` in JDK-8257822 to only move data nodes to the dominating `If` if it is not a `Div` or `Mod` node that could have a zero divisor (i.e. a zero check). >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > > > Add additional runs without fixed seed Thanks for updating, looks good! ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/89 From chagedorn at openjdk.java.net Thu Jan 7 14:56:22 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Thu, 7 Jan 2021 14:56:22 GMT Subject: [jdk16] RFR: 8259227: C2 crashes with SIGFPE due to a division that floats above its zero check [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 10:57:53 GMT, Tobias Hartmann wrote: >> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: >> >> >> >> Add additional runs without fixed seed > > test/hotspot/jtreg/compiler/loopopts/TestDivZeroDominatedBy.java line 31: > >> 29: * @requires vm.compiler2.enabled >> 30: * @run main/othervm -Xcomp -XX:-TieredCompilation -XX:CompileOnly=compiler/loopopts/TestDivZeroDominatedBy::test >> 31: * -XX:+UnlockDiagnosticVMOptions -XX:+StressGCM -XX:StressSeed=917280111 compiler.loopopts.TestDivZeroDominatedBy > > Just wondering if the `StressSeed` should really be hardcoded? If things change in the VM, this seed might not longer reproduce the issue. Maybe add another `@run `with no fixed seed? Good idea. I also updated the test from JDK-8257822 with such an additional run. ------------- PR: https://git.openjdk.java.net/jdk16/pull/89 From chagedorn at openjdk.java.net Thu Jan 7 14:56:21 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Thu, 7 Jan 2021 14:56:21 GMT Subject: [jdk16] RFR: 8259227: C2 crashes with SIGFPE due to a division that floats above its zero check [v2] In-Reply-To: References: Message-ID: > This bug is very similar to [JDK-8257822](https://bugs.openjdk.java.net/browse/JDK-8257822). In this testcase, a `Div` node has no longer its zero check as direct control input and is later moved before the zero check by `IfNode::dominated_by()` which updates all data nodes to a dominating `If` (in JDK-8257822 it was done by `PhaseIdealLoop::dominated_by()`) . > > I suggest to use the same fix for `IfNode::dominated_by()` as for `PhaseIdealLoop::dominated_by()` in JDK-8257822 to only move data nodes to the dominating `If` if it is not a `Div` or `Mod` node that could have a zero divisor (i.e. a zero check). > > Thanks, > Christian Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: Add additional runs without fixed seed ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/89/files - new: https://git.openjdk.java.net/jdk16/pull/89/files/4273fcfb..461681a6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=89&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=89&range=00-01 Stats: 7 lines in 2 files changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/89.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/89/head:pull/89 PR: https://git.openjdk.java.net/jdk16/pull/89 From chagedorn at openjdk.java.net Thu Jan 7 14:59:57 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Thu, 7 Jan 2021 14:59:57 GMT Subject: [jdk16] RFR: 8259227: C2 crashes with SIGFPE due to a division that floats above its zero check [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 14:52:50 GMT, Tobias Hartmann wrote: >> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: >> >> >> >> Add additional runs without fixed seed > > Thanks for updating, looks good! Thanks Tobias for your review! ------------- PR: https://git.openjdk.java.net/jdk16/pull/89 From chagedorn at openjdk.java.net Thu Jan 7 15:05:58 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Thu, 7 Jan 2021 15:05:58 GMT Subject: [jdk16] Integrated: 8259227: C2 crashes with SIGFPE due to a division that floats above its zero check In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 13:43:17 GMT, Christian Hagedorn wrote: > This bug is very similar to [JDK-8257822](https://bugs.openjdk.java.net/browse/JDK-8257822). In this testcase, a `Div` node has no longer its zero check as direct control input and is later moved before the zero check by `IfNode::dominated_by()` which updates all data nodes to a dominating `If` (in JDK-8257822 it was done by `PhaseIdealLoop::dominated_by()`) . > > I suggest to use the same fix for `IfNode::dominated_by()` as for `PhaseIdealLoop::dominated_by()` in JDK-8257822 to only move data nodes to the dominating `If` if it is not a `Div` or `Mod` node that could have a zero divisor (i.e. a zero check). > > Thanks, > Christian This pull request has now been integrated. Changeset: c1fb5216 Author: Christian Hagedorn URL: https://git.openjdk.java.net/jdk16/commit/c1fb5216 Stats: 131 lines in 7 files changed: 105 ins; 22 del; 4 mod 8259227: C2 crashes with SIGFPE due to a division that floats above its zero check Reviewed-by: kvn, thartmann ------------- PR: https://git.openjdk.java.net/jdk16/pull/89 From aph at redhat.com Thu Jan 7 15:49:23 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Jan 2021 15:49:23 +0000 Subject: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions In-Reply-To: References: Message-ID: On 07/01/2021 14:18, Langer, Christoph wrote: > with the discussion/information so far I also tend to accept it. Andrew, please make the final call ?? OK. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From coleenp at openjdk.java.net Thu Jan 7 18:31:09 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Jan 2021 18:31:09 GMT Subject: RFR: 8259373: c1 and jvmci runtime code use ResetNoHandleMark incorrectly Message-ID: Please review this trivial change to the compiler runtime code. See CR for details. Tested with tier1-3. ------------- Commit messages: - 8259373: c1 and jvmci runtime code use ResetNoHandleMark incorrectly Changes: https://git.openjdk.java.net/jdk/pull/1982/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1982&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259373 Stats: 17 lines in 3 files changed: 1 ins; 6 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/1982.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1982/head:pull/1982 PR: https://git.openjdk.java.net/jdk/pull/1982 From redestad at openjdk.java.net Thu Jan 7 18:37:58 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 7 Jan 2021 18:37:58 GMT Subject: RFR: 8258792: LogCompilation: remove redundant check fixed by 8257518 In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 16:44:39 GMT, Eric Caspole wrote: > There is no need to do the same check again doing -U processing, it is already done during XML parsing. Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1860 From rcastanedalo at openjdk.java.net Thu Jan 7 18:49:56 2021 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 7 Jan 2021 18:49:56 GMT Subject: RFR: 8258772: Some runtime/cds tests fail with +LogCompilation or +StressX [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 10:13:13 GMT, Tobias Hartmann wrote: >> Roberto Casta?eda Lozano has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Update copyright year >> - Merge branch 'master' into JDK-8258772 >> - 8258772: Some runtime/cds tests fail with +LogCompilation or +StressX >> >> Emit warning about TraceDependencies results in >> ClassHierarchyWalker::count_find_witness_calls() only if TraceDependencies is >> actually enabled. Use standard warning() function instead of ad hoc printing. >> Remove warning about using Stress(LCM|GCM|IGVN) without LogCompilation in >> Compile::Compile(), and add the information to the description of the StressSeed >> option instead. These changes prevent false test failures when using >> LogCompilation or Stress(LCM|GCM|IGVN). > > Marked as reviewed by thartmann (Reviewer). Thanks for re-reviewing, Christian and Tobias! ------------- PR: https://git.openjdk.java.net/jdk/pull/1863 From rcastanedalo at openjdk.java.net Thu Jan 7 19:00:55 2021 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 7 Jan 2021 19:00:55 GMT Subject: Integrated: 8258772: Some runtime/cds tests fail with +LogCompilation or +StressX In-Reply-To: References: Message-ID: <5OffhvqMNt0ofpC-LhYGZScDdNaPmzCq1y0smt9fh3M=.65df502e-34b1-4b13-8307-b8a16e60c9ae@github.com> On Tue, 22 Dec 2020 09:13:45 GMT, Roberto Casta?eda Lozano wrote: > Emit warning about TraceDependencies results in `ClassHierarchyWalker::count_find_witness_calls()` only if `TraceDependencies` is actually enabled. Use standard `warning()` function instead of ad hoc printing. Remove warning about using `Stress(LCM|GCM|IGVN)` without `LogCompilation` in `Compile::Compile()`, and add the information to the description of the `StressSeed` option instead. These changes prevent false test failures when using `LogCompilation` or `Stress(LCM|GCM|IGVN)`. This pull request has now been integrated. Changeset: d8ad6301 Author: Roberto Casta?eda Lozano Committer: Vladimir Kozlov URL: https://git.openjdk.java.net/jdk/commit/d8ad6301 Stats: 9 lines in 3 files changed: 1 ins; 2 del; 6 mod 8258772: Some runtime/cds tests fail with +LogCompilation or +StressX Emit warning about TraceDependencies results in ClassHierarchyWalker::count_find_witness_calls() only if TraceDependencies is actually enabled. Use standard warning() function instead of ad hoc printing. Remove warning about using Stress(LCM|GCM|IGVN) without LogCompilation in Compile::Compile(), and add the information to the description of the StressSeed option instead. These changes prevent false test failures when using LogCompilation or Stress(LCM|GCM|IGVN). Reviewed-by: chagedorn, kvn, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/1863 From kvn at openjdk.java.net Thu Jan 7 19:08:55 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 7 Jan 2021 19:08:55 GMT Subject: RFR: 8259373: c1 and jvmci runtime code use ResetNoHandleMark incorrectly In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 18:26:26 GMT, Coleen Phillimore wrote: > Please review this trivial change to the compiler runtime code. See CR for details. Tested with tier1-3. Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1982 From rcastanedalo at openjdk.java.net Thu Jan 7 19:25:25 2021 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 7 Jan 2021 19:25:25 GMT Subject: RFR: 8256535: C2: randomize CCP processing order for stress testing [v2] In-Reply-To: References: Message-ID: > Add `StressCCP` option to randomize the selection of the node to be examined in each CCP iteration. Roberto Casta?eda Lozano has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Update copyright year - Merge branch 'master' into JDK-8256535 - Merge branch 'master' into JDK-8256535 - Add missing bug reference - 8256535: C2: randomize CCP processing order for stress testing Add 'StressCCP' option to randomize the selection of the node to be examined in each CCP iteration. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1765/files - new: https://git.openjdk.java.net/jdk/pull/1765/files/95d2cae3..ba182c7e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1765&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1765&range=00-01 Stats: 48323 lines in 1564 files changed: 26858 ins; 9646 del; 11819 mod Patch: https://git.openjdk.java.net/jdk/pull/1765.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1765/head:pull/1765 PR: https://git.openjdk.java.net/jdk/pull/1765 From rcastanedalo at openjdk.java.net Thu Jan 7 19:57:54 2021 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 7 Jan 2021 19:57:54 GMT Subject: RFR: 8256535: C2: randomize CCP processing order for stress testing [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 09:33:01 GMT, Roberto Casta?eda Lozano wrote: >> Back from holidays, please sponsor. > > I just realized the headers of the touched files need to be update with the current copyright year. Withdrawing request for integration again, sorry for going back and forth. Ready for review after updating copyright headers. ------------- PR: https://git.openjdk.java.net/jdk/pull/1765 From kvn at openjdk.java.net Thu Jan 7 20:07:05 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 7 Jan 2021 20:07:05 GMT Subject: RFR: 8256535: C2: randomize CCP processing order for stress testing [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 19:25:25 GMT, Roberto Casta?eda Lozano wrote: >> Add `StressCCP` option to randomize the selection of the node to be examined in each CCP iteration. > > Roberto Casta?eda Lozano has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Update copyright year > - Merge branch 'master' into JDK-8256535 > - Merge branch 'master' into JDK-8256535 > - Add missing bug reference > - 8256535: C2: randomize CCP processing order for stress testing > > Add 'StressCCP' option to randomize the selection of the node to be examined in > each CCP iteration. Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1765 From kvn at openjdk.java.net Thu Jan 7 20:07:08 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 7 Jan 2021 20:07:08 GMT Subject: RFR: 8256535: C2: randomize CCP processing order for stress testing [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 20:02:17 GMT, Vladimir Kozlov wrote: >> Roberto Casta?eda Lozano has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Update copyright year >> - Merge branch 'master' into JDK-8256535 >> - Merge branch 'master' into JDK-8256535 >> - Add missing bug reference >> - 8256535: C2: randomize CCP processing order for stress testing >> >> Add 'StressCCP' option to randomize the selection of the node to be examined in >> each CCP iteration. > > Good. I don't think you need to wait all reviews again. You only updated Copyright years. I can sponsor after you integrate it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1765 From rcastanedalo at openjdk.java.net Thu Jan 7 20:12:59 2021 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 7 Jan 2021 20:12:59 GMT Subject: RFR: 8256535: C2: randomize CCP processing order for stress testing [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 20:04:09 GMT, Vladimir Kozlov wrote: > I don't think you need to wait all reviews again. You only updated Copyright years. I can sponsor after you integrate it. OK, thanks for re-reviewing Vladimir! ------------- PR: https://git.openjdk.java.net/jdk/pull/1765 From coleenp at openjdk.java.net Thu Jan 7 20:25:55 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Jan 2021 20:25:55 GMT Subject: RFR: 8259373: c1 and jvmci runtime code use ResetNoHandleMark incorrectly In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 19:05:48 GMT, Vladimir Kozlov wrote: >> Please review this trivial change to the compiler runtime code. See CR for details. Tested with tier1-3. > > Good. Thanks Vladimir. Trivial too? ------------- PR: https://git.openjdk.java.net/jdk/pull/1982 From iveresov at openjdk.java.net Thu Jan 7 20:36:07 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Thu, 7 Jan 2021 20:36:07 GMT Subject: RFR: 8251462: Remove legacy compilation policy Message-ID: This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! ------------- Commit messages: - Fix copyright years - Remove legacy compilation policy. Changes: https://git.openjdk.java.net/jdk/pull/1985/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251462 Stats: 5285 lines in 95 files changed: 1481 ins; 2979 del; 825 mod Patch: https://git.openjdk.java.net/jdk/pull/1985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1985/head:pull/1985 PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Thu Jan 7 20:45:55 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 7 Jan 2021 20:45:55 GMT Subject: RFR: 8259373: c1 and jvmci runtime code use ResetNoHandleMark incorrectly In-Reply-To: References: Message-ID: <_KyFN3um0BM8uHCiq3EOmBAkq-KnQcjtj5bO0IuDLBY=.293e1b40-9afe-4db9-94ee-30ae0bfc46ed@github.com> On Thu, 7 Jan 2021 20:22:46 GMT, Coleen Phillimore wrote: > Thanks Vladimir. Trivial too? Yes, trivial. What testing you did? ------------- PR: https://git.openjdk.java.net/jdk/pull/1982 From rcastanedalo at openjdk.java.net Thu Jan 7 20:46:59 2021 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 7 Jan 2021 20:46:59 GMT Subject: Integrated: 8256535: C2: randomize CCP processing order for stress testing In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 12:35:07 GMT, Roberto Casta?eda Lozano wrote: > Add `StressCCP` option to randomize the selection of the node to be examined in each CCP iteration. This pull request has now been integrated. Changeset: bc565414 Author: Roberto Casta?eda Lozano Committer: Vladimir Kozlov URL: https://git.openjdk.java.net/jdk/commit/bc565414 Stats: 267 lines in 8 files changed: 146 ins; 114 del; 7 mod 8256535: C2: randomize CCP processing order for stress testing Add 'StressCCP' option to randomize the selection of the node to be examined in each CCP iteration. Reviewed-by: chagedorn, kvn, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/1765 From cjplummer at openjdk.java.net Thu Jan 7 20:54:01 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 7 Jan 2021 20:54:01 GMT Subject: RFR: 8251462: Remove legacy compilation policy In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 18:43:51 GMT, Igor Veresov wrote: > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. > > Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.java line 35: > 33: * While running the thread, it calls a method (doTask2() ) for number of times (10000). > 34: * That would cause this method to be compiled, which causes a jvmti callback for compiled method load. > 35: * (Hint : to force method compilation -XX:CompileThreshold=900 is used). The test still uses (and the comments state it uses) -XX:CompileThreshold=900 to force compilation, yet it looks like you needed to bump the number of times the method is called from 1000 to 10000 to keep this test working. Why doesn't 1000 still work? ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From sandhya.viswanathan at intel.com Thu Jan 7 21:08:09 2021 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Thu, 7 Jan 2021 21:08:09 +0000 Subject: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions In-Reply-To: References: Message-ID: Thanks so much! Best Regards, Sandhya -----Original Message----- From: Andrew Haley Sent: Thursday, January 07, 2021 7:49 AM To: Langer, Christoph ; Hohensee, Paul ; Florian Weimer Cc: Doerr, Martin ; Viswanathan, Sandhya ; Lindenmaier, Goetz ; Vladimir Kozlov ; jdk-updates-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Subject: Re: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions On 07/01/2021 14:18, Langer, Christoph wrote: > with the discussion/information so far I also tend to accept it. > Andrew, please make the final call ?? OK. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From iveresov at openjdk.java.net Thu Jan 7 21:35:11 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Thu, 7 Jan 2021 21:35:11 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 20:50:50 GMT, Chris Plummer wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix s390 build > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.java line 35: > >> 33: * While running the thread, it calls a method (doTask2() ) for number of times (10000). >> 34: * That would cause this method to be compiled, which causes a jvmti callback for compiled method load. >> 35: * (Hint : to force method compilation -XX:CompileThreshold=900 is used). > > The test still uses (and the comments state it uses) -XX:CompileThreshold=900 to force compilation, yet it looks like you needed to bump the number of times the method is called from 1000 to 10000 to keep this test working. Why doesn't 1000 still work? Tiered policy (which the -TieredCompilation emulation mode piggybacks on now) functions by doing periodic callbacks into the runtime to make policy decisions. The callback intervals are a power-of-2. So, because of the resulting rounding I cannot guarantee that the compilation will be triggered exactly at the specified threshold. Plus there are various adaptive mechanisms that I kept on even in the emulation mode that may also result in a method being compiled later than expected. To summarize, in the new world, the advisable way of triggering a compilation is to use the WB API. If that's too much effort, make sure that the method that you'd like to compile is invoked more than 2^(log2(CompileThreshold) + 1) times, plus a bit more. Very few tests actually depend on the legacy behavior, this just happens to be one of those. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Thu Jan 7 21:35:10 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Thu, 7 Jan 2021 21:35:10 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: Message-ID: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. > > Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: Fix s390 build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1985/files - new: https://git.openjdk.java.net/jdk/pull/1985/files/1a4c6a46..c6983a18 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1985/head:pull/1985 PR: https://git.openjdk.java.net/jdk/pull/1985 From cjplummer at openjdk.java.net Thu Jan 7 21:51:58 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 7 Jan 2021 21:51:58 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: On Thu, 7 Jan 2021 21:35:10 GMT, Igor Veresov wrote: >> This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> >> I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. >> >> Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Fix s390 build Marking as reviewed, but only for the jvmti tests. I don't believe there are any other svc changes in this PR. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1985 From cjplummer at openjdk.java.net Thu Jan 7 21:51:59 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 7 Jan 2021 21:51:59 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: Message-ID: <1-LylT7vEKyn34M0hmOfrMckVgNK02PaHVy19Mgc_3M=.abfaf6e0-4b16-48d7-a51d-acfe4f87c95c@github.com> On Thu, 7 Jan 2021 21:29:32 GMT, Igor Veresov wrote: >> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.java line 35: >> >>> 33: * While running the thread, it calls a method (doTask2() ) for number of times (10000). >>> 34: * That would cause this method to be compiled, which causes a jvmti callback for compiled method load. >>> 35: * (Hint : to force method compilation -XX:CompileThreshold=900 is used). >> >> The test still uses (and the comments state it uses) -XX:CompileThreshold=900 to force compilation, yet it looks like you needed to bump the number of times the method is called from 1000 to 10000 to keep this test working. Why doesn't 1000 still work? > > Tiered policy (which the -TieredCompilation emulation mode piggybacks on now) functions by doing periodic callbacks into the runtime to make policy decisions. The callback intervals are a power-of-2. So, because of the resulting rounding I cannot guarantee that the compilation will be triggered exactly at the specified threshold. Plus there are various adaptive mechanisms that I kept on even in the emulation mode that may also result in a method being compiled later than expected. To summarize, in the new world, the advisable way of triggering a compilation is to use the WB API. If that's too much effort, make sure that the method that you'd like to compile is invoked more than 2^(log2(CompileThreshold) + 1) times, plus a bit more. Very few tests actually depend on the legacy behavior, this just happens to be one of those. Ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From coleenp at openjdk.java.net Thu Jan 7 22:16:55 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Jan 2021 22:16:55 GMT Subject: RFR: 8259373: c1 and jvmci runtime code use ResetNoHandleMark incorrectly In-Reply-To: <_KyFN3um0BM8uHCiq3EOmBAkq-KnQcjtj5bO0IuDLBY=.293e1b40-9afe-4db9-94ee-30ae0bfc46ed@github.com> References: <_KyFN3um0BM8uHCiq3EOmBAkq-KnQcjtj5bO0IuDLBY=.293e1b40-9afe-4db9-94ee-30ae0bfc46ed@github.com> Message-ID: On Thu, 7 Jan 2021 20:42:52 GMT, Vladimir Kozlov wrote: >> Thanks Vladimir. Trivial too? > >> Thanks Vladimir. Trivial too? > > Yes, trivial. What testing you did? I ran tier1-3 testing on it. Does that test jvmciRuntime ? I thought it did. ------------- PR: https://git.openjdk.java.net/jdk/pull/1982 From kvn at openjdk.java.net Thu Jan 7 22:27:06 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 7 Jan 2021 22:27:06 GMT Subject: RFR: 8259373: c1 and jvmci runtime code use ResetNoHandleMark incorrectly In-Reply-To: References: <_KyFN3um0BM8uHCiq3EOmBAkq-KnQcjtj5bO0IuDLBY=.293e1b40-9afe-4db9-94ee-30ae0bfc46ed@github.com> Message-ID: On Thu, 7 Jan 2021 22:14:39 GMT, Coleen Phillimore wrote: >>> Thanks Vladimir. Trivial too? >> >> Yes, trivial. What testing you did? > > I ran tier1-3 testing on it. Does that test jvmciRuntime ? I thought it did. Yes, JVMCI is tested in tier1. Changes are good for push. ------------- PR: https://git.openjdk.java.net/jdk/pull/1982 From iveresov at openjdk.java.net Thu Jan 7 23:06:19 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Thu, 7 Jan 2021 23:06:19 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. > > Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: Fix another s390 compilation failure ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1985/files - new: https://git.openjdk.java.net/jdk/pull/1985/files/c6983a18..dfffc35b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1985/head:pull/1985 PR: https://git.openjdk.java.net/jdk/pull/1985 From coleenp at openjdk.java.net Thu Jan 7 23:07:56 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Jan 2021 23:07:56 GMT Subject: RFR: 8259373: c1 and jvmci runtime code use ResetNoHandleMark incorrectly In-Reply-To: References: <_KyFN3um0BM8uHCiq3EOmBAkq-KnQcjtj5bO0IuDLBY=.293e1b40-9afe-4db9-94ee-30ae0bfc46ed@github.com> Message-ID: On Thu, 7 Jan 2021 22:23:48 GMT, Vladimir Kozlov wrote: >> I ran tier1-3 testing on it. Does that test jvmciRuntime ? I thought it did. > > Yes, JVMCI is tested in tier1. > Changes are good for push. Thanks Vladimir! ------------- PR: https://git.openjdk.java.net/jdk/pull/1982 From coleenp at openjdk.java.net Thu Jan 7 23:07:57 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Jan 2021 23:07:57 GMT Subject: Integrated: 8259373: c1 and jvmci runtime code use ResetNoHandleMark incorrectly In-Reply-To: References: Message-ID: <0QmW9zz6iBIsqnmo2lTZs5FjmRt9DPXYng6DT1Pb_f0=.e994d988-8479-44e2-852e-7bc90e15c58a@github.com> On Thu, 7 Jan 2021 18:26:26 GMT, Coleen Phillimore wrote: > Please review this trivial change to the compiler runtime code. See CR for details. Tested with tier1-3. This pull request has now been integrated. Changeset: b996cccf Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/b996cccf Stats: 17 lines in 3 files changed: 1 ins; 6 del; 10 mod 8259373: c1 and jvmci runtime code use ResetNoHandleMark incorrectly Reviewed-by: kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/1982 From dongbo at openjdk.java.net Fri Jan 8 02:53:58 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Fri, 8 Jan 2021 02:53:58 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 10:04:45 GMT, Andrew Haley wrote: >> Dong Bo has updated the pull request incrementally with one additional commit since the last revision: >> >> put faddp/fmaxp/fminp together in a group > > test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java line 67: > >> 65: for (int i = 0; i < COUNT; i++) { >> 66: max = Math.max(max, floatsA[i] - floatsB[i]); >> 67: } > > This test code looks a bit contrived. If you're looking for the smallest delta it'd be > > Math.max(max, Math.abs(floatsA[i] - floatsB[i])); > > and if you're looking for the smallest value it'd probably be > > Math.max(max, floatsA[i]); > > Do we gain any advantage with these? Hi, As the experiment shows, we do not gain improvements with these. For `Math.max(max, Math.abs(floatsA[i] - floatsB[i]))`, the code is not vectorized if `COUNT < 12`. When `COUNT == 12`, the node we have is not `Max2F` but `Max4F`. The `Math.max(max, floatsA[i] - floatsB[i])` suffers same problem that it does not match `Max2F` with small `COUNT`. For `Math.max(max, floatsA[i])`, it is not auto-vectorized even with `COUNT = 512`. I think the auto-vectorized optimization for this is disabled by JDK-8078563 [1]. One of the advantages of `Max2F with fmaxp` can gain for `VectorAPI`, the test code is available in [2]. We witnessed about `12%` improvements for `reduceLanes(VectorOperators.MAX)` of `FloatVector.SPECIES_64`: Benchmark (COUNT) (seed) Mode Cnt Score Error Units # Kunpeng 916, default VectorReduction2FMinMax.maxRed2F 512 0 avgt 10 667.173 ? 0.576 ns/op VectorReduction2FMinMax.minRed2F 512 0 avgt 10 667.172 ? 0.649 ns/op # Kunpeng 916, with fmaxp/fminp VectorReduction2FMinMax.maxRed2F 512 0 avgt 10 592.404 ? 0.885 ns/op VectorReduction2FMinMax.minRed2F 512 0 avgt 10 592.293 ? 0.607 ns/op I agree the testcode for `floats` in `VectorReductionFloatingMinMax.java` is contrived. Do you think we should replace the tests for `MinMaxF` in `VectorReductionFloatingMinMax` with tests in [2]? [1] https://bugs.openjdk.java.net/browse/JDK-8078563 [2] [VectorReduction2FMinMax.java.txt](https://github.com/openjdk/jdk/files/5784948/VectorReduction2FMinMax.java.txt) ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From david.holmes at oracle.com Fri Jan 8 04:57:45 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Jan 2021 14:57:45 +1000 Subject: RFR: 8251462: Remove legacy compilation policy In-Reply-To: References: Message-ID: <01bf1e4c-cda5-32b8-45e4-5b4100314947@oracle.com> Hi Igor, On 8/01/2021 6:36 am, Igor Veresov wrote: > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. Can you clarify, for non-compiler folk, what all the alternative configs actually mean now. I'm a bit confused by this definition: define_pd_global(bool, TieredCompilation, COMPILER1_PRESENT(true) NOT_COMPILER1(false)); as I expected tiered compilation to require COMPILER1 and COMPILER2. Also I see interpreter code that used to be guarded by TieredCompilation now being executed unconditionally, which seems to assume C1 or C2 must be present? Overall it is a big change to digest, but after skimming it looks like a few of the refactorings could have been applied in a layered fashion using multiple commits to make it easier to review. Thanks, David ----- > I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. > > Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! > > ------------- > > Commit messages: > - Fix copyright years > - Remove legacy compilation policy. > > Changes: https://git.openjdk.java.net/jdk/pull/1985/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8251462 > Stats: 5285 lines in 95 files changed: 1481 ins; 2979 del; 825 mod > Patch: https://git.openjdk.java.net/jdk/pull/1985.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/1985/head:pull/1985 > > PR: https://git.openjdk.java.net/jdk/pull/1985 > From iveresov at openjdk.java.net Fri Jan 8 06:09:55 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 8 Jan 2021 06:09:55 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: On Thu, 7 Jan 2021 21:49:56 GMT, Chris Plummer wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix s390 build > > Marking as reviewed, but only for the jvmti tests. I don't believe there are any other svc changes in this PR. Please find the answers in-line. > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ > > Hi Igor, > > On 8/01/2021 6:36 am, Igor Veresov wrote: > > > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > Can you clarify, for non-compiler folk, what all the alternative configs > actually mean now. I'm a bit confused by this definition: > > define_pd_global(bool, TieredCompilation, > COMPILER1_PRESENT(true) NOT_COMPILER1(false)); That's in a c2_globals_*.hpp, which is only included if C2 is present. Given that, if C1 is present as well the flag is set to true. > > as I expected tiered compilation to require COMPILER1 and COMPILER2. > Right. That's exactly what's happening. > Also I see interpreter code that used to be guarded by TieredCompilation > now being executed unconditionally, which seems to assume C1 or C2 must > be present? > Counters and compilation policy callbacks are historically guarded by UseCompiler and UseLoopCounter flags, which are set to false if there are no compilers present. I haven't changed the semantics. > Overall it is a big change to digest, but after skimming it looks like a > few of the refactorings could have been applied in a layered fashion > using multiple commits to make it easier to review. > Frankly, I don't know how to split it into smaller pieces. There are surprisingly lots of interdependencies. However, the best way to think about it is that there are three major parts: 1. CompilerConfig API that is an abstraction over compiler configuration (what's compiled in, what flags are present that restrict compiler usage, etc); 2. The legacy policy removal. 3. Emulation of the old JVM behavior. As far as the runtime part of the change is concerted, it's pretty much only the legacy policy removal. In particular, the parts of the interpreter that dealt with the old policy (basically everything in the interpreter that was under !TieredCompilation has gotten removed). Igor > Thanks, > David > ----- ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 8 06:31:56 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 8 Jan 2021 06:31:56 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: On Fri, 8 Jan 2021 06:07:23 GMT, Igor Veresov wrote: >> Marking as reviewed, but only for the jvmti tests. I don't believe there are any other svc changes in this PR. > > Please find the answers in-line. > >> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ >> >> Hi Igor, >> >> On 8/01/2021 6:36 am, Igor Veresov wrote: >> >> > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> >> Can you clarify, for non-compiler folk, what all the alternative configs >> actually mean now. I'm a bit confused by this definition: >> >> define_pd_global(bool, TieredCompilation, >> COMPILER1_PRESENT(true) NOT_COMPILER1(false)); > > That's in a c2_globals_*.hpp, which is only included if C2 is present. Given that, if C1 is present as well the flag is set to true. >> >> as I expected tiered compilation to require COMPILER1 and COMPILER2. >> > Right. That's exactly what's happening. > >> Also I see interpreter code that used to be guarded by TieredCompilation >> now being executed unconditionally, which seems to assume C1 or C2 must >> be present? >> > > Counters and compilation policy callbacks are historically guarded by UseCompiler and UseLoopCounter flags, which are set to false if there are no compilers present. I haven't changed the semantics. > >> Overall it is a big change to digest, but after skimming it looks like a >> few of the refactorings could have been applied in a layered fashion >> using multiple commits to make it easier to review. >> > > Frankly, I don't know how to split it into smaller pieces. There are surprisingly lots of interdependencies. However, the best way to think about it is that there are three major parts: 1. CompilerConfig API that is an abstraction over compiler configuration (what's compiled in, what flags are present that restrict compiler usage, etc); 2. The legacy policy removal. 3. Emulation of the old JVM behavior. > > As far as the runtime part of the change is concerted, it's pretty much only the legacy policy removal. In particular, the parts of the interpreter that dealt with the old policy (basically everything in the interpreter that was under !TieredCompilation has gotten removed). > > Igor > >> Thanks, >> David >> ----- To clarify the possible configs. 1. There is only one policy now. Functions with both compilers or a single compiler. 2. The best way to control the operation mode is with the ```-XX:CompilationMode=``` flag. Possible values so far are: normal (aka default), high-only (c2 or graal only), quick-only(c1 only), high-only-quick-internal (a special mode for jar graal where only graal itself is compiled by c1, but the user code is compiled with graal). 3. There is a mode that emulates the behavior when the user specifies -TieredCompilation. That's basically the high-only mode. 4. There is also support for legacy policy flags such as CompileThreshold, which would properly setup the policy parameters to match the old behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From github.com+10482586+therealeliu at openjdk.java.net Fri Jan 8 08:33:54 2021 From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu) Date: Fri, 8 Jan 2021 08:33:54 GMT Subject: RFR: 8255339: CodeBuffer::_last_insn is only used on AArch64 In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 08:07:16 GMT, Eric Liu wrote: > CodeBuffer::_last_insn was used to merge consecutive memory barriers and > adjacent load/store on AArch64. > > This patch marks it as AArch64 only so that 8 bytes could be dropped > from CodeBuffer on other architectures. Can anyone help to take a look at this **trivial** PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/1971 From shade at openjdk.java.net Fri Jan 8 08:48:59 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 8 Jan 2021 08:48:59 GMT Subject: RFR: 8255339: CodeBuffer::_last_insn is only used on AArch64 In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 08:07:16 GMT, Eric Liu wrote: > CodeBuffer::_last_insn was used to merge consecutive memory barriers and > adjacent load/store on AArch64. > > This patch marks it as AArch64 only so that 8 bytes could be dropped > from CodeBuffer on other architectures. I understand the desire to do this, but I really doubt that introducing arch-specific behaviors in shared code buys us enough. I believe it saves 8 bytes for a transient code buffer, so ballparking 10K methods are compiled, it saves 80K of temporary allocations? If this was saving more and for non-transient footprint, it would be interesting. ------------- PR: https://git.openjdk.java.net/jdk/pull/1971 From redestad at openjdk.java.net Fri Jan 8 09:19:53 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 8 Jan 2021 09:19:53 GMT Subject: RFR: 8255339: CodeBuffer::_last_insn is only used on AArch64 In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 08:46:18 GMT, Aleksey Shipilev wrote: >> CodeBuffer::_last_insn was used to merge consecutive memory barriers and >> adjacent load/store on AArch64. >> >> This patch marks it as AArch64 only so that 8 bytes could be dropped >> from CodeBuffer on other architectures. > > I understand the desire to do this, but I really doubt that introducing arch-specific behaviors in shared code buys us enough. I believe it saves 8 bytes for a transient code buffer, so ballparking 10K methods are compiled, it saves 80K of temporary allocations? If this was saving more and for non-transient footprint, it would be interesting. I filed this RFE while looking through and cleaning out unused code in the area. Letting arch-specific behavior like this live on in shared code means static analysis highlights it as unused which is a bit of a nuisance. Any performance benefit is decidedly slim here, though. While macroing out code looks superficially messy I think the reading and understanding of code is overall helped when being explicit. ------------- PR: https://git.openjdk.java.net/jdk/pull/1971 From github.com+10482586+therealeliu at openjdk.java.net Fri Jan 8 09:23:55 2021 From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu) Date: Fri, 8 Jan 2021 09:23:55 GMT Subject: RFR: 8255339: CodeBuffer::_last_insn is only used on AArch64 In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 09:17:35 GMT, Claes Redestad wrote: >> I understand the desire to do this, but I really doubt that introducing arch-specific behaviors in shared code buys us enough. I believe it saves 8 bytes for a transient code buffer, so ballparking 10K methods are compiled, it saves 80K of temporary allocations? If this was saving more and for non-transient footprint, it would be interesting. > > I filed this RFE while looking through and cleaning out unused code in the area. Letting arch-specific behavior like this live on in shared code means static analysis highlights it as unused which is a bit of a nuisance. Any performance benefit is decidedly slim here, though. > > While macroing out code looks superficially messy I think the reading and understanding of code is overall helped when being explicit. Hi Aleksey, Thanks for your feedback. > I understand the desire to do this, but I really doubt that introducing arch-specific behaviors in shared code buys us enough. I thought the best position for recording the last instruction was macro-assembler, it's architecture dependent and closer to the final code in general. But it's a shame that each instruction has its own macro-assembler instance. The first shared place I can find is exactly the CodeBuffer which was used as an argument of macro-assembler. Perhaps it's not the best way but efficient, otherwise the arch-specific CodeBuffer seems too weird. > I believe it saves 8 bytes for a transient code buffer, so ballparking 10K methods are compiled, it saves 80K of temporary allocations? If this was saving more and for non-transient footprint, it would be interesting. I'd like to investigate more. Thanks, -Eric ------------- PR: https://git.openjdk.java.net/jdk/pull/1971 From aph at openjdk.java.net Fri Jan 8 09:54:58 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 8 Jan 2021 09:54:58 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 02:51:19 GMT, Dong Bo wrote: >> test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java line 67: >> >>> 65: for (int i = 0; i < COUNT; i++) { >>> 66: max = Math.max(max, floatsA[i] - floatsB[i]); >>> 67: } >> >> This test code looks a bit contrived. If you're looking for the smallest delta it'd be >> >> Math.max(max, Math.abs(floatsA[i] - floatsB[i])); >> >> and if you're looking for the smallest value it'd probably be >> >> Math.max(max, floatsA[i]); >> >> Do we gain any advantage with these? > > Hi, > > As the experiment shows, we do not gain improvements with these. > > For `Math.max(max, Math.abs(floatsA[i] - floatsB[i]))`, the code is not vectorized if `COUNT < 12`. > When `COUNT == 12`, the node we have is not `Max2F` but `Max4F`. > The `Math.max(max, floatsA[i] - floatsB[i])` suffers same problem that it does not match `Max2F` with small `COUNT`. > > For `Math.max(max, floatsA[i])`, it is not auto-vectorized even with `COUNT = 512`. > I think the auto-vectorized optimization for this is disabled by JDK-8078563 [1]. > > One of the advantages of `Max2F with fmaxp` can gain for `VectorAPI`, the test code is available in [2]. > We witnessed about `12%` improvements for `reduceLanes(VectorOperators.MAX)` of `FloatVector.SPECIES_64`: > Benchmark (COUNT) (seed) Mode Cnt Score Error Units > # Kunpeng 916, default > VectorReduction2FMinMax.maxRed2F 512 0 avgt 10 667.173 ? 0.576 ns/op > VectorReduction2FMinMax.minRed2F 512 0 avgt 10 667.172 ? 0.649 ns/op > # Kunpeng 916, with fmaxp/fminp > VectorReduction2FMinMax.maxRed2F 512 0 avgt 10 592.404 ? 0.885 ns/op > VectorReduction2FMinMax.minRed2F 512 0 avgt 10 592.293 ? 0.607 ns/op > > I agree the testcode for `floats` in `VectorReductionFloatingMinMax.java` is contrived. > Do you think we should replace the tests for `MinMaxF` in `VectorReductionFloatingMinMax` with tests in [2]? > > [1] https://bugs.openjdk.java.net/browse/JDK-8078563 > [2] [VectorReduction2FMinMax.java.txt](https://github.com/openjdk/jdk/files/5784948/VectorReduction2FMinMax.java.txt) I don't think the real problem is only the tests, it's that common cases don't get vectorized. Can we fix this code so that it works with ```Math.abs()``` ? Are there any examples of plausible Java code that benefit from this optimization? ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From shade at openjdk.java.net Fri Jan 8 10:47:02 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 8 Jan 2021 10:47:02 GMT Subject: RFR: 8259475: Fix bad merge in compilerOracle Message-ID: When reapplying JDK-8252505 to jdk/jdk, I stumbled upon the bad merge. This was the original changeset: https://github.com/openjdk/jdk16/commit/ad456787 This was the merge: https://github.com/openjdk/jdk/commit/555641ede5e234c936fca98436ef6aeace2351fc Note that not all blocks were removed from compilerOracle. Attention @JesperIRL. Additional testing: - [x] Patch from JDK-8252505 applies now - [x] No refrerences to "blackhole" or "Blackhole" in `src/hotspot` now ------------- Commit messages: - 8259475: Fix bad merge in compilerOracle Changes: https://git.openjdk.java.net/jdk/pull/2002/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2002&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259475 Stats: 17 lines in 2 files changed: 0 ins; 17 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2002.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2002/head:pull/2002 PR: https://git.openjdk.java.net/jdk/pull/2002 From redestad at openjdk.java.net Fri Jan 8 10:50:55 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 8 Jan 2021 10:50:55 GMT Subject: RFR: 8259475: Fix bad merge in compilerOracle In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 10:41:53 GMT, Aleksey Shipilev wrote: > When reapplying JDK-8252505 to jdk/jdk, I stumbled upon the bad merge. > > This was the original changeset: > https://github.com/openjdk/jdk16/commit/ad456787 > > This was the merge: > https://github.com/openjdk/jdk/commit/555641ede5e234c936fca98436ef6aeace2351fc > > Note that not all blocks were removed from compilerOracle. > > Attention @JesperIRL. > > Additional testing: > - [x] Patch from JDK-8252505 applies now > - [x] No refrerences to "blackhole" or "Blackhole" in `src/hotspot` now Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2002 From redestad at openjdk.java.net Fri Jan 8 10:55:57 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 8 Jan 2021 10:55:57 GMT Subject: RFR: 8259475: Fix bad merge in compilerOracle In-Reply-To: References: Message-ID: <00aN34Yz__9sHMY6Svx6YV6mT_yrPCKwJrhSefKmP94=.a5c4b1e3-e09d-4048-831d-6565fb107cf6@github.com> On Fri, 8 Jan 2021 10:47:58 GMT, Claes Redestad wrote: >> When reapplying JDK-8252505 to jdk/jdk, I stumbled upon the bad merge. >> >> This was the original changeset: >> https://github.com/openjdk/jdk16/commit/ad456787 >> >> This was the merge: >> https://github.com/openjdk/jdk/commit/555641ede5e234c936fca98436ef6aeace2351fc >> >> Note that not all blocks were removed from compilerOracle. >> >> Attention @JesperIRL. >> >> Additional testing: >> - [x] Patch from JDK-8252505 applies now >> - [x] No refrerences to "blackhole" or "Blackhole" in `src/hotspot` now > > Marked as reviewed by redestad (Reviewer). Looks trivial ------------- PR: https://git.openjdk.java.net/jdk/pull/2002 From chagedorn at openjdk.java.net Fri Jan 8 14:10:07 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Fri, 8 Jan 2021 14:10:07 GMT Subject: RFR: 8258243: C2: assert failed ("Bad derived pointer") with -XX:+VerifyRegisterAllocator Message-ID: The base pointer verification code in the register allocator checks that a base for a derived constant node is always `NULL`. However, this is not the case if the offset is zero (returns on L1744): https://github.com/openjdk/jdk/blob/b549cbd39250c5b22c6e863172d18cf247022894/src/hotspot/share/opto/chaitin.cpp#L1740-L1754 This case is added to the verification code which fixes the reported failing testcases. I additionally added a hello world test to sanity check the `-XX:+VerifyRegisterAllocator` flag. Thanks, Christian ------------- Commit messages: - 8258243: C2: assert failed ("Bad derived pointer") with -XX:+VerifyRegisterAllocator Changes: https://git.openjdk.java.net/jdk/pull/2005/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2005&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258243 Stats: 43 lines in 2 files changed: 40 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2005.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2005/head:pull/2005 PR: https://git.openjdk.java.net/jdk/pull/2005 From ecaspole at openjdk.java.net Fri Jan 8 14:22:57 2021 From: ecaspole at openjdk.java.net (Eric Caspole) Date: Fri, 8 Jan 2021 14:22:57 GMT Subject: Integrated: 8258792: LogCompilation: remove redundant check fixed by 8257518 In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 16:44:39 GMT, Eric Caspole wrote: > There is no need to do the same check again doing -U processing, it is already done during XML parsing. This pull request has now been integrated. Changeset: 6f7723b4 Author: Eric Caspole URL: https://git.openjdk.java.net/jdk/commit/6f7723b4 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod 8258792: LogCompilation: remove redundant check fixed by 8257518 Reviewed-by: kvn, redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/1860 From xliu at openjdk.java.net Fri Jan 8 17:32:56 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 8 Jan 2021 17:32:56 GMT Subject: RFR: 8258961: devirtualize SafePointNode::jvms() In-Reply-To: References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> <08g7HiFIZyPHlhan7KLe4_w9_BGQZPpnoDxtnzraj_s=.161392a6-49d6-4d40-9b56-cb188bafad82@github.com> Message-ID: On Wed, 6 Jan 2021 09:30:37 GMT, Xin Liu wrote: >> @navyxliu There is a title mismatch between the PR and the JBS issue that you need to fix before integration. > > Yes, I did modify the JBS title. I found it's hard to hide out _jvms because offset_of(klass, field) needs to access the field. > > I plan to see if we can use template metaprogramming or constexpr to workaround it(https://gist.github.com/graphitemaster/494f21190bb2c63c5516). I will file a separate issue if I figure out how. I found Node::jvms() is virtual, so it's useless to remove keyword "virtual" in SafePointNode::jvms(). I need another revision to fix it. Paul asked me to hide away those public fields into protected. I discover a straightforward solution -- just declare friend class VMStructs. Other classes do that. ------------- PR: https://git.openjdk.java.net/jdk/pull/1899 From github.com+7991079+danlemmond at openjdk.java.net Fri Jan 8 18:02:09 2021 From: github.com+7991079+danlemmond at openjdk.java.net (Dan) Date: Fri, 8 Jan 2021 18:02:09 GMT Subject: RFR: 8255216: ciEnv::_break_at_compile isn't in use [v2] In-Reply-To: References: Message-ID: > _break_at_compile is no longer in use and can be safely removed. > No new code, and Tier1 tests succeed after code is removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 Dan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8255216: ciEnv::_break_at_compile isn't in use _break_at_compile is no longer in use and can be safely removed. No new code, and Tier1 tests succeed after code is removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1806/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1806&range=01 Stats: 11 lines in 3 files changed: 0 ins; 11 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1806.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1806/head:pull/1806 PR: https://git.openjdk.java.net/jdk/pull/1806 From github.com+7991079+danlemmond at openjdk.java.net Fri Jan 8 19:38:15 2021 From: github.com+7991079+danlemmond at openjdk.java.net (Dan) Date: Fri, 8 Jan 2021 19:38:15 GMT Subject: RFR: 8255216: ciEnv::_break_at_compile isn't in use [v3] In-Reply-To: References: Message-ID: > _break_at_compile is no longer in use and can be safely removed. > No new code, and Tier1 tests succeed after code is removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 Dan has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8255216: ciEnv::_break_at_compile isn't in use _break_at_compile is no longer in use and can be safely removed. No new code, and Tier1 tests succeed after code is removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1806/files - new: https://git.openjdk.java.net/jdk/pull/1806/files/bbbda14e..efbd3e45 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1806&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1806&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1806.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1806/head:pull/1806 PR: https://git.openjdk.java.net/jdk/pull/1806 From kvn at openjdk.java.net Fri Jan 8 20:42:53 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 8 Jan 2021 20:42:53 GMT Subject: RFR: 8258243: C2: assert failed ("Bad derived pointer") with -XX:+VerifyRegisterAllocator In-Reply-To: References: Message-ID: <0F8hu5pvEnGAS2HLvaVkjGsHqsEcF7pJS9tSwMZswfs=.b065032e-24a8-4532-9396-43ae1e7beb01@github.com> On Fri, 8 Jan 2021 14:05:32 GMT, Christian Hagedorn wrote: > The base pointer verification code in the register allocator checks that a base for a derived constant node is always `NULL`. However, this is not the case if the offset is zero (returns on L1744): > https://github.com/openjdk/jdk/blob/b549cbd39250c5b22c6e863172d18cf247022894/src/hotspot/share/opto/chaitin.cpp#L1740-L1754 > > This case is added to the verification code which fixes the reported failing testcases. > > I additionally added a hello world test to sanity check the `-XX:+VerifyRegisterAllocator` flag. > > Thanks, > Christian Good. Make sense. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2005 From xliu at openjdk.java.net Sat Jan 9 00:43:13 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Sat, 9 Jan 2021 00:43:13 GMT Subject: RFR: 8258961: devirtualize SafePointNode::jvms() [v4] In-Reply-To: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> Message-ID: > SafePointNode::jvms() declares virtual but has never been overridden. It seems unnecessary. > The member variable _jvms declares 'JVMState* const', but set_jvms() updates its value anyway. > Geting rid of the const qualifier and hides if out using protected. Xin Liu has updated the pull request incrementally with one additional commit since the last revision: 8258961: devirtualize SafePointNode::jvms() remove the virtual qualifier from Node::jvms(). check its type is SafePointNode and MachSafePointNode instead. This patch also move some fiels to proctected zone and declare VMStructs is a friend. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1899/files - new: https://git.openjdk.java.net/jdk/pull/1899/files/f393855d..44d7b8e7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1899&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1899&range=02-03 Stats: 81 lines in 8 files changed: 34 ins; 22 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/1899.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1899/head:pull/1899 PR: https://git.openjdk.java.net/jdk/pull/1899 From dongbo at openjdk.java.net Sat Jan 9 08:16:55 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Sat, 9 Jan 2021 08:16:55 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 09:52:02 GMT, Andrew Haley wrote: >> Hi, >> >> As the experiment shows, we do not gain improvements with these. >> >> For `Math.max(max, Math.abs(floatsA[i] - floatsB[i]))`, the code is not vectorized if `COUNT < 12`. >> When `COUNT == 12`, the node we have is not `Max2F` but `Max4F`. >> The `Math.max(max, floatsA[i] - floatsB[i])` suffers same problem that it does not match `Max2F` with small `COUNT`. >> >> For `Math.max(max, floatsA[i])`, it is not auto-vectorized even with `COUNT = 512`. >> I think the auto-vectorized optimization for this is disabled by JDK-8078563 [1]. >> >> One of the advantages of `Max2F with fmaxp` can gain for `VectorAPI`, the test code is available in [2]. >> We witnessed about `12%` improvements for `reduceLanes(VectorOperators.MAX)` of `FloatVector.SPECIES_64`: >> Benchmark (COUNT) (seed) Mode Cnt Score Error Units >> # Kunpeng 916, default >> VectorReduction2FMinMax.maxRed2F 512 0 avgt 10 667.173 ? 0.576 ns/op >> VectorReduction2FMinMax.minRed2F 512 0 avgt 10 667.172 ? 0.649 ns/op >> # Kunpeng 916, with fmaxp/fminp >> VectorReduction2FMinMax.maxRed2F 512 0 avgt 10 592.404 ? 0.885 ns/op >> VectorReduction2FMinMax.minRed2F 512 0 avgt 10 592.293 ? 0.607 ns/op >> >> I agree the testcode for `floats` in `VectorReductionFloatingMinMax.java` is contrived. >> Do you think we should replace the tests for `MinMaxF` in `VectorReductionFloatingMinMax` with tests in [2]? >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8078563 >> [2] [VectorReduction2FMinMax.java.txt](https://github.com/openjdk/jdk/files/5784948/VectorReduction2FMinMax.java.txt) > > I don't think the real problem is only the tests, it's that common cases don't get vectorized. > Can we fix this code so that it works with ```Math.abs()``` ? > Are there any examples of plausible Java code that benefit from this optimization? According to the results of `JMH perfasm`, `Math.max(max, Math.abs(floatsA[i] - floatsB[i]))` is vectorized when `COUNT=8` on a X86 platform. While on aarch64, `floatsB[i] = Math.abs(floatsA[i])` is not vectorized when `COUNT = 10` and we can not match `Max2F` for `AbsF` neither. I am going to investigate the failed vectorization and see if we can have `Max2F` matched. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From david.holmes at oracle.com Mon Jan 11 02:01:42 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Jan 2021 12:01:42 +1000 Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: <67dfcdae-be37-f702-71cf-f58079322824@oracle.com> On 8/01/2021 4:09 pm, Igor Veresov wrote: > On Thu, 7 Jan 2021 21:49:56 GMT, Chris Plummer wrote: > >>> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Fix s390 build >> >> Marking as reviewed, but only for the jvmti tests. I don't believe there are any other svc changes in this PR. > > Please find the answers in-line. > >> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ >> >> Hi Igor, >> >> On 8/01/2021 6:36 am, Igor Veresov wrote: >> >>> This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> >> Can you clarify, for non-compiler folk, what all the alternative configs >> actually mean now. I'm a bit confused by this definition: >> >> define_pd_global(bool, TieredCompilation, >> COMPILER1_PRESENT(true) NOT_COMPILER1(false)); > > That's in a c2_globals_*.hpp, which is only included if C2 is present. Given that, if C1 is present as well the flag is set to true. Sorry I overlooked the exact placement. >> >> as I expected tiered compilation to require COMPILER1 and COMPILER2. >> > Right. That's exactly what's happening. > >> Also I see interpreter code that used to be guarded by TieredCompilation >> now being executed unconditionally, which seems to assume C1 or C2 must >> be present? >> > > Counters and compilation policy callbacks are historically guarded by UseCompiler and UseLoopCounter flags, which are set to false if there are no compilers present. I haven't changed the semantics. That is not at all obvious. For example in templateInterpreterGenerator_aarch64.cpp this code used to guarded by TieredCompilation: 608: __ bind(no_mdo); // Increment counter in MethodCounters const Address invocation_counter(rscratch2, MethodCounters::invocation_counter_offset() + InvocationCounter::counter_offset()); __ get_method_counters(rmethod, rscratch2, done); const Address mask(rscratch2, in_bytes(MethodCounters::invoke_mask_offset())); __ increment_mask_and_jump(invocation_counter, increment, mask, rscratch1, r1, false, Assembler::EQ, overflow); __ bind(done); but now it seems to be executed unconditionally with no reference to either flag you mentioned. > >> Overall it is a big change to digest, but after skimming it looks like a >> few of the refactorings could have been applied in a layered fashion >> using multiple commits to make it easier to review. >> > > Frankly, I don't know how to split it into smaller pieces. There are surprisingly lots of interdependencies. However, the best way to think about it is that there are three major parts: 1. CompilerConfig API that is an abstraction over compiler configuration (what's compiled in, what flags are present that restrict compiler usage, etc); 2. The legacy policy removal. 3. Emulation of the old JVM behavior. I was thinking the ifdef related changes as one commit; then the TieredCompilation removals; then the addition of CompilerConfig API ... These aren't separate changes just different commits within the PR so that it can be reviewed in stages. Cheers, David ----- > As far as the runtime part of the change is concerted, it's pretty much only the legacy policy removal. In particular, the parts of the interpreter that dealt with the old policy (basically everything in the interpreter that was under !TieredCompilation has gotten removed). > > Igor > >> Thanks, >> David >> ----- > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1985 > From iveresov at openjdk.java.net Mon Jan 11 02:56:57 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Mon, 11 Jan 2021 02:56:57 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: On Fri, 8 Jan 2021 06:29:10 GMT, Igor Veresov wrote: >> Please find the answers in-line. >> >>> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ >>> >>> Hi Igor, >>> >>> On 8/01/2021 6:36 am, Igor Veresov wrote: >>> >>> > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >>> >>> Can you clarify, for non-compiler folk, what all the alternative configs >>> actually mean now. I'm a bit confused by this definition: >>> >>> define_pd_global(bool, TieredCompilation, >>> COMPILER1_PRESENT(true) NOT_COMPILER1(false)); >> >> That's in a c2_globals_*.hpp, which is only included if C2 is present. Given that, if C1 is present as well the flag is set to true. >>> >>> as I expected tiered compilation to require COMPILER1 and COMPILER2. >>> >> Right. That's exactly what's happening. >> >>> Also I see interpreter code that used to be guarded by TieredCompilation >>> now being executed unconditionally, which seems to assume C1 or C2 must >>> be present? >>> >> >> Counters and compilation policy callbacks are historically guarded by UseCompiler and UseLoopCounter flags, which are set to false if there are no compilers present. I haven't changed the semantics. >> >>> Overall it is a big change to digest, but after skimming it looks like a >>> few of the refactorings could have been applied in a layered fashion >>> using multiple commits to make it easier to review. >>> >> >> Frankly, I don't know how to split it into smaller pieces. There are surprisingly lots of interdependencies. However, the best way to think about it is that there are three major parts: 1. CompilerConfig API that is an abstraction over compiler configuration (what's compiled in, what flags are present that restrict compiler usage, etc); 2. The legacy policy removal. 3. Emulation of the old JVM behavior. >> >> As far as the runtime part of the change is concerted, it's pretty much only the legacy policy removal. In particular, the parts of the interpreter that dealt with the old policy (basically everything in the interpreter that was under !TieredCompilation has gotten removed). >> >> Igor >> >>> Thanks, >>> David >>> ----- > > To clarify the possible configs. > 1. There is only one policy now. Functions with both compilers or a single compiler. > 2. The best way to control the operation mode is with the ```-XX:CompilationMode=``` flag. Possible values so far are: normal (aka default), high-only (c2 or graal only), quick-only(c1 only), high-only-quick-internal (a special mode for jar graal where only graal itself is compiled by c1, but the user code is compiled with graal). > 3. There is a mode that emulates the behavior when the user specifies -TieredCompilation. That's basically the high-only mode. > 4. There is also support for legacy policy flags such as CompileThreshold, which would properly setup the policy parameters to match the old behavior. Dave, I'm answering inline. > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ > > On 8/01/2021 4:09 pm, Igor Veresov wrote: > > > On Thu, 7 Jan 2021 21:49:56 GMT, Chris Plummer wrote: > > > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > > > Fix s390 build > > > > > > > > > Marking as reviewed, but only for the jvmti tests. I don't believe there are any other svc changes in this PR. > > > > > > Please find the answers in-line. > > > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ > > > Hi Igor, > > > On 8/01/2021 6:36 am, Igor Veresov wrote: > > > > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > > > > > > > > Can you clarify, for non-compiler folk, what all the alternative configs > > > actually mean now. I'm a bit confused by this definition: > > > define_pd_global(bool, TieredCompilation, > > > COMPILER1_PRESENT(true) NOT_COMPILER1(false)); > > > > > > That's in a c2_globals_*.hpp, which is only included if C2 is present. Given that, if C1 is present as well the flag is set to true. > > Sorry I overlooked the exact placement. > > > > as I expected tiered compilation to require COMPILER1 and COMPILER2. > > > > > > Right. That's exactly what's happening. > > > Also I see interpreter code that used to be guarded by TieredCompilation > > > now being executed unconditionally, which seems to assume C1 or C2 must > > > be present? > > > > > > Counters and compilation policy callbacks are historically guarded by UseCompiler and UseLoopCounter flags, which are set to false if there are no compilers present. I haven't changed the semantics. > > That is not at all obvious. For example in > templateInterpreterGenerator_aarch64.cpp this code used to guarded by > TieredCompilation: > > 608: __ bind(no_mdo); > // Increment counter in MethodCounters > const Address invocation_counter(rscratch2, > MethodCounters::invocation_counter_offset() + > InvocationCounter::counter_offset()); > __ get_method_counters(rmethod, rscratch2, done); > const Address mask(rscratch2, > in_bytes(MethodCounters::invoke_mask_offset())); > __ increment_mask_and_jump(invocation_counter, increment, mask, > rscratch1, r1, false, Assembler::EQ, overflow); > __ bind(done); This code is in generate_counter_incr() each call to which is guarded by ```if (inc_counter)```, and ```inc_counter``` is defined as ``` bool inc_counter = UseCompiler || CountCompiledCalls || LogTouchedMethods;```. Again, I haven't changed that at all, that how it always worked. We may try to tidy this up but I feel like this change is big enough already. > > but now it seems to be executed unconditionally with no reference to > either flag you mentioned. > > > > Overall it is a big change to digest, but after skimming it looks like a > > > few of the refactorings could have been applied in a layered fashion > > > using multiple commits to make it easier to review. > > > > > > Frankly, I don't know how to split it into smaller pieces. There are surprisingly lots of interdependencies. However, the best way to think about it is that there are three major parts: 1. CompilerConfig API that is an abstraction over compiler configuration (what's compiled in, what flags are present that restrict compiler usage, etc); 2. The legacy policy removal. 3. Emulation of the old JVM behavior. > > I was thinking the ifdef related changes as one commit; then the > TieredCompilation removals; then the addition of CompilerConfig API ... > > These aren't separate changes just different commits within the PR so > that it can be reviewed in stages. I could've done that, I guess, but I usually like to make my checkpoints compilable. Sorry. > > Cheers, > David > ----- ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From dongbo at openjdk.java.net Mon Jan 11 05:14:21 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Mon, 11 Jan 2021 05:14:21 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v5] In-Reply-To: References: Message-ID: > This patch optimizes vectorial Min/Max reduction of two floating-point numbers on aarch64 with NEON instructions `fmaxp` and `fminp`. > > Passed jtreg tier1-3 tests with `linux-aarch64-server-fastdebug` build. > Tests under `test/jdk/jdk/incubator/vector/` runned specially for the correctness and passed. > > Introduced a new JMH micro `test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java` for performance test. > Witnessed abount `37%` performance improvements on Kunpeng916. The JMH Results: > Benchmark (COUNT) (seed) Mode Cnt Score Error Units > # Kunpeng 916, default > VectorReduction.maxRedD 512 0 avgt 10 678.126 ? 0.815 ns/op > VectorReduction.maxRedF 512 0 avgt 10 242.958 ? 0.212 ns/op > VectorReduction.minRedD 512 0 avgt 10 678.554 ? 0.824 ns/op > VectorReduction.minRedF 512 0 avgt 10 243.368 ? 0.205 ns/op > > # Kunpeng 916, with fmaxp/fminp > VectorReduction.maxRedD 512 0 avgt 10 430.201 ? 0.353 ns/op => 36.56% > VectorReduction.maxRedF 512 0 avgt 10 243.404 ? 0.297 ns/op > VectorReduction.minRedD 512 0 avgt 10 427.805 ? 0.528 ns/op => 36.89% > VectorReduction.minRedF 512 0 avgt 10 242.963 ? 0.210 ns/op Dong Bo has updated the pull request incrementally with one additional commit since the last revision: modify test code to match Max2F ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1925/files - new: https://git.openjdk.java.net/jdk/pull/1925/files/96dc92f8..f244ed01 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1925&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1925&range=03-04 Stats: 20 lines in 1 file changed: 7 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/1925.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1925/head:pull/1925 PR: https://git.openjdk.java.net/jdk/pull/1925 From dongbo at openjdk.java.net Mon Jan 11 05:16:53 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Mon, 11 Jan 2021 05:16:53 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Sat, 9 Jan 2021 08:13:45 GMT, Dong Bo wrote: >> I don't think the real problem is only the tests, it's that common cases don't get vectorized. >> Can we fix this code so that it works with ```Math.abs()``` ? >> Are there any examples of plausible Java code that benefit from this optimization? > > According to the results of `JMH perfasm`, `Math.max(max, Math.abs(floatsA[i] - floatsB[i]))` is vectorized when `COUNT=8` on a X86 platform. > While on aarch64, `floatsB[i] = Math.abs(floatsA[i])` is not vectorized when `COUNT = 10` and we can not match `VAbs2F` neither. > I am going to investigate the failed vectorization and see if we can have `Max2F` matched. Thanks. Hi, I made a mistake to say that the code is not vectorized with `COUNT < 12`, seems that the percentages of vectorized code is too small to be catched by `JMH perfasm`. To observed if `Min/MaxReductionVNode` are created or not, I added a explicit print in `ReductionNode::make`, like: --- a/src/hotspot/share/opto/vectornode.cpp +++ b/src/hotspot/share/opto/vectornode.cpp @@ -961,7 +961,9 @@ ReductionNode* ReductionNode::make(int opc, Node *ctrl, Node* n1, Node* n2, Basi case Op_MinReductionV: return new MinReductionVNode(ctrl, n1, n2); - case Op_MaxReductionV: return new MaxReductionVNode(ctrl, n1, n2); + case Op_MaxReductionV: + warning("in ReductionNode::make, making a MaxReductionVNode, length %d", n2->bottom_type()->is_vect()->length()); + return new MaxReductionVNode(ctrl, n1, n2); case Op_AndReductionV: return new AndReductionVNode(ctrl, n1, n2); In my observation, we have `Max4F` when `COUNT >= 4`, it is resonable to create `Max4F` other than `Max2F`. The `Max2F` is created with `COUNT == 3` and `-XX:-SuperWordLoopUnrollAnalysis`. But I did not find any noticeable improvements with such a small percentage. The JMH has been updated, the performance results are: Benchmark (COUNT_DOUBLE) (COUNT_FLOAT) (seed) Mode Cnt Score Error Units # Kunpeng 916, default VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 677.778 ? 0.694 ns/op VectorReductionFloatingMinMax.maxRedF 512 3 0 avgt 10 21.016 ? 0.097 ns/op VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 677.633 ? 0.664 ns/op VectorReductionFloatingMinMax.minRedF 512 3 0 avgt 10 21.001 ? 0.019 ns/op # Kunpeng 916, fmaxp/fminp VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 425.776 ? 0.785 ns/op VectorReductionFloatingMinMax.maxRedF 512 3 0 avgt 10 20.883 ? 0.033 ns/op VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 426.177 ? 3.258 ns/op VectorReductionFloatingMinMax.minRedF 512 3 0 avgt 10 20.871 ? 0.044 ns/op ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From stuefe at openjdk.java.net Mon Jan 11 06:42:00 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 11 Jan 2021 06:42:00 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests [v2] In-Reply-To: <4wsrcJIZMSQcI-bEYswi7vI4MznlHMCuYkxCFjzY6S4=.ec088b95-496c-4ecc-98a7-e239c7247348@github.com> References: <9XtCnqp4eKcBDXlXSm18R6tUIH9mCPZUZJE3Htio2Bs=.606bf77d-fec8-434a-b1e9-6cb5484605a1@github.com> <4wsrcJIZMSQcI-bEYswi7vI4MznlHMCuYkxCFjzY6S4=.ec088b95-496c-4ecc-98a7-e239c7247348@github.com> Message-ID: On Tue, 5 Jan 2021 10:40:11 GMT, Andrew Dinn wrote: >> Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year to 2021. > > src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp line 252: > >> 250: pc, info, NULL, NULL, 0, 0); >> 251: va_end(detail_args); >> 252: } > > I'm not sure it is ok to revert this code. The fix this is part of (for JDK-8255711) was provided explicitly to re-organize the flow of control for handling of fatal errors. Reverting this code appears to undermine the goal of that issue. I would like to get Thomas Stuefe's (@tstuefe) opinion on whether it is appropriate to abort the JVM here vs returning false before accepting this specific change. Sorry for the delay. I'll take a look. ------------- PR: https://git.openjdk.java.net/jdk16/pull/50 From thartmann at openjdk.java.net Mon Jan 11 06:50:54 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 11 Jan 2021 06:50:54 GMT Subject: RFR: 8259475: Fix bad merge in compilerOracle In-Reply-To: References: Message-ID: <_OtqO7HALzAeQ5AfDK76Xb5kMxwER_GjCSeU3p_u7yY=.9b6cda80-55bb-4511-9f7b-2a2d055db240@github.com> On Fri, 8 Jan 2021 10:41:53 GMT, Aleksey Shipilev wrote: > When reapplying JDK-8252505 to jdk/jdk, I stumbled upon the bad merge. > > This was the original changeset: > https://github.com/openjdk/jdk16/commit/ad456787 > > This was the merge: > https://github.com/openjdk/jdk/commit/555641ede5e234c936fca98436ef6aeace2351fc > > Note that not all blocks were removed from compilerOracle. > > Attention @JesperIRL. > > Additional testing: > - [x] Patch from JDK-8252505 applies now > - [x] No refrerences to "blackhole" or "Blackhole" in `src/hotspot` now Looks good. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2002 From thartmann at openjdk.java.net Mon Jan 11 06:58:55 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 11 Jan 2021 06:58:55 GMT Subject: RFR: 8258243: C2: assert failed ("Bad derived pointer") with -XX:+VerifyRegisterAllocator In-Reply-To: References: Message-ID: <9x0eWUjv2v7GUzCoNH8wlwG5TjnEqp4dSQtYJUR8AXk=.589a6669-4d51-4bf8-954c-a8f2a3949fe2@github.com> On Fri, 8 Jan 2021 14:05:32 GMT, Christian Hagedorn wrote: > The base pointer verification code in the register allocator checks that a base for a derived constant node is always `NULL`. However, this is not the case if the offset is zero (returns on L1744): > https://github.com/openjdk/jdk/blob/b549cbd39250c5b22c6e863172d18cf247022894/src/hotspot/share/opto/chaitin.cpp#L1740-L1754 > > This case is added to the verification code which fixes the reported failing testcases. > > I additionally added a hello world test to sanity check the `-XX:+VerifyRegisterAllocator` flag. > > Thanks, > Christian Looks good. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2005 From stuefe at openjdk.java.net Mon Jan 11 07:00:01 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 11 Jan 2021 07:00:01 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests [v2] In-Reply-To: References: <9XtCnqp4eKcBDXlXSm18R6tUIH9mCPZUZJE3Htio2Bs=.606bf77d-fec8-434a-b1e9-6cb5484605a1@github.com> <4wsrcJIZMSQcI-bEYswi7vI4MznlHMCuYkxCFjzY6S4=.ec088b95-496c-4ecc-98a7-e239c7247348@github.com> Message-ID: On Mon, 11 Jan 2021 06:39:27 GMT, Thomas Stuefe wrote: >> src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp line 252: >> >>> 250: pc, info, NULL, NULL, 0, 0); >>> 251: va_end(detail_args); >>> 252: } >> >> I'm not sure it is ok to revert this code. The fix this is part of (for JDK-8255711) was provided explicitly to re-organize the flow of control for handling of fatal errors. Reverting this code appears to undermine the goal of that issue. I would like to get Thomas Stuefe's (@tstuefe) opinion on whether it is appropriate to abort the JVM here vs returning false before accepting this specific change. > > Sorry for the delay. I'll take a look. Thanks for finding that, and for pinging me. Please revert this part of the change, I opened a separate issue for it (also affects ppc64): https://bugs.openjdk.java.net/browse/JDK-8259539. ------------- PR: https://git.openjdk.java.net/jdk16/pull/50 From njian at openjdk.java.net Mon Jan 11 07:30:15 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Mon, 11 Jan 2021 07:30:15 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests [v3] In-Reply-To: References: Message-ID: > After applying [1], some Vector API tests fail with SIGILL on SVE > system. The SIGILL was triggered by verify_ptrue before c2 compiled > function returns, which means that the preserved p7 register (as ptrue) > has been clobbered before returning to c2 compiled code. (p7 is not > preserved cross function calls, and system calls [2]). > > Currently we try to reinitialize ptrue at each entrypoint of returning > from non-c2 compiled code, which indicating possible C or system calls. > However, there's still one entrypoint missing, exception handling, as > we may jump to c2 compiled code for exception handler. See > OptoRuntime::generate_exception_blob(). > > Adding reinitialize_ptrue before jumping back to c2 compiled code in > generate_exception_blob() could solve those Vector API test failures. > Actually I had that in my initial test patch [3], I don't know why I > missed that in final patch... I reran tests with the same approach of > [3] and found that there's still something missing, the > nmethod_entry_barrier() in c2 function prolog. The barrier may call to > runtime code (see generate_method_entry_barrier()). To reduce the risk > of missing such reinitialize_ptrue in newly added code in future, I > think it would be better to do the reinitialize in > pop_call_clobbered_registers(). > > P.S. the SIGILL message is also not clear, it should print detailed > message as indicated by MacroAssembler::stop() call. This is caused by > JDK-8255711 removing the message printing code. This patch also adds it > back, so that it could print detailed message for abort. > > Tested with tier1-3 on SVE hardware. Also verified with the same > approach of patch [3] with jtreg tests hotspot_all_no_apps and > jdk:tier1-3 passed without incorrect ptrue value assertion failure. > > [1] https://github.com/openjdk/jdk/pull/1621 > [2] https://github.com/torvalds/linux/blob/master/Documentation/arm64/sve.rst > [3] http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision: Revert signal handler changes, which will be fixed in JDK-8259539. ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/50/files - new: https://git.openjdk.java.net/jdk16/pull/50/files/873c2506..7bd8bcb5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=50&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=50&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk16/pull/50.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/50/head:pull/50 PR: https://git.openjdk.java.net/jdk16/pull/50 From njian at openjdk.java.net Mon Jan 11 07:34:05 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Mon, 11 Jan 2021 07:34:05 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests [v2] In-Reply-To: <4wsrcJIZMSQcI-bEYswi7vI4MznlHMCuYkxCFjzY6S4=.ec088b95-496c-4ecc-98a7-e239c7247348@github.com> References: <9XtCnqp4eKcBDXlXSm18R6tUIH9mCPZUZJE3Htio2Bs=.606bf77d-fec8-434a-b1e9-6cb5484605a1@github.com> <4wsrcJIZMSQcI-bEYswi7vI4MznlHMCuYkxCFjzY6S4=.ec088b95-496c-4ecc-98a7-e239c7247348@github.com> Message-ID: On Tue, 5 Jan 2021 10:40:11 GMT, Andrew Dinn wrote: >> Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year to 2021. > > src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp line 252: > >> 250: pc, info, NULL, NULL, 0, 0); >> 251: va_end(detail_args); >> 252: } > > I'm not sure it is ok to revert this code. The fix this is part of (for JDK-8255711) was provided explicitly to re-organize the flow of control for handling of fatal errors. Reverting this code appears to undermine the goal of that issue. I would like to get Thomas Stuefe's (@tstuefe) opinion on whether it is appropriate to abort the JVM here vs returning false before accepting this specific change. Thank you Thomas. I have removed the change from my patch. Would you mind taking another look and approving this patch @adinn ? ------------- PR: https://git.openjdk.java.net/jdk16/pull/50 From shade at openjdk.java.net Mon Jan 11 07:35:58 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Jan 2021 07:35:58 GMT Subject: Integrated: 8259475: Fix bad merge in compilerOracle In-Reply-To: References: Message-ID: <7nq5DtWtBS2Oi5UDTYXfj9roMD3-GX0VzwbGwFGMZWY=.716a5d06-422e-4dbe-aa08-7e5809433ef2@github.com> On Fri, 8 Jan 2021 10:41:53 GMT, Aleksey Shipilev wrote: > When reapplying JDK-8252505 to jdk/jdk, I stumbled upon the bad merge. > > This was the original changeset: > https://github.com/openjdk/jdk16/commit/ad456787 > > This was the merge: > https://github.com/openjdk/jdk/commit/555641ede5e234c936fca98436ef6aeace2351fc > > Note that not all blocks were removed from compilerOracle. > > Attention @JesperIRL. > > Additional testing: > - [x] Patch from JDK-8252505 applies now > - [x] No refrerences to "blackhole" or "Blackhole" in `src/hotspot` now This pull request has now been integrated. Changeset: 2806bf2e Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/2806bf2e Stats: 17 lines in 2 files changed: 0 ins; 17 del; 0 mod 8259475: Fix bad merge in compilerOracle Reviewed-by: redestad, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/2002 From whuang at openjdk.java.net Mon Jan 11 08:20:00 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Mon, 11 Jan 2021 08:20:00 GMT Subject: [jdk16] RFR: =?UTF-8?B?ODI1OTA0NO+8mg==?= JVM lacks data type qualifier when using -XX:+PrintAssembly with AArch64-Neon backend In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 03:17:43 GMT, Wang Huang wrote: >> This looks good to me. But should this P4 enhancement go to https://github.com/openjdk/jdk instead of here? > >> This looks good to me. But should this P4 enhancement go to https://github.com/openjdk/jdk instead of here? > > OK. I will post a PR against jdk/jdk ASAP. I have posted a new PR against jdk/jdk: https://github.com/openjdk/jdk/pull/1941 please close this PR. Thank you. @nsjian ------------- PR: https://git.openjdk.java.net/jdk16/pull/77 From whuang at openjdk.java.net Mon Jan 11 08:30:00 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Mon, 11 Jan 2021 08:30:00 GMT Subject: [jdk16] Withdrawn: =?UTF-8?B?ODI1OTA0NO+8mg==?= JVM lacks data type qualifier when using -XX:+PrintAssembly with AArch64-Neon backend In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 09:37:33 GMT, Wang Huang wrote: > For instace: in the implentation of VectorMaskCmp & VectorStoreMask : > > $jtreg -vmoptions:"-XX:+PrintAssembly" ./Int128VectorTests.java > > before fixing > ----------------- > 0dc ldrq V17,[R10, #16] # vector (128 bits) > 0e0 cmeq V16, V16, V17 # vector cmp (4I) > 0e4 xtn V16, V16 # 4S to 4H > xtn V16, V16 # 4H to 4B > negr V16, V16 # store mask (4S to 4B) > ----------------- > Here? the output lacks data type qualifiers like T4S in `cmeq V16, V16, V17`. > > Expect: > ----------------- > 0dc ldrq V16,[R10, #16] # vector (128 bits) > 0e0 cmeq V16, T4S, V16, V18 # vector cmp (4I) > 0e4 xtn V16, T4H, V16, T4S # 4S to 4H > xtn V16, T8B, V16, T8H # 4H to 4B > negr V16, T8B, V16 # store mask (4S to 4B) > ----------------- This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk16/pull/77 From chagedorn at openjdk.java.net Mon Jan 11 08:34:06 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 11 Jan 2021 08:34:06 GMT Subject: RFR: 8258243: C2: assert failed ("Bad derived pointer") with -XX:+VerifyRegisterAllocator In-Reply-To: <0F8hu5pvEnGAS2HLvaVkjGsHqsEcF7pJS9tSwMZswfs=.b065032e-24a8-4532-9396-43ae1e7beb01@github.com> References: <0F8hu5pvEnGAS2HLvaVkjGsHqsEcF7pJS9tSwMZswfs=.b065032e-24a8-4532-9396-43ae1e7beb01@github.com> Message-ID: On Fri, 8 Jan 2021 20:40:19 GMT, Vladimir Kozlov wrote: >> The base pointer verification code in the register allocator checks that a base for a derived constant node is always `NULL`. However, this is not the case if the offset is zero (returns on L1744): >> https://github.com/openjdk/jdk/blob/b549cbd39250c5b22c6e863172d18cf247022894/src/hotspot/share/opto/chaitin.cpp#L1740-L1754 >> >> This case is added to the verification code which fixes the reported failing testcases. >> >> I additionally added a hello world test to sanity check the `-XX:+VerifyRegisterAllocator` flag. >> >> Thanks, >> Christian > > Good. Make sense. @vnkozlov @TobiHartmann Thank you for your reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/2005 From whuang at openjdk.java.net Mon Jan 11 08:43:55 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Mon, 11 Jan 2021 08:43:55 GMT Subject: Withdrawn: 8258989: JVM is failed to inline in jdk.internal.vm.vector.VectorSupport::convert In-Reply-To: References: Message-ID: On Wed, 30 Dec 2020 09:09:37 GMT, Wang Huang wrote: > $java --add-modules=jdk.incubator.vector -Xcomp -XX:CompileCommand=compileonly,TestCast16BTo2D::* -XX:+UnlockDiagnosticVMOptions -XX:+PrintIntrinsics TestCast16BTo2D > before fixing: > ** not supported: arity=1 op=cast/5 vlen2=2 etype1=byte ismask=0 > @ 3 jdk.internal.util.Preconditions::checkIndex (18 bytes) (intrinsic) > @ 101 java.lang.Object::getClass (0 bytes) (intrinsic) > @ 109 java.lang.Object::getClass (0 bytes) (intrinsic) > @ 3 jdk.internal.util.Preconditions::checkIndex (18 bytes) (intrinsic) > @ 31 jdk.internal.vm.vector.VectorSupport::load (38 bytes) (intrinsic) > @ 128 jdk.internal.vm.vector.VectorSupport::convert (39 bytes) failed to inline (intrinsic) > @ 42 jdk.internal.vm.vector.VectorSupport::store (38 bytes) (intrinsic) > Expect: > @ 3 jdk.internal.util.Preconditions::checkIndex (18 bytes) (intrinsic) > @ 101 java.lang.Object::getClass (0 bytes) (intrinsic) > @ 109 java.lang.Object::getClass (0 bytes) (intrinsic) > @ 3 jdk.internal.util.Preconditions::checkIndex (18 bytes) (intrinsic) > @ 31 jdk.internal.vm.vector.VectorSupport::load (38 bytes) (intrinsic) > @ 128 jdk.internal.vm.vector.VectorSupport::convert (39 bytes) (intrinsic) > @ 42 jdk.internal.vm.vector.VectorSupport::store (38 bytes) (intrinsic) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1909 From bulasevich at openjdk.java.net Mon Jan 11 09:09:05 2021 From: bulasevich at openjdk.java.net (Boris Ulasevich) Date: Mon, 11 Jan 2021 09:09:05 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: <3FqXOR8NSsGbCExqGxRWPfWOrlb0Rpl0bU3Ug__8I8g=.c74bae33-89af-47b5-b02d-6546a9f538a7@github.com> On Thu, 7 Jan 2021 23:06:19 GMT, Igor Veresov wrote: >> This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> >> I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. >> >> Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Fix another s390 compilation failure src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp line 376: > 374: // Note: In tiered we increment either counters in MethodCounters* or > 375: // in MDO depending if we're profiling or not. > 376: int increment = InvocationCounter::count_increment; The small code below seems not to be equivalent replacement for the above code. I would appreciate some explanation on why we change the things. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From bulasevich at openjdk.java.net Mon Jan 11 09:11:56 2021 From: bulasevich at openjdk.java.net (Boris Ulasevich) Date: Mon, 11 Jan 2021 09:11:56 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: On Mon, 11 Jan 2021 02:54:02 GMT, Igor Veresov wrote: >> To clarify the possible configs. >> 1. There is only one policy now. Functions with both compilers or a single compiler. >> 2. The best way to control the operation mode is with the ```-XX:CompilationMode=``` flag. Possible values so far are: normal (aka default), high-only (c2 or graal only), quick-only(c1 only), high-only-quick-internal (a special mode for jar graal where only graal itself is compiled by c1, but the user code is compiled with graal). >> 3. There is a mode that emulates the behavior when the user specifies -TieredCompilation. That's basically the high-only mode. >> 4. There is also support for legacy policy flags such as CompileThreshold, which would properly setup the policy parameters to match the old behavior. > > Dave, I'm answering inline. > >> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ >> >> On 8/01/2021 4:09 pm, Igor Veresov wrote: >> >> > On Thu, 7 Jan 2021 21:49:56 GMT, Chris Plummer wrote: >> > > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> > > > Fix s390 build >> > > >> > > >> > > Marking as reviewed, but only for the jvmti tests. I don't believe there are any other svc changes in this PR. >> > >> > >> > Please find the answers in-line. >> > > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ >> > > Hi Igor, >> > > On 8/01/2021 6:36 am, Igor Veresov wrote: >> > > > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> > > >> > > >> > > Can you clarify, for non-compiler folk, what all the alternative configs >> > > actually mean now. I'm a bit confused by this definition: >> > > define_pd_global(bool, TieredCompilation, >> > > COMPILER1_PRESENT(true) NOT_COMPILER1(false)); >> > >> > >> > That's in a c2_globals_*.hpp, which is only included if C2 is present. Given that, if C1 is present as well the flag is set to true. >> >> Sorry I overlooked the exact placement. >> >> > > as I expected tiered compilation to require COMPILER1 and COMPILER2. >> > >> > >> > Right. That's exactly what's happening. >> > > Also I see interpreter code that used to be guarded by TieredCompilation >> > > now being executed unconditionally, which seems to assume C1 or C2 must >> > > be present? >> > >> > >> > Counters and compilation policy callbacks are historically guarded by UseCompiler and UseLoopCounter flags, which are set to false if there are no compilers present. I haven't changed the semantics. >> >> That is not at all obvious. For example in >> templateInterpreterGenerator_aarch64.cpp this code used to guarded by >> TieredCompilation: >> >> 608: __ bind(no_mdo); >> // Increment counter in MethodCounters >> const Address invocation_counter(rscratch2, >> MethodCounters::invocation_counter_offset() + >> InvocationCounter::counter_offset()); >> __ get_method_counters(rmethod, rscratch2, done); >> const Address mask(rscratch2, >> in_bytes(MethodCounters::invoke_mask_offset())); >> __ increment_mask_and_jump(invocation_counter, increment, mask, >> rscratch1, r1, false, Assembler::EQ, overflow); >> __ bind(done); > > This code is in generate_counter_incr() each call to which is guarded by ```if (inc_counter)```, and ```inc_counter``` is defined as ``` bool inc_counter = UseCompiler || CountCompiledCalls || LogTouchedMethods;```. Again, I haven't changed that at all, that how it always worked. We may try to tidy this up but I feel like this change is big enough already. > >> >> but now it seems to be executed unconditionally with no reference to >> either flag you mentioned. >> >> > > Overall it is a big change to digest, but after skimming it looks like a >> > > few of the refactorings could have been applied in a layered fashion >> > > using multiple commits to make it easier to review. >> > >> > >> > Frankly, I don't know how to split it into smaller pieces. There are surprisingly lots of interdependencies. However, the best way to think about it is that there are three major parts: 1. CompilerConfig API that is an abstraction over compiler configuration (what's compiled in, what flags are present that restrict compiler usage, etc); 2. The legacy policy removal. 3. Emulation of the old JVM behavior. >> >> I was thinking the ifdef related changes as one commit; then the >> TieredCompilation removals; then the addition of CompilerConfig API ... >> >> These aren't separate changes just different commits within the PR so >> that it can be reviewed in stages. > > I could've done that, I guess, but I usually like to make my checkpoints compilable. Sorry. > >> >> Cheers, >> David >> ----- I see some regression on ARM32 with this change: http://cr.openjdk.java.net/~bulasevich/tmp/8251462_jtreg_hotspot/ ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From xgong at openjdk.java.net Mon Jan 11 09:29:10 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Mon, 11 Jan 2021 09:29:10 GMT Subject: [jdk16] RFR: 8259353: VectorReinterpretNode is incorrectly optimized out Message-ID: Vector reinterpretation just reinterprets the bytes of the vector without performing any value conversions. So normally, optimization like: (VectorReinterpret (VectorReinterpret src)) -> src can be applied correctly if the logical result and the input `"src"` have the same vector type. However, the results might not be correct if truncation happens after the first reinterpretation: `"(VectorReinterpret src)"`. Consider the following case: byte[] a = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15} byte[] b = new byte[16] byte[] c = new byte[16] // load vector from "a" with 128-bits ByteVector av = ByteVector.fromArray(SPECIES_128, a, 0); // reinterpret to 64-bits ByteVector bv = (ByteVector)av.reinterpretShape(SPECIES_64, 0); // reinterpret back to 128-bits with the above reinterpreting results ByteVector cv = (ByteVector)bv.reinterpretShape(SPECIES_128, 0); cv.intoArray(c, 0) This case: 1. Reinterprets vector `"av"` from 128-bits to 64-bits. It should only copy the first 8 elements to vector `"bv"` and discard the higher half parts. 2. Reinterprets vector `"bv"` back to 128-bits. It copies the 64-bits from` "bv"` to` "cv"`, and paddings the rest part of `"cv"` with zero. The final values in array `"c"` are expected to be: c = [ 0, 1, 2, 3, 4, 5, 6, 7, 0, 0, 0, 0, 0, 0, 0, 0] However, with the optimization mentioned at the beginning, the second reinterpretation is optimized out. The values in array` "c" `are incorrectly copied from array `"a"`. The values are: c = [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] To fix it, this patch adds the vector size constraint for the optimization, that is the first reinterpretation must not be conducted to a shorter vector. It also fixes a potential issue for the implementation of match rule `"reinterpretX2D (from 16 bytes to 8 bytes)" `on Arm NEON. Specifically, the `"mov"` is always needed even if the` "dst"` and `"src"` are the same register since truncation should be conducted in order to be consistent with the semantics. ------------- Commit messages: - 8259353: VectorReinterpretNode is incorrectly optimized out Changes: https://git.openjdk.java.net/jdk16/pull/100/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=100&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259353 Stats: 45 lines in 3 files changed: 19 ins; 1 del; 25 mod Patch: https://git.openjdk.java.net/jdk16/pull/100.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/100/head:pull/100 PR: https://git.openjdk.java.net/jdk16/pull/100 From adinn at openjdk.java.net Mon Jan 11 09:35:01 2021 From: adinn at openjdk.java.net (Andrew Dinn) Date: Mon, 11 Jan 2021 09:35:01 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests [v3] In-Reply-To: References: Message-ID: <2vNAJAihgpB4q_wqeuf2Dtjbu9X-NpqfXtNMibnOOUc=.f52ed07a-702f-4d8b-9200-46986181e6a1@github.com> On Mon, 11 Jan 2021 07:30:15 GMT, Ningsheng Jian wrote: >> After applying [1], some Vector API tests fail with SIGILL on SVE >> system. The SIGILL was triggered by verify_ptrue before c2 compiled >> function returns, which means that the preserved p7 register (as ptrue) >> has been clobbered before returning to c2 compiled code. (p7 is not >> preserved cross function calls, and system calls [2]). >> >> Currently we try to reinitialize ptrue at each entrypoint of returning >> from non-c2 compiled code, which indicating possible C or system calls. >> However, there's still one entrypoint missing, exception handling, as >> we may jump to c2 compiled code for exception handler. See >> OptoRuntime::generate_exception_blob(). >> >> Adding reinitialize_ptrue before jumping back to c2 compiled code in >> generate_exception_blob() could solve those Vector API test failures. >> Actually I had that in my initial test patch [3], I don't know why I >> missed that in final patch... I reran tests with the same approach of >> [3] and found that there's still something missing, the >> nmethod_entry_barrier() in c2 function prolog. The barrier may call to >> runtime code (see generate_method_entry_barrier()). To reduce the risk >> of missing such reinitialize_ptrue in newly added code in future, I >> think it would be better to do the reinitialize in >> pop_call_clobbered_registers(). >> >> P.S. the SIGILL message is also not clear, it should print detailed >> message as indicated by MacroAssembler::stop() call. This is caused by >> JDK-8255711 removing the message printing code. This will be fixed by JDK-8259539. >> >> Tested with tier1-3 on SVE hardware. Also verified with the same >> approach of patch [3] with jtreg tests hotspot_all_no_apps and >> jdk:tier1-3 passed without incorrect ptrue value assertion failure. >> >> [1] https://github.com/openjdk/jdk/pull/1621 >> [2] https://github.com/torvalds/linux/blob/master/Documentation/arm64/sve.rst >> [3] http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch > > Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision: > > Revert signal handler changes, which will be fixed in JDK-8259539. This looks fine now. ------------- Marked as reviewed by adinn (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/50 From ngasson at openjdk.java.net Mon Jan 11 10:08:00 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Mon, 11 Jan 2021 10:08:00 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests [v3] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 07:30:15 GMT, Ningsheng Jian wrote: >> After applying [1], some Vector API tests fail with SIGILL on SVE >> system. The SIGILL was triggered by verify_ptrue before c2 compiled >> function returns, which means that the preserved p7 register (as ptrue) >> has been clobbered before returning to c2 compiled code. (p7 is not >> preserved cross function calls, and system calls [2]). >> >> Currently we try to reinitialize ptrue at each entrypoint of returning >> from non-c2 compiled code, which indicating possible C or system calls. >> However, there's still one entrypoint missing, exception handling, as >> we may jump to c2 compiled code for exception handler. See >> OptoRuntime::generate_exception_blob(). >> >> Adding reinitialize_ptrue before jumping back to c2 compiled code in >> generate_exception_blob() could solve those Vector API test failures. >> Actually I had that in my initial test patch [3], I don't know why I >> missed that in final patch... I reran tests with the same approach of >> [3] and found that there's still something missing, the >> nmethod_entry_barrier() in c2 function prolog. The barrier may call to >> runtime code (see generate_method_entry_barrier()). To reduce the risk >> of missing such reinitialize_ptrue in newly added code in future, I >> think it would be better to do the reinitialize in >> pop_call_clobbered_registers(). >> >> P.S. the SIGILL message is also not clear, it should print detailed >> message as indicated by MacroAssembler::stop() call. This is caused by >> JDK-8255711 removing the message printing code. This will be fixed by JDK-8259539. >> >> Tested with tier1-3 on SVE hardware. Also verified with the same >> approach of patch [3] with jtreg tests hotspot_all_no_apps and >> jdk:tier1-3 passed without incorrect ptrue value assertion failure. >> >> [1] https://github.com/openjdk/jdk/pull/1621 >> [2] https://github.com/torvalds/linux/blob/master/Documentation/arm64/sve.rst >> [3] http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch > > Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision: > > Revert signal handler changes, which will be fixed in JDK-8259539. Marked as reviewed by ngasson (Committer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/50 From aph at openjdk.java.net Mon Jan 11 10:41:58 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 11 Jan 2021 10:41:58 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 05:14:05 GMT, Dong Bo wrote: >> According to the results of `JMH perfasm`, `Math.max(max, Math.abs(floatsA[i] - floatsB[i]))` is vectorized when `COUNT=8` on a X86 platform. >> While on aarch64, `floatsB[i] = Math.abs(floatsA[i])` is not vectorized when `COUNT = 10` and we can not match `VAbs2F` neither. >> I am going to investigate the failed vectorization and see if we can have `Max2F` matched. Thanks. > > Hi, > > I made a mistake to say that the code is not vectorized with `COUNT < 12`, seems that the percentages of vectorized code is too small to be catched by `JMH perfasm`. > To observed if `Min/MaxReductionVNode` are created or not, I added a explicit print in `ReductionNode::make`, like: > --- a/src/hotspot/share/opto/vectornode.cpp > +++ b/src/hotspot/share/opto/vectornode.cpp > @@ -961,7 +961,9 @@ ReductionNode* ReductionNode::make(int opc, Node *ctrl, Node* n1, Node* n2, Basi > case Op_MinReductionV: return new MinReductionVNode(ctrl, n1, n2); > - case Op_MaxReductionV: return new MaxReductionVNode(ctrl, n1, n2); > + case Op_MaxReductionV: > + warning("in ReductionNode::make, making a MaxReductionVNode, length %d", n2->bottom_type()->is_vect()->length()); > + return new MaxReductionVNode(ctrl, n1, n2); > case Op_AndReductionV: return new AndReductionVNode(ctrl, n1, n2); > > In my observation, we have `Max4F` when `COUNT >= 4`, it is resonable to create `Max4F` other than `Max2F`. > The `Max2F` is created with `COUNT == 3` and `-XX:-SuperWordLoopUnrollAnalysis`. > But I did not find any noticeable improvements with such a small percentage. > > The JMH has been updated, the performance results are: > Benchmark (COUNT_DOUBLE) (COUNT_FLOAT) (seed) Mode Cnt Score Error Units > # Kunpeng 916, default > VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 677.778 ? 0.694 ns/op > VectorReductionFloatingMinMax.maxRedF 512 3 0 avgt 10 21.016 ? 0.097 ns/op > VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 677.633 ? 0.664 ns/op > VectorReductionFloatingMinMax.minRedF 512 3 0 avgt 10 21.001 ? 0.019 ns/op > # Kunpeng 916, fmaxp/fminp > VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 425.776 ? 0.785 ns/op > VectorReductionFloatingMinMax.maxRedF 512 3 0 avgt 10 20.883 ? 0.033 ns/op > VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 426.177 ? 3.258 ns/op > VectorReductionFloatingMinMax.minRedF 512 3 0 avgt 10 20.871 ? 0.044 ns/op Did you try math.abs() for doubles? ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From aph at openjdk.java.net Mon Jan 11 10:45:02 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 11 Jan 2021 10:45:02 GMT Subject: RFR: 8259044: JVM lacks data type qualifier when using -XX:+PrintAssembly with AArch64-Neon backend In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 03:32:44 GMT, Wang Huang wrote: > For instace: in the implentation of VectorMaskCmp & VectorStoreMask : > > $jtreg -vmoptions:"-XX:+PrintAssembly" ./Int128VectorTests.java > > Before fixing: > ----------------- > 0dc ldrq V17,[R10, #16] # vector (128 bits) > 0e0 cmeq V16, V16, V17 # vector cmp (4I) > 0e4 xtn V16, V16 # 4S to 4H > xtn V16, V16 # 4H to 4B > negr V16, V16 # store mask (4S to 4B) > ----------------- > Here? the output lacks data type qualifiers like T4S in `cmeq V16, V16, V17`. > > Expect: > ----------------- > 0dc ldrq V16,[R10, #16] # vector (128 bits) > 0e0 cmeq V16, T4S, V16, V18 # vector cmp (4I) > 0e4 xtn V16, T4H, V16, T4S # 4S to 4H > xtn V16, T8B, V16, T8H # 4H to 4B > negr V16, T8B, V16 # store mask (4S to 4B) > ----------------- Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1941 From github.com+6061213+sergey-platonov at openjdk.java.net Mon Jan 11 11:23:07 2021 From: github.com+6061213+sergey-platonov at openjdk.java.net (Sergey Platonov) Date: Mon, 11 Jan 2021 11:23:07 GMT Subject: RFR: 8257709: C1: Double assignment in InstructionPrinter::print_stack Message-ID: There is currently a minor bug (just a typo, actually) in the hotspot, leading to undefined behavior. ------------- Commit messages: - 8257709: C1: Double assignment in InstructionPrinter::print_stack Changes: https://git.openjdk.java.net/jdk/pull/1519/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1519&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257709 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1519.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1519/head:pull/1519 PR: https://git.openjdk.java.net/jdk/pull/1519 From shade at openjdk.java.net Mon Jan 11 11:23:07 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Jan 2021 11:23:07 GMT Subject: RFR: 8257709: C1: Double assignment in InstructionPrinter::print_stack In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 14:26:23 GMT, Sergey Platonov wrote: > There is currently a minor bug (just a typo, actually) in the hotspot, leading > to undefined behavior. Changes requested by shade (Reviewer). Submitted: https://bugs.openjdk.java.net/browse/JDK-8257709 -- please rename this PR to "8257709: C1: Double assignment in InstructionPrinter::print_stack" to get it hooked properly. Also, can you please go to https://github.com/sergey-platonov/jdk/actions and check that testing workflow is enabled? If not, can you trigger it manually on your branch? src/hotspot/share/c1/c1_InstructionPrinter.cpp line 242: > 240: fill_to(start_position, ' '); > 241: output()->print("locks ["); > 242: for (int i = 0; i < stack->locks_size(); ++i) { I would prefer to keep `i++`, as in old code, unless it fixes something I don't quite see. ------------- PR: https://git.openjdk.java.net/jdk/pull/1519 From github.com+6061213+sergey-platonov at openjdk.java.net Mon Jan 11 11:23:08 2021 From: github.com+6061213+sergey-platonov at openjdk.java.net (Sergey Platonov) Date: Mon, 11 Jan 2021 11:23:08 GMT Subject: RFR: 8257709: C1: Double assignment in InstructionPrinter::print_stack In-Reply-To: References: Message-ID: <_AKtHZkLVudBwUR28MyqJ7QNyypJ_piP5cxP0xLhWDU=.5790f40a-e84f-4163-8c4c-eef9a2de5870@github.com> On Thu, 3 Dec 2020 18:00:29 GMT, Aleksey Shipilev wrote: >> There is currently a minor bug (just a typo, actually) in the hotspot, leading >> to undefined behavior. > > src/hotspot/share/c1/c1_InstructionPrinter.cpp line 242: > >> 240: fill_to(start_position, ' '); >> 241: output()->print("locks ["); >> 242: for (int i = 0; i < stack->locks_size(); ++i) { > > I would prefer to keep `i++`, as in old code, unless it fixes something I don't quite see. Done. Can you, please, create an issue, so I can mention it here? ------------- PR: https://git.openjdk.java.net/jdk/pull/1519 From shade at openjdk.java.net Mon Jan 11 11:23:09 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Jan 2021 11:23:09 GMT Subject: RFR: 8257709: C1: Double assignment in InstructionPrinter::print_stack In-Reply-To: <_AKtHZkLVudBwUR28MyqJ7QNyypJ_piP5cxP0xLhWDU=.5790f40a-e84f-4163-8c4c-eef9a2de5870@github.com> References: <_AKtHZkLVudBwUR28MyqJ7QNyypJ_piP5cxP0xLhWDU=.5790f40a-e84f-4163-8c4c-eef9a2de5870@github.com> Message-ID: On Mon, 11 Jan 2021 08:33:27 GMT, Sergey Platonov wrote: >> src/hotspot/share/c1/c1_InstructionPrinter.cpp line 242: >> >>> 240: fill_to(start_position, ' '); >>> 241: output()->print("locks ["); >>> 242: for (int i = 0; i < stack->locks_size(); ++i) { >> >> I would prefer to keep `i++`, as in old code, unless it fixes something I don't quite see. > > Done. Can you, please, create an issue, so I can mention it here? I did already, see https://github.com/openjdk/jdk/pull/1519#issuecomment-738180725. ------------- PR: https://git.openjdk.java.net/jdk/pull/1519 From github.com+6061213+sergey-platonov at openjdk.java.net Mon Jan 11 11:23:09 2021 From: github.com+6061213+sergey-platonov at openjdk.java.net (Sergey Platonov) Date: Mon, 11 Jan 2021 11:23:09 GMT Subject: RFR: 8257709: C1: Double assignment in InstructionPrinter::print_stack In-Reply-To: References: <_AKtHZkLVudBwUR28MyqJ7QNyypJ_piP5cxP0xLhWDU=.5790f40a-e84f-4163-8c4c-eef9a2de5870@github.com> Message-ID: On Mon, 11 Jan 2021 09:40:14 GMT, Aleksey Shipilev wrote: >> Done. Can you, please, create an issue, so I can mention it here? > > I did already, see https://github.com/openjdk/jdk/pull/1519#issuecomment-738180725. Oh, sorry! I guess, haven't completely got back from the vacation :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/1519 From github.com+6061213+sergey-platonov at openjdk.java.net Mon Jan 11 11:23:09 2021 From: github.com+6061213+sergey-platonov at openjdk.java.net (Sergey Platonov) Date: Mon, 11 Jan 2021 11:23:09 GMT Subject: RFR: 8257709: C1: Double assignment in InstructionPrinter::print_stack In-Reply-To: References: <_AKtHZkLVudBwUR28MyqJ7QNyypJ_piP5cxP0xLhWDU=.5790f40a-e84f-4163-8c4c-eef9a2de5870@github.com> Message-ID: On Mon, 11 Jan 2021 11:12:14 GMT, Sergey Platonov wrote: >> I did already, see https://github.com/openjdk/jdk/pull/1519#issuecomment-738180725. > > Oh, sorry! I guess, haven't completely got back from the vacation :-) Pipeline is on the way. ------------- PR: https://git.openjdk.java.net/jdk/pull/1519 From shade at openjdk.java.net Mon Jan 11 11:26:58 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Jan 2021 11:26:58 GMT Subject: RFR: 8257709: C1: Double assignment in InstructionPrinter::print_stack In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 14:26:23 GMT, Sergey Platonov wrote: > There is currently a minor bug (just a typo, actually) in the hotspot, leading > to undefined behavior. Looks good. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1519 From shade at openjdk.java.net Mon Jan 11 11:30:01 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Jan 2021 11:30:01 GMT Subject: RFR: 8257709: C1: Double assignment in InstructionPrinter::print_stack In-Reply-To: References: Message-ID: <5zWThs7TbqUpXyN-VcOYQTYIhqdongSSIqKXglkVpbE=.885111b2-d828-43b7-93ba-db8b2e173b82@github.com> On Mon, 11 Jan 2021 11:24:04 GMT, Aleksey Shipilev wrote: >> There is currently a minor bug (just a typo, actually) in the hotspot, leading >> to undefined behavior. > > Looks good. ...ah, and maybe merge from `master` to get all the recent fixes. Current tests might fail on known issues. Not that it is necessary for a simple issue like this, but it helps to learn the contribution ropes in this project. ------------- PR: https://git.openjdk.java.net/jdk/pull/1519 From dongbo at openjdk.java.net Mon Jan 11 11:41:14 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Mon, 11 Jan 2021 11:41:14 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 10:38:41 GMT, Andrew Haley wrote: >> Hi, >> >> I made a mistake to say that the code is not vectorized with `COUNT < 12`, seems that the percentages of vectorized code is too small to be catched by `JMH perfasm`. >> To observed if `Min/MaxReductionVNode` are created or not, I added a explicit print in `ReductionNode::make`, like: >> --- a/src/hotspot/share/opto/vectornode.cpp >> +++ b/src/hotspot/share/opto/vectornode.cpp >> @@ -961,7 +961,9 @@ ReductionNode* ReductionNode::make(int opc, Node *ctrl, Node* n1, Node* n2, Basi >> case Op_MinReductionV: return new MinReductionVNode(ctrl, n1, n2); >> - case Op_MaxReductionV: return new MaxReductionVNode(ctrl, n1, n2); >> + case Op_MaxReductionV: >> + warning("in ReductionNode::make, making a MaxReductionVNode, length %d", n2->bottom_type()->is_vect()->length()); >> + return new MaxReductionVNode(ctrl, n1, n2); >> case Op_AndReductionV: return new AndReductionVNode(ctrl, n1, n2); >> >> In my observation, we have `Max4F` when `COUNT >= 4`, it is resonable to create `Max4F` other than `Max2F`. >> The `Max2F` is created with `COUNT == 3` and `-XX:-SuperWordLoopUnrollAnalysis`. >> But I did not find any noticeable improvements with such a small percentage. >> >> The JMH has been updated, the performance results are: >> Benchmark (COUNT_DOUBLE) (COUNT_FLOAT) (seed) Mode Cnt Score Error Units >> # Kunpeng 916, default >> VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 677.778 ? 0.694 ns/op >> VectorReductionFloatingMinMax.maxRedF 512 3 0 avgt 10 21.016 ? 0.097 ns/op >> VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 677.633 ? 0.664 ns/op >> VectorReductionFloatingMinMax.minRedF 512 3 0 avgt 10 21.001 ? 0.019 ns/op >> # Kunpeng 916, fmaxp/fminp >> VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 425.776 ? 0.785 ns/op >> VectorReductionFloatingMinMax.maxRedF 512 3 0 avgt 10 20.883 ? 0.033 ns/op >> VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 426.177 ? 3.258 ns/op >> VectorReductionFloatingMinMax.minRedF 512 3 0 avgt 10 20.871 ? 0.044 ns/op > > Did you try math.abs() for doubles? The `Math.abs(doublesA[i] - doublesB[i])` has `~36%` improvements. I updated the tests for doubles with `Math.abs()`, it looks more consistent. Thanks. The JMH results of doubles with `Math.abs()`: Benchmark (COUNT_DOUBLE) (COUNT_FLOAT) (seed) Mode Cnt Score Error Units # Kunpeng 916, default VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 681.319 ? 0.658 ns/op VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 682.596 ? 4.322 ns/op # Kunpeng 916, fmaxp/fminp VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 439.130 ? 0.450 ns/op => 35.54% VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 439.105 ? 0.435 ns/op => 35.67% ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From dongbo at openjdk.java.net Mon Jan 11 11:41:13 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Mon, 11 Jan 2021 11:41:13 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v6] In-Reply-To: References: Message-ID: <4nnhdRP9gsILzFv5MvE_1usJtLBwmtoThIErfRgcftw=.277fc10e-1bc2-4a99-97e6-ca1562b625c3@github.com> > This patch optimizes vectorial Min/Max reduction of two floating-point numbers on aarch64 with NEON instructions `fmaxp` and `fminp`. > > Passed jtreg tier1-3 tests with `linux-aarch64-server-fastdebug` build. > Tests under `test/jdk/jdk/incubator/vector/` runned specially for the correctness and passed. > > Introduced a new JMH micro `test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java` for performance test. > Witnessed abount `37%` performance improvements on Kunpeng916. The JMH Results: > Benchmark (COUNT) (seed) Mode Cnt Score Error Units > # Kunpeng 916, default > VectorReduction.maxRedD 512 0 avgt 10 678.126 ? 0.815 ns/op > VectorReduction.maxRedF 512 0 avgt 10 242.958 ? 0.212 ns/op > VectorReduction.minRedD 512 0 avgt 10 678.554 ? 0.824 ns/op > VectorReduction.minRedF 512 0 avgt 10 243.368 ? 0.205 ns/op > > # Kunpeng 916, with fmaxp/fminp > VectorReduction.maxRedD 512 0 avgt 10 430.201 ? 0.353 ns/op => 36.56% > VectorReduction.maxRedF 512 0 avgt 10 243.404 ? 0.297 ns/op > VectorReduction.minRedD 512 0 avgt 10 427.805 ? 0.528 ns/op => 36.89% > VectorReduction.minRedF 512 0 avgt 10 242.963 ? 0.210 ns/op Dong Bo has updated the pull request incrementally with one additional commit since the last revision: test improvements for doubles with Math.abs() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1925/files - new: https://git.openjdk.java.net/jdk/pull/1925/files/f244ed01..4d6d32e6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1925&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1925&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1925.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1925/head:pull/1925 PR: https://git.openjdk.java.net/jdk/pull/1925 From chagedorn at openjdk.java.net Mon Jan 11 11:42:55 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 11 Jan 2021 11:42:55 GMT Subject: RFR: 8257709: C1: Double assignment in InstructionPrinter::print_stack In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 14:26:23 GMT, Sergey Platonov wrote: > There is currently a minor bug (just a typo, actually) in the hotspot, leading > to undefined behavior. Looks good. ------------- Marked as reviewed by chagedorn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1519 From dongbo at openjdk.java.net Mon Jan 11 12:31:56 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Mon, 11 Jan 2021 12:31:56 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 11:38:01 GMT, Dong Bo wrote: >> Did you try math.abs() for doubles? > > The `Math.abs(doublesA[i] - doublesB[i])` has `~36%` improvements. > I updated the tests for doubles with `Math.abs()`, it looks more consistent. Thanks. > The JMH results of doubles with `Math.abs()`: > Benchmark (COUNT_DOUBLE) (COUNT_FLOAT) (seed) Mode Cnt Score Error Units > # Kunpeng 916, default > VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 681.319 ? 0.658 ns/op > VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 682.596 ? 4.322 ns/op > # Kunpeng 916, fmaxp/fminp > VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 439.130 ? 0.450 ns/op => 35.54% > VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 439.105 ? 0.435 ns/op => 35.67% For single-precision floating-point operands, as the experiments showed, we can have `Max2F` match only with `COUNT == 3`. With such a small loop under superword framework, it is diffcult to tell how much improvements of `fmaxp/fminp` over `fmaxv+ins`. Although it sounds unreasonable for an application to use `Float64Vector` rather than `Float128Vecotor`, the optimization does being useful for VectorAPI `Float64Vector.reduceLanes(VectorOperators.MAX)` as mentioned previously. Do you think we should remove single-precision floating-point parts in this patch? ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From rcastanedalo at openjdk.java.net Mon Jan 11 12:49:09 2021 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Mon, 11 Jan 2021 12:49:09 GMT Subject: [jdk16] RFR: 8259061: C2: assert(found) failed: memory-writing node is not placed in its original loop or an ancestor of it Message-ID: Remove assertion that is too general, that is, it can fail on compilations where C2 generates correct code otherwise. The assertion was introduced in [JDK-8255763](https://bugs.openjdk.java.net/browse/JDK-8255763) to prevent potential miscompilations in the case of irreducible CFGs, and will be reconsidered in [JDK-8258894](https://bugs.openjdk.java.net/browse/JDK-8258894) where the general case is addressed. Tested by building (release and debug) on different platforms. ------------- Commit messages: - JDK-8259061: C2: assert(found) failed: memory-writing node is not placed in its original loop or an ancestor of it Changes: https://git.openjdk.java.net/jdk16/pull/101/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=101&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259061 Stats: 20 lines in 1 file changed: 0 ins; 20 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/101.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/101/head:pull/101 PR: https://git.openjdk.java.net/jdk16/pull/101 From rcastanedalo at openjdk.java.net Mon Jan 11 12:49:09 2021 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Mon, 11 Jan 2021 12:49:09 GMT Subject: [jdk16] RFR: 8259061: C2: assert(found) failed: memory-writing node is not placed in its original loop or an ancestor of it In-Reply-To: References: Message-ID: <9GQqhkvo5yxFZghj4firam7697e8lwU9XBVB8pfz6vo=.65ab8d19-e983-459d-86ea-622f17f1a54b@github.com> On Mon, 11 Jan 2021 12:27:18 GMT, Roberto Casta?eda Lozano wrote: > Remove assertion that is too general, that is, it can fail on compilations where C2 generates correct code otherwise. > > The assertion was introduced in [JDK-8255763](https://bugs.openjdk.java.net/browse/JDK-8255763) to prevent potential miscompilations in the case of irreducible CFGs, and will be reconsidered in [JDK-8258894](https://bugs.openjdk.java.net/browse/JDK-8258894) where the general case is addressed. > > Tested by building (release and debug) on different platforms. Remove assertion that is too general, that is, it can fail on compilations where C2 generates correct code otherwise. ------------- PR: https://git.openjdk.java.net/jdk16/pull/101 From chagedorn at openjdk.java.net Mon Jan 11 12:57:04 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 11 Jan 2021 12:57:04 GMT Subject: [jdk16] RFR: 8259061: C2: assert(found) failed: memory-writing node is not placed in its original loop or an ancestor of it In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 12:27:18 GMT, Roberto Casta?eda Lozano wrote: > Remove assertion that is too general, that is, it can fail on compilations where C2 generates correct code otherwise. > > The assertion was introduced in [JDK-8255763](https://bugs.openjdk.java.net/browse/JDK-8255763) to prevent potential miscompilations in the case of irreducible CFGs, and will be reconsidered in [JDK-8258894](https://bugs.openjdk.java.net/browse/JDK-8258894) where the general case is addressed. > > Tested by building (release and debug) on different platforms. That's reasonable. Looks good to me! ------------- Marked as reviewed by chagedorn (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/101 From vlivanov at openjdk.java.net Mon Jan 11 12:59:00 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 11 Jan 2021 12:59:00 GMT Subject: [jdk16] RFR: 8259353: VectorReinterpretNode is incorrectly optimized out In-Reply-To: References: Message-ID: <8bPOqQ22N2FDGHuRqcJ7aOsezcNYT7c4FhTD_X7RbhU=.a5112299-bdac-41fc-ad4d-9cbb19a75ee8@github.com> On Mon, 11 Jan 2021 09:23:24 GMT, Xiaohong Gong wrote: > Vector reinterpretation just reinterprets the bytes of the vector without performing any value conversions. So normally, optimization like: > (VectorReinterpret (VectorReinterpret src)) -> src > can be applied correctly if the logical result and the input `"src"` have the same vector type. However, the results might not be correct if truncation happens after the first reinterpretation: `"(VectorReinterpret src)"`. > > Consider the following case: > byte[] a = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15} > byte[] b = new byte[16] > byte[] c = new byte[16] > > // load vector from "a" with 128-bits > ByteVector av = ByteVector.fromArray(SPECIES_128, a, 0); > > // reinterpret to 64-bits > ByteVector bv = (ByteVector)av.reinterpretShape(SPECIES_64, 0); > > // reinterpret back to 128-bits with the above reinterpreting results > ByteVector cv = (ByteVector)bv.reinterpretShape(SPECIES_128, 0); > cv.intoArray(c, 0) > This case: > 1. Reinterprets vector `"av"` from 128-bits to 64-bits. It should only copy the first 8 elements to vector `"bv"` and discard the higher half parts. > 2. Reinterprets vector `"bv"` back to 128-bits. It copies the 64-bits from` "bv"` to` "cv"`, and paddings the rest part of `"cv"` with zero. > The final values in array `"c"` are expected to be: > c = [ 0, 1, 2, 3, 4, 5, 6, 7, 0, 0, 0, 0, 0, 0, 0, 0] > However, with the optimization mentioned at the beginning, the second reinterpretation is optimized out. The values in array` "c" `are incorrectly copied from array `"a"`. The values are: > c = [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] > To fix it, this patch adds the vector size constraint for the optimization, that is the first reinterpretation must not be conducted to a shorter vector. > > It also fixes a potential issue for the implementation of match rule `"reinterpretX2D (from 16 bytes to 8 bytes)" `on Arm NEON. Specifically, the `"mov"` is always needed even if the` "dst"` and `"src"` are the same register since truncation should be conducted in order to be consistent with the semantics. Marked as reviewed by vlivanov (Reviewer). Good catch! The fix in shared code looks good. I suggest to split up the patch and review AArch64-specific changes separately. ------------- PR: https://git.openjdk.java.net/jdk16/pull/100 From thartmann at openjdk.java.net Mon Jan 11 13:06:05 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 11 Jan 2021 13:06:05 GMT Subject: [jdk16] RFR: 8259061: C2: assert(found) failed: memory-writing node is not placed in its original loop or an ancestor of it In-Reply-To: References: Message-ID: <9mWihHdwZSm8TbOm3VRjW0_OcdKtRsCupU-O_8Fwjzo=.139fb5d9-5405-43fc-b0ee-22df079db081@github.com> On Mon, 11 Jan 2021 12:27:18 GMT, Roberto Casta?eda Lozano wrote: > Remove assertion that is too general, that is, it can fail on compilations where C2 generates correct code otherwise. > > The assertion was introduced in [JDK-8255763](https://bugs.openjdk.java.net/browse/JDK-8255763) to prevent potential miscompilations in the case of irreducible CFGs, and will be reconsidered in [JDK-8258894](https://bugs.openjdk.java.net/browse/JDK-8258894) where the general case is addressed. > > Tested by building (release and debug) on different platforms. Looks good to me too. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/101 From rcastanedalo at openjdk.java.net Mon Jan 11 13:06:05 2021 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Mon, 11 Jan 2021 13:06:05 GMT Subject: [jdk16] RFR: 8259061: C2: assert(found) failed: memory-writing node is not placed in its original loop or an ancestor of it In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 12:53:57 GMT, Christian Hagedorn wrote: > That's reasonable. Looks good to me! Thanks for reviewing, Christian! ------------- PR: https://git.openjdk.java.net/jdk16/pull/101 From rcastanedalo at openjdk.java.net Mon Jan 11 13:08:55 2021 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Mon, 11 Jan 2021 13:08:55 GMT Subject: [jdk16] RFR: 8259061: C2: assert(found) failed: memory-writing node is not placed in its original loop or an ancestor of it In-Reply-To: <9mWihHdwZSm8TbOm3VRjW0_OcdKtRsCupU-O_8Fwjzo=.139fb5d9-5405-43fc-b0ee-22df079db081@github.com> References: <9mWihHdwZSm8TbOm3VRjW0_OcdKtRsCupU-O_8Fwjzo=.139fb5d9-5405-43fc-b0ee-22df079db081@github.com> Message-ID: <8IwkSFYqFFeXL5Q-Q0Wn1DLDoLY2pM_eaSznzDaXB_s=.653f0bc2-60c4-45fb-a823-47c61f7ddf82@github.com> On Mon, 11 Jan 2021 13:03:18 GMT, Tobias Hartmann wrote: > Looks good to me too. Thanks, Tobias! ------------- PR: https://git.openjdk.java.net/jdk16/pull/101 From github.com+6061213+sergey-platonov at openjdk.java.net Mon Jan 11 14:14:21 2021 From: github.com+6061213+sergey-platonov at openjdk.java.net (Sergey Platonov) Date: Mon, 11 Jan 2021 14:14:21 GMT Subject: RFR: 8257709: C1: Double assignment in InstructionPrinter::print_stack [v2] In-Reply-To: References: Message-ID: > There is currently a minor bug (just a typo, actually) in the hotspot, leading > to undefined behavior. Sergey Platonov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into fix/hotspot-possible-ub - 8257709: C1: Double assignment in InstructionPrinter::print_stack There is currently a minor bug (just a typo, actually) in the hotspot, leading to undefined behavior. Issue: JDK-8257709: C1: Double assignment in InstructionPrinter::print_stack ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1519/files - new: https://git.openjdk.java.net/jdk/pull/1519/files/ca66b57a..c75652cd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1519&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1519&range=00-01 Stats: 96528 lines in 2605 files changed: 58391 ins; 19776 del; 18361 mod Patch: https://git.openjdk.java.net/jdk/pull/1519.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1519/head:pull/1519 PR: https://git.openjdk.java.net/jdk/pull/1519 From github.com+6061213+sergey-platonov at openjdk.java.net Mon Jan 11 14:14:24 2021 From: github.com+6061213+sergey-platonov at openjdk.java.net (Sergey Platonov) Date: Mon, 11 Jan 2021 14:14:24 GMT Subject: RFR: 8257709: C1: Double assignment in InstructionPrinter::print_stack [v2] In-Reply-To: References: Message-ID: <0QnuBA5eYke6BCBi1gIfhM-tNzY6rVmx0zUY0Fyyot0=.c7cd63e1-be06-43c4-b109-8a3eabe80522@github.com> On Mon, 11 Jan 2021 11:39:56 GMT, Christian Hagedorn wrote: >> Sergey Platonov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into fix/hotspot-possible-ub >> - 8257709: C1: Double assignment in InstructionPrinter::print_stack >> >> There is currently a minor bug (just a typo, actually) in the hotspot, leading >> to undefined behavior. >> Issue: JDK-8257709: C1: Double assignment in InstructionPrinter::print_stack > > Looks good. > ...ah, and maybe merge from `master` to get all the recent fixes. Current tests might fail on known issues. Not that it is necessary for a simple issue like this, but it helps to learn the contribution ropes in this project. Done! Will commits be squashed? ------------- PR: https://git.openjdk.java.net/jdk/pull/1519 From shade at openjdk.java.net Mon Jan 11 14:14:24 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Jan 2021 14:14:24 GMT Subject: RFR: 8257709: C1: Double assignment in InstructionPrinter::print_stack [v2] In-Reply-To: <0QnuBA5eYke6BCBi1gIfhM-tNzY6rVmx0zUY0Fyyot0=.c7cd63e1-be06-43c4-b109-8a3eabe80522@github.com> References: <0QnuBA5eYke6BCBi1gIfhM-tNzY6rVmx0zUY0Fyyot0=.c7cd63e1-be06-43c4-b109-8a3eabe80522@github.com> Message-ID: On Mon, 11 Jan 2021 14:08:40 GMT, Sergey Platonov wrote: > > ...ah, and maybe merge from `master` to get all the recent fixes. Current tests might fail on known issues. Not that it is necessary for a simple issue like this, but it helps to learn the contribution ropes in this project. > > Done! Will commits be squashed? Yes, bots would squash the commits during integration. You don't need to rebase or do anything else Git-wise. Once testing is clean, you can say `/integrate`, as bots suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/1519 From github.com+6061213+sergey-platonov at openjdk.java.net Mon Jan 11 14:30:54 2021 From: github.com+6061213+sergey-platonov at openjdk.java.net (Sergey Platonov) Date: Mon, 11 Jan 2021 14:30:54 GMT Subject: RFR: 8257709: C1: Double assignment in InstructionPrinter::print_stack [v2] In-Reply-To: References: <0QnuBA5eYke6BCBi1gIfhM-tNzY6rVmx0zUY0Fyyot0=.c7cd63e1-be06-43c4-b109-8a3eabe80522@github.com> Message-ID: On Mon, 11 Jan 2021 14:10:50 GMT, Aleksey Shipilev wrote: > > > ...ah, and maybe merge from `master` to get all the recent fixes. Current tests might fail on known issues. Not that it is necessary for a simple issue like this, but it helps to learn the contribution ropes in this project. > > > > > > Done! Will commits be squashed? > > Yes, bots would squash the commits during integration. You don't need to rebase or do anything else Git-wise. Once testing is clean, you can say `/integrate`, as bots suggested. Great! Thank you for your help, Aleksey! ------------- PR: https://git.openjdk.java.net/jdk/pull/1519 From martin.doerr at sap.com Mon Jan 11 15:49:52 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 11 Jan 2021 15:49:52 +0000 Subject: [11u] RFR: 8255479: [aarch64] assert(src->section_index_of(target) == CodeBuffer::SECT_NONE) failed: sanity Message-ID: Hi, JDK-8255479 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly. I had to integrate 2 small hunks manually: 1. g1BarrierSetAssembler_aarch64.cpp: Unrelated context change. 2. macroAssembler_aarch64.cpp: Unrelated context change, minor differences in code which gets removed by this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8255479 Original change: https://github.com/openjdk/jdk/commit/695117f8 11u backport: http://cr.openjdk.java.net/~mdoerr/8255479_aarch64_11u/webrev.00/ Please review. Best regards, Martin From eosterlund at openjdk.java.net Mon Jan 11 16:17:14 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 11 Jan 2021 16:17:14 GMT Subject: [jdk16] RFR: 8259063: Possible deadlock with vtable/itable creation vs concurrent class unloading Message-ID: There is an offender of consistent lock ordering: the creation of itable/vtable stubs. It happens when an inline cache is transitioning to megamorphic. Way earlier in the call stack, we grab the nmethod lock for IC patching, and then when a megamorphic transition happens *and* there is no stub created yet for the given vtable/itable index (rather uncommon), a new vtable/itable stub is created. This creation of a stub takes the CodeCache lock. We already deal with failure to create the stubs today, by making the inline cache "clean" instead, essentially deferring the transition to megamorphic to a subsequent call. We deal with that today to handle the code cache running out of memory, making it temporarily impossible to transition to megamorphic until memory has been freed up. My patch rides on that logic, so that we can try_lock() the CodeCache_lock instead. If we fail to take the lock, then it is arguably a bad time to do this megamorphic transition, regardless of deadlocks, as we m ight have to wait quite a while. So if we fail to take the lock, I just return NULL saying we couldn't create a vtable/itable stub at this time, signalling we defer the transition to later, as we would also do if we couldn't create the stub due to memory exhaustion. This solves the deadlock situation. Eric Caspole who reported the bug has tried this patch, and it solved the problem. I also tried it with the same test myself, with the same successful results. I also ran it through tier1-5 as it is touching inline cache code which can be a bit subtle. ------------- Commit messages: - 8259063: Possible deadlock with vtable/itable creation vs concurrent class unloading Changes: https://git.openjdk.java.net/jdk16/pull/103/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=103&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259063 Stats: 15 lines in 1 file changed: 13 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk16/pull/103.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/103/head:pull/103 PR: https://git.openjdk.java.net/jdk16/pull/103 From iveresov at openjdk.java.net Mon Jan 11 17:52:02 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Mon, 11 Jan 2021 17:52:02 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: <3FqXOR8NSsGbCExqGxRWPfWOrlb0Rpl0bU3Ug__8I8g=.c74bae33-89af-47b5-b02d-6546a9f538a7@github.com> References: <3FqXOR8NSsGbCExqGxRWPfWOrlb0Rpl0bU3Ug__8I8g=.c74bae33-89af-47b5-b02d-6546a9f538a7@github.com> Message-ID: On Mon, 11 Jan 2021 09:06:36 GMT, Boris Ulasevich wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix another s390 compilation failure > > src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp line 376: > >> 374: // Note: In tiered we increment either counters in MethodCounters* or >> 375: // in MDO depending if we're profiling or not. >> 376: int increment = InvocationCounter::count_increment; > > The small code below seems not to be equivalent replacement for the above code. I would appreciate some explanation on why we change the things. Thanks. It's a just the code that was guarded before by ```if (TieredCompilation)```. It was just the else part that's gotten removed. Since the new policy is base off of tiered we don't need the old style of callbacks. Is there something else that you've noticed? ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Mon Jan 11 17:56:54 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Mon, 11 Jan 2021 17:56:54 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: On Mon, 11 Jan 2021 09:09:12 GMT, Boris Ulasevich wrote: > I see some regression on ARM32 with this change: > http://cr.openjdk.java.net/~bulasevich/tmp/8251462_jtreg_hotspot/ I don't think those are related to the changes. Those are probably some preexisting c1 and c2 problems respectively that for some reason weren't triggered before. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Mon Jan 11 18:14:00 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 11 Jan 2021 18:14:00 GMT Subject: [jdk16] RFR: 8259061: C2: assert(found) failed: memory-writing node is not placed in its original loop or an ancestor of it In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 12:27:18 GMT, Roberto Casta?eda Lozano wrote: > Remove assertion that is too general, that is, it can fail on compilations where C2 generates correct code otherwise. > > The assertion was introduced in [JDK-8255763](https://bugs.openjdk.java.net/browse/JDK-8255763) to prevent potential miscompilations in the case of irreducible CFGs, and will be reconsidered in [JDK-8258894](https://bugs.openjdk.java.net/browse/JDK-8258894) where the general case is addressed. > > Tested by building (release and debug) on different platforms. Agree. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/101 From shade at openjdk.java.net Mon Jan 11 18:42:07 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Jan 2021 18:42:07 GMT Subject: RFR: 8259576: Misplaced curly brace in Matcher::find_shared_post_visit Message-ID: SonarCloud demo instance reports the issue here: case Op_VectorMaskCmp: { n->set_req(1, new BinaryNode(n->in(1), n->in(2))); n->set_req(2, n->in(3)); n->del_req(3); break; default: // <----- ERROR break; } "The direct parent of this switch-label is not the body of a switch statement." This is added by JDK-8223347, and it is an obviously misplaced curly-brace. It is innocuous in current code, but may become problematic as more cases are added to the switch. ------------- Commit messages: - 8259576: Misplaced curly brace in Matcher::find_shared_post_visit Changes: https://git.openjdk.java.net/jdk/pull/2031/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2031&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259576 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2031.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2031/head:pull/2031 PR: https://git.openjdk.java.net/jdk/pull/2031 From lucy at openjdk.java.net Mon Jan 11 18:51:06 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Mon, 11 Jan 2021 18:51:06 GMT Subject: RFR: 8259576: Misplaced curly brace in Matcher::find_shared_post_visit In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 18:37:40 GMT, Aleksey Shipilev wrote: > SonarCloud demo instance reports the issue here: > > case Op_VectorMaskCmp: { > n->set_req(1, new BinaryNode(n->in(1), n->in(2))); > n->set_req(2, n->in(3)); > n->del_req(3); > break; > default: // <----- ERROR > break; > } > > "The direct parent of this switch-label is not the body of a switch statement." > > This is added by JDK-8223347, and it is an obviously misplaced curly-brace. It is innocuous in current code, but may become problematic as more cases are added to the switch. This fix looks good (and trivial) to me. I personally would open a separate context for a case body only if there is an actual need (decl of locals, e.g.). But that's just my taste. Not relevant at all. ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2031 From shade at openjdk.java.net Mon Jan 11 19:17:11 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Jan 2021 19:17:11 GMT Subject: RFR: 8259583: Remove unused decode_env::_codeBuffer Message-ID: SonarCloud instance reports that decode_env::_codeBuffer field is not initialized in constructor. But really, the field is never used after [JDK-8222079](https://bugs.openjdk.java.net/browse/JDK-8222079). Additional testing: - [x] No grep hits for `_codeBuffer` in `src/` ------------- Commit messages: - 8259583: Remove unused decode_env::_codeBuffer Changes: https://git.openjdk.java.net/jdk/pull/2034/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2034&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259583 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2034.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2034/head:pull/2034 PR: https://git.openjdk.java.net/jdk/pull/2034 From hohensee at amazon.com Mon Jan 11 22:32:13 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 11 Jan 2021 22:32:13 +0000 Subject: [11u] RFR: 8255479: [aarch64] assert(src->section_index_of(target) == CodeBuffer::SECT_NONE) failed: sanity Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Doerr, Martin" Date: Monday, January 11, 2021 at 7:51 AM To: "jdk-updates-dev at openjdk.java.net" , "'hotspot-compiler-dev at openjdk.java.net'" Cc: "Lindenmaier, Goetz" , "Langer, Christoph" Subject: [11u] RFR: 8255479: [aarch64] assert(src->section_index_of(target) == CodeBuffer::SECT_NONE) failed: sanity Hi, JDK-8255479 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly. I had to integrate 2 small hunks manually: 1. g1BarrierSetAssembler_aarch64.cpp: Unrelated context change. 2. macroAssembler_aarch64.cpp: Unrelated context change, minor differences in code which gets removed by this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8255479 Original change: https://github.com/openjdk/jdk/commit/695117f8 11u backport: http://cr.openjdk.java.net/~mdoerr/8255479_aarch64_11u/webrev.00/ Please review. Best regards, Martin From martin.doerr at sap.com Mon Jan 11 22:41:35 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 11 Jan 2021 22:41:35 +0000 Subject: [11u] RFR: 8255479: [aarch64] assert(src->section_index_of(target) == CodeBuffer::SECT_NONE) failed: sanity In-Reply-To: References: Message-ID: Hi Paul, thanks for the review. Best regards, Martin > -----Original Message----- > From: Hohensee, Paul > Sent: Montag, 11. Januar 2021 23:32 > To: Doerr, Martin ; jdk-updates- > dev at openjdk.java.net; 'hotspot-compiler-dev at openjdk.java.net' compiler-dev at openjdk.java.net> > Cc: Lindenmaier, Goetz ; Langer, Christoph > > Subject: RE: [11u] RFR: 8255479: [aarch64] assert(src- > >section_index_of(target) == CodeBuffer::SECT_NONE) failed: sanity > > Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on > behalf of "Doerr, Martin" > Date: Monday, January 11, 2021 at 7:51 AM > To: "jdk-updates-dev at openjdk.java.net" dev at openjdk.java.net>, "'hotspot-compiler-dev at openjdk.java.net'" > > Cc: "Lindenmaier, Goetz" , "Langer, > Christoph" > Subject: [11u] RFR: 8255479: [aarch64] assert(src->section_index_of(target) > == CodeBuffer::SECT_NONE) failed: sanity > > Hi, > > JDK-8255479 is backported to 11.0.11-oracle. I'd like to backport it for parity. > Change doesn't apply cleanly. I had to integrate 2 small hunks manually: > 1. g1BarrierSetAssembler_aarch64.cpp: Unrelated context change. > 2. macroAssembler_aarch64.cpp: Unrelated context change, minor > differences in code which gets removed by this change. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8255479 > > Original change: > https://github.com/openjdk/jdk/commit/695117f8 > > 11u backport: > http://cr.openjdk.java.net/~mdoerr/8255479_aarch64_11u/webrev.00/ > > Please review. > > Best regards, > Martin > From neliasso at openjdk.java.net Mon Jan 11 23:00:08 2021 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Mon, 11 Jan 2021 23:00:08 GMT Subject: [jdk16] RFR: 8258272: LoadVectorMaskedNode can't be replaced by zero con Message-ID: <1uFiDtbFRK-a5WyMKqNVh0Tx1ospvidf6O0ExS3bRbs=.d8fa7cdf-e712-48a1-902d-77d3b35ae801@github.com> A test fails for this code: byte [] src = new byte[0]; byte [] dest = Arrays::copy_of(src); This is transformed to something like: byte [] src = new byte[0]; byte [] dest = new byte[0]; System.arraycopy(src, 0, dest, 0, src.lenght()); This causes a problem in LoadNode::Value for the new LoadVectorMasked nodes. LoadNode::Value sees that the load will always load a zero - and will try to replace itself with a zero constant. That doesn't work for the LoadVectorMaskedNodes currently. This patch adds a check to the zero-optimization to pass on vector types. This patch is currently missing a new test. Since we are nearing the end of bugfixing in JDK16 I decided to publish the fix first so that any discussion of the fix can be had now. ------------- Commit messages: - LoadVectorMasked have no zero con Changes: https://git.openjdk.java.net/jdk16/pull/105/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=105&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258272 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk16/pull/105.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/105/head:pull/105 PR: https://git.openjdk.java.net/jdk16/pull/105 From whuang at openjdk.java.net Tue Jan 12 01:17:56 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 12 Jan 2021 01:17:56 GMT Subject: RFR: 8259044: JVM lacks data type qualifier when using -XX:+PrintAssembly with AArch64-Neon backend In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 10:41:41 GMT, Andrew Haley wrote: >> For instace: in the implentation of VectorMaskCmp & VectorStoreMask : >> >> $jtreg -vmoptions:"-XX:+PrintAssembly" ./Int128VectorTests.java >> >> Before fixing: >> ----------------- >> 0dc ldrq V17,[R10, #16] # vector (128 bits) >> 0e0 cmeq V16, V16, V17 # vector cmp (4I) >> 0e4 xtn V16, V16 # 4S to 4H >> xtn V16, V16 # 4H to 4B >> negr V16, V16 # store mask (4S to 4B) >> ----------------- >> Here? the output lacks data type qualifiers like T4S in `cmeq V16, V16, V17`. >> >> Expect: >> ----------------- >> 0dc ldrq V16,[R10, #16] # vector (128 bits) >> 0e0 cmeq V16, T4S, V16, V18 # vector cmp (4I) >> 0e4 xtn V16, T4H, V16, T4S # 4S to 4H >> xtn V16, T8B, V16, T8H # 4H to 4B >> negr V16, T8B, V16 # store mask (4S to 4B) >> ----------------- > > Marked as reviewed by aph (Reviewer). / > Looks good to me. Thank you for your review. ------------- PR: https://git.openjdk.java.net/jdk/pull/1941 From njian at openjdk.java.net Tue Jan 12 01:35:06 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 12 Jan 2021 01:35:06 GMT Subject: [jdk16] Integrated: 8258384: AArch64: SVE verify_ptrue fails on some tests In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 07:11:11 GMT, Ningsheng Jian wrote: > After applying [1], some Vector API tests fail with SIGILL on SVE > system. The SIGILL was triggered by verify_ptrue before c2 compiled > function returns, which means that the preserved p7 register (as ptrue) > has been clobbered before returning to c2 compiled code. (p7 is not > preserved cross function calls, and system calls [2]). > > Currently we try to reinitialize ptrue at each entrypoint of returning > from non-c2 compiled code, which indicating possible C or system calls. > However, there's still one entrypoint missing, exception handling, as > we may jump to c2 compiled code for exception handler. See > OptoRuntime::generate_exception_blob(). > > Adding reinitialize_ptrue before jumping back to c2 compiled code in > generate_exception_blob() could solve those Vector API test failures. > Actually I had that in my initial test patch [3], I don't know why I > missed that in final patch... I reran tests with the same approach of > [3] and found that there's still something missing, the > nmethod_entry_barrier() in c2 function prolog. The barrier may call to > runtime code (see generate_method_entry_barrier()). To reduce the risk > of missing such reinitialize_ptrue in newly added code in future, I > think it would be better to do the reinitialize in > pop_call_clobbered_registers(). > > P.S. the SIGILL message is also not clear, it should print detailed > message as indicated by MacroAssembler::stop() call. This is caused by > JDK-8255711 removing the message printing code. This will be fixed by JDK-8259539. > > Tested with tier1-3 on SVE hardware. Also verified with the same > approach of patch [3] with jtreg tests hotspot_all_no_apps and > jdk:tier1-3 passed without incorrect ptrue value assertion failure. > > [1] https://github.com/openjdk/jdk/pull/1621 > [2] https://github.com/torvalds/linux/blob/master/Documentation/arm64/sve.rst > [3] http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch This pull request has now been integrated. Changeset: a7e5da22 Author: Ningsheng Jian URL: https://git.openjdk.java.net/jdk16/commit/a7e5da22 Stats: 61 lines in 6 files changed: 18 ins; 16 del; 27 mod 8258384: AArch64: SVE verify_ptrue fails on some tests Reviewed-by: adinn, ngasson ------------- PR: https://git.openjdk.java.net/jdk16/pull/50 From njian at openjdk.java.net Tue Jan 12 01:35:05 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 12 Jan 2021 01:35:05 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests [v3] In-Reply-To: <2vNAJAihgpB4q_wqeuf2Dtjbu9X-NpqfXtNMibnOOUc=.f52ed07a-702f-4d8b-9200-46986181e6a1@github.com> References: <2vNAJAihgpB4q_wqeuf2Dtjbu9X-NpqfXtNMibnOOUc=.f52ed07a-702f-4d8b-9200-46986181e6a1@github.com> Message-ID: On Mon, 11 Jan 2021 09:31:51 GMT, Andrew Dinn wrote: >> Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert signal handler changes, which will be fixed in JDK-8259539. > > This looks fine now. Thank you @adinn @nick-arm for the review! ------------- PR: https://git.openjdk.java.net/jdk16/pull/50 From whuang at openjdk.java.net Tue Jan 12 01:43:00 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 12 Jan 2021 01:43:00 GMT Subject: Integrated: 8259044: JVM lacks data type qualifier when using -XX:+PrintAssembly with AArch64-Neon backend In-Reply-To: References: Message-ID: <42uekWro2JiKp6Ug5bnG_1rXYvnbeJIdiUxtk6KF5j4=.9583bf05-0a9c-4b97-93bd-99557615568f@github.com> On Tue, 5 Jan 2021 03:32:44 GMT, Wang Huang wrote: > For instace: in the implentation of VectorMaskCmp & VectorStoreMask : > > $jtreg -vmoptions:"-XX:+PrintAssembly" ./Int128VectorTests.java > > Before fixing: > ----------------- > 0dc ldrq V17,[R10, #16] # vector (128 bits) > 0e0 cmeq V16, V16, V17 # vector cmp (4I) > 0e4 xtn V16, V16 # 4S to 4H > xtn V16, V16 # 4H to 4B > negr V16, V16 # store mask (4S to 4B) > ----------------- > Here? the output lacks data type qualifiers like T4S in `cmeq V16, V16, V17`. > > Expect: > ----------------- > 0dc ldrq V16,[R10, #16] # vector (128 bits) > 0e0 cmeq V16, T4S, V16, V18 # vector cmp (4I) > 0e4 xtn V16, T4H, V16, T4S # 4S to 4H > xtn V16, T8B, V16, T8H # 4H to 4B > negr V16, T8B, V16 # store mask (4S to 4B) > ----------------- This pull request has now been integrated. Changeset: ae0532ed Author: Wang Huang Committer: Fei Yang URL: https://git.openjdk.java.net/jdk/commit/ae0532ed Stats: 197 lines in 2 files changed: 0 ins; 0 del; 197 mod 8259044: JVM lacks data type qualifier when using -XX:+PrintAssembly with AArch64-Neon backend Co-authored-by: He Xuejin Reviewed-by: njian, aph ------------- PR: https://git.openjdk.java.net/jdk/pull/1941 From xgong at openjdk.java.net Tue Jan 12 01:44:56 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Tue, 12 Jan 2021 01:44:56 GMT Subject: [jdk16] RFR: 8259353: VectorReinterpretNode is incorrectly optimized out In-Reply-To: <8bPOqQ22N2FDGHuRqcJ7aOsezcNYT7c4FhTD_X7RbhU=.a5112299-bdac-41fc-ad4d-9cbb19a75ee8@github.com> References: <8bPOqQ22N2FDGHuRqcJ7aOsezcNYT7c4FhTD_X7RbhU=.a5112299-bdac-41fc-ad4d-9cbb19a75ee8@github.com> Message-ID: On Mon, 11 Jan 2021 12:56:17 GMT, Vladimir Ivanov wrote: >> Vector reinterpretation just reinterprets the bytes of the vector without performing any value conversions. So normally, optimization like: >> (VectorReinterpret (VectorReinterpret src)) -> src >> can be applied correctly if the logical result and the input `"src"` have the same vector type. However, the results might not be correct if truncation happens after the first reinterpretation: `"(VectorReinterpret src)"`. >> >> Consider the following case: >> byte[] a = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15} >> byte[] b = new byte[16] >> byte[] c = new byte[16] >> >> // load vector from "a" with 128-bits >> ByteVector av = ByteVector.fromArray(SPECIES_128, a, 0); >> >> // reinterpret to 64-bits >> ByteVector bv = (ByteVector)av.reinterpretShape(SPECIES_64, 0); >> >> // reinterpret back to 128-bits with the above reinterpreting results >> ByteVector cv = (ByteVector)bv.reinterpretShape(SPECIES_128, 0); >> cv.intoArray(c, 0) >> This case: >> 1. Reinterprets vector `"av"` from 128-bits to 64-bits. It should only copy the first 8 elements to vector `"bv"` and discard the higher half parts. >> 2. Reinterprets vector `"bv"` back to 128-bits. It copies the 64-bits from` "bv"` to` "cv"`, and paddings the rest part of `"cv"` with zero. >> The final values in array `"c"` are expected to be: >> c = [ 0, 1, 2, 3, 4, 5, 6, 7, 0, 0, 0, 0, 0, 0, 0, 0] >> However, with the optimization mentioned at the beginning, the second reinterpretation is optimized out. The values in array` "c" `are incorrectly copied from array `"a"`. The values are: >> c = [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] >> To fix it, this patch adds the vector size constraint for the optimization, that is the first reinterpretation must not be conducted to a shorter vector. >> >> It also fixes a potential issue for the implementation of match rule `"reinterpretX2D (from 16 bytes to 8 bytes)" `on Arm NEON. Specifically, the `"mov"` is always needed even if the` "dst"` and `"src"` are the same register since truncation should be conducted in order to be consistent with the semantics. > > Marked as reviewed by vlivanov (Reviewer). > Good catch! The fix in shared code looks good. > > I suggest to split up the patch and review AArch64-specific changes separately. Hi @iwanowww , thanks for the review! I will split the patch later then. Thanks! ------------- PR: https://git.openjdk.java.net/jdk16/pull/100 From xgong at openjdk.java.net Tue Jan 12 02:52:13 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Tue, 12 Jan 2021 02:52:13 GMT Subject: [jdk16] RFR: 8259353: VectorReinterpretNode is incorrectly optimized out [v2] In-Reply-To: References: Message-ID: > Vector reinterpretation just reinterprets the bytes of the vector without performing any value conversions. So normally, optimization like: > (VectorReinterpret (VectorReinterpret src)) -> src > can be applied correctly if the logical result and the input `"src"` have the same vector type. However, the results might not be correct if truncation happens after the first reinterpretation: `"(VectorReinterpret src)"`. > > Consider the following case: > byte[] a = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15} > byte[] b = new byte[16] > byte[] c = new byte[16] > > // load vector from "a" with 128-bits > ByteVector av = ByteVector.fromArray(SPECIES_128, a, 0); > > // reinterpret to 64-bits > ByteVector bv = (ByteVector)av.reinterpretShape(SPECIES_64, 0); > > // reinterpret back to 128-bits with the above reinterpreting results > ByteVector cv = (ByteVector)bv.reinterpretShape(SPECIES_128, 0); > cv.intoArray(c, 0) > This case: > 1. Reinterprets vector `"av"` from 128-bits to 64-bits. It should only copy the first 8 elements to vector `"bv"` and discard the higher half parts. > 2. Reinterprets vector `"bv"` back to 128-bits. It copies the 64-bits from` "bv"` to` "cv"`, and paddings the rest part of `"cv"` with zero. > The final values in array `"c"` are expected to be: > c = [ 0, 1, 2, 3, 4, 5, 6, 7, 0, 0, 0, 0, 0, 0, 0, 0] > However, with the optimization mentioned at the beginning, the second reinterpretation is optimized out. The values in array` "c" `are incorrectly copied from array `"a"`. The values are: > c = [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] > To fix it, this patch adds the vector size constraint for the optimization, that is the first reinterpretation must not be conducted to a shorter vector. > > It also fixes a potential issue for the implementation of match rule `"reinterpretX2D (from 16 bytes to 8 bytes)" `on Arm NEON. Specifically, the `"mov"` is always needed even if the` "dst"` and `"src"` are the same register since truncation should be conducted in order to be consistent with the semantics. Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: Revert Arm NEON match rule fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/100/files - new: https://git.openjdk.java.net/jdk16/pull/100/files/47a4978f..6857bdd1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=100&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=100&range=00-01 Stats: 39 lines in 2 files changed: 1 ins; 15 del; 23 mod Patch: https://git.openjdk.java.net/jdk16/pull/100.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/100/head:pull/100 PR: https://git.openjdk.java.net/jdk16/pull/100 From xgong at openjdk.java.net Tue Jan 12 02:52:14 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Tue, 12 Jan 2021 02:52:14 GMT Subject: [jdk16] RFR: 8259353: VectorReinterpretNode is incorrectly optimized out [v2] In-Reply-To: <8bPOqQ22N2FDGHuRqcJ7aOsezcNYT7c4FhTD_X7RbhU=.a5112299-bdac-41fc-ad4d-9cbb19a75ee8@github.com> References: <8bPOqQ22N2FDGHuRqcJ7aOsezcNYT7c4FhTD_X7RbhU=.a5112299-bdac-41fc-ad4d-9cbb19a75ee8@github.com> Message-ID: On Mon, 11 Jan 2021 12:56:17 GMT, Vladimir Ivanov wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert Arm NEON match rule fixes > > Marked as reviewed by vlivanov (Reviewer). Hi @iwanowww , the AArch64 specific changes have been reverted. I will create another PR for it. Could you please have a look again? Thanks! ------------- PR: https://git.openjdk.java.net/jdk16/pull/100 From xgong at openjdk.java.net Tue Jan 12 04:08:07 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Tue, 12 Jan 2021 04:08:07 GMT Subject: [jdk16] RFR: 8259601: AArch64: Fix reinterpretX2D match rule issue Message-ID: Currently the `"reinterpretX2D"` match rule does not generate any register move instruction if the` 'dst'` and` 'src'` are the same register. This rule implements the vector reinterpretation from 16 bytes to 8 bytes. It is a kind of data truncation, which should make sure the higher 8 bytes of the `'dst' `register cleared to zero. So the `"mov" `is always needed even if the` "dst"` and `"src"` are the same register in case of the issue mentioned in [1]. We have tested the case [3] with Arm NEON. And the issue still exists even if [1] is fixed with [2]. Removing the check (i.e. whether `'src'` and `'dst`' are the same register) in the rule would fix it finally. [1] https://bugs.openjdk.java.net/browse/JDK-8259353 [2] https://github.com/openjdk/jdk16/pull/100 [3] https://bugs.openjdk.java.net/secure/attachment/92713/Test.java ------------- Commit messages: - 8259601: AArch64: Fix reinterpretX2D match rule issue Changes: https://git.openjdk.java.net/jdk16/pull/108/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=108&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259601 Stats: 41 lines in 2 files changed: 17 ins; 1 del; 23 mod Patch: https://git.openjdk.java.net/jdk16/pull/108.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/108/head:pull/108 PR: https://git.openjdk.java.net/jdk16/pull/108 From iveresov at openjdk.java.net Tue Jan 12 05:04:11 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Tue, 12 Jan 2021 05:04:11 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. > > Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: Check legacy flags validity before deriving flag values for emulation mode. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1985/files - new: https://git.openjdk.java.net/jdk/pull/1985/files/dfffc35b..82dffbe9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=02-03 Stats: 49 lines in 2 files changed: 37 ins; 8 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1985/head:pull/1985 PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Tue Jan 12 05:07:01 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Tue, 12 Jan 2021 05:07:01 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: <_kzqYF9JIc1ten32g062993eEyhRKHBGOoKoeemvQ9w=.c98f3d6c-cea1-4a8b-b64e-b4e7108d643d@github.com> On Mon, 11 Jan 2021 17:54:10 GMT, Igor Veresov wrote: >> I see some regression on ARM32 with this change: >> http://cr.openjdk.java.net/~bulasevich/tmp/8251462_jtreg_hotspot/ > >> I see some regression on ARM32 with this change: >> http://cr.openjdk.java.net/~bulasevich/tmp/8251462_jtreg_hotspot/ > > I don't think those are related to the changes. Those are probably some preexisting c1 and c2 problems respectively that for some reason weren't triggered before. > > The TestOptionsWithRanges is my fault though. I'll fix that. I've added the flag validity pre-checks, which should solve the issues with VM complaining about tiered flags being invalid as a result of CompileThreshold and friends being invalid. We'd have to solve the C1 SIGILL and the C2 loop opts crash separately. Those are not really related to the change. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From thartmann at openjdk.java.net Tue Jan 12 06:50:57 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 12 Jan 2021 06:50:57 GMT Subject: RFR: 8259583: Remove unused decode_env::_codeBuffer In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 19:11:51 GMT, Aleksey Shipilev wrote: > SonarCloud instance reports that decode_env::_codeBuffer field is not initialized in constructor. But really, the field is never used after [JDK-8222079](https://bugs.openjdk.java.net/browse/JDK-8222079). > > Additional testing: > - [x] No grep hits for `_codeBuffer` in `src/` Looks good and trivial. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2034 From thartmann at openjdk.java.net Tue Jan 12 06:53:55 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 12 Jan 2021 06:53:55 GMT Subject: RFR: 8259576: Misplaced curly brace in Matcher::find_shared_post_visit In-Reply-To: References: Message-ID: <8UxknD9oi3NVCAmeOhycbesamyNPsDXPor2dNAhvZfk=.0eef5702-d7ca-41c6-aae7-366d6a0a5fb6@github.com> On Mon, 11 Jan 2021 18:37:40 GMT, Aleksey Shipilev wrote: > SonarCloud demo instance reports the issue here: > > case Op_VectorMaskCmp: { > n->set_req(1, new BinaryNode(n->in(1), n->in(2))); > n->set_req(2, n->in(3)); > n->del_req(3); > break; > default: // <----- ERROR > break; > } > > "The direct parent of this switch-label is not the body of a switch statement." > > This is added by JDK-8223347, and it is an obviously misplaced curly-brace. It is innocuous in current code, but may become problematic as more cases are added to the switch. Looks good. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2031 From shade at openjdk.java.net Tue Jan 12 08:01:56 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 12 Jan 2021 08:01:56 GMT Subject: Integrated: 8259583: Remove unused decode_env::_codeBuffer In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 19:11:51 GMT, Aleksey Shipilev wrote: > SonarCloud instance reports that decode_env::_codeBuffer field is not initialized in constructor. But really, the field is never used after [JDK-8222079](https://bugs.openjdk.java.net/browse/JDK-8222079). > > Additional testing: > - [x] No grep hits for `_codeBuffer` in `src/` This pull request has now been integrated. Changeset: 46637047 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/46637047 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8259583: Remove unused decode_env::_codeBuffer Reviewed-by: thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/2034 From chagedorn at openjdk.java.net Tue Jan 12 08:20:02 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 12 Jan 2021 08:20:02 GMT Subject: [jdk16] RFR: 8258272: LoadVectorMaskedNode can't be replaced by zero con In-Reply-To: <1uFiDtbFRK-a5WyMKqNVh0Tx1ospvidf6O0ExS3bRbs=.d8fa7cdf-e712-48a1-902d-77d3b35ae801@github.com> References: <1uFiDtbFRK-a5WyMKqNVh0Tx1ospvidf6O0ExS3bRbs=.d8fa7cdf-e712-48a1-902d-77d3b35ae801@github.com> Message-ID: On Mon, 11 Jan 2021 22:51:48 GMT, Nils Eliasson wrote: > A test fails for this code: > > byte [] src = new byte[0]; > byte [] dest = Arrays::copy_of(src); > > This is transformed to something like: > byte [] src = new byte[0]; > byte [] dest = new byte[0]; > System.arraycopy(src, 0, dest, 0, src.lenght()); > > This causes a problem in LoadNode::Value for the new LoadVectorMasked nodes. LoadNode::Value sees that the load will always load a zero - and will try to replace itself with a zero constant. That doesn't work for the LoadVectorMaskedNodes currently. > > This patch adds a check to the zero-optimization to pass on vector types. > > This patch is currently missing a new test. Since we are nearing the end of bugfixing in JDK16 I decided to publish the fix first so that any discussion of the fix can be had now. That looks good to me! ------------- Marked as reviewed by chagedorn (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/105 From chagedorn at openjdk.java.net Tue Jan 12 08:22:07 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 12 Jan 2021 08:22:07 GMT Subject: Integrated: 8258243: C2: assert failed ("Bad derived pointer") with -XX:+VerifyRegisterAllocator In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 14:05:32 GMT, Christian Hagedorn wrote: > The base pointer verification code in the register allocator checks that a base for a derived constant node is always `NULL`. However, this is not the case if the offset is zero (returns on L1744): > https://github.com/openjdk/jdk/blob/b549cbd39250c5b22c6e863172d18cf247022894/src/hotspot/share/opto/chaitin.cpp#L1740-L1754 > > This case is added to the verification code which fixes the reported failing testcases. > > I additionally added a hello world test to sanity check the `-XX:+VerifyRegisterAllocator` flag. > > Thanks, > Christian This pull request has now been integrated. Changeset: a3561ae8 Author: Christian Hagedorn URL: https://git.openjdk.java.net/jdk/commit/a3561ae8 Stats: 43 lines in 2 files changed: 40 ins; 0 del; 3 mod 8258243: C2: assert failed ("Bad derived pointer") with -XX:+VerifyRegisterAllocator Reviewed-by: kvn, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/2005 From rcastanedalo at openjdk.java.net Tue Jan 12 08:29:58 2021 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Tue, 12 Jan 2021 08:29:58 GMT Subject: [jdk16] RFR: 8259061: C2: assert(found) failed: memory-writing node is not placed in its original loop or an ancestor of it In-Reply-To: References: Message-ID: <7e9h0MpQ9eGQ_ji1ki8u3RdO-m6RIn_dR3c4mLOaKvI=.925ca765-48d3-43fa-bbee-7005eb55657d@github.com> On Mon, 11 Jan 2021 18:11:07 GMT, Vladimir Kozlov wrote: > Agree. Thanks, Vladimir! ------------- PR: https://git.openjdk.java.net/jdk16/pull/101 From rwestrel at redhat.com Tue Jan 12 08:40:10 2021 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 12 Jan 2021 09:40:10 +0100 Subject: [11u] RFR 8257561 Some code is not vectorized after 8251925 and 8250607 Message-ID: <87sg76a6qd.fsf@redhat.com> Hi, Original bug: https://bugs.openjdk.java.net/browse/JDK-8257561 https://github.com/openjdk/jdk/commit/6c9482ee Original patch does not apply cleanly to 11u, because the change to src/hotspot/share/opto/cfgnode.cpp is specific to jdk 16. Change is otherwise identical to upstream change. 11u webrev: https://cr.openjdk.java.net/~roland/8257561.11u/webrev.00/ Testing: x86_64 build, tier1, manually verified with superword tests that vectorization happens now Roland. From adinn at openjdk.java.net Tue Jan 12 10:04:04 2021 From: adinn at openjdk.java.net (Andrew Dinn) Date: Tue, 12 Jan 2021 10:04:04 GMT Subject: [jdk16] RFR: 8259601: AArch64: Fix reinterpretX2D match rule issue In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 04:02:00 GMT, Xiaohong Gong wrote: > Currently the `"reinterpretX2D"` match rule does not generate any register move instruction if the` 'dst'` and` 'src'` are the same register. This rule implements the vector reinterpretation from 16 bytes to 8 bytes. It is a kind of data truncation, which should make sure the higher 8 bytes of the `'dst' `register cleared to zero. So the `"mov" `is always needed even if the` "dst"` and `"src"` are the same register in case of the issue mentioned in [1]. > > We have tested the case [3] with Arm NEON. And the issue still exists even if [1] is fixed with [2]. Removing the check (i.e. whether `'src'` and `'dst`' are the same register) in the rule would fix it finally. > > [1] https://bugs.openjdk.java.net/browse/JDK-8259353 > [2] https://github.com/openjdk/jdk16/pull/100 > [3] https://bugs.openjdk.java.net/secure/attachment/92713/Test.java Yes, these changes look good. ------------- Marked as reviewed by adinn (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/108 From pliden at openjdk.java.net Tue Jan 12 10:06:02 2021 From: pliden at openjdk.java.net (Per Liden) Date: Tue, 12 Jan 2021 10:06:02 GMT Subject: [jdk16] RFR: 8259063: Possible deadlock with vtable/itable creation vs concurrent class unloading In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 16:11:34 GMT, Erik ?sterlund wrote: > There is an offender of consistent lock ordering: the creation of itable/vtable stubs. It happens when an inline cache is transitioning to megamorphic. Way earlier in the call stack, we grab the nmethod lock for IC patching, and then when a megamorphic transition happens *and* there is no stub created yet for the given vtable/itable index (rather uncommon), a new vtable/itable stub is created. This creation of a stub takes the CodeCache lock. We already deal with failure to create the stubs today, by making the inline cache "clean" instead, essentially deferring the transition to megamorphic to a subsequent call. We deal with that today to handle the code cache running out of memory, making it temporarily impossible to transition to megamorphic until memory has been freed up. My patch rides on that logic, so that we can try_lock() the CodeCache_lock instead. If we fail to take the lock, then it is arguably a bad time to do this megamorphic transition, regardless of deadlocks, as we might have to wait quite a while. So if we fail to take the lock, I just return NULL saying we couldn't create a vtable/itable stub at this time, signalling we defer the transition to later, as we would also do if we couldn't create the stub due to memory exhaustion. This solves the deadlock situation. > > Eric Caspole who reported the bug has tried this patch, and it solved the problem. I also tried it with the same test myself, with the same successful results. I also ran it through tier1-5 as it is touching inline cache code which can be a bit subtle. Looks good to me! ------------- Marked as reviewed by pliden (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/103 From aph at openjdk.java.net Tue Jan 12 10:28:57 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 12 Jan 2021 10:28:57 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 12:28:57 GMT, Dong Bo wrote: >> The `Math.abs(doublesA[i] - doublesB[i])` has `~36%` improvements. >> I updated the tests for doubles with `Math.abs()`, it looks more consistent. Thanks. >> The JMH results of doubles with `Math.abs()`: >> Benchmark (COUNT_DOUBLE) (COUNT_FLOAT) (seed) Mode Cnt Score Error Units >> # Kunpeng 916, default >> VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 681.319 ? 0.658 ns/op >> VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 682.596 ? 4.322 ns/op >> # Kunpeng 916, fmaxp/fminp >> VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 439.130 ? 0.450 ns/op => 35.54% >> VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 439.105 ? 0.435 ns/op => 35.67% > > For single-precision floating-point operands, as the experiments showed, we can have `Max2F` match only with `COUNT == 3`. > With such a small loop under superword framework, it is diffcult to tell how much improvements of `fmaxp/fminp` over `fmaxv+ins`. > > Although it sounds unreasonable for an application to use `Float64Vector` rather than `Float128Vecotor`, > the optimization does being useful for VectorAPI `Float64Vector.reduceLanes(VectorOperators.MAX)` as mentioned previously. > > Do you think we should remove single-precision floating-point parts in this patch? OK, I guess we'll keep both. Even though the acceleration for single-precision float is disappointing on these cores, it might well be useful for some future processor, and I do care about the Vector API. ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From aph at openjdk.java.net Tue Jan 12 10:28:56 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 12 Jan 2021 10:28:56 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v6] In-Reply-To: <4nnhdRP9gsILzFv5MvE_1usJtLBwmtoThIErfRgcftw=.277fc10e-1bc2-4a99-97e6-ca1562b625c3@github.com> References: <4nnhdRP9gsILzFv5MvE_1usJtLBwmtoThIErfRgcftw=.277fc10e-1bc2-4a99-97e6-ca1562b625c3@github.com> Message-ID: On Mon, 11 Jan 2021 11:41:13 GMT, Dong Bo wrote: >> This patch optimizes vectorial Min/Max reduction of two floating-point numbers on aarch64 with NEON instructions `fmaxp` and `fminp`. >> >> Passed jtreg tier1-3 tests with `linux-aarch64-server-fastdebug` build. >> Tests under `test/jdk/jdk/incubator/vector/` runned specially for the correctness and passed. >> >> Introduced a new JMH micro `test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java` for performance test. >> Witnessed abount `37%` performance improvements on Kunpeng916. The JMH Results: >> Benchmark (COUNT) (seed) Mode Cnt Score Error Units >> # Kunpeng 916, default >> VectorReduction.maxRedD 512 0 avgt 10 678.126 ? 0.815 ns/op >> VectorReduction.maxRedF 512 0 avgt 10 242.958 ? 0.212 ns/op >> VectorReduction.minRedD 512 0 avgt 10 678.554 ? 0.824 ns/op >> VectorReduction.minRedF 512 0 avgt 10 243.368 ? 0.205 ns/op >> >> # Kunpeng 916, with fmaxp/fminp >> VectorReduction.maxRedD 512 0 avgt 10 430.201 ? 0.353 ns/op => 36.56% >> VectorReduction.maxRedF 512 0 avgt 10 243.404 ? 0.297 ns/op >> VectorReduction.minRedD 512 0 avgt 10 427.805 ? 0.528 ns/op => 36.89% >> VectorReduction.minRedF 512 0 avgt 10 242.963 ? 0.210 ns/op > > Dong Bo has updated the pull request incrementally with one additional commit since the last revision: > > test improvements for doubles with Math.abs() Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From shade at openjdk.java.net Tue Jan 12 10:55:00 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 12 Jan 2021 10:55:00 GMT Subject: RFR: 8259576: Misplaced curly brace in Matcher::find_shared_post_visit In-Reply-To: <8UxknD9oi3NVCAmeOhycbesamyNPsDXPor2dNAhvZfk=.0eef5702-d7ca-41c6-aae7-366d6a0a5fb6@github.com> References: <8UxknD9oi3NVCAmeOhycbesamyNPsDXPor2dNAhvZfk=.0eef5702-d7ca-41c6-aae7-366d6a0a5fb6@github.com> Message-ID: On Tue, 12 Jan 2021 06:50:59 GMT, Tobias Hartmann wrote: >> SonarCloud demo instance reports the issue here: >> >> case Op_VectorMaskCmp: { >> n->set_req(1, new BinaryNode(n->in(1), n->in(2))); >> n->set_req(2, n->in(3)); >> n->del_req(3); >> break; >> default: // <----- ERROR >> break; >> } >> >> "The direct parent of this switch-label is not the body of a switch statement." >> >> This is added by JDK-8223347, and it is an obviously misplaced curly-brace. It is innocuous in current code, but may become problematic as more cases are added to the switch. > > Looks good. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/2031 From shade at openjdk.java.net Tue Jan 12 10:55:01 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 12 Jan 2021 10:55:01 GMT Subject: Integrated: 8259576: Misplaced curly brace in Matcher::find_shared_post_visit In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 18:37:40 GMT, Aleksey Shipilev wrote: > SonarCloud demo instance reports the issue here: > > case Op_VectorMaskCmp: { > n->set_req(1, new BinaryNode(n->in(1), n->in(2))); > n->set_req(2, n->in(3)); > n->del_req(3); > break; > default: // <----- ERROR > break; > } > > "The direct parent of this switch-label is not the body of a switch statement." > > This is added by JDK-8223347, and it is an obviously misplaced curly-brace. It is innocuous in current code, but may become problematic as more cases are added to the switch. This pull request has now been integrated. Changeset: 4697cfa4 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/4697cfa4 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod 8259576: Misplaced curly brace in Matcher::find_shared_post_visit Reviewed-by: lucy, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/2031 From shade at openjdk.java.net Tue Jan 12 11:03:53 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 12 Jan 2021 11:03:53 GMT Subject: RFR: 8257709: C1: Double assignment in InstructionPrinter::print_stack [v2] In-Reply-To: References: <0QnuBA5eYke6BCBi1gIfhM-tNzY6rVmx0zUY0Fyyot0=.c7cd63e1-be06-43c4-b109-8a3eabe80522@github.com> Message-ID: <2FHmvwWpa9Jc0P0X1YLE5h7LMDqeMVQ5Yrd-zhzkfMQ=.819e8c7a-9add-4939-8266-f48a5d12cbe1@github.com> On Mon, 11 Jan 2021 14:28:17 GMT, Sergey Platonov wrote: >>> > ...ah, and maybe merge from `master` to get all the recent fixes. Current tests might fail on known issues. Not that it is necessary for a simple issue like this, but it helps to learn the contribution ropes in this project. >>> >>> Done! Will commits be squashed? >> >> Yes, bots would squash the commits during integration. You don't need to rebase or do anything else Git-wise. Once testing is clean, you can say `/integrate`, as bots suggested. > >> > > ...ah, and maybe merge from `master` to get all the recent fixes. Current tests might fail on known issues. Not that it is necessary for a simple issue like this, but it helps to learn the contribution ropes in this project. >> > >> > >> > Done! Will commits be squashed? >> >> Yes, bots would squash the commits during integration. You don't need to rebase or do anything else Git-wise. Once testing is clean, you can say `/integrate`, as bots suggested. > > Great! Thank you for your help, Aleksey! If you go an look at "Checks" tab, you will see it says that everything is green. You can say `/integrate` now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1519 From vlivanov at openjdk.java.net Tue Jan 12 11:40:01 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 12 Jan 2021 11:40:01 GMT Subject: [jdk16] RFR: 8258272: LoadVectorMaskedNode can't be replaced by zero con In-Reply-To: <1uFiDtbFRK-a5WyMKqNVh0Tx1ospvidf6O0ExS3bRbs=.d8fa7cdf-e712-48a1-902d-77d3b35ae801@github.com> References: <1uFiDtbFRK-a5WyMKqNVh0Tx1ospvidf6O0ExS3bRbs=.d8fa7cdf-e712-48a1-902d-77d3b35ae801@github.com> Message-ID: On Mon, 11 Jan 2021 22:51:48 GMT, Nils Eliasson wrote: > A test fails for this code: > > byte [] src = new byte[0]; > byte [] dest = Arrays::copy_of(src); > > This is transformed to something like: > byte [] src = new byte[0]; > byte [] dest = new byte[0]; > System.arraycopy(src, 0, dest, 0, src.lenght()); > > This causes a problem in LoadNode::Value for the new LoadVectorMasked nodes. LoadNode::Value sees that the load will always load a zero - and will try to replace itself with a zero constant. That doesn't work for the LoadVectorMaskedNodes currently. > > This patch adds a check to the zero-optimization to pass on vector types. > > This patch is currently missing a new test. Since we are nearing the end of bugfixing in JDK16 I decided to publish the fix first so that any discussion of the fix can be had now. Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/105 From roland at openjdk.java.net Tue Jan 12 11:50:10 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Tue, 12 Jan 2021 11:50:10 GMT Subject: RFR: 8259609: C2: optimize long range checks in long counted loops Message-ID: JDK-8255150 makes it possible for java code to explicitly perform a range check on long values. JDK-8223051 provides a transformation of long counted loops into loop nests with an inner int counted loop. With this change I propose transforming long range checks that operate on the iv of a long counted loop into range checks that operate on the iv of the int inner loop once it has been created. Existing range check eliminations can then kick in. Transformation of range checks is piggy backed on the loop nest creation for 2 reasons: - pattern matching range checks is easier right before the loop nest is created - the number of iterations of the inner loop is adjusted so scale * inner_iv doesn't overflow C2 has logic to delay some split if transformations so they don't break the scale * iv + offset pattern. I reused that logic for long range checks and had to relax what's considered a range check because initially a range check from Object.checkIndex() may include a test for range > 0 that needs a round of loop opts to be hoisted. I realize there's some code duplication but I didn't see a way to share logic between IdealLoopTree::may_have_range_check() IdealLoopTree::policy_range_check() that would feel right. I realize the comment in PhaseIdealLoop::transform_long_range_checks() is scary. FWIW, it's not as complicated as it looks. I found drawing the range covered by the entire long loop and the range covered by the inner loop help see how range checks can be transformed. Then the comment helps make sure all cases are covered and verify the generated code actually covers all of them. One issue is overflow. I think the fact that inner_iv * scale doesn't overflow helps simplify thing. One possible overflow is that of scale * upper + offset which is handled by forcing all range checks in that case to deoptimize. I don't think other case of overflow needs special handling. This was tested with a Memory Segment micro benchmark (and patched Memory Segment support to take advantage of the new checkIndex intrinsic, both provided by Maurizio). Range checks in the micro benchmark are properly optimized (and performance increases significantly). ------------- Commit messages: - whitespaces - build fix + test cleanup - range checks Changes: https://git.openjdk.java.net/jdk/pull/2045/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2045&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259609 Stats: 770 lines in 10 files changed: 647 ins; 54 del; 69 mod Patch: https://git.openjdk.java.net/jdk/pull/2045.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2045/head:pull/2045 PR: https://git.openjdk.java.net/jdk/pull/2045 From github.com+6061213+sergey-platonov at openjdk.java.net Tue Jan 12 12:00:58 2021 From: github.com+6061213+sergey-platonov at openjdk.java.net (Sergey Platonov) Date: Tue, 12 Jan 2021 12:00:58 GMT Subject: Integrated: 8257709: C1: Double assignment in InstructionPrinter::print_stack In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 14:26:23 GMT, Sergey Platonov wrote: > There is currently a minor bug (just a typo, actually) in the hotspot, leading > to undefined behavior. This pull request has now been integrated. Changeset: 563b268c Author: Sergey Platonov Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/563b268c Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8257709: C1: Double assignment in InstructionPrinter::print_stack Reviewed-by: shade, chagedorn ------------- PR: https://git.openjdk.java.net/jdk/pull/1519 From shade at openjdk.java.net Tue Jan 12 12:26:10 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 12 Jan 2021 12:26:10 GMT Subject: RFR: 8259619: C1, x86: 3-arg StubAssembler::call_RT stack-use condition is incorrect Message-ID: SonarCould instance reports this code smell in c1_Runtime_x86.cpp: Identical sub-expressions on both sides of operator "||" int StubAssembler::call_RT(Register oop_result1, Register metadata_result, address entry, Register arg1, Register arg2, Register arg3) { #ifdef _LP64 // if there is any conflict use the stack if (arg1 == c_rarg2 || arg1 == c_rarg3 || arg2 == c_rarg1 || arg1 == c_rarg3 || arg3 == c_rarg1 || arg1 == c_rarg2) { <---- HERE push(arg3); push(arg2); push(arg1); pop(c_rarg1); pop(c_rarg2); pop(c_rarg3); } else { mov(c_rarg1, arg1); mov(c_rarg2, arg2); mov(c_rarg3, arg3); } It seems obvious that the right column in the condition should have been `arg1`, `arg2`, `arg3`. Additional testing: - [x] Linux x86_64 `tier1` ------------- Commit messages: - 8259619: C1, x86: 3-arg StubAssembler::call_RT stack-use condition is incorrect Changes: https://git.openjdk.java.net/jdk/pull/2048/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2048&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259619 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2048.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2048/head:pull/2048 PR: https://git.openjdk.java.net/jdk/pull/2048 From chagedorn at openjdk.java.net Tue Jan 12 12:41:54 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 12 Jan 2021 12:41:54 GMT Subject: RFR: 8259619: C1, x86: 3-arg StubAssembler::call_RT stack-use condition is incorrect In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 12:21:15 GMT, Aleksey Shipilev wrote: > SonarCould instance reports this code smell in c1_Runtime_x86.cpp: Identical sub-expressions on both sides of operator "||" > > int StubAssembler::call_RT(Register oop_result1, Register metadata_result, address entry, Register arg1, Register arg2, Register arg3) { > #ifdef _LP64 > // if there is any conflict use the stack > if (arg1 == c_rarg2 || arg1 == c_rarg3 || > arg2 == c_rarg1 || arg1 == c_rarg3 || > arg3 == c_rarg1 || arg1 == c_rarg2) { <---- HERE > push(arg3); > push(arg2); > push(arg1); > pop(c_rarg1); > pop(c_rarg2); > pop(c_rarg3); > } else { > mov(c_rarg1, arg1); > mov(c_rarg2, arg2); > mov(c_rarg3, arg3); > } > > It seems obvious that the right column in the condition should have been `arg1`, `arg2`, `arg3`. > > Additional testing: > - [x] Linux x86_64 `tier1` Good catch! That looks reasonable to me. Can you also fix this in [c1_Runtime1_aarch64.cpp](https://github.com/openjdk/jdk/blob/563b268c8f23a1f9f5e70065419d4e8661d1d0b4/src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp#L144-L148)? ------------- Changes requested by chagedorn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2048 From shade at openjdk.java.net Tue Jan 12 12:47:11 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 12 Jan 2021 12:47:11 GMT Subject: RFR: 8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect [v2] In-Reply-To: References: Message-ID: <8Ixvi5AkRmzbkmxAYnrkU30Jla8JtykXbzkcvfz9aEw=.8982dca6-dbf2-4f14-b1e5-bbe99c534f32@github.com> > SonarCould instance reports this code smell in c1_Runtime_x86.cpp: Identical sub-expressions on both sides of operator "||" > > int StubAssembler::call_RT(Register oop_result1, Register metadata_result, address entry, Register arg1, Register arg2, Register arg3) { > #ifdef _LP64 > // if there is any conflict use the stack > if (arg1 == c_rarg2 || arg1 == c_rarg3 || > arg2 == c_rarg1 || arg1 == c_rarg3 || > arg3 == c_rarg1 || arg1 == c_rarg2) { <---- HERE > push(arg3); > push(arg2); > push(arg1); > pop(c_rarg1); > pop(c_rarg2); > pop(c_rarg3); > } else { > mov(c_rarg1, arg1); > mov(c_rarg2, arg2); > mov(c_rarg3, arg3); > } > > It seems obvious that the right column in the condition should have been `arg1`, `arg2`, `arg3`. > > Additional testing: > - [x] Linux x86_64 `tier1` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Also fix AArch64 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2048/files - new: https://git.openjdk.java.net/jdk/pull/2048/files/699a3e29..443eb85f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2048&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2048&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2048.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2048/head:pull/2048 PR: https://git.openjdk.java.net/jdk/pull/2048 From chagedorn at openjdk.java.net Tue Jan 12 12:47:12 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 12 Jan 2021 12:47:12 GMT Subject: RFR: 8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect [v2] In-Reply-To: <8Ixvi5AkRmzbkmxAYnrkU30Jla8JtykXbzkcvfz9aEw=.8982dca6-dbf2-4f14-b1e5-bbe99c534f32@github.com> References: <8Ixvi5AkRmzbkmxAYnrkU30Jla8JtykXbzkcvfz9aEw=.8982dca6-dbf2-4f14-b1e5-bbe99c534f32@github.com> Message-ID: <2BdbhbFCL_kSpU8nn4iIvgRpAZuG41cNKAe4g_2Dw6k=.9b61a6f5-e745-49f6-987a-e6acd5d2cfa9@github.com> On Tue, 12 Jan 2021 12:44:14 GMT, Aleksey Shipilev wrote: >> SonarCould instance reports this code smell in c1_Runtime_x86.cpp: Identical sub-expressions on both sides of operator "||" >> >> int StubAssembler::call_RT(Register oop_result1, Register metadata_result, address entry, Register arg1, Register arg2, Register arg3) { >> #ifdef _LP64 >> // if there is any conflict use the stack >> if (arg1 == c_rarg2 || arg1 == c_rarg3 || >> arg2 == c_rarg1 || arg1 == c_rarg3 || >> arg3 == c_rarg1 || arg1 == c_rarg2) { <---- HERE >> push(arg3); >> push(arg2); >> push(arg1); >> pop(c_rarg1); >> pop(c_rarg2); >> pop(c_rarg3); >> } else { >> mov(c_rarg1, arg1); >> mov(c_rarg2, arg2); >> mov(c_rarg3, arg3); >> } >> >> It seems obvious that the right column in the condition should have been `arg1`, `arg2`, `arg3`. >> >> Additional testing: >> - [x] Linux x86_64 `tier1` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Also fix AArch64 Thanks, looks good! ------------- Marked as reviewed by chagedorn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2048 From shade at openjdk.java.net Tue Jan 12 12:47:12 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 12 Jan 2021 12:47:12 GMT Subject: RFR: 8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect [v2] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 12:39:04 GMT, Christian Hagedorn wrote: > Can you also fix this in [c1_Runtime1_aarch64.cpp](https://github.com/openjdk/jdk/blob/563b268c8f23a1f9f5e70065419d4e8661d1d0b4/src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp#L144-L148)? Oh! Fixed there too. ------------- PR: https://git.openjdk.java.net/jdk/pull/2048 From dongbo at openjdk.java.net Tue Jan 12 12:58:55 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Tue, 12 Jan 2021 12:58:55 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v6] In-Reply-To: References: <4nnhdRP9gsILzFv5MvE_1usJtLBwmtoThIErfRgcftw=.277fc10e-1bc2-4a99-97e6-ca1562b625c3@github.com> Message-ID: On Tue, 12 Jan 2021 10:26:39 GMT, Andrew Haley wrote: >> Dong Bo has updated the pull request incrementally with one additional commit since the last revision: >> >> test improvements for doubles with Math.abs() > > Marked as reviewed by aph (Reviewer). @theRealAph Thanks for the review. @pfustc @DamonFool Thank you for looking into this. I see some aarch64 files created recently include Oracle copyright, e.g. `aarch64_sve.ad`. And when I wrote the test code, I did take some files with Oracle copyright as references. I think the Oracle copyright statements in testcode should be kept there. ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From dongbo at openjdk.java.net Tue Jan 12 13:30:57 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Tue, 12 Jan 2021 13:30:57 GMT Subject: Integrated: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 06:23:33 GMT, Dong Bo wrote: > This patch optimizes vectorial Min/Max reduction of two floating-point numbers on aarch64 with NEON instructions `fmaxp` and `fminp`. > > Passed jtreg tier1-3 tests with `linux-aarch64-server-fastdebug` build. > Tests under `test/jdk/jdk/incubator/vector/` runned specially for the correctness and passed. > > Introduced a new JMH micro `test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java` for performance test. > Witnessed abount `37%` performance improvements on Kunpeng916. The JMH Results: > Benchmark (COUNT) (seed) Mode Cnt Score Error Units > # Kunpeng 916, default > VectorReduction.maxRedD 512 0 avgt 10 678.126 ? 0.815 ns/op > VectorReduction.maxRedF 512 0 avgt 10 242.958 ? 0.212 ns/op > VectorReduction.minRedD 512 0 avgt 10 678.554 ? 0.824 ns/op > VectorReduction.minRedF 512 0 avgt 10 243.368 ? 0.205 ns/op > > # Kunpeng 916, with fmaxp/fminp > VectorReduction.maxRedD 512 0 avgt 10 430.201 ? 0.353 ns/op => 36.56% > VectorReduction.maxRedF 512 0 avgt 10 243.404 ? 0.297 ns/op > VectorReduction.minRedD 512 0 avgt 10 427.805 ? 0.528 ns/op => 36.89% > VectorReduction.minRedF 512 0 avgt 10 242.963 ? 0.210 ns/op This pull request has now been integrated. Changeset: ccac7aae Author: Dong Bo Committer: Fei Yang URL: https://git.openjdk.java.net/jdk/commit/ccac7aae Stats: 658 lines in 7 files changed: 226 ins; 93 del; 339 mod 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp Reviewed-by: aph ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From kbarrett at openjdk.java.net Tue Jan 12 14:13:57 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 12 Jan 2021 14:13:57 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v6] In-Reply-To: References: <4nnhdRP9gsILzFv5MvE_1usJtLBwmtoThIErfRgcftw=.277fc10e-1bc2-4a99-97e6-ca1562b625c3@github.com> Message-ID: On Tue, 12 Jan 2021 12:56:03 GMT, Dong Bo wrote: >> Marked as reviewed by aph (Reviewer). > > @theRealAph Thanks for the review. > > @pfustc @DamonFool Thank you for looking into this. > I see some aarch64 files created recently include Oracle copyright, e.g. `aarch64_sve.ad`. > And when I wrote the test code, I did take some files with Oracle copyright as references. > I think the Oracle copyright statements in testcode should be kept there. All linux-aarch64 builds have started failing in Oracle's CI testing after this change was pushed. See https://bugs.openjdk.java.net/browse/JDK-8259629 ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From bulasevich at openjdk.java.net Tue Jan 12 14:44:01 2021 From: bulasevich at openjdk.java.net (Boris Ulasevich) Date: Tue, 12 Jan 2021 14:44:01 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: <_kzqYF9JIc1ten32g062993eEyhRKHBGOoKoeemvQ9w=.c98f3d6c-cea1-4a8b-b64e-b4e7108d643d@github.com> References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> <_kzqYF9JIc1ten32g062993eEyhRKHBGOoKoeemvQ9w=.c98f3d6c-cea1-4a8b-b64e-b4e7108d643d@github.com> Message-ID: On Tue, 12 Jan 2021 05:03:45 GMT, Igor Veresov wrote: >>> I see some regression on ARM32 with this change: >>> http://cr.openjdk.java.net/~bulasevich/tmp/8251462_jtreg_hotspot/ >> >> I don't think those are related to the changes. Those are probably some preexisting c1 and c2 problems respectively that for some reason weren't triggered before. >> >> The TestOptionsWithRanges is my fault though. I'll fix that. > > I've added the flag validity pre-checks, which should solve the issues with VM complaining about tiered flags being invalid as a result of CompileThreshold and friends being invalid. We'd have to solve the C1 SIGILL and the C2 loop opts crash separately. Those are not really related to the change. Ok. I will see what is wrong there. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From eosterlund at openjdk.java.net Tue Jan 12 15:28:19 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 12 Jan 2021 15:28:19 GMT Subject: [jdk16] RFR: 8259063: Possible deadlock with vtable/itable creation vs concurrent class unloading [v2] In-Reply-To: References: Message-ID: > There is an offender of consistent lock ordering: the creation of itable/vtable stubs. It happens when an inline cache is transitioning to megamorphic. Way earlier in the call stack, we grab the nmethod lock for IC patching, and then when a megamorphic transition happens *and* there is no stub created yet for the given vtable/itable index (rather uncommon), a new vtable/itable stub is created. This creation of a stub takes the CodeCache lock. We already deal with failure to create the stubs today, by making the inline cache "clean" instead, essentially deferring the transition to megamorphic to a subsequent call. We deal with that today to handle the code cache running out of memory, making it temporarily impossible to transition to megamorphic until memory has been freed up. My patch rides on that logic, so that we can try_lock() the CodeCache_lock instead. If we fail to take the lock, then it is arguably a bad time to do this megamorphic transition, regardless of deadlocks, as we might have to wait quite a while. So if we fail to take the lock, I just return NULL saying we couldn't create a vtable/itable stub at this time, signalling we defer the transition to later, as we would also do if we couldn't create the stub due to memory exhaustion. This solves the deadlock situation. > > Eric Caspole who reported the bug has tried this patch, and it solved the problem. I also tried it with the same test myself, with the same successful results. I also ran it through tier1-5 as it is touching inline cache code which can be a bit subtle. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: don't handle code cache exhaustion fully during inline cache patching ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/103/files - new: https://git.openjdk.java.net/jdk16/pull/103/files/71c09794..bdf75c79 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=103&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=103&range=00-01 Stats: 19 lines in 4 files changed: 14 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk16/pull/103.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/103/head:pull/103 PR: https://git.openjdk.java.net/jdk16/pull/103 From neliasso at openjdk.java.net Tue Jan 12 15:45:05 2021 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Tue, 12 Jan 2021 15:45:05 GMT Subject: [jdk16] RFR: 8259063: Possible deadlock with vtable/itable creation vs concurrent class unloading [v2] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 15:28:19 GMT, Erik ?sterlund wrote: >> There is an offender of consistent lock ordering: the creation of itable/vtable stubs. It happens when an inline cache is transitioning to megamorphic. Way earlier in the call stack, we grab the nmethod lock for IC patching, and then when a megamorphic transition happens *and* there is no stub created yet for the given vtable/itable index (rather uncommon), a new vtable/itable stub is created. This creation of a stub takes the CodeCache lock. We already deal with failure to create the stubs today, by making the inline cache "clean" instead, essentially deferring the transition to megamorphic to a subsequent call. We deal with that today to handle the code cache running out of memory, making it temporarily impossible to transition to megamorphic until memory has been freed up. My patch rides on that logic, so that we can try_lock() the CodeCache_lock instead. If we fail to take the lock, then it is arguably a bad time to do this megamorphic transition, regardless of deadlocks, as w e might have to wait quite a while. So if we fail to take the lock, I just return NULL saying we couldn't create a vtable/itable stub at this time, signalling we defer the transition to later, as we would also do if we couldn't create the stub due to memory exhaustion. This solves the deadlock situation. >> >> Eric Caspole who reported the bug has tried this patch, and it solved the problem. I also tried it with the same test myself, with the same successful results. I also ran it through tier1-5 as it is touching inline cache code which can be a bit subtle. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > don't handle code cache exhaustion fully during inline cache patching I like the solution - simple and without adding extra complexity or lock juggling. It's a good just skipping the call to handle_full_code_cache. The VTableBlobs are not the thing usually filling up the code cache - and they can be placed in any codeheap. And even if we skip it - no harm done - there will be other allocations that will trigger the call. ------------- Marked as reviewed by neliasso (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/103 From eosterlund at openjdk.java.net Tue Jan 12 15:55:59 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 12 Jan 2021 15:55:59 GMT Subject: [jdk16] RFR: 8259063: Possible deadlock with vtable/itable creation vs concurrent class unloading [v2] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 15:42:14 GMT, Nils Eliasson wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> don't handle code cache exhaustion fully during inline cache patching > > I like the solution - simple and without adding extra complexity or lock juggling. > > It's a good just skipping the call to handle_full_code_cache. The VTableBlobs are not the thing usually filling up the code cache - and they can be placed in any codeheap. And even if we skip it - no harm done - there will be other allocations that will trigger the call. Thanks for the reviews @neliasso and @pliden. ------------- PR: https://git.openjdk.java.net/jdk16/pull/103 From dongbo at openjdk.java.net Tue Jan 12 16:28:10 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Tue, 12 Jan 2021 16:28:10 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v6] In-Reply-To: References: <4nnhdRP9gsILzFv5MvE_1usJtLBwmtoThIErfRgcftw=.277fc10e-1bc2-4a99-97e6-ca1562b625c3@github.com> Message-ID: <-ySS8X0WKKilPfASGTraHnIkUErfiVFjOoPcFgponTg=.45a4032e-122e-4cdf-9a91-aa0afdcd90a7@github.com> On Tue, 12 Jan 2021 14:11:07 GMT, Kim Barrett wrote: > All linux-aarch64 builds have started failing in Oracle's CI testing after this change was pushed. > See https://bugs.openjdk.java.net/browse/JDK-8259629 I'm really sorry for producing a serious BUG here. I have raise a PR [1] to fix this. Would you mind having a look? Thanks. [1] https://github.com/openjdk/jdk/pull/2052 ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From neliasso at openjdk.java.net Tue Jan 12 16:35:29 2021 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Tue, 12 Jan 2021 16:35:29 GMT Subject: [jdk16] RFR: 8258272: LoadVectorMaskedNode can't be replaced by zero con [v2] In-Reply-To: <1uFiDtbFRK-a5WyMKqNVh0Tx1ospvidf6O0ExS3bRbs=.d8fa7cdf-e712-48a1-902d-77d3b35ae801@github.com> References: <1uFiDtbFRK-a5WyMKqNVh0Tx1ospvidf6O0ExS3bRbs=.d8fa7cdf-e712-48a1-902d-77d3b35ae801@github.com> Message-ID: > A test fails for this code: > > byte [] src = new byte[0]; > byte [] dest = Arrays::copy_of(src); > > This is transformed to something like: > byte [] src = new byte[0]; > byte [] dest = new byte[0]; > System.arraycopy(src, 0, dest, 0, src.lenght()); > > This causes a problem in LoadNode::Value for the new LoadVectorMasked nodes. LoadNode::Value sees that the load will always load a zero - and will try to replace itself with a zero constant. That doesn't work for the LoadVectorMaskedNodes currently. > > This patch adds a check to the zero-optimization to pass on vector types. > > This patch is currently missing a new test. Since we are nearing the end of bugfixing in JDK16 I decided to publish the fix first so that any discussion of the fix can be had now. Nils Eliasson has updated the pull request incrementally with one additional commit since the last revision: add test and update fix ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/105/files - new: https://git.openjdk.java.net/jdk16/pull/105/files/0fb4aab1..61505336 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=105&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=105&range=00-01 Stats: 60 lines in 2 files changed: 59 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/105.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/105/head:pull/105 PR: https://git.openjdk.java.net/jdk16/pull/105 From vladimir.kozlov at oracle.com Tue Jan 12 17:08:03 2021 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Jan 2021 09:08:03 -0800 Subject: [11u] RFR 8257561 Some code is not vectorized after 8251925 and 8250607 In-Reply-To: <87sg76a6qd.fsf@redhat.com> References: <87sg76a6qd.fsf@redhat.com> Message-ID: Looks good. Thanks, Vladimir K On 1/12/21 12:40 AM, Roland Westrelin wrote: > > Hi, > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8257561 > https://github.com/openjdk/jdk/commit/6c9482ee > > Original patch does not apply cleanly to 11u, because the change to > src/hotspot/share/opto/cfgnode.cpp is specific to jdk 16. Change is > otherwise identical to upstream change. > > 11u webrev: > https://cr.openjdk.java.net/~roland/8257561.11u/webrev.00/ > > Testing: x86_64 build, tier1, manually verified with superword tests > that vectorization happens now > > Roland. > From kvn at openjdk.java.net Tue Jan 12 17:20:57 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 12 Jan 2021 17:20:57 GMT Subject: RFR: 8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect [v2] In-Reply-To: <8Ixvi5AkRmzbkmxAYnrkU30Jla8JtykXbzkcvfz9aEw=.8982dca6-dbf2-4f14-b1e5-bbe99c534f32@github.com> References: <8Ixvi5AkRmzbkmxAYnrkU30Jla8JtykXbzkcvfz9aEw=.8982dca6-dbf2-4f14-b1e5-bbe99c534f32@github.com> Message-ID: On Tue, 12 Jan 2021 12:47:11 GMT, Aleksey Shipilev wrote: >> SonarCould instance reports this code smell in c1_Runtime_x86.cpp: Identical sub-expressions on both sides of operator "||" >> >> int StubAssembler::call_RT(Register oop_result1, Register metadata_result, address entry, Register arg1, Register arg2, Register arg3) { >> #ifdef _LP64 >> // if there is any conflict use the stack >> if (arg1 == c_rarg2 || arg1 == c_rarg3 || >> arg2 == c_rarg1 || arg1 == c_rarg3 || >> arg3 == c_rarg1 || arg1 == c_rarg2) { <---- HERE >> push(arg3); >> push(arg2); >> push(arg1); >> pop(c_rarg1); >> pop(c_rarg2); >> pop(c_rarg3); >> } else { >> mov(c_rarg1, arg1); >> mov(c_rarg2, arg2); >> mov(c_rarg3, arg3); >> } >> >> It seems obvious that the right column in the condition should have been `arg1`, `arg2`, `arg3`. >> >> Additional testing: >> - [x] Linux x86_64 `tier1` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Also fix AArch64 Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2048 From vlivanov at openjdk.java.net Tue Jan 12 17:48:56 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 12 Jan 2021 17:48:56 GMT Subject: [jdk16] RFR: 8259353: VectorReinterpretNode is incorrectly optimized out [v2] In-Reply-To: References: <8bPOqQ22N2FDGHuRqcJ7aOsezcNYT7c4FhTD_X7RbhU=.a5112299-bdac-41fc-ad4d-9cbb19a75ee8@github.com> Message-ID: On Tue, 12 Jan 2021 02:49:22 GMT, Xiaohong Gong wrote: >> Marked as reviewed by vlivanov (Reviewer). > > Hi @iwanowww , the AArch64 specific changes have been reverted. I will create another PR for it. Could you please have a look again? Thanks! Still looks good. ------------- PR: https://git.openjdk.java.net/jdk16/pull/100 From chagedorn at openjdk.java.net Tue Jan 12 18:24:00 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 12 Jan 2021 18:24:00 GMT Subject: [jdk16] RFR: 8258272: LoadVectorMaskedNode can't be replaced by zero con [v2] In-Reply-To: References: <1uFiDtbFRK-a5WyMKqNVh0Tx1ospvidf6O0ExS3bRbs=.d8fa7cdf-e712-48a1-902d-77d3b35ae801@github.com> Message-ID: On Tue, 12 Jan 2021 16:35:29 GMT, Nils Eliasson wrote: >> A test fails for this code: >> >> byte [] src = new byte[0]; >> byte [] dest = Arrays::copy_of(src); >> >> This is transformed to something like: >> byte [] src = new byte[0]; >> byte [] dest = new byte[0]; >> System.arraycopy(src, 0, dest, 0, src.lenght()); >> >> This causes a problem in LoadNode::Value for the new LoadVectorMasked nodes. LoadNode::Value sees that the load will always load a zero - and will try to replace itself with a zero constant. That doesn't work for the LoadVectorMaskedNodes currently. >> >> This patch adds a check to the zero-optimization to pass on vector types. >> >> This patch is currently missing a new test. Since we are nearing the end of bugfixing in JDK16 I decided to publish the fix first so that any discussion of the fix can be had now. > > Nils Eliasson has updated the pull request incrementally with one additional commit since the last revision: > > add test and update fix Looks good! ------------- Marked as reviewed by chagedorn (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/105 From neliasso at openjdk.java.net Tue Jan 12 22:00:22 2021 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Tue, 12 Jan 2021 22:00:22 GMT Subject: [jdk16] RFR: 8258272: LoadVectorMaskedNode can't be replaced by zero con [v3] In-Reply-To: <1uFiDtbFRK-a5WyMKqNVh0Tx1ospvidf6O0ExS3bRbs=.d8fa7cdf-e712-48a1-902d-77d3b35ae801@github.com> References: <1uFiDtbFRK-a5WyMKqNVh0Tx1ospvidf6O0ExS3bRbs=.d8fa7cdf-e712-48a1-902d-77d3b35ae801@github.com> Message-ID: > A test fails for this code: > > byte [] src = new byte[0]; > byte [] dest = Arrays::copy_of(src); > > This is transformed to something like: > byte [] src = new byte[0]; > byte [] dest = new byte[0]; > System.arraycopy(src, 0, dest, 0, src.lenght()); > > This causes a problem in LoadNode::Value for the new LoadVectorMasked nodes. LoadNode::Value sees that the load will always load a zero - and will try to replace itself with a zero constant. That doesn't work for the LoadVectorMaskedNodes currently. > > This patch adds a check to the zero-optimization to pass on vector types. > > This patch is currently missing a new test. Since we are nearing the end of bugfixing in JDK16 I decided to publish the fix first so that any discussion of the fix can be had now. Nils Eliasson has updated the pull request incrementally with one additional commit since the last revision: Make check a bool ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/105/files - new: https://git.openjdk.java.net/jdk16/pull/105/files/61505336..b50b7372 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=105&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=105&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/105.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/105/head:pull/105 PR: https://git.openjdk.java.net/jdk16/pull/105 From vlivanov at openjdk.java.net Tue Jan 12 22:00:23 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 12 Jan 2021 22:00:23 GMT Subject: [jdk16] RFR: 8258272: LoadVectorMaskedNode can't be replaced by zero con [v3] In-Reply-To: References: <1uFiDtbFRK-a5WyMKqNVh0Tx1ospvidf6O0ExS3bRbs=.d8fa7cdf-e712-48a1-902d-77d3b35ae801@github.com> Message-ID: On Tue, 12 Jan 2021 21:42:23 GMT, Nils Eliasson wrote: >> A test fails for this code: >> >> byte [] src = new byte[0]; >> byte [] dest = Arrays::copy_of(src); >> >> This is transformed to something like: >> byte [] src = new byte[0]; >> byte [] dest = new byte[0]; >> System.arraycopy(src, 0, dest, 0, src.lenght()); >> >> This causes a problem in LoadNode::Value for the new LoadVectorMasked nodes. LoadNode::Value sees that the load will always load a zero - and will try to replace itself with a zero constant. That doesn't work for the LoadVectorMaskedNodes currently. >> >> This patch adds a check to the zero-optimization to pass on vector types. >> >> This patch is currently missing a new test. Since we are nearing the end of bugfixing in JDK16 I decided to publish the fix first so that any discussion of the fix can be had now. > > Nils Eliasson has updated the pull request incrementally with one additional commit since the last revision: > > Make check a bool Even better! ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/105 From vlivanov at openjdk.java.net Tue Jan 12 23:17:07 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 12 Jan 2021 23:17:07 GMT Subject: [jdk16] RFR: 8255120: C2: assert(outer->outcnt() >= phis + 2 && outer->outcnt() <= phis + 2 + stores + 1) failed: only phis Message-ID: <2PEWRbpWVrdRx47oZPJQVs082bVynDioRaD2GjZExqs=.3561364b-f502-416d-a0ac-1a6bc1087627@github.com> JDK-8255000 made post-loopopts IGVN processing predictable, but also reordered it with macro node expansion. It turned out that macro node expansion is sensitive to narrower types post-loopopts IGVN generates and it either triggers the aforementioned assert or produces less efficient code (some runtime checks aren't eliminated anymore and it adds up some overhead, see JDK-8255705 for details). I'll file a separate RFE to make macro node expansion more robust (and relax the problematic assert), but for now (jdk16) I propose to restore the original order of transformations. Testing: - [x] failing test - [x] hs-tier1 - hs-tier6 - [x] SPECjvm2008 MPEG - [x] gc/shenandoah/ ------------- Commit messages: - 8255120: C2: assert(outer->outcnt() >= phis + 2 && outer->outcnt() <= phis + 2 + stores + 1) failed: only phis Changes: https://git.openjdk.java.net/jdk16/pull/113/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=113&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255120 Stats: 40 lines in 5 files changed: 14 ins; 15 del; 11 mod Patch: https://git.openjdk.java.net/jdk16/pull/113.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/113/head:pull/113 PR: https://git.openjdk.java.net/jdk16/pull/113 From xgong at openjdk.java.net Wed Jan 13 01:39:00 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Wed, 13 Jan 2021 01:39:00 GMT Subject: [jdk16] RFR: 8259601: AArch64: Fix reinterpretX2D match rule issue In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 10:00:54 GMT, Andrew Dinn wrote: > Yes, these changes look good. Thanks for your review @adinn ! ------------- PR: https://git.openjdk.java.net/jdk16/pull/108 From njian at openjdk.java.net Wed Jan 13 02:37:04 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Wed, 13 Jan 2021 02:37:04 GMT Subject: [jdk16] RFR: 8259353: VectorReinterpretNode is incorrectly optimized out [v2] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 02:52:13 GMT, Xiaohong Gong wrote: >> Vector reinterpretation just reinterprets the bytes of the vector without performing any value conversions. So normally, optimization like: >> (VectorReinterpret (VectorReinterpret src)) -> src >> can be applied correctly if the logical result and the input `"src"` have the same vector type. However, the results might not be correct if truncation happens after the first reinterpretation: `"(VectorReinterpret src)"`. >> >> Consider the following case: >> byte[] a = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15} >> byte[] b = new byte[16] >> byte[] c = new byte[16] >> >> // load vector from "a" with 128-bits >> ByteVector av = ByteVector.fromArray(SPECIES_128, a, 0); >> >> // reinterpret to 64-bits >> ByteVector bv = (ByteVector)av.reinterpretShape(SPECIES_64, 0); >> >> // reinterpret back to 128-bits with the above reinterpreting results >> ByteVector cv = (ByteVector)bv.reinterpretShape(SPECIES_128, 0); >> cv.intoArray(c, 0) >> This case: >> 1. Reinterprets vector `"av"` from 128-bits to 64-bits. It should only copy the first 8 elements to vector `"bv"` and discard the higher half parts. >> 2. Reinterprets vector `"bv"` back to 128-bits. It copies the 64-bits from` "bv"` to` "cv"`, and paddings the rest part of `"cv"` with zero. >> The final values in array `"c"` are expected to be: >> c = [ 0, 1, 2, 3, 4, 5, 6, 7, 0, 0, 0, 0, 0, 0, 0, 0] >> However, with the optimization mentioned at the beginning, the second reinterpretation is optimized out. The values in array` "c" `are incorrectly copied from array `"a"`. The values are: >> c = [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] >> To fix it, this patch adds the vector size constraint for the optimization, that is the first reinterpretation must not be conducted to a shorter vector. >> >> It also fixes a potential issue for the implementation of match rule `"reinterpretX2D (from 16 bytes to 8 bytes)" `on Arm NEON. Specifically, the `"mov"` is always needed even if the` "dst"` and `"src"` are the same register since truncation should be conducted in order to be consistent with the semantics. > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Revert Arm NEON match rule fixes LGTM ------------- Marked as reviewed by njian (Committer). PR: https://git.openjdk.java.net/jdk16/pull/100 From njian at openjdk.java.net Wed Jan 13 02:42:00 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Wed, 13 Jan 2021 02:42:00 GMT Subject: [jdk16] RFR: 8259601: AArch64: Fix reinterpretX2D match rule issue In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 04:02:00 GMT, Xiaohong Gong wrote: > Currently the `"reinterpretX2D"` match rule does not generate any register move instruction if the` 'dst'` and` 'src'` are the same register. This rule implements the vector reinterpretation from 16 bytes to 8 bytes. It is a kind of data truncation, which should make sure the higher 8 bytes of the `'dst' `register cleared to zero. So the `"mov" `is always needed even if the` "dst"` and `"src"` are the same register in case of the issue mentioned in [1]. > > We have tested the case [3] with Arm NEON. And the issue still exists even if [1] is fixed with [2]. Removing the check (i.e. whether `'src'` and `'dst`' are the same register) in the rule would fix it finally. > > [1] https://bugs.openjdk.java.net/browse/JDK-8259353 > [2] https://github.com/openjdk/jdk16/pull/100 > [3] https://bugs.openjdk.java.net/secure/attachment/92713/Test.java Looks good to me too. ------------- Marked as reviewed by njian (Committer). PR: https://git.openjdk.java.net/jdk16/pull/108 From njian at openjdk.java.net Wed Jan 13 05:52:58 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Wed, 13 Jan 2021 05:52:58 GMT Subject: [jdk16] RFR: 8259353: VectorReinterpretNode is incorrectly optimized out [v2] In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 02:34:19 GMT, Ningsheng Jian wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert Arm NEON match rule fixes > > LGTM I don't think the Windows x64 build failure in pre-submit tests is related to this patch. Sponsoring. ------------- PR: https://git.openjdk.java.net/jdk16/pull/100 From xgong at openjdk.java.net Wed Jan 13 05:52:59 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Wed, 13 Jan 2021 05:52:59 GMT Subject: [jdk16] Integrated: 8259353: VectorReinterpretNode is incorrectly optimized out In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 09:23:24 GMT, Xiaohong Gong wrote: > Vector reinterpretation just reinterprets the bytes of the vector without performing any value conversions. So normally, optimization like: > (VectorReinterpret (VectorReinterpret src)) -> src > can be applied correctly if the logical result and the input `"src"` have the same vector type. However, the results might not be correct if truncation happens after the first reinterpretation: `"(VectorReinterpret src)"`. > > Consider the following case: > byte[] a = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15} > byte[] b = new byte[16] > byte[] c = new byte[16] > > // load vector from "a" with 128-bits > ByteVector av = ByteVector.fromArray(SPECIES_128, a, 0); > > // reinterpret to 64-bits > ByteVector bv = (ByteVector)av.reinterpretShape(SPECIES_64, 0); > > // reinterpret back to 128-bits with the above reinterpreting results > ByteVector cv = (ByteVector)bv.reinterpretShape(SPECIES_128, 0); > cv.intoArray(c, 0) > This case: > 1. Reinterprets vector `"av"` from 128-bits to 64-bits. It should only copy the first 8 elements to vector `"bv"` and discard the higher half parts. > 2. Reinterprets vector `"bv"` back to 128-bits. It copies the 64-bits from` "bv"` to` "cv"`, and paddings the rest part of `"cv"` with zero. > The final values in array `"c"` are expected to be: > c = [ 0, 1, 2, 3, 4, 5, 6, 7, 0, 0, 0, 0, 0, 0, 0, 0] > However, with the optimization mentioned at the beginning, the second reinterpretation is optimized out. The values in array` "c" `are incorrectly copied from array `"a"`. The values are: > c = [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] > To fix it, this patch adds the vector size constraint for the optimization, that is the first reinterpretation must not be conducted to a shorter vector. > > It also fixes a potential issue for the implementation of match rule `"reinterpretX2D (from 16 bytes to 8 bytes)" `on Arm NEON. Specifically, the `"mov"` is always needed even if the` "dst"` and `"src"` are the same register since truncation should be conducted in order to be consistent with the semantics. This pull request has now been integrated. Changeset: 1cf2378b Author: Xiaohong Gong Committer: Ningsheng Jian URL: https://git.openjdk.java.net/jdk16/commit/1cf2378b Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod 8259353: VectorReinterpretNode is incorrectly optimized out Reviewed-by: vlivanov, njian ------------- PR: https://git.openjdk.java.net/jdk16/pull/100 From xgong at openjdk.java.net Wed Jan 13 05:56:10 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Wed, 13 Jan 2021 05:56:10 GMT Subject: [jdk16] Integrated: 8259601: AArch64: Fix reinterpretX2D match rule issue In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 04:02:00 GMT, Xiaohong Gong wrote: > Currently the `"reinterpretX2D"` match rule does not generate any register move instruction if the` 'dst'` and` 'src'` are the same register. This rule implements the vector reinterpretation from 16 bytes to 8 bytes. It is a kind of data truncation, which should make sure the higher 8 bytes of the `'dst' `register cleared to zero. So the `"mov" `is always needed even if the` "dst"` and `"src"` are the same register in case of the issue mentioned in [1]. > > We have tested the case [3] with Arm NEON. And the issue still exists even if [1] is fixed with [2]. Removing the check (i.e. whether `'src'` and `'dst`' are the same register) in the rule would fix it finally. > > [1] https://bugs.openjdk.java.net/browse/JDK-8259353 > [2] https://github.com/openjdk/jdk16/pull/100 > [3] https://bugs.openjdk.java.net/secure/attachment/92713/Test.java This pull request has now been integrated. Changeset: 793017d2 Author: Xiaohong Gong Committer: Ningsheng Jian URL: https://git.openjdk.java.net/jdk16/commit/793017d2 Stats: 41 lines in 2 files changed: 17 ins; 1 del; 23 mod 8259601: AArch64: Fix reinterpretX2D match rule issue Reviewed-by: adinn, njian ------------- PR: https://git.openjdk.java.net/jdk16/pull/108 From rcastanedalo at openjdk.java.net Wed Jan 13 07:14:54 2021 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Wed, 13 Jan 2021 07:14:54 GMT Subject: [jdk16] RFR: 8259061: C2: assert(found) failed: memory-writing node is not placed in its original loop or an ancestor of it In-Reply-To: <7e9h0MpQ9eGQ_ji1ki8u3RdO-m6RIn_dR3c4mLOaKvI=.925ca765-48d3-43fa-bbee-7005eb55657d@github.com> References: <7e9h0MpQ9eGQ_ji1ki8u3RdO-m6RIn_dR3c4mLOaKvI=.925ca765-48d3-43fa-bbee-7005eb55657d@github.com> Message-ID: <4f9oFkLYGaZFU3w-Ujx7qQo1KWCEiK9gD8Ot-mH00x8=.bce331f2-93d2-4700-aac2-4566dd354d61@github.com> On Tue, 12 Jan 2021 08:27:21 GMT, Roberto Casta?eda Lozano wrote: >> Agree. > >> Agree. > > Thanks, Vladimir! Thanks again for the reviews, please sponsor. ------------- PR: https://git.openjdk.java.net/jdk16/pull/101 From rcastanedalo at openjdk.java.net Wed Jan 13 07:25:00 2021 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Wed, 13 Jan 2021 07:25:00 GMT Subject: [jdk16] Integrated: 8259061: C2: assert(found) failed: memory-writing node is not placed in its original loop or an ancestor of it In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 12:27:18 GMT, Roberto Casta?eda Lozano wrote: > Remove assertion that is too general, that is, it can fail on compilations where C2 generates correct code otherwise. > > The assertion was introduced in [JDK-8255763](https://bugs.openjdk.java.net/browse/JDK-8255763) to prevent potential miscompilations in the case of irreducible CFGs, and will be reconsidered in [JDK-8258894](https://bugs.openjdk.java.net/browse/JDK-8258894) where the general case is addressed. > > Tested by building (release and debug) on different platforms. This pull request has now been integrated. Changeset: 417e1d1a Author: Roberto Casta?eda Lozano Committer: Tobias Hartmann URL: https://git.openjdk.java.net/jdk16/commit/417e1d1a Stats: 20 lines in 1 file changed: 0 ins; 20 del; 0 mod 8259061: C2: assert(found) failed: memory-writing node is not placed in its original loop or an ancestor of it Remove assertion that is too general, that is, it can fail on compilations where C2 generates correct code otherwise. Reviewed-by: chagedorn, thartmann, kvn ------------- PR: https://git.openjdk.java.net/jdk16/pull/101 From rwestrel at redhat.com Wed Jan 13 07:51:17 2021 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 13 Jan 2021 08:51:17 +0100 Subject: [11u] RFR 8257561 Some code is not vectorized after 8251925 and 8250607 In-Reply-To: References: <87sg76a6qd.fsf@redhat.com> Message-ID: <87pn299swa.fsf@redhat.com> Thanks for the review, Vladimir. Roland. From chagedorn at openjdk.java.net Wed Jan 13 08:02:03 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Wed, 13 Jan 2021 08:02:03 GMT Subject: [jdk16] RFR: 8258272: LoadVectorMaskedNode can't be replaced by zero con [v3] In-Reply-To: References: <1uFiDtbFRK-a5WyMKqNVh0Tx1ospvidf6O0ExS3bRbs=.d8fa7cdf-e712-48a1-902d-77d3b35ae801@github.com> Message-ID: <1yN-gAjz4p-4DMkbsfoESKTOPkTKWaIL-ZfiVQgsg8I=.8c8768f7-b38b-4b42-bca8-53338861ce67@github.com> On Tue, 12 Jan 2021 22:00:22 GMT, Nils Eliasson wrote: >> A test fails for this code: >> >> byte [] src = new byte[0]; >> byte [] dest = Arrays::copy_of(src); >> >> This is transformed to something like: >> byte [] src = new byte[0]; >> byte [] dest = new byte[0]; >> System.arraycopy(src, 0, dest, 0, src.lenght()); >> >> This causes a problem in LoadNode::Value for the new LoadVectorMasked nodes. LoadNode::Value sees that the load will always load a zero - and will try to replace itself with a zero constant. That doesn't work for the LoadVectorMaskedNodes currently. >> >> This patch adds a check to the zero-optimization to pass on vector types. >> >> This patch is currently missing a new test. Since we are nearing the end of bugfixing in JDK16 I decided to publish the fix first so that any discussion of the fix can be had now. > > Nils Eliasson has updated the pull request incrementally with one additional commit since the last revision: > > Make check a bool Marked as reviewed by chagedorn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/105 From thartmann at openjdk.java.net Wed Jan 13 08:03:59 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 13 Jan 2021 08:03:59 GMT Subject: [jdk16] RFR: 8255120: C2: assert(outer->outcnt() >= phis + 2 && outer->outcnt() <= phis + 2 + stores + 1) failed: only phis In-Reply-To: <2PEWRbpWVrdRx47oZPJQVs082bVynDioRaD2GjZExqs=.3561364b-f502-416d-a0ac-1a6bc1087627@github.com> References: <2PEWRbpWVrdRx47oZPJQVs082bVynDioRaD2GjZExqs=.3561364b-f502-416d-a0ac-1a6bc1087627@github.com> Message-ID: On Tue, 12 Jan 2021 22:16:54 GMT, Vladimir Ivanov wrote: > JDK-8255000 made post-loopopts IGVN processing predictable, but also reordered it with macro node expansion. > > It turned out that macro node expansion is sensitive to narrower types post-loopopts IGVN generates and it either triggers the aforementioned assert or produces less efficient code (some runtime checks aren't eliminated anymore and it adds up some overhead, see JDK-8255705 for details). > > I'll file a separate RFE to make macro node expansion more robust (and relax the problematic assert), but for now (jdk16) I propose to restore the original order of transformations. > > Testing: > - [x] failing test > - [x] hs-tier1 - hs-tier6 > - [x] SPECjvm2008 MPEG > - [x] gc/shenandoah/ Looks good to me. Can JDK-8255705 be closed as duplicate or are there other performance issues left? ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/113 From vlivanov at openjdk.java.net Wed Jan 13 08:25:01 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 13 Jan 2021 08:25:01 GMT Subject: [jdk16] RFR: 8255120: C2: assert(outer->outcnt() >= phis + 2 && outer->outcnt() <= phis + 2 + stores + 1) failed: only phis In-Reply-To: References: <2PEWRbpWVrdRx47oZPJQVs082bVynDioRaD2GjZExqs=.3561364b-f502-416d-a0ac-1a6bc1087627@github.com> Message-ID: On Wed, 13 Jan 2021 08:00:59 GMT, Tobias Hartmann wrote: >> JDK-8255000 made post-loopopts IGVN processing predictable, but also reordered it with macro node expansion. >> >> It turned out that macro node expansion is sensitive to narrower types post-loopopts IGVN generates and it either triggers the aforementioned assert or produces less efficient code (some runtime checks aren't eliminated anymore and it adds up some overhead, see JDK-8255705 for details). >> >> I'll file a separate RFE to make macro node expansion more robust (and relax the problematic assert), but for now (jdk16) I propose to restore the original order of transformations. >> >> Testing: >> - [x] failing test >> - [x] hs-tier1 - hs-tier6 >> - [x] SPECjvm2008 MPEG >> - [x] gc/shenandoah/ > > Looks good to me. Can JDK-8255705 be closed as duplicate or are there other performance issues left? Thanks, Tobias. > Can JDK-8255705 be closed as duplicate or are there other performance issues left? I don't have a conclusive answer yet. The fix does improve MPEG score a bit, but it is still slower than jdk-16+20. jdk-16.latest 150.391 +- 0.361 ops/min jdk-16.fix 151.212 +- 0.356 ops/min jdk-16+20 152.267 +- 0.378 ops/min jdk-16+21 150.343 +- 0.294 ops/min Will conduct additional performance experiments before deciding what to do with JDK-8255705. ------------- PR: https://git.openjdk.java.net/jdk16/pull/113 From neliasso at openjdk.java.net Wed Jan 13 09:19:04 2021 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Wed, 13 Jan 2021 09:19:04 GMT Subject: [jdk16] Integrated: 8258272: LoadVectorMaskedNode can't be replaced by zero con In-Reply-To: <1uFiDtbFRK-a5WyMKqNVh0Tx1ospvidf6O0ExS3bRbs=.d8fa7cdf-e712-48a1-902d-77d3b35ae801@github.com> References: <1uFiDtbFRK-a5WyMKqNVh0Tx1ospvidf6O0ExS3bRbs=.d8fa7cdf-e712-48a1-902d-77d3b35ae801@github.com> Message-ID: On Mon, 11 Jan 2021 22:51:48 GMT, Nils Eliasson wrote: > A test fails for this code: > > byte [] src = new byte[0]; > byte [] dest = Arrays::copy_of(src); > > This is transformed to something like: > byte [] src = new byte[0]; > byte [] dest = new byte[0]; > System.arraycopy(src, 0, dest, 0, src.lenght()); > > This causes a problem in LoadNode::Value for the new LoadVectorMasked nodes. LoadNode::Value sees that the load will always load a zero - and will try to replace itself with a zero constant. That doesn't work for the LoadVectorMaskedNodes currently. > > This patch adds a check to the zero-optimization to pass on vector types. > > This patch is currently missing a new test. Since we are nearing the end of bugfixing in JDK16 I decided to publish the fix first so that any discussion of the fix can be had now. This pull request has now been integrated. Changeset: 55675309 Author: Nils Eliasson URL: https://git.openjdk.java.net/jdk16/commit/55675309 Stats: 63 lines in 2 files changed: 61 ins; 0 del; 2 mod 8258272: LoadVectorMaskedNode can't be replaced by zero con Reviewed-by: chagedorn, vlivanov ------------- PR: https://git.openjdk.java.net/jdk16/pull/105 From thartmann at openjdk.java.net Wed Jan 13 10:47:55 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 13 Jan 2021 10:47:55 GMT Subject: RFR: 8259609: C2: optimize long range checks in long counted loops In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 10:15:01 GMT, Roland Westrelin wrote: > JDK-8255150 makes it possible for java code to explicitly perform a > range check on long values. JDK-8223051 provides a transformation of > long counted loops into loop nests with an inner int counted > loop. With this change I propose transforming long range checks that > operate on the iv of a long counted loop into range checks that > operate on the iv of the int inner loop once it has been > created. Existing range check eliminations can then kick in. > > Transformation of range checks is piggy backed on the loop nest > creation for 2 reasons: > > - pattern matching range checks is easier right before the loop nest > is created > > - the number of iterations of the inner loop is adjusted so scale * > inner_iv doesn't overflow > > C2 has logic to delay some split if transformations so they don't > break the scale * iv + offset pattern. I reused that logic for long > range checks and had to relax what's considered a range check because > initially a range check from Object.checkIndex() may include a test > for range > 0 that needs a round of loop opts to be hoisted. I realize > there's some code duplication but I didn't see a way to share logic > between IdealLoopTree::may_have_range_check() > IdealLoopTree::policy_range_check() that would feel right. > > I realize the comment in PhaseIdealLoop::transform_long_range_checks() > is scary. FWIW, it's not as complicated as it looks. I found drawing > the range covered by the entire long loop and the range covered by the > inner loop help see how range checks can be transformed. Then the > comment helps make sure all cases are covered and verify the generated > code actually covers all of them. > > One issue is overflow. I think the fact that inner_iv * scale doesn't > overflow helps simplify thing. One possible overflow is that of scale > * upper + offset which is handled by forcing all range checks in that > case to deoptimize. I don't think other case of overflow needs special > handling. > > This was tested with a Memory Segment micro benchmark (and patched > Memory Segment support to take advantage of the new checkIndex > intrinsic, both provided by Maurizio). Range checks in the micro > benchmark are properly optimized (and performance increases > significantly). Hi Roland, I haven't looked at the code in detail yet but submitted some quick testing. Unfortunately, there are failures with an internal test that I'm unable to share. Some details: # Internal Error (src/hotspot/share/utilities/globalDefinitions.hpp:460), pid=27250, tid=27265 # assert(static_cast(result) == thing) failed: must be Stack: [0x00007fca9cdfa000,0x00007fca9cefb000], sp=0x00007fca9cef5360, free space=1004k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x12f5a3e] IdealLoopTree::policy_range_check(PhaseIdealLoop*) const [clone .part.0]+0x33e V [libjvm.so+0x1301e4f] IdealLoopTree::iteration_split_impl(PhaseIdealLoop*, Node_List&) [clone .part.0]+0x6ef V [libjvm.so+0x13021bb] IdealLoopTree::iteration_split(PhaseIdealLoop*, Node_List&)+0x13b V [libjvm.so+0x13020b5] IdealLoopTree::iteration_split(PhaseIdealLoop*, Node_List&)+0x35 V [libjvm.so+0x1330633] PhaseIdealLoop::build_and_optimize(LoopOptsMode)+0xc83 V [libjvm.so+0xa1cbdb] PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x32b V [libjvm.so+0xa18636] Compile::Optimize()+0x586 V [libjvm.so+0xa1b370] Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, DirectiveSet*)+0x1840 V [libjvm.so+0x84b1bc] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1dc V [libjvm.so+0xa2b3a8] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xe88 V [libjvm.so+0xa2bff8] CompileBroker::compiler_thread_loop()+0x5a8 V [libjvm.so+0x18b06c6] JavaThread::thread_main_inner()+0x256 V [libjvm.so+0x18b70d0] Thread::call_run()+0x100 V [libjvm.so+0x1599dd6] thread_native_entry(Thread*)+0x116 Hope that helps. ------------- PR: https://git.openjdk.java.net/jdk/pull/2045 From shade at openjdk.java.net Wed Jan 13 12:33:57 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 13 Jan 2021 12:33:57 GMT Subject: RFR: 8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect [v2] In-Reply-To: References: <8Ixvi5AkRmzbkmxAYnrkU30Jla8JtykXbzkcvfz9aEw=.8982dca6-dbf2-4f14-b1e5-bbe99c534f32@github.com> Message-ID: <65GVZ6dI5j6AmtlCkVuWyAjWX-QWMYAA6Pe-_Ajo3RQ=.7c986cc4-6612-4afe-9dbf-1d735f58e020@github.com> On Tue, 12 Jan 2021 17:18:30 GMT, Vladimir Kozlov wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Also fix AArch64 > > Good. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/2048 From shade at openjdk.java.net Wed Jan 13 12:33:58 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 13 Jan 2021 12:33:58 GMT Subject: Integrated: 8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 12:21:15 GMT, Aleksey Shipilev wrote: > SonarCould instance reports this code smell in c1_Runtime_x86.cpp: Identical sub-expressions on both sides of operator "||" > > int StubAssembler::call_RT(Register oop_result1, Register metadata_result, address entry, Register arg1, Register arg2, Register arg3) { > #ifdef _LP64 > // if there is any conflict use the stack > if (arg1 == c_rarg2 || arg1 == c_rarg3 || > arg2 == c_rarg1 || arg1 == c_rarg3 || > arg3 == c_rarg1 || arg1 == c_rarg2) { <---- HERE > push(arg3); > push(arg2); > push(arg1); > pop(c_rarg1); > pop(c_rarg2); > pop(c_rarg3); > } else { > mov(c_rarg1, arg1); > mov(c_rarg2, arg2); > mov(c_rarg3, arg3); > } > > It seems obvious that the right column in the condition should have been `arg1`, `arg2`, `arg3`. > > Additional testing: > - [x] Linux x86_64 `tier1` This pull request has now been integrated. Changeset: ce945120 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/ce945120 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect Reviewed-by: chagedorn, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/2048 From thartmann at openjdk.java.net Wed Jan 13 13:12:09 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 13 Jan 2021 13:12:09 GMT Subject: RFR: 8259706: C2 compilation fails with assert(vtable_index == Method::invalid_vtable_index) failed: correct sentinel value Message-ID: When trying to backport [JDK-8259339](https://bugs.openjdk.java.net/browse/JDK-8259339) to JDK 11u, I've hit an assert on Sparc that triggers because the slow virtual call to `Unsafe.allocateUninitializedArray0` could be optimized to a static call since the `Unsafe` class is final. Thanks, Tobias ------------- Commit messages: - 8259706: C2 compilation fails with assert(vtable_index == Method::invalid_vtable_index) failed: correct sentinel value Changes: https://git.openjdk.java.net/jdk/pull/2062/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2062&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259706 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2062.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2062/head:pull/2062 PR: https://git.openjdk.java.net/jdk/pull/2062 From roland at openjdk.java.net Wed Jan 13 13:43:02 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Wed, 13 Jan 2021 13:43:02 GMT Subject: RFR: 8259609: C2: optimize long range checks in long counted loops In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 10:44:49 GMT, Tobias Hartmann wrote: > I haven't looked at the code in detail yet but submitted some quick testing. Unfortunately, there are failures with an internal test that I'm unable to share. Some details: Thanks. I pushed a fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/2045 From eosterlund at openjdk.java.net Wed Jan 13 16:52:12 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 13 Jan 2021 16:52:12 GMT Subject: [jdk16] Integrated: 8259063: Possible deadlock with vtable/itable creation vs concurrent class unloading In-Reply-To: References: Message-ID: <7nIw7d3aYS1Ep4zySQDUGA-rvPsm6s7_h4yXpJSzfYY=.51184b46-7a12-43db-962c-795144c7882c@github.com> On Mon, 11 Jan 2021 16:11:34 GMT, Erik ?sterlund wrote: > There is an offender of consistent lock ordering: the creation of itable/vtable stubs. It happens when an inline cache is transitioning to megamorphic. Way earlier in the call stack, we grab the nmethod lock for IC patching, and then when a megamorphic transition happens *and* there is no stub created yet for the given vtable/itable index (rather uncommon), a new vtable/itable stub is created. This creation of a stub takes the CodeCache lock. We already deal with failure to create the stubs today, by making the inline cache "clean" instead, essentially deferring the transition to megamorphic to a subsequent call. We deal with that today to handle the code cache running out of memory, making it temporarily impossible to transition to megamorphic until memory has been freed up. My patch rides on that logic, so that we can try_lock() the CodeCache_lock instead. If we fail to take the lock, then it is arguably a bad time to do this megamorphic transition, regardless of deadlocks, as we might have to wait quite a while. So if we fail to take the lock, I just return NULL saying we couldn't create a vtable/itable stub at this time, signalling we defer the transition to later, as we would also do if we couldn't create the stub due to memory exhaustion. This solves the deadlock situation. > > Eric Caspole who reported the bug has tried this patch, and it solved the problem. I also tried it with the same test myself, with the same successful results. I also ran it through tier1-5 as it is touching inline cache code which can be a bit subtle. This pull request has now been integrated. Changeset: 42d2d6dc Author: Erik ?sterlund URL: https://git.openjdk.java.net/jdk16/commit/42d2d6dc Stats: 34 lines in 4 files changed: 27 ins; 0 del; 7 mod 8259063: Possible deadlock with vtable/itable creation vs concurrent class unloading Reviewed-by: pliden, neliasso ------------- PR: https://git.openjdk.java.net/jdk16/pull/103 From lucy at openjdk.java.net Wed Jan 13 17:02:04 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 13 Jan 2021 17:02:04 GMT Subject: RFR: 8259706: C2 compilation fails with assert(vtable_index == Method::invalid_vtable_index) failed: correct sentinel value In-Reply-To: References: Message-ID: <149_CqNhCs-Z_lF4vH3iGBbyxiG0FfpZUP0uJDays08=.67e8ea00-d896-48e1-ac99-f6e62448e150@github.com> On Wed, 13 Jan 2021 13:07:51 GMT, Tobias Hartmann wrote: > When trying to backport [JDK-8259339](https://bugs.openjdk.java.net/browse/JDK-8259339) to JDK 11u, I've hit an assert on Sparc that triggers because the slow virtual call to `Unsafe.allocateUninitializedArray0` could be optimized to a static call since the `Unsafe` class is final. > > Thanks, > Tobias Tobias, this change looks good to me. Thanks for fixing. Lutz ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2062 From chagedorn at openjdk.java.net Thu Jan 14 07:26:02 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Thu, 14 Jan 2021 07:26:02 GMT Subject: RFR: 8259706: C2 compilation fails with assert(vtable_index == Method::invalid_vtable_index) failed: correct sentinel value In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 13:07:51 GMT, Tobias Hartmann wrote: > When trying to backport [JDK-8259339](https://bugs.openjdk.java.net/browse/JDK-8259339) to JDK 11u, I've hit an assert on Sparc that triggers because the slow virtual call to `Unsafe.allocateUninitializedArray0` could be optimized to a static call since the `Unsafe` class is final. > > Thanks, > Tobias Looks good! ------------- Marked as reviewed by chagedorn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2062 From thartmann at openjdk.java.net Thu Jan 14 07:26:04 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 14 Jan 2021 07:26:04 GMT Subject: Integrated: 8259706: C2 compilation fails with assert(vtable_index == Method::invalid_vtable_index) failed: correct sentinel value In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 13:07:51 GMT, Tobias Hartmann wrote: > When trying to backport [JDK-8259339](https://bugs.openjdk.java.net/browse/JDK-8259339) to JDK 11u, I've hit an assert on Sparc that triggers because the slow virtual call to `Unsafe.allocateUninitializedArray0` could be optimized to a static call since the `Unsafe` class is final. > > Thanks, > Tobias This pull request has now been integrated. Changeset: 8b8b1f9a Author: Tobias Hartmann URL: https://git.openjdk.java.net/jdk/commit/8b8b1f9a Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod 8259706: C2 compilation fails with assert(vtable_index == Method::invalid_vtable_index) failed: correct sentinel value Reviewed-by: lucy, chagedorn ------------- PR: https://git.openjdk.java.net/jdk/pull/2062 From thartmann at openjdk.java.net Thu Jan 14 07:26:04 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 14 Jan 2021 07:26:04 GMT Subject: RFR: 8259706: C2 compilation fails with assert(vtable_index == Method::invalid_vtable_index) failed: correct sentinel value In-Reply-To: <149_CqNhCs-Z_lF4vH3iGBbyxiG0FfpZUP0uJDays08=.67e8ea00-d896-48e1-ac99-f6e62448e150@github.com> References: <149_CqNhCs-Z_lF4vH3iGBbyxiG0FfpZUP0uJDays08=.67e8ea00-d896-48e1-ac99-f6e62448e150@github.com> Message-ID: <6IdwTlTpInC19PKu6tB8JOGN3FWffj__nvtowEgM56Y=.1f297c12-29c5-42c4-8632-d760e3d6161f@github.com> On Wed, 13 Jan 2021 16:59:33 GMT, Lutz Schmidt wrote: >> When trying to backport [JDK-8259339](https://bugs.openjdk.java.net/browse/JDK-8259339) to JDK 11u, I've hit an assert on Sparc that triggers because the slow virtual call to `Unsafe.allocateUninitializedArray0` could be optimized to a static call since the `Unsafe` class is final. >> >> Thanks, >> Tobias > > Tobias, > this change looks good to me. Thanks for fixing. > Lutz @RealLucy, @chhagedorn, thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/2062 From stuefe at openjdk.java.net Thu Jan 14 07:39:09 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 14 Jan 2021 07:39:09 GMT Subject: RFR: JDK-8259710: Inlining trace leaks memory Message-ID: We see C-heap leaking, originating in C2: 1434777 [0x00007f58214af461] stringStream::stringStream(unsigned long)+0x55 1434778 [0x00007f5820c6db3e] Compile::PrintInliningBuffer::PrintInliningBuffer()+0x6c 1434779 [0x00007f5820c724f1] GrowableArrayWithAllocator >::grow(int)+0x163 1434780 [0x00007f5820c7160e] GrowableArrayWithAllocator >::insert_before(int, Compile::PrintInliningBuffer const&)+0x82 1434781 [0x00007f5820c6aaf2] Compile::print_inlining_push()+0x70 accumulating over the course of days to some hundred MB at a customer site where inline tracing was active. Analysis: To build up a comprehensive inlining trace, c2 keeps trace snippets in an internal list and assembles them at print time. These are stringStream's, contained in PrintInliningBuffer: GrowableArray* _print_inlining_list; ... class PrintInliningBuffer : public ResourceObj { private: CallGenerator* _cg; stringStream* _ss; public: PrintInliningBuffer() : _cg(NULL) { _ss = new stringStream(); } void freeStream() { _ss->~stringStream(); _ss = NULL; } ... }; With [JDK-8224193](https://bugs.openjdk.java.net/browse/JDK-8224193), stringStream was changed to use C-heap instead of ResourceArea for its internal buffer. This means one cannot just omit stringStream destruction anymore - even where stringStream objects themselves live in RA, their internal buffers don't, they live in C-Heap. To clean up properly, ~stringStream() must be called. Those `PrintInliningBuffer` objects are kept _by value_ in a GrowableArray `Compile::_print_inlining_list`. Normally, if an object is kept by value, it needs to implement correct copy- and destruction-semantics. PrintInliningBuffer does not do that and instead relies on manual cleanup (`PrintInliningBuffer::freeStream()`) - I assume the authors did not want to deal with reference counting the contained stringStream on copying. That however is a problem because GrowableArray creates internally temporary objects of the item type to pre-populate its array - its whole capacity - when it grows: template void GrowableArrayWithAllocator::grow(int j) { ... for ( ; i < this->_len; i++) ::new ((void*)&newData[i]) E(this->_data[i]); for ( ; i < this->_max; i++) ::new ((void*)&newData[i]) E(); <<<<<<< for (i = 0; i < old_max; i++) this->_data[i].~E(); ... } this it does for the whole new capacity, which means more objects get created than have been added; if the caller does not fill the GrowableArray up to its capacity, it never knows about the excess objects created. This is normally not a problem since all these objects are destructed by GrowableArray in `void GrowableArrayWithAllocator::clear_and_deallocate()`. But since PrintInliningBuffer does not implement a destructor, this has no effect. PrintInliningBuffer instead relies on manual cleanup of the stringStreams: at the end of the compile phase, it calls `PrintInliningBuffer::freeStream()` on all buffers it thinks are contained in the array: assert(_print_inlining_list != NULL, "process_print_inlining should be called only once."); for (int i = 0; i < _print_inlining_list->length(); i++) { ss.print("%s", _print_inlining_list->adr_at(i)->ss()->as_string()); _print_inlining_list->at(i).freeStream(); } but this of course leaves the excess objects untouched (objects whose index is array length >= index >= array capacity). ----------- There are several ways to fix this: 1) implement correct destructor- and copy semantics for PrintInliningBuffer. This would work but is not optimal since we would still pay for creation of unnecessary PrintInliningBuffer objects when the array is prepopulated on grow() 2) delay construction of `PrintInliningBuffer::_ss` until the stream is actually used for writing into. This would would mean we have to check the stringStream for NULL before using it. 3) Just let the PrintInliningBuffer live in C-heap instead of the RA. Its only a small shell anywhere now that the stringStream buffer lives in C-heap. Instead, let PrintInliningBuffer contain the stringStream as a member, allocate PrintInliningBuffer from C-heap, and change the list to contain pointers to PrintInliningBuffer, not the object itself. This removes all that unnecessary copying, removes creation of temporary objects, and simplifies the code. Having to free those objects is no big deal since we free the stringStream objects manually anyway. I went with (3). I also decreased the default stringStream buffer size for this scenario since when testing I found out that many trace snippets are below 128 bytes. Tests: - github actions - Nightlies at SAP - I manually tested the patch and compared the NMT output of a tracing scenario to verify that the leak went away and no other numbers changed Thanks, Thomas ------------- Commit messages: - Decrease default buffer size for ilt stringStream - Initial Changes: https://git.openjdk.java.net/jdk/pull/2063/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2063&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259710 Stats: 24 lines in 2 files changed: 3 ins; 7 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/2063.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2063/head:pull/2063 PR: https://git.openjdk.java.net/jdk/pull/2063 From chagedorn at openjdk.java.net Thu Jan 14 08:19:09 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Thu, 14 Jan 2021 08:19:09 GMT Subject: RFR: 8257498: Remove useless skeleton predicates Message-ID: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com> This enhancement removes useless skeleton predicates in the same way as we already remove normal useless predicates in `PhaseIdealLoop::eliminate_useless_predicates()`. Thanks, Christian ------------- Commit messages: - 8257498: Remove useless skeleton predicates Changes: https://git.openjdk.java.net/jdk/pull/2075/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2075&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257498 Stats: 92 lines in 5 files changed: 58 ins; 16 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/2075.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2075/head:pull/2075 PR: https://git.openjdk.java.net/jdk/pull/2075 From roland at openjdk.java.net Thu Jan 14 08:25:18 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Thu, 14 Jan 2021 08:25:18 GMT Subject: [jdk16] RFR: 8259641: C2: assert(early->dominates(LCA)) failed: early is high enough Message-ID: <1aDWWln8xu9qmWLSgnGJOYlllvN_QfzJsRtW5qKFjbA=.a46186b0-14ff-4306-a44c-34b943a082da@github.com> For the fix of 8258393 that causes this regression, I wrote that the goal was: "I propose to be less conservative in anti-dependence analysis for Phis. For a Phi, when computing the LCA, I think it's sufficient to only consider region's inputs that we actually reach by following the memory edges and that's what I propose here." But that's not what the logic I added does. It checks whether a Phi input should be taken into account by checking whether it's in the worklist but the worklist doesn't include mem, the memory state from which we started. ------------- Commit messages: - whitespaces - test & fix Changes: https://git.openjdk.java.net/jdk16/pull/121/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=121&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259641 Stats: 96 lines in 2 files changed: 95 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/121.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/121/head:pull/121 PR: https://git.openjdk.java.net/jdk16/pull/121 From chagedorn at openjdk.java.net Thu Jan 14 09:42:05 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Thu, 14 Jan 2021 09:42:05 GMT Subject: [jdk16] RFR: 8259641: C2: assert(early->dominates(LCA)) failed: early is high enough In-Reply-To: <1aDWWln8xu9qmWLSgnGJOYlllvN_QfzJsRtW5qKFjbA=.a46186b0-14ff-4306-a44c-34b943a082da@github.com> References: <1aDWWln8xu9qmWLSgnGJOYlllvN_QfzJsRtW5qKFjbA=.a46186b0-14ff-4306-a44c-34b943a082da@github.com> Message-ID: On Thu, 14 Jan 2021 08:05:25 GMT, Roland Westrelin wrote: > For the fix of 8258393 that causes this regression, I wrote that the > goal was: > > "I propose to be less conservative in anti-dependence analysis for > Phis. For a Phi, when computing the LCA, I think it's sufficient to > only consider region's inputs that we actually reach by following the > memory edges and that's what I propose here." > > But that's not what the logic I added does. It checks whether a Phi > input should be taken into account by checking whether it's in the > worklist but the worklist doesn't include mem, the memory state from > which we started. That looks good to me! test/hotspot/jtreg/compiler/loopopts/TestBrokenAntiDependenceWithPhi.java line 30: > 28: * > 29: * @run main/othervm -Xcomp -XX:CompileOnly=TestBrokenAntiDependenceWithPhi TestBrokenAntiDependenceWithPhi > 30: * Empty line can be removed test/hotspot/jtreg/compiler/loopopts/TestBrokenAntiDependenceWithPhi.java line 32: > 30: * > 31: */ > 32: You could move the test into the `compiler.loopopts` package. ------------- Marked as reviewed by chagedorn (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/121 From jbhateja at openjdk.java.net Thu Jan 14 11:46:10 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 14 Jan 2021 11:46:10 GMT Subject: RFR: 8259773: Incorrect encoding of AVX-512 kmovq instruction Message-ID: While working on a prototype for supporting opmask register allocation encountered this bug. Encoding for following instruction[1] which spills the value of an opmask register into memory should have 0x91 as the opcode instead of 0x90. KMOVQ Address , K1. [1] https://www.felixcloutier.com/x86/kmovw:kmovb:kmovq:kmovd ------------- Commit messages: - 8259773: Incorrect encoding of AVX-512 kmovq instruction Changes: https://git.openjdk.java.net/jdk/pull/2078/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2078&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259773 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2078.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2078/head:pull/2078 PR: https://git.openjdk.java.net/jdk/pull/2078 From vlivanov at openjdk.java.net Thu Jan 14 12:01:03 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 14 Jan 2021 12:01:03 GMT Subject: RFR: 8259773: Incorrect encoding of AVX-512 kmovq instruction In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 11:41:35 GMT, Jatin Bhateja wrote: > While working on a prototype for supporting opmask register allocation encountered this bug. > > Encoding for following instruction[1] which spills the value of an opmask register into memory should have 0x91 as the opcode instead of 0x90. > > KMOVQ Address , K1. > > [1] https://www.felixcloutier.com/x86/kmovw:kmovb:kmovq:kmovd Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2078 From jiefu at openjdk.java.net Thu Jan 14 12:37:11 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 14 Jan 2021 12:37:11 GMT Subject: [jdk16] RFR: 8259775: [Vector API] Incorrect code-gen for VectorReinterpret operation Message-ID: Hi all, The code-gen for VectorReinterpret may be wrong on x86. Let's see the opto-assembly for the reproducer in the JBS, which was actually based on @XiaohongGong 's example in JDK-8259353 and many thanks to her. 066 B7: # out( N1 ) <- in( B6 ) Freq: 0.999994 066 vector_reinterpret_expand XMM0,XMM0 ! 066 store_vector [R12 + R11 << 3 + #16] (compressed oop addressing),XMM0 Please note that the dst and src [1] share the same XMM0 register and movdqu [2] should be generated for this case. But when dst == src, movdqu actually generates nothing [3], which leads to incorrect result; For this case, movdqu should not be empty since the upper bits of dst should be zeroed. The similar error also exists for vmovdqu [4]. I think we should also change movflt [5] to movss but I just can't understand why we have 4-byte vectors. Isn't the shortest vectors 8-byte on x86? Thanks. Best regards, Jie [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3354 [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3364 [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2490 [4] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2515 [5] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3379 ------------- Commit messages: - 8259775: [Vector API] Incorrect code-gen for VectorReinterpret operation Changes: https://git.openjdk.java.net/jdk16/pull/122/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=122&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259775 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/122.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/122/head:pull/122 PR: https://git.openjdk.java.net/jdk16/pull/122 From jbhateja at openjdk.java.net Thu Jan 14 13:19:07 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 14 Jan 2021 13:19:07 GMT Subject: RFR: 8259777: Incorrect predication condition generated by ADLC Message-ID: Please consider following instruction selection pattern:- ` match(Set dst (VectorBlend (Binary src1 (AddVB src1 src2)) mask)); ` Currently, ADLC emits following predication check for src1 in matcher DFA. ` /*src1*/(_kids[0]->_kids[0]->_leaf == _kids[1]->_kids[0]->_leaf) ` src1 appears twice in the State tree corresponding to this pattern, first as the leaf of left child state of Binary node which is left child state of VectorBlend and secondly as the leaf of left child of AddVB which is the right child state of Binary node. Thus following is the correct predication check to test both the occurrences of src1. ` /*src1*/(_kids[0]->_kids[0]->_leaf == _kids[0]->_kids[1]->_kids[0]->_leaf) ` This patch does a minor re-organizes the predication generation algorithm to fix this issue. Validated that there is no change in generated DFA for current X86 AD files with and without this patch since such instruction patterns do not exist in AD files currently. ------------- Commit messages: - 8259777: Incorrect predication condition generated by ADLC Changes: https://git.openjdk.java.net/jdk/pull/2080/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2080&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259777 Stats: 26 lines in 2 files changed: 15 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/2080.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2080/head:pull/2080 PR: https://git.openjdk.java.net/jdk/pull/2080 From jbhateja at openjdk.java.net Thu Jan 14 13:23:03 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 14 Jan 2021 13:23:03 GMT Subject: RFR: 8259773: Incorrect encoding of AVX-512 kmovq instruction In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 11:58:21 GMT, Vladimir Ivanov wrote: > Looks good. Thanks Vladimir. ------------- PR: https://git.openjdk.java.net/jdk/pull/2078 From jbhateja at openjdk.java.net Thu Jan 14 13:23:05 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 14 Jan 2021 13:23:05 GMT Subject: Integrated: 8259773: Incorrect encoding of AVX-512 kmovq instruction In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 11:41:35 GMT, Jatin Bhateja wrote: > While working on a prototype for supporting opmask register allocation encountered this bug. > > Encoding for following instruction[1] which spills the value of an opmask register into memory should have 0x91 as the opcode instead of 0x90. > > KMOVQ Address , K1. > > [1] https://www.felixcloutier.com/x86/kmovw:kmovb:kmovq:kmovd This pull request has now been integrated. Changeset: ff3e6e46 Author: Jatin Bhateja URL: https://git.openjdk.java.net/jdk/commit/ff3e6e46 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8259773: Incorrect encoding of AVX-512 kmovq instruction Reviewed-by: vlivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/2078 From vlivanov at openjdk.java.net Thu Jan 14 13:44:04 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 14 Jan 2021 13:44:04 GMT Subject: RFR: 8259777: Incorrect predication condition generated by ADLC In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 13:13:21 GMT, Jatin Bhateja wrote: > Please consider following instruction selection pattern:- > > ` match(Set dst (VectorBlend (Binary src1 (AddVB src1 src2)) mask)); > ` > > Currently, ADLC emits following predication check for src1 in matcher DFA. > > ` /*src1*/(_kids[0]->_kids[0]->_leaf == _kids[1]->_kids[0]->_leaf) > ` > > src1 appears twice in the State tree corresponding to this pattern, first as the leaf of left child state of Binary node which is > left child state of VectorBlend and secondly as the leaf of left child of AddVB which is the right child state of Binary node. > Thus following is the correct predication check to test both the occurrences of src1. > > ` /*src1*/(_kids[0]->_kids[0]->_leaf == _kids[0]->_kids[1]->_kids[0]->_leaf) > ` > > This patch does a minor re-organizes the predication generation algorithm to fix this issue. > > Validated that there is no change in generated DFA for current X86 AD files with and without this patch since such instruction patterns do not exist in AD files currently. Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2080 From thartmann at openjdk.java.net Thu Jan 14 15:40:02 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 14 Jan 2021 15:40:02 GMT Subject: [jdk16] RFR: 8259641: C2: assert(early->dominates(LCA)) failed: early is high enough In-Reply-To: <1aDWWln8xu9qmWLSgnGJOYlllvN_QfzJsRtW5qKFjbA=.a46186b0-14ff-4306-a44c-34b943a082da@github.com> References: <1aDWWln8xu9qmWLSgnGJOYlllvN_QfzJsRtW5qKFjbA=.a46186b0-14ff-4306-a44c-34b943a082da@github.com> Message-ID: <1srxfxe1v2UNmsrwI4vRevgVVPSIS62G2a0nzamfaWQ=.15d2f99f-2b6a-417c-95a7-61372fd69b6c@github.com> On Thu, 14 Jan 2021 08:05:25 GMT, Roland Westrelin wrote: > For the fix of 8258393 that causes this regression, I wrote that the > goal was: > > "I propose to be less conservative in anti-dependence analysis for > Phis. For a Phi, when computing the LCA, I think it's sufficient to > only consider region's inputs that we actually reach by following the > memory edges and that's what I propose here." > > But that's not what the logic I added does. It checks whether a Phi > input should be taken into account by checking whether it's in the > worklist but the worklist doesn't include mem, the memory state from > which we started. Looks good to me. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/121 From iignatyev at openjdk.java.net Thu Jan 14 17:15:16 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 14 Jan 2021 17:15:16 GMT Subject: [jdk16] RFR: 8259757: add a regression test for 8259353 and 8259601 Message-ID: Hi all, could you please review this small test-only patch which adds a regression test for [8259353](https://bugs.openjdk.java.net/browse/JDK-8259353) and [8259601](https://bugs.openjdk.java.net/browse/JDK-8259353)? testing: - [x] `test/hotspot/jtreg/compiler/vectorapi/Test8259353.java` against jdk-16+26 (which doesn't have fixes) : failed, as expected - [x] `test/hotspot/jtreg/compiler/vectorapi/Test8259353.java` multiple times against jdk-16+32 : passed Thanks, -- Igor ------------- Commit messages: - 8259757: add a regression test for 8259353 and 8259601 Changes: https://git.openjdk.java.net/jdk16/pull/120/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=120&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259757 Stats: 82 lines in 1 file changed: 82 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/120.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/120/head:pull/120 PR: https://git.openjdk.java.net/jdk16/pull/120 From vlivanov at openjdk.java.net Thu Jan 14 17:22:11 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 14 Jan 2021 17:22:11 GMT Subject: [jdk16] Integrated: 8255120: C2: assert(outer->outcnt() >= phis + 2 && outer->outcnt() <= phis + 2 + stores + 1) failed: only phis In-Reply-To: <2PEWRbpWVrdRx47oZPJQVs082bVynDioRaD2GjZExqs=.3561364b-f502-416d-a0ac-1a6bc1087627@github.com> References: <2PEWRbpWVrdRx47oZPJQVs082bVynDioRaD2GjZExqs=.3561364b-f502-416d-a0ac-1a6bc1087627@github.com> Message-ID: On Tue, 12 Jan 2021 22:16:54 GMT, Vladimir Ivanov wrote: > JDK-8255000 made post-loopopts IGVN processing predictable, but also reordered it with macro node expansion. > > It turned out that macro node expansion is sensitive to narrower types post-loopopts IGVN generates and it either triggers the aforementioned assert or produces less efficient code (some runtime checks aren't eliminated anymore and it adds up some overhead, see JDK-8255705 for details). > > I'll file a separate RFE to make macro node expansion more robust (and relax the problematic assert), but for now (jdk16) I propose to restore the original order of transformations. > > Testing: > - [x] failing test > - [x] hs-tier1 - hs-tier6 > - [x] SPECjvm2008 MPEG > - [x] gc/shenandoah/ This pull request has now been integrated. Changeset: 0148adf2 Author: Vladimir Ivanov URL: https://git.openjdk.java.net/jdk16/commit/0148adf2 Stats: 40 lines in 5 files changed: 14 ins; 15 del; 11 mod 8255120: C2: assert(outer->outcnt() >= phis + 2 && outer->outcnt() <= phis + 2 + stores + 1) failed: only phis Reviewed-by: thartmann ------------- PR: https://git.openjdk.java.net/jdk16/pull/113 From jbhateja at openjdk.java.net Thu Jan 14 17:31:04 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 14 Jan 2021 17:31:04 GMT Subject: RFR: 8259777: Incorrect predication condition generated by ADLC In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 13:41:45 GMT, Vladimir Ivanov wrote: > Looks good. Hi Vladimir, Please suggest if its ok to push this patch with one reviewer approval. ------------- PR: https://git.openjdk.java.net/jdk/pull/2080 From vladimir.x.ivanov at oracle.com Thu Jan 14 17:34:59 2021 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 14 Jan 2021 20:34:59 +0300 Subject: RFR: 8259777: Incorrect predication condition generated by ADLC In-Reply-To: References: Message-ID: The guideline is to wait around a day to give people a chance speak up. Otherwise, I don't see a problem having a single (R)eview here. Best regards, Vladimir Ivanov On 14.01.2021 20:31, Jatin Bhateja wrote: > On Thu, 14 Jan 2021 13:41:45 GMT, Vladimir Ivanov wrote: > >> Looks good. > > Hi Vladimir, Please suggest if its ok to push this patch with one reviewer approval. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2080 > From iignatyev at openjdk.java.net Thu Jan 14 19:27:28 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 14 Jan 2021 19:27:28 GMT Subject: [jdk16] RFR: 8259757: add a regression test for 8259353 and 8259601 [v2] In-Reply-To: References: Message-ID: > Hi all, > > could you please review this small test-only patch which adds a regression test for [8259353](https://bugs.openjdk.java.net/browse/JDK-8259353) and [8259601](https://bugs.openjdk.java.net/browse/JDK-8259353)? > > testing: > - [x] `test/hotspot/jtreg/compiler/vectorapi/Test8259353.java` against jdk-16+26 (which doesn't have fixes) : failed, as expected > - [x] `test/hotspot/jtreg/compiler/vectorapi/Test8259353.java` multiple times against jdk-16+32 : passed > > Thanks, > -- Igor Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision: fix copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/120/files - new: https://git.openjdk.java.net/jdk16/pull/120/files/8b78323f..3d7e2e46 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=120&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=120&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/120.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/120/head:pull/120 PR: https://git.openjdk.java.net/jdk16/pull/120 From xliu at openjdk.java.net Fri Jan 15 02:13:19 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 15 Jan 2021 02:13:19 GMT Subject: RFR: 8258961: move some fields of SafePointNode from public to protected [v5] In-Reply-To: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> Message-ID: > SafePointNode::jvms() declares virtual but has never been overridden. It seems unnecessary. > The member variable _jvms declares 'JVMState* const', but set_jvms() updates its value anyway. > Geting rid of the const qualifier and hides if out using protected. Xin Liu has updated the pull request incrementally with one additional commit since the last revision: 8258961: move some fields of SafePointNode from public to protected revert code change to devirtualize Node::jvms(). There are 3 nodes override jvms() -- SafePointNode, MachSafePointNode and MachHalt. It does not make sense to devirtualize it because we have to do non-trivial dispatch based on types in Node::jvms(). It is not worth it. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1899/files - new: https://git.openjdk.java.net/jdk/pull/1899/files/44d7b8e7..cdac2d76 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1899&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1899&range=03-04 Stats: 15 lines in 3 files changed: 0 ins; 9 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1899.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1899/head:pull/1899 PR: https://git.openjdk.java.net/jdk/pull/1899 From roland at openjdk.java.net Fri Jan 15 08:24:02 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Fri, 15 Jan 2021 08:24:02 GMT Subject: [jdk16] RFR: 8259641: C2: assert(early->dominates(LCA)) failed: early is high enough In-Reply-To: <1srxfxe1v2UNmsrwI4vRevgVVPSIS62G2a0nzamfaWQ=.15d2f99f-2b6a-417c-95a7-61372fd69b6c@github.com> References: <1aDWWln8xu9qmWLSgnGJOYlllvN_QfzJsRtW5qKFjbA=.a46186b0-14ff-4306-a44c-34b943a082da@github.com> <1srxfxe1v2UNmsrwI4vRevgVVPSIS62G2a0nzamfaWQ=.15d2f99f-2b6a-417c-95a7-61372fd69b6c@github.com> Message-ID: On Thu, 14 Jan 2021 15:37:44 GMT, Tobias Hartmann wrote: >> For the fix of 8258393 that causes this regression, I wrote that the >> goal was: >> >> "I propose to be less conservative in anti-dependence analysis for >> Phis. For a Phi, when computing the LCA, I think it's sufficient to >> only consider region's inputs that we actually reach by following the >> memory edges and that's what I propose here." >> >> But that's not what the logic I added does. It checks whether a Phi >> input should be taken into account by checking whether it's in the >> worklist but the worklist doesn't include mem, the memory state from >> which we started. > > Looks good to me. Thanks for the reviews, Christian & Tobias. ------------- PR: https://git.openjdk.java.net/jdk16/pull/121 From chagedorn at openjdk.java.net Fri Jan 15 08:24:09 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Fri, 15 Jan 2021 08:24:09 GMT Subject: [jdk16] RFR: 8259641: C2: assert(early->dominates(LCA)) failed: early is high enough In-Reply-To: References: <1aDWWln8xu9qmWLSgnGJOYlllvN_QfzJsRtW5qKFjbA=.a46186b0-14ff-4306-a44c-34b943a082da@github.com> Message-ID: <-aWQa-FWJuHcCk3h4xmp4jRxJITSa5JU3uxDzVBTFgI=.fca24c7b-bfb0-4133-be17-0c007f9c8834@github.com> On Fri, 15 Jan 2021 08:18:07 GMT, Roland Westrelin wrote: >> test/hotspot/jtreg/compiler/loopopts/TestBrokenAntiDependenceWithPhi.java line 32: >> >>> 30: * >>> 31: */ >>> 32: >> >> You could move the test into the `compiler.loopopts` package. > > Sure but I usually don't (so they are a several tests without it). Why is it important? I've just seen that the majority of the compiler tests are in a package. But I'm not sure if it required. Probably not. So I'm fine with how it is now. >> test/hotspot/jtreg/compiler/loopopts/TestBrokenAntiDependenceWithPhi.java line 30: >> >>> 28: * >>> 29: * @run main/othervm -Xcomp -XX:CompileOnly=TestBrokenAntiDependenceWithPhi TestBrokenAntiDependenceWithPhi >>> 30: * >> >> Empty line can be removed > > Which of the lines do you suggest removing? One that starts with a *? I've meant the very the last one but it's a minor detail. No need to update it just for that. ------------- PR: https://git.openjdk.java.net/jdk16/pull/121 From roland at openjdk.java.net Fri Jan 15 08:24:06 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Fri, 15 Jan 2021 08:24:06 GMT Subject: [jdk16] RFR: 8259641: C2: assert(early->dominates(LCA)) failed: early is high enough In-Reply-To: References: <1aDWWln8xu9qmWLSgnGJOYlllvN_QfzJsRtW5qKFjbA=.a46186b0-14ff-4306-a44c-34b943a082da@github.com> Message-ID: On Thu, 14 Jan 2021 09:37:36 GMT, Christian Hagedorn wrote: >> For the fix of 8258393 that causes this regression, I wrote that the >> goal was: >> >> "I propose to be less conservative in anti-dependence analysis for >> Phis. For a Phi, when computing the LCA, I think it's sufficient to >> only consider region's inputs that we actually reach by following the >> memory edges and that's what I propose here." >> >> But that's not what the logic I added does. It checks whether a Phi >> input should be taken into account by checking whether it's in the >> worklist but the worklist doesn't include mem, the memory state from >> which we started. > > test/hotspot/jtreg/compiler/loopopts/TestBrokenAntiDependenceWithPhi.java line 30: > >> 28: * >> 29: * @run main/othervm -Xcomp -XX:CompileOnly=TestBrokenAntiDependenceWithPhi TestBrokenAntiDependenceWithPhi >> 30: * > > Empty line can be removed Which of the lines do you suggest removing? One that starts with a *? > test/hotspot/jtreg/compiler/loopopts/TestBrokenAntiDependenceWithPhi.java line 32: > >> 30: * >> 31: */ >> 32: > > You could move the test into the `compiler.loopopts` package. Sure but I usually don't (so they are a several tests without it). Why is it important? ------------- PR: https://git.openjdk.java.net/jdk16/pull/121 From ogatak at openjdk.java.net Fri Jan 15 08:40:10 2021 From: ogatak at openjdk.java.net (Kazunori Ogata) Date: Fri, 15 Jan 2021 08:40:10 GMT Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format added in POWER10 In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 08:09:56 GMT, Kazunori Ogata wrote: > The POWER10 processor, which implements Power ISA 3.1 [1], supports new instruction formats where an instruction takes two 32bit words. The first word is called prefix, and the instructions with prefix are called prefixed instructions. With more bits in opcode and operand fields, POWER10 supports larger immediate value in an operand, as well as many new instructions. > > This is the first changes to handle prefixed instructions, and this adds support of prefixed addi (= paddi) instruction as an example of prefix usage. paddi accepts 34bit immediate value, while original addi accepts 16bit value. > > [1] https://ibm.ent.box.com/s/hhjfw0x0lrbtyzmiaffnbxh2fuo0fog0 I ran jtreg test on POWER10 box by using "make test-tier1" and verified no additional fails. ------------- PR: https://git.openjdk.java.net/jdk/pull/2095 From ogatak at openjdk.java.net Fri Jan 15 08:40:10 2021 From: ogatak at openjdk.java.net (Kazunori Ogata) Date: Fri, 15 Jan 2021 08:40:10 GMT Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format added in POWER10 Message-ID: The POWER10 processor, which implements Power ISA 3.1 [1], supports new instruction formats where an instruction takes two 32bit words. The first word is called prefix, and the instructions with prefix are called prefixed instructions. With more bits in opcode and operand fields, POWER10 supports larger immediate value in an operand, as well as many new instructions. This is the first changes to handle prefixed instructions, and this adds support of prefixed addi (= paddi) instruction as an example of prefix usage. paddi accepts 34bit immediate value, while original addi accepts 16bit value. [1] https://ibm.ent.box.com/s/hhjfw0x0lrbtyzmiaffnbxh2fuo0fog0 ------------- Commit messages: - Expand tab to space - Revert unnecessary changes - Merge branch 'master' of github.com:openjdk/jdk into paddi - Support the prefixed instruction format added in POWER 10 Changes: https://git.openjdk.java.net/jdk/pull/2095/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2095&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259822 Stats: 310 lines in 4 files changed: 303 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/2095.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2095/head:pull/2095 PR: https://git.openjdk.java.net/jdk/pull/2095 From jiefu at openjdk.java.net Fri Jan 15 13:45:10 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 15 Jan 2021 13:45:10 GMT Subject: RFR: 8259840: [Vector API] Fix an assert in Assembler::vpmovzxbw if UseAVX=0 Message-ID: Hi all, This assert was observed when running jdk/incubator/vector/ShortMaxVectorTests.java with -XX:UseAVX=0. # # Internal Error (/home/jvm/jiefu/docker/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:4263), pid=19129, tid=19145 # Error: assert(vector_len == AVX_128bit? VM_Version::supports_avx() : vector_len == AVX_256bit? VM_Version::supports_avx2() : vector_len == AVX_512bit? VM_Version::supports_avx512bw() : 0) failed # Stack: [0x00007f4c095fa000,0x00007f4c096fb000], sp=0x00007f4c096f5d40, free space=1007k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x5e0ab6] Assembler::vpmovzxbw(XMMRegisterImpl*, XMMRegisterImpl*, int)+0x136 V [libjvm.so+0x41d0dd] loadShuffleSNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0x3ad V [libjvm.so+0x13ea963] PhaseOutput::scratch_emit_size(Node const*)+0x423 V [libjvm.so+0x13e1b44] PhaseOutput::shorten_branches(unsigned int*)+0x2a4 V [libjvm.so+0x13f25aa] PhaseOutput::Output()+0xb8a V [libjvm.so+0x96a003] Compile::Code_Gen()+0x443 V [libjvm.so+0x97303a] Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, DirectiveSet*)+0x178a The reason is that loadShuffleS should not use vpmovzxbw when -XX:UseAVX=0. The fix splits loadShuffleS's AVX code-gen logic into loadShuffleS_avx. Testing: - jdk/incubator/vector on an AVX512 machine with UseAVX=3/2/1/0, no regression Thanks. Best regards, Jie ------------- Commit messages: - 8259840: [Vector API] Fix an assert in Assembler::vpmovzxbw if UseAVX=0 Changes: https://git.openjdk.java.net/jdk/pull/2100/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2100&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259840 Stats: 52 lines in 1 file changed: 26 ins; 16 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/2100.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2100/head:pull/2100 PR: https://git.openjdk.java.net/jdk/pull/2100 From jbhateja at openjdk.java.net Fri Jan 15 15:06:08 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Fri, 15 Jan 2021 15:06:08 GMT Subject: Integrated: 8259777: Incorrect predication condition generated by ADLC In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 13:13:21 GMT, Jatin Bhateja wrote: > Please consider following instruction selection pattern:- > > ` match(Set dst (VectorBlend (Binary src1 (AddVB src1 src2)) mask)); > ` > > Currently, ADLC emits following predication check for src1 in matcher DFA. > > ` /*src1*/(_kids[0]->_kids[0]->_leaf == _kids[1]->_kids[0]->_leaf) > ` > > src1 appears twice in the State tree corresponding to this pattern, first as the leaf of left child state of Binary node which is > left child state of VectorBlend and secondly as the leaf of left child of AddVB which is the right child state of Binary node. > Thus following is the correct predication check to test both the occurrences of src1. > > ` /*src1*/(_kids[0]->_kids[0]->_leaf == _kids[0]->_kids[1]->_kids[0]->_leaf) > ` > > This patch does a minor re-organizes the predication generation algorithm to fix this issue. > > Validated that there is no change in generated DFA for current X86 AD files with and without this patch since such instruction patterns do not exist in AD files currently. This pull request has now been integrated. Changeset: bcf20a0d Author: Jatin Bhateja URL: https://git.openjdk.java.net/jdk/commit/bcf20a0d Stats: 26 lines in 2 files changed: 15 ins; 0 del; 11 mod 8259777: Incorrect predication condition generated by ADLC Reviewed-by: vlivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/2080 From jiefu at openjdk.java.net Fri Jan 15 15:05:26 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 15 Jan 2021 15:05:26 GMT Subject: RFR: 8259840: [Vector API] Fix an assert in Assembler::vpmovzxbw if UseAVX=0 [v2] In-Reply-To: References: Message-ID: <6IkOYV5IlCAtm_M4HNsJpRdwP9y1G6Ff5TL7_qpXkPQ=.89fe882b-3747-4b12-ae47-2e126df93c03@github.com> > Hi all, > > This assert was observed when running jdk/incubator/vector/ShortMaxVectorTests.java with -XX:UseAVX=0. > > # > # Internal Error (/home/jvm/jiefu/docker/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:4263), pid=19129, tid=19145 > # Error: assert(vector_len == AVX_128bit? VM_Version::supports_avx() : vector_len == AVX_256bit? VM_Version::supports_avx2() : vector_len == AVX_512bit? VM_Version::supports_avx512bw() : 0) failed > # > > Stack: [0x00007f4c095fa000,0x00007f4c096fb000], sp=0x00007f4c096f5d40, free space=1007k > Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x5e0ab6] Assembler::vpmovzxbw(XMMRegisterImpl*, XMMRegisterImpl*, int)+0x136 > V [libjvm.so+0x41d0dd] loadShuffleSNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0x3ad > V [libjvm.so+0x13ea963] PhaseOutput::scratch_emit_size(Node const*)+0x423 > V [libjvm.so+0x13e1b44] PhaseOutput::shorten_branches(unsigned int*)+0x2a4 > V [libjvm.so+0x13f25aa] PhaseOutput::Output()+0xb8a > V [libjvm.so+0x96a003] Compile::Code_Gen()+0x443 > V [libjvm.so+0x97303a] Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, DirectiveSet*)+0x178a > > The reason is that loadShuffleS should not use vpmovzxbw when -XX:UseAVX=0. > The fix splits loadShuffleS's AVX code-gen logic into loadShuffleS_avx. > > Testing: > - jdk/incubator/vector on an AVX512 machine with UseAVX=3/2/1/0, no regression > > Thanks. > Best regards, > Jie Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Support vlen=8 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2100/files - new: https://git.openjdk.java.net/jdk/pull/2100/files/de6c2382..53945b76 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2100&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2100&range=00-01 Stats: 7 lines in 1 file changed: 1 ins; 3 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2100.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2100/head:pull/2100 PR: https://git.openjdk.java.net/jdk/pull/2100 From dcubed at openjdk.java.net Fri Jan 15 15:56:18 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 15 Jan 2021 15:56:18 GMT Subject: RFR: 8259846: [BACKOUT] JDK-8259278 Optimize Vector API slice and unslice operations Message-ID: This reverts commit a6b2162f5400b4596afa5b88219c9cb55dcdb729. ------------- Commit messages: - 8259846: [BACKOUT] JDK-8259278 Optimize Vector API slice and unslice operations Changes: https://git.openjdk.java.net/jdk/pull/2103/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2103&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259846 Stats: 983 lines in 45 files changed: 523 ins; 266 del; 194 mod Patch: https://git.openjdk.java.net/jdk/pull/2103.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2103/head:pull/2103 PR: https://git.openjdk.java.net/jdk/pull/2103 From vlivanov at openjdk.java.net Fri Jan 15 15:56:18 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 15 Jan 2021 15:56:18 GMT Subject: RFR: 8259846: [BACKOUT] JDK-8259278 Optimize Vector API slice and unslice operations In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 15:46:09 GMT, Daniel D. Daugherty wrote: > This reverts commit a6b2162f5400b4596afa5b88219c9cb55dcdb729. Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2103 From roland at openjdk.java.net Fri Jan 15 15:57:04 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Fri, 15 Jan 2021 15:57:04 GMT Subject: RFR: 8257498: Remove useless skeleton predicates In-Reply-To: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com> References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com> Message-ID: On Thu, 14 Jan 2021 08:14:18 GMT, Christian Hagedorn wrote: > This enhancement removes useless skeleton predicates in the same way as we already remove normal useless predicates in `PhaseIdealLoop::eliminate_useless_predicates()`. > > Thanks, > Christian Changes requested by roland (Reviewer). src/hotspot/share/opto/loopnode.cpp line 3560: > 3558: > 3559: if (UseLoopPredicate) { > 3560: predicate = find_predicate_insertion_point(entry, Deoptimization::Reason_predicate); Don't we need to do this for Deoptimization::Reason_profile_predicate as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/2075 From dcubed at openjdk.java.net Fri Jan 15 15:59:02 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 15 Jan 2021 15:59:02 GMT Subject: RFR: 8259846: [BACKOUT] JDK-8259278 Optimize Vector API slice and unslice operations In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 15:52:40 GMT, Vladimir Ivanov wrote: >> This reverts commit a6b2162f5400b4596afa5b88219c9cb55dcdb729. > > Looks good. @iwanowww - Thanks for the very fast review. I have a Tier1 running right now. ------------- PR: https://git.openjdk.java.net/jdk/pull/2103 From psandoz at openjdk.java.net Fri Jan 15 16:46:05 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Jan 2021 16:46:05 GMT Subject: RFR: 8259846: [BACKOUT] JDK-8259278 Optimize Vector API slice and unslice operations In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 16:26:22 GMT, Daniel D. Daugherty wrote: >> Java changes look good. > > @PaulSandoz - thanks for the review. @sviswa7 unfortunately the integration of https://github.com/openjdk/jdk/pull/1950 needed to be reverted due to failures in conversion tests. Some were timing out and some were crashing (on some older Mac hardware). ------------- PR: https://git.openjdk.java.net/jdk/pull/2103 From dcubed at openjdk.java.net Fri Jan 15 16:28:59 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 15 Jan 2021 16:28:59 GMT Subject: RFR: 8259846: [BACKOUT] JDK-8259278 Optimize Vector API slice and unslice operations In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 16:22:56 GMT, Paul Sandoz wrote: >> This reverts commit a6b2162f5400b4596afa5b88219c9cb55dcdb729. > > Java changes look good. @PaulSandoz - thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/2103 From psandoz at openjdk.java.net Fri Jan 15 16:26:02 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Jan 2021 16:26:02 GMT Subject: RFR: 8259846: [BACKOUT] JDK-8259278 Optimize Vector API slice and unslice operations In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 15:46:09 GMT, Daniel D. Daugherty wrote: > This reverts commit a6b2162f5400b4596afa5b88219c9cb55dcdb729. Java changes look good. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2103 From dcubed at openjdk.java.net Fri Jan 15 16:57:04 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 15 Jan 2021 16:57:04 GMT Subject: Integrated: 8259846: [BACKOUT] JDK-8259278 Optimize Vector API slice and unslice operations In-Reply-To: References: Message-ID: <7jdfUwB8XGEWHZzcPLimtIGTJOnU8puR4cV3XSczXes=.962b987c-2853-4730-b7b9-280492dd665b@github.com> On Fri, 15 Jan 2021 15:46:09 GMT, Daniel D. Daugherty wrote: > This reverts commit a6b2162f5400b4596afa5b88219c9cb55dcdb729. This pull request has now been integrated. Changeset: b78cd633 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/b78cd633 Stats: 983 lines in 45 files changed: 523 ins; 266 del; 194 mod 8259846: [BACKOUT] JDK-8259278 Optimize Vector API slice and unslice operations Reviewed-by: vlivanov, psandoz ------------- PR: https://git.openjdk.java.net/jdk/pull/2103 From xliu at openjdk.java.net Fri Jan 15 17:57:06 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 15 Jan 2021 17:57:06 GMT Subject: RFR: 8258961: move some fields of SafePointNode from public to protected In-Reply-To: References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> <08g7HiFIZyPHlhan7KLe4_w9_BGQZPpnoDxtnzraj_s=.161392a6-49d6-4d40-9b56-cb188bafad82@github.com> Message-ID: On Fri, 8 Jan 2021 17:30:20 GMT, Xin Liu wrote: >> Yes, I did modify the JBS title. I found it's hard to hide out _jvms because offset_of(klass, field) needs to access the field. >> >> I plan to see if we can use template metaprogramming or constexpr to workaround it(https://gist.github.com/graphitemaster/494f21190bb2c63c5516). I will file a separate issue if I figure out how. > > I found Node::jvms() is virtual, so it's useless to remove keyword "virtual" in SafePointNode::jvms(). I need another revision to fix it. > > Paul asked me to hide away those public fields into protected. I discover a straightforward solution -- just declare friend class VMStructs. Other classes do that. I took back the devirtual attempt because it's not worth it. there're 3 nodes override Node::jvms(). non-virtual jvms() looks more expensive to access vtable. JVMState* Node::jvms() const { if (is_SafePoint()) { return as_SafePoint()->jvms(); } else if (is_MachSafePoint()) { return as_MachSafePoint()->jvms(); } else if (is_MachHalt()) { return as_MachHalt()->jvms(); } return nullptr; } ------------- PR: https://git.openjdk.java.net/jdk/pull/1899 From xliu at openjdk.java.net Fri Jan 15 23:08:21 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 15 Jan 2021 23:08:21 GMT Subject: RFR: 8258961: move some fields of SafePointNode from public to protected In-Reply-To: <08g7HiFIZyPHlhan7KLe4_w9_BGQZPpnoDxtnzraj_s=.161392a6-49d6-4d40-9b56-cb188bafad82@github.com> References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> <08g7HiFIZyPHlhan7KLe4_w9_BGQZPpnoDxtnzraj_s=.161392a6-49d6-4d40-9b56-cb188bafad82@github.com> Message-ID: On Wed, 6 Jan 2021 09:15:24 GMT, Tobias Hartmann wrote: >> Declare VMStructs is a friend of SafePointNode so we can move some fields from public zone to protected zone. >> Clean up the forward declaration section in callnode.hpp. Lock/Unlock Nodes are subclasses of AbstractLockNode. > > @navyxliu There is a title mismatch between the PR and the JBS issue that you need to fix before integration. hello, @TobiHartmann , Could you take a look at this PR again? I've corrected title and description to reflect what this patch does. ------------- PR: https://git.openjdk.java.net/jdk/pull/1899 From kvn at openjdk.java.net Sat Jan 16 02:08:15 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Sat, 16 Jan 2021 02:08:15 GMT Subject: [jdk16] RFR: 8259757: add a regression test for 8259353 and 8259601 [v2] In-Reply-To: References: Message-ID: <8YBvI0H1IgBgW7v8mtSOxekjm1MqmgKcnKgm6yglgv8=.854cf89e-5335-4273-82c4-ba095ef657e7@github.com> On Thu, 14 Jan 2021 19:27:28 GMT, Igor Ignatyev wrote: >> Hi all, >> >> could you please review this small test-only patch which adds a regression test for [8259353](https://bugs.openjdk.java.net/browse/JDK-8259353) and [8259601](https://bugs.openjdk.java.net/browse/JDK-8259353)? >> >> testing: >> - [x] `test/hotspot/jtreg/compiler/vectorapi/Test8259353.java` against jdk-16+26 (which doesn't have fixes) : failed, as expected >> - [x] `test/hotspot/jtreg/compiler/vectorapi/Test8259353.java` multiple times against jdk-16+32 : passed >> >> Thanks, >> -- Igor > > Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision: > > fix copyright year Marked as reviewed by kvn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/120 From jiefu at openjdk.java.net Sat Jan 16 02:21:09 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 16 Jan 2021 02:21:09 GMT Subject: [jdk16] RFR: 8259757: add a regression test for 8259353 and 8259601 [v2] In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 19:27:28 GMT, Igor Ignatyev wrote: >> Hi all, >> >> could you please review this small test-only patch which adds a regression test for [8259353](https://bugs.openjdk.java.net/browse/JDK-8259353) and [8259601](https://bugs.openjdk.java.net/browse/JDK-8259353)? >> >> testing: >> - [x] `test/hotspot/jtreg/compiler/vectorapi/Test8259353.java` against jdk-16+26 (which doesn't have fixes) : failed, as expected >> - [x] `test/hotspot/jtreg/compiler/vectorapi/Test8259353.java` multiple times against jdk-16+32 : passed >> >> Thanks, >> -- Igor > > Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision: > > fix copyright year Marked as reviewed by jiefu (Committer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/120 From jiefu at openjdk.java.net Sat Jan 16 04:11:31 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 16 Jan 2021 04:11:31 GMT Subject: [jdk16] RFR: 8259775: [Vector API] Incorrect code-gen for VectorReinterpret operation [v2] In-Reply-To: References: Message-ID: > Hi all, > > The code-gen for VectorReinterpret may be wrong on x86. > > Let's see the opto-assembly for the reproducer in the JBS, which was actually based on @XiaohongGong 's example in JDK-8259353 and many thanks to her. > 066 B7: # out( N1 ) <- in( B6 ) Freq: 0.999994 > 066 vector_reinterpret_expand XMM0,XMM0 ! > 066 store_vector [R12 + R11 << 3 + #16] (compressed oop addressing),XMM0 > > Please note that the dst and src [1] share the same XMM0 register and movdqu [2] should be generated for this case. > But when dst == src, movdqu actually generates nothing [3], which leads to incorrect result; > > For this case, movdqu should not be empty since the upper bits of dst should be zeroed. > The similar error also exists for vmovdqu [4]. > > I think we should also change movflt [5] to movss but I just can't understand why we have 4-byte vectors. > Isn't the shortest vectors 8-byte on x86? > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3354 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3364 > [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2490 > [4] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2515 > [5] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3379 Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Add a jtreg test ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/122/files - new: https://git.openjdk.java.net/jdk16/pull/122/files/f00904bf..db5d7589 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=122&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=122&range=00-01 Stats: 77 lines in 1 file changed: 77 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/122.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/122/head:pull/122 PR: https://git.openjdk.java.net/jdk16/pull/122 From jiefu at openjdk.java.net Sat Jan 16 04:15:10 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 16 Jan 2021 04:15:10 GMT Subject: RFR: 8259840: [Vector API] Fix an assert in Assembler::vpmovzxbw if UseAVX=0 In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 13:40:04 GMT, Jie Fu wrote: > Hi all, > > This assert was observed when running jdk/incubator/vector/ShortMaxVectorTests.java with -XX:UseAVX=0. > > # > # Internal Error (/home/jvm/jiefu/docker/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:4263), pid=19129, tid=19145 > # Error: assert(vector_len == AVX_128bit? VM_Version::supports_avx() : vector_len == AVX_256bit? VM_Version::supports_avx2() : vector_len == AVX_512bit? VM_Version::supports_avx512bw() : 0) failed > # > > Stack: [0x00007f4c095fa000,0x00007f4c096fb000], sp=0x00007f4c096f5d40, free space=1007k > Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x5e0ab6] Assembler::vpmovzxbw(XMMRegisterImpl*, XMMRegisterImpl*, int)+0x136 > V [libjvm.so+0x41d0dd] loadShuffleSNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0x3ad > V [libjvm.so+0x13ea963] PhaseOutput::scratch_emit_size(Node const*)+0x423 > V [libjvm.so+0x13e1b44] PhaseOutput::shorten_branches(unsigned int*)+0x2a4 > V [libjvm.so+0x13f25aa] PhaseOutput::Output()+0xb8a > V [libjvm.so+0x96a003] Compile::Code_Gen()+0x443 > V [libjvm.so+0x97303a] Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, DirectiveSet*)+0x178a > > The reason is that loadShuffleS should not use vpmovzxbw when -XX:UseAVX=0. > The fix splits loadShuffleS's AVX code-gen logic into loadShuffleS_avx. > > Testing: > - jdk/incubator/vector on an AVX512 machine with UseAVX=3/2/1/0, no regression > > Thanks. > Best regards, > Jie Close this PR after https://github.com/openjdk/jdk/pull/2103 ------------- PR: https://git.openjdk.java.net/jdk/pull/2100 From jiefu at openjdk.java.net Sat Jan 16 04:15:10 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 16 Jan 2021 04:15:10 GMT Subject: Withdrawn: 8259840: [Vector API] Fix an assert in Assembler::vpmovzxbw if UseAVX=0 In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 13:40:04 GMT, Jie Fu wrote: > Hi all, > > This assert was observed when running jdk/incubator/vector/ShortMaxVectorTests.java with -XX:UseAVX=0. > > # > # Internal Error (/home/jvm/jiefu/docker/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:4263), pid=19129, tid=19145 > # Error: assert(vector_len == AVX_128bit? VM_Version::supports_avx() : vector_len == AVX_256bit? VM_Version::supports_avx2() : vector_len == AVX_512bit? VM_Version::supports_avx512bw() : 0) failed > # > > Stack: [0x00007f4c095fa000,0x00007f4c096fb000], sp=0x00007f4c096f5d40, free space=1007k > Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x5e0ab6] Assembler::vpmovzxbw(XMMRegisterImpl*, XMMRegisterImpl*, int)+0x136 > V [libjvm.so+0x41d0dd] loadShuffleSNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0x3ad > V [libjvm.so+0x13ea963] PhaseOutput::scratch_emit_size(Node const*)+0x423 > V [libjvm.so+0x13e1b44] PhaseOutput::shorten_branches(unsigned int*)+0x2a4 > V [libjvm.so+0x13f25aa] PhaseOutput::Output()+0xb8a > V [libjvm.so+0x96a003] Compile::Code_Gen()+0x443 > V [libjvm.so+0x97303a] Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, DirectiveSet*)+0x178a > > The reason is that loadShuffleS should not use vpmovzxbw when -XX:UseAVX=0. > The fix splits loadShuffleS's AVX code-gen logic into loadShuffleS_avx. > > Testing: > - jdk/incubator/vector on an AVX512 machine with UseAVX=3/2/1/0, no regression > > Thanks. > Best regards, > Jie This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2100 From jiefu at openjdk.java.net Sat Jan 16 05:34:41 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 16 Jan 2021 05:34:41 GMT Subject: [jdk16] RFR: 8259775: [Vector API] Incorrect code-gen for VectorReinterpret operation [v3] In-Reply-To: References: Message-ID: > Hi all, > > The code-gen for VectorReinterpret may be wrong on x86. > > Let's see the opto-assembly for the reproducer in the JBS, which was actually based on @XiaohongGong 's example in JDK-8259353 and many thanks to her. > 066 B7: # out( N1 ) <- in( B6 ) Freq: 0.999994 > 066 vector_reinterpret_expand XMM0,XMM0 ! > 066 store_vector [R12 + R11 << 3 + #16] (compressed oop addressing),XMM0 > > Please note that the dst and src [1] share the same XMM0 register and movdqu [2] should be generated for this case. > But when dst == src, movdqu actually generates nothing [3], which leads to incorrect result; > > For this case, movdqu should not be empty since the upper bits of dst should be zeroed. > The similar error also exists for vmovdqu [4]. > > I think we should also change movflt [5] to movss but I just can't understand why we have 4-byte vectors. > Isn't the shortest vectors 8-byte on x86? > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3354 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3364 > [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2490 > [4] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2515 > [5] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3379 Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Add tests for both 256 and 512 vectors ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/122/files - new: https://git.openjdk.java.net/jdk16/pull/122/files/db5d7589..e17ba6cf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=122&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=122&range=01-02 Stats: 205 lines in 3 files changed: 128 ins; 77 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/122.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/122/head:pull/122 PR: https://git.openjdk.java.net/jdk16/pull/122 From jiefu at openjdk.java.net Sat Jan 16 11:37:40 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 16 Jan 2021 11:37:40 GMT Subject: [jdk16] RFR: 8259775: [Vector API] Incorrect code-gen for VectorReinterpret operation [v4] In-Reply-To: References: Message-ID: > Hi all, > > The code-gen for VectorReinterpret may be wrong on x86. > > Let's see the opto-assembly for the reproducer in the JBS, which was actually based on @XiaohongGong 's example in JDK-8259353 and many thanks to her. > 066 B7: # out( N1 ) <- in( B6 ) Freq: 0.999994 > 066 vector_reinterpret_expand XMM0,XMM0 ! > 066 store_vector [R12 + R11 << 3 + #16] (compressed oop addressing),XMM0 > > Please note that the dst and src [1] share the same XMM0 register and movdqu [2] should be generated for this case. > But when dst == src, movdqu actually generates nothing [3], which leads to incorrect result; > > For this case, movdqu should not be empty since the upper bits of dst should be zeroed. > The similar error also exists for vmovdqu [4]. > > I think we should also change movflt [5] to movss but I just can't understand why we have 4-byte vectors. > Isn't the shortest vectors 8-byte on x86? > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3354 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3364 > [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2490 > [4] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2515 > [5] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3379 Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Zero upper bits of 4-byte vectors ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/122/files - new: https://git.openjdk.java.net/jdk16/pull/122/files/e17ba6cf..d86bf850 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=122&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=122&range=02-03 Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/122.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/122/head:pull/122 PR: https://git.openjdk.java.net/jdk16/pull/122 From github.com+10482586+therealeliu at openjdk.java.net Mon Jan 18 02:13:42 2021 From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu) Date: Mon, 18 Jan 2021 02:13:42 GMT Subject: RFR: 8255339: CodeBuffer::_last_insn is only used on AArch64 In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 09:21:31 GMT, Eric Liu wrote: >> I filed this RFE while looking through and cleaning out unused code in the area. Letting arch-specific behavior like this live on in shared code means static analysis highlights it as unused which is a bit of a nuisance. Any performance benefit is decidedly slim here, though. >> >> While macroing out code looks superficially messy I think the reading and understanding of code is overall helped when being explicit. > > Hi Aleksey, > > Thanks for your feedback. > >> I understand the desire to do this, but I really doubt that introducing arch-specific behaviors in shared code buys us enough. > > I thought the best position for recording the last instruction was macro-assembler, it's architecture dependent and closer to the final code in general. But it's a shame that each instruction has its own macro-assembler instance. The first shared place I can find is exactly the CodeBuffer which was used as an argument of macro-assembler. Perhaps it's not the best way but efficient, otherwise the arch-specific CodeBuffer seems too weird. > >> I believe it saves 8 bytes for a transient code buffer, so ballparking 10K methods are compiled, it saves 80K of temporary allocations? If this was saving more and for non-transient footprint, it would be interesting. > > I'd like to investigate more. > > Thanks, > -Eric If no better solution, I prefer to close this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/1971 From github.com+10482586+therealeliu at openjdk.java.net Mon Jan 18 02:13:42 2021 From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu) Date: Mon, 18 Jan 2021 02:13:42 GMT Subject: Withdrawn: 8255339: CodeBuffer::_last_insn is only used on AArch64 In-Reply-To: References: Message-ID: <6jlowq1pLYpjWhNGGiYYkTHWKGbdsbb176mJvSzqpCc=.a9444615-8907-433b-ba69-12a9bba01650@github.com> On Thu, 7 Jan 2021 08:07:16 GMT, Eric Liu wrote: > CodeBuffer::_last_insn was used to merge consecutive memory barriers and > adjacent load/store on AArch64. > > This patch marks it as AArch64 only so that 8 bytes could be dropped > from CodeBuffer on other architectures. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1971 From roland at openjdk.java.net Mon Jan 18 07:57:47 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Mon, 18 Jan 2021 07:57:47 GMT Subject: [jdk16] Integrated: 8259641: C2: assert(early->dominates(LCA)) failed: early is high enough In-Reply-To: <1aDWWln8xu9qmWLSgnGJOYlllvN_QfzJsRtW5qKFjbA=.a46186b0-14ff-4306-a44c-34b943a082da@github.com> References: <1aDWWln8xu9qmWLSgnGJOYlllvN_QfzJsRtW5qKFjbA=.a46186b0-14ff-4306-a44c-34b943a082da@github.com> Message-ID: On Thu, 14 Jan 2021 08:05:25 GMT, Roland Westrelin wrote: > For the fix of 8258393 that causes this regression, I wrote that the > goal was: > > "I propose to be less conservative in anti-dependence analysis for > Phis. For a Phi, when computing the LCA, I think it's sufficient to > only consider region's inputs that we actually reach by following the > memory edges and that's what I propose here." > > But that's not what the logic I added does. It checks whether a Phi > input should be taken into account by checking whether it's in the > worklist but the worklist doesn't include mem, the memory state from > which we started. This pull request has now been integrated. Changeset: d5ca3b3f Author: Roland Westrelin URL: https://git.openjdk.java.net/jdk16/commit/d5ca3b3f Stats: 96 lines in 2 files changed: 95 ins; 0 del; 1 mod 8259641: C2: assert(early->dominates(LCA)) failed: early is high enough Reviewed-by: chagedorn, thartmann ------------- PR: https://git.openjdk.java.net/jdk16/pull/121 From thartmann at openjdk.java.net Mon Jan 18 08:00:50 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 18 Jan 2021 08:00:50 GMT Subject: RFR: 8258961: move some fields of SafePointNode from public to protected [v5] In-Reply-To: References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> Message-ID: <1D1jeHHwxAQG6IONoI01nZb8BFAyiq31OE40UJX_PKY=.2dc7fc85-68fa-4ab4-adb1-d4d75bde6332@github.com> On Fri, 15 Jan 2021 02:13:19 GMT, Xin Liu wrote: >> Declare VMStructs is a friend of SafePointNode so we can move some fields from public zone to protected zone. >> Clean up the forward declaration section in callnode.hpp. Lock/Unlock Nodes are subclasses of AbstractLockNode. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > 8258961: move some fields of SafePointNode from public to protected > > revert code change to devirtualize Node::jvms(). > There are 3 nodes override jvms() -- SafePointNode, MachSafePointNode and > MachHalt. It does not make sense to devirtualize it because we have to do > non-trivial dispatch based on types in Node::jvms(). It is not worth it. Looks reasonable to me but @vnkozlov should also review this again. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1899 From chagedorn at openjdk.java.net Mon Jan 18 09:41:10 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 18 Jan 2021 09:41:10 GMT Subject: RFR: 8257498: Remove useless skeleton predicates [v2] In-Reply-To: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com> References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com> Message-ID: > This enhancement removes useless skeleton predicates in the same way as we already remove normal useless predicates in `PhaseIdealLoop::eliminate_useless_predicates()`. > > Thanks, > Christian Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: Add handling of Deoptimization::Reason_profile_predicate ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2075/files - new: https://git.openjdk.java.net/jdk/pull/2075/files/49601392..0ed11ba9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2075&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2075&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2075.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2075/head:pull/2075 PR: https://git.openjdk.java.net/jdk/pull/2075 From chagedorn at openjdk.java.net Mon Jan 18 09:41:11 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 18 Jan 2021 09:41:11 GMT Subject: RFR: 8257498: Remove useless skeleton predicates [v2] In-Reply-To: References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com> Message-ID: <04QzGEnxVy4JlX8wAjg9lHnB7TnTgfn5HjjNnfaIEtc=.027ec615-a810-43fb-b033-78cab38a0e73@github.com> On Fri, 15 Jan 2021 15:54:23 GMT, Roland Westrelin wrote: >> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: >> >> Add handling of Deoptimization::Reason_profile_predicate > > src/hotspot/share/opto/loopnode.cpp line 3560: > >> 3558: >> 3559: if (UseLoopPredicate) { >> 3560: predicate = find_predicate_insertion_point(entry, Deoptimization::Reason_predicate); > > Don't we need to do this for Deoptimization::Reason_profile_predicate as well? You're right, we need that as well. I updated it. ------------- PR: https://git.openjdk.java.net/jdk/pull/2075 From thartmann at openjdk.java.net Mon Jan 18 11:28:47 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 18 Jan 2021 11:28:47 GMT Subject: RFR: JDK-8259710: Inlining trace leaks memory In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 14:51:44 GMT, Thomas Stuefe wrote: > We see C-heap leaking, originating in C2: > > 1434777 [0x00007f58214af461] stringStream::stringStream(unsigned long)+0x55 > 1434778 [0x00007f5820c6db3e] Compile::PrintInliningBuffer::PrintInliningBuffer()+0x6c > 1434779 [0x00007f5820c724f1] GrowableArrayWithAllocator >::grow(int)+0x163 > 1434780 [0x00007f5820c7160e] GrowableArrayWithAllocator >::insert_before(int, Compile::PrintInliningBuffer const&)+0x82 > 1434781 [0x00007f5820c6aaf2] Compile::print_inlining_push()+0x70 > > accumulating over the course of days to some hundred MB at a customer site where inline tracing was active. > > > Analysis: > > > To build up a comprehensive inlining trace, c2 keeps trace snippets in an internal list and assembles them at print time. These are stringStream's, contained in PrintInliningBuffer: > > GrowableArray* _print_inlining_list; > ... > class PrintInliningBuffer : public ResourceObj { > private: > CallGenerator* _cg; > stringStream* _ss; > > public: > PrintInliningBuffer() > : _cg(NULL) { > _ss = new stringStream(); > } > > void freeStream() { > _ss->~stringStream(); _ss = NULL; } > ... > }; > > With [JDK-8224193](https://bugs.openjdk.java.net/browse/JDK-8224193), stringStream was changed to use C-heap instead of ResourceArea for its internal buffer. This means one cannot just omit stringStream destruction anymore - even where stringStream objects themselves live in RA, their internal buffers don't, they live in C-Heap. To clean up properly, ~stringStream() must be called. > > Those `PrintInliningBuffer` objects are kept _by value_ in a GrowableArray `Compile::_print_inlining_list`. Normally, if an object is kept by value, it needs to implement correct copy- and destruction-semantics. PrintInliningBuffer does not do that and instead relies on manual cleanup (`PrintInliningBuffer::freeStream()`) - I assume the authors did not want to deal with reference counting the contained stringStream on copying. > > That however is a problem because GrowableArray creates internally temporary objects of the item type to pre-populate its array - its whole capacity - when it grows: > > > template > void GrowableArrayWithAllocator::grow(int j) { > > ... > for ( ; i < this->_len; i++) ::new ((void*)&newData[i]) E(this->_data[i]); > for ( ; i < this->_max; i++) ::new ((void*)&newData[i]) E(); <<<<<<< > for (i = 0; i < old_max; i++) this->_data[i].~E(); > ... > } > > this it does for the whole new capacity, which means more objects get created than have been added; if the caller does not fill the GrowableArray up to its capacity, it never knows about the excess objects created. This is normally not a problem since all these objects are destructed by GrowableArray in `void GrowableArrayWithAllocator::clear_and_deallocate()`. But since PrintInliningBuffer does not implement a destructor, this has no effect. > > PrintInliningBuffer instead relies on manual cleanup of the stringStreams: at the end of the compile phase, it calls `PrintInliningBuffer::freeStream()` on all buffers it thinks are contained in the array: > > assert(_print_inlining_list != NULL, "process_print_inlining should be called only once."); > for (int i = 0; i < _print_inlining_list->length(); i++) { > ss.print("%s", _print_inlining_list->adr_at(i)->ss()->as_string()); > _print_inlining_list->at(i).freeStream(); > } > > but this of course leaves the excess objects untouched (objects whose index is array length >= index >= array capacity). > > ----------- > > There are several ways to fix this: > > 1) implement correct destructor- and copy semantics for PrintInliningBuffer. This would work but is not optimal since we would still pay for creation of unnecessary PrintInliningBuffer objects when the array is prepopulated on grow() > > 2) delay construction of `PrintInliningBuffer::_ss` until the stream is actually used for writing into. This would would mean we have to check the stringStream for NULL before using it. > > 3) Just let the PrintInliningBuffer live in C-heap instead of the RA. Its only a small shell anywhere now that the stringStream buffer lives in C-heap. Instead, let PrintInliningBuffer contain the stringStream as a member, allocate PrintInliningBuffer from C-heap, and change the list to contain pointers to PrintInliningBuffer, not the object itself. This removes all that unnecessary copying, removes creation of temporary objects, and simplifies the code. Having to free those objects is no big deal since we free the stringStream objects manually anyway. > > I went with (3). I also decreased the default stringStream buffer size for this scenario since when testing I found out that many trace snippets are below 128 bytes. > > Note that (3) is not only simpler, but also more efficient: many of the PrintInliningBuffer objects are inserted into the middle of the _print_inlining_list; GrowableArray does shift all higher items up to provide space for the new item. If those items are simple pointers instead of whole objects, less memory is moved around. > > Tests: > - github actions > - Nightlies at SAP > - I manually tested the patch and compared the NMT output of a tracing scenario to verify that the leak went away and no other numbers changed > > Thanks, Thomas Otherwise, looks good to me. src/hotspot/share/opto/compile.cpp line 4224: > 4222: > 4223: Compile::PrintInliningBuffer& Compile::print_inlining_current() { > 4224: return *(_print_inlining_list->at(_print_inlining_idx)); Maybe just change the return to `Compile::PrintInliningBuffer*` and update callers accordingly (there are only a few). ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2063 From thartmann at openjdk.java.net Mon Jan 18 11:51:49 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 18 Jan 2021 11:51:49 GMT Subject: RFR: 8259609: C2: optimize long range checks in long counted loops In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 13:40:40 GMT, Roland Westrelin wrote: >> Hi Roland, >> >> I haven't looked at the code in detail yet but submitted some quick testing. Unfortunately, there are failures with an internal test that I'm unable to share. Some details: >> >> # Internal Error (src/hotspot/share/utilities/globalDefinitions.hpp:460), pid=27250, tid=27265 >> # assert(static_cast(result) == thing) failed: must be >> >> Stack: [0x00007fca9cdfa000,0x00007fca9cefb000], sp=0x00007fca9cef5360, free space=1004k >> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x12f5a3e] IdealLoopTree::policy_range_check(PhaseIdealLoop*) const [clone .part.0]+0x33e >> V [libjvm.so+0x1301e4f] IdealLoopTree::iteration_split_impl(PhaseIdealLoop*, Node_List&) [clone .part.0]+0x6ef >> V [libjvm.so+0x13021bb] IdealLoopTree::iteration_split(PhaseIdealLoop*, Node_List&)+0x13b >> V [libjvm.so+0x13020b5] IdealLoopTree::iteration_split(PhaseIdealLoop*, Node_List&)+0x35 >> V [libjvm.so+0x1330633] PhaseIdealLoop::build_and_optimize(LoopOptsMode)+0xc83 >> V [libjvm.so+0xa1cbdb] PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x32b >> V [libjvm.so+0xa18636] Compile::Optimize()+0x586 >> V [libjvm.so+0xa1b370] Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, DirectiveSet*)+0x1840 >> V [libjvm.so+0x84b1bc] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1dc >> V [libjvm.so+0xa2b3a8] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xe88 >> V [libjvm.so+0xa2bff8] CompileBroker::compiler_thread_loop()+0x5a8 >> V [libjvm.so+0x18b06c6] JavaThread::thread_main_inner()+0x256 >> V [libjvm.so+0x18b70d0] Thread::call_run()+0x100 >> V [libjvm.so+0x1599dd6] thread_native_entry(Thread*)+0x116 >> >> Hope that helps. > >> I haven't looked at the code in detail yet but submitted some quick testing. Unfortunately, there are failures with an internal test that I'm unable to share. Some details: > > Thanks. I pushed a fix. I think you forgot to push the fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/2045 From redestad at openjdk.java.net Mon Jan 18 12:16:00 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 18 Jan 2021 12:16:00 GMT Subject: RFR: 8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException Message-ID: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com> Change `MethodHandles.byteArrayViewVarHandle` to throw `ArrayIndexOutOfBoundsException` rather than the more generic `IndexArrayOutOfBoundsException`. This feels more natural, and reduces the risk for subtle behavioral mismatch when migrating code from arrays/Unsafe to VHs. CSR: [JDK-8259912](https://bugs.openjdk.java.net/browse/JDK-8259912) ------------- Commit messages: - byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException Changes: https://git.openjdk.java.net/jdk/pull/2124/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2124&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259911 Stats: 8 lines in 2 files changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2124.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2124/head:pull/2124 PR: https://git.openjdk.java.net/jdk/pull/2124 From roland at openjdk.java.net Mon Jan 18 13:38:15 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Mon, 18 Jan 2021 13:38:15 GMT Subject: RFR: 8259609: C2: optimize long range checks in long counted loops [v2] In-Reply-To: References: Message-ID: > JDK-8255150 makes it possible for java code to explicitly perform a > range check on long values. JDK-8223051 provides a transformation of > long counted loops into loop nests with an inner int counted > loop. With this change I propose transforming long range checks that > operate on the iv of a long counted loop into range checks that > operate on the iv of the int inner loop once it has been > created. Existing range check eliminations can then kick in. > > Transformation of range checks is piggy backed on the loop nest > creation for 2 reasons: > > - pattern matching range checks is easier right before the loop nest > is created > > - the number of iterations of the inner loop is adjusted so scale * > inner_iv doesn't overflow > > C2 has logic to delay some split if transformations so they don't > break the scale * iv + offset pattern. I reused that logic for long > range checks and had to relax what's considered a range check because > initially a range check from Object.checkIndex() may include a test > for range > 0 that needs a round of loop opts to be hoisted. I realize > there's some code duplication but I didn't see a way to share logic > between IdealLoopTree::may_have_range_check() > IdealLoopTree::policy_range_check() that would feel right. > > I realize the comment in PhaseIdealLoop::transform_long_range_checks() > is scary. FWIW, it's not as complicated as it looks. I found drawing > the range covered by the entire long loop and the range covered by the > inner loop help see how range checks can be transformed. Then the > comment helps make sure all cases are covered and verify the generated > code actually covers all of them. > > One issue is overflow. I think the fact that inner_iv * scale doesn't > overflow helps simplify thing. One possible overflow is that of scale > * upper + offset which is handled by forcing all range checks in that > case to deoptimize. I don't think other case of overflow needs special > handling. > > This was tested with a Memory Segment micro benchmark (and patched > Memory Segment support to take advantage of the new checkIndex > intrinsic, both provided by Maurizio). Range checks in the micro > benchmark are properly optimized (and performance increases > significantly). Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into JDK-8259609 - assert(static_cast(result) == thing) fix - whitespaces - build fix + test cleanup - range checks ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2045/files - new: https://git.openjdk.java.net/jdk/pull/2045/files/dd765971..ed7390f1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2045&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2045&range=00-01 Stats: 18890 lines in 829 files changed: 10743 ins; 4557 del; 3590 mod Patch: https://git.openjdk.java.net/jdk/pull/2045.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2045/head:pull/2045 PR: https://git.openjdk.java.net/jdk/pull/2045 From roland at openjdk.java.net Mon Jan 18 13:38:16 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Mon, 18 Jan 2021 13:38:16 GMT Subject: RFR: 8259609: C2: optimize long range checks in long counted loops In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 11:49:13 GMT, Tobias Hartmann wrote: > I think you forgot to push the fix. Indeed. Pushed now. ------------- PR: https://git.openjdk.java.net/jdk/pull/2045 From kvn at openjdk.java.net Mon Jan 18 22:36:52 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 18 Jan 2021 22:36:52 GMT Subject: RFR: 8258961: move some fields of SafePointNode from public to protected [v5] In-Reply-To: References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> Message-ID: On Fri, 15 Jan 2021 02:13:19 GMT, Xin Liu wrote: >> Declare VMStructs is a friend of SafePointNode so we can move some fields from public zone to protected zone. >> Clean up the forward declaration section in callnode.hpp. Lock/Unlock Nodes are subclasses of AbstractLockNode. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > 8258961: move some fields of SafePointNode from public to protected > > revert code change to devirtualize Node::jvms(). > There are 3 nodes override jvms() -- SafePointNode, MachSafePointNode and > MachHalt. It does not make sense to devirtualize it because we have to do > non-trivial dispatch based on types in Node::jvms(). It is not worth it. Looks good. Latest version passed hs-tier1-3 testing. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1899 From xliu at openjdk.java.net Mon Jan 18 22:36:52 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Mon, 18 Jan 2021 22:36:52 GMT Subject: Integrated: 8258961: move some fields of SafePointNode from public to protected In-Reply-To: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> Message-ID: On Mon, 28 Dec 2020 09:48:29 GMT, Xin Liu wrote: > Declare VMStructs is a friend of SafePointNode so we can move some fields from public zone to protected zone. > Clean up the forward declaration section in callnode.hpp. Lock/Unlock Nodes are subclasses of AbstractLockNode. This pull request has now been integrated. Changeset: 533a2d39 Author: Xin Liu Committer: Vladimir Kozlov URL: https://git.openjdk.java.net/jdk/commit/533a2d39 Stats: 67 lines in 5 files changed: 25 ins; 22 del; 20 mod 8258961: move some fields of SafePointNode from public to protected Reviewed-by: thartmann, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/1899 From xliu at openjdk.java.net Mon Jan 18 22:44:50 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Mon, 18 Jan 2021 22:44:50 GMT Subject: RFR: 8258961: move some fields of SafePointNode from public to protected [v5] In-Reply-To: References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com> Message-ID: <9hyUgbUuuDIw108BdCTUsWQupGNdQ949AAKblIiULxM=.b89a3302-05a9-46e0-bc10-47b9c0119af1@github.com> On Mon, 18 Jan 2021 22:32:32 GMT, Vladimir Kozlov wrote: >> Xin Liu has updated the pull request incrementally with one additional commit since the last revision: >> >> 8258961: move some fields of SafePointNode from public to protected >> >> revert code change to devirtualize Node::jvms(). >> There are 3 nodes override jvms() -- SafePointNode, MachSafePointNode and >> MachHalt. It does not make sense to devirtualize it because we have to do >> non-trivial dispatch based on types in Node::jvms(). It is not worth it. > > Looks good. > > Latest version passed hs-tier1-3 testing. Thanks for all reviewers. ------------- PR: https://git.openjdk.java.net/jdk/pull/1899 From ysuenaga at openjdk.java.net Tue Jan 19 01:42:38 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 19 Jan 2021 01:42:38 GMT Subject: RFR: 8259035: Comments for load order of hsdis should be updated In-Reply-To: References: Message-ID: On Sun, 3 Jan 2021 04:46:10 GMT, Yasumasa Suenaga wrote: > Load order for hsdis is described in both src/utils/hsdis/README and src/hotspot/share/compiler/disassembler.cpp. README has been updated in [JDK-8215977](https://bugs.openjdk.java.net/browse/JDK-8215977), however disassembler.cpp has not been updated yet. PING: could you review this PR? It makes just change comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/1919 From jiefu at openjdk.java.net Tue Jan 19 03:57:16 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 19 Jan 2021 03:57:16 GMT Subject: [jdk16] RFR: 8259775: [Vector API] Incorrect code-gen for VectorReinterpret operation [v5] In-Reply-To: References: Message-ID: <5ZRm7yr18uW4HQWoMQHlI1CHdqUa70mbcj7r6PkROKU=.e5991488-7d71-4657-95c3-8a034b654db6@github.com> > Hi all, > > The code-gen for VectorReinterpret may be wrong on x86. > > Let's see the opto-assembly for the reproducer in the JBS, which was actually based on @XiaohongGong 's example in JDK-8259353 and many thanks to her. > 066 B7: # out( N1 ) <- in( B6 ) Freq: 0.999994 > 066 vector_reinterpret_expand XMM0,XMM0 ! > 066 store_vector [R12 + R11 << 3 + #16] (compressed oop addressing),XMM0 > > Please note that the dst and src [1] share the same XMM0 register and movdqu [2] should be generated for this case. > But when dst == src, movdqu actually generates nothing [3], which leads to incorrect result; > > For this case, movdqu should not be empty since the upper bits of dst should be zeroed. > The similar error also exists for vmovdqu [4]. > > I think we should also change movflt [5] to movss but I just can't understand why we have 4-byte vectors. > Isn't the shortest vectors 8-byte on x86? > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3354 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3364 > [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2490 > [4] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2515 > [5] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3379 Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Refine the test to always reproduce the bug ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/122/files - new: https://git.openjdk.java.net/jdk16/pull/122/files/d86bf850..94350c09 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=122&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=122&range=03-04 Stats: 205 lines in 3 files changed: 77 ins; 128 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/122.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/122/head:pull/122 PR: https://git.openjdk.java.net/jdk16/pull/122 From stuefe at openjdk.java.net Tue Jan 19 06:06:18 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 19 Jan 2021 06:06:18 GMT Subject: RFR: JDK-8259710: Inlining trace leaks memory [v2] In-Reply-To: References: Message-ID: <4ONcTjZt6YQKyWyuZ87LPSe2GYVAr70qPSWq8cXoxsI=.e9b59bb5-2fbe-4710-980b-86fe142392a1@github.com> On Mon, 18 Jan 2021 11:25:32 GMT, Tobias Hartmann wrote: > Otherwise, looks good to me. Thanks Tobias. I added your suggestion. Cheers, Thoams ------------- PR: https://git.openjdk.java.net/jdk/pull/2063 From stuefe at openjdk.java.net Tue Jan 19 06:06:17 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 19 Jan 2021 06:06:17 GMT Subject: RFR: JDK-8259710: Inlining trace leaks memory [v2] In-Reply-To: References: Message-ID: > We see C-heap leaking, originating in C2: > > 1434777 [0x00007f58214af461] stringStream::stringStream(unsigned long)+0x55 > 1434778 [0x00007f5820c6db3e] Compile::PrintInliningBuffer::PrintInliningBuffer()+0x6c > 1434779 [0x00007f5820c724f1] GrowableArrayWithAllocator >::grow(int)+0x163 > 1434780 [0x00007f5820c7160e] GrowableArrayWithAllocator >::insert_before(int, Compile::PrintInliningBuffer const&)+0x82 > 1434781 [0x00007f5820c6aaf2] Compile::print_inlining_push()+0x70 > > accumulating over the course of days to some hundred MB at a customer site where inline tracing was active. > > > Analysis: > > > To build up a comprehensive inlining trace, c2 keeps trace snippets in an internal list and assembles them at print time. These are stringStream's, contained in PrintInliningBuffer: > > GrowableArray* _print_inlining_list; > ... > class PrintInliningBuffer : public ResourceObj { > private: > CallGenerator* _cg; > stringStream* _ss; > > public: > PrintInliningBuffer() > : _cg(NULL) { > _ss = new stringStream(); > } > > void freeStream() { > _ss->~stringStream(); _ss = NULL; } > ... > }; > > With [JDK-8224193](https://bugs.openjdk.java.net/browse/JDK-8224193), stringStream was changed to use C-heap instead of ResourceArea for its internal buffer. This means one cannot just omit stringStream destruction anymore - even where stringStream objects themselves live in RA, their internal buffers don't, they live in C-Heap. To clean up properly, ~stringStream() must be called. > > Those `PrintInliningBuffer` objects are kept _by value_ in a GrowableArray `Compile::_print_inlining_list`. Normally, if an object is kept by value, it needs to implement correct copy- and destruction-semantics. PrintInliningBuffer does not do that and instead relies on manual cleanup (`PrintInliningBuffer::freeStream()`) - I assume the authors did not want to deal with reference counting the contained stringStream on copying. > > That however is a problem because GrowableArray creates internally temporary objects of the item type to pre-populate its array - its whole capacity - when it grows: > > > template > void GrowableArrayWithAllocator::grow(int j) { > > ... > for ( ; i < this->_len; i++) ::new ((void*)&newData[i]) E(this->_data[i]); > for ( ; i < this->_max; i++) ::new ((void*)&newData[i]) E(); <<<<<<< > for (i = 0; i < old_max; i++) this->_data[i].~E(); > ... > } > > this it does for the whole new capacity, which means more objects get created than have been added; if the caller does not fill the GrowableArray up to its capacity, it never knows about the excess objects created. This is normally not a problem since all these objects are destructed by GrowableArray in `void GrowableArrayWithAllocator::clear_and_deallocate()`. But since PrintInliningBuffer does not implement a destructor, this has no effect. > > PrintInliningBuffer instead relies on manual cleanup of the stringStreams: at the end of the compile phase, it calls `PrintInliningBuffer::freeStream()` on all buffers it thinks are contained in the array: > > assert(_print_inlining_list != NULL, "process_print_inlining should be called only once."); > for (int i = 0; i < _print_inlining_list->length(); i++) { > ss.print("%s", _print_inlining_list->adr_at(i)->ss()->as_string()); > _print_inlining_list->at(i).freeStream(); > } > > but this of course leaves the excess objects untouched (objects whose index is array length >= index >= array capacity). > > ----------- > > There are several ways to fix this: > > 1) implement correct destructor- and copy semantics for PrintInliningBuffer. This would work but is not optimal since we would still pay for creation of unnecessary PrintInliningBuffer objects when the array is prepopulated on grow() > > 2) delay construction of `PrintInliningBuffer::_ss` until the stream is actually used for writing into. This would would mean we have to check the stringStream for NULL before using it. > > 3) Just let the PrintInliningBuffer live in C-heap instead of the RA. Its only a small shell anywhere now that the stringStream buffer lives in C-heap. Instead, let PrintInliningBuffer contain the stringStream as a member, allocate PrintInliningBuffer from C-heap, and change the list to contain pointers to PrintInliningBuffer, not the object itself. This removes all that unnecessary copying, removes creation of temporary objects, and simplifies the code. Having to free those objects is no big deal since we free the stringStream objects manually anyway. > > I went with (3). I also decreased the default stringStream buffer size for this scenario since when testing I found out that many trace snippets are below 128 bytes. > > Note that (3) is not only simpler, but also more efficient: many of the PrintInliningBuffer objects are inserted into the middle of the _print_inlining_list; GrowableArray does shift all higher items up to provide space for the new item. If those items are simple pointers instead of whole objects, less memory is moved around. > > Tests: > - github actions > - Nightlies at SAP > - I manually tested the patch and compared the NMT output of a tracing scenario to verify that the leak went away and no other numbers changed > > Thanks, Thomas Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: change return parameter of Compile::print_inlining_current() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2063/files - new: https://git.openjdk.java.net/jdk/pull/2063/files/4045f2f8..b52b140b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2063&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2063&range=00-01 Stats: 2375 lines in 4 files changed: 2365 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/2063.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2063/head:pull/2063 PR: https://git.openjdk.java.net/jdk/pull/2063 From roland at openjdk.java.net Tue Jan 19 08:26:52 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Tue, 19 Jan 2021 08:26:52 GMT Subject: RFR: 8257498: Remove useless skeleton predicates [v2] In-Reply-To: References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com> Message-ID: On Mon, 18 Jan 2021 09:41:10 GMT, Christian Hagedorn wrote: >> This enhancement removes useless skeleton predicates in the same way as we already remove normal useless predicates in `PhaseIdealLoop::eliminate_useless_predicates()`. >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > Add handling of Deoptimization::Reason_profile_predicate Changes requested by roland (Reviewer). src/hotspot/share/opto/loopPredicate.cpp line 280: > 278: // Put all skeleton predicate projections on a list, starting at 'predicate' and going up in the tree. If 'get_opaque' > 279: // is set, then the Opaque4 nodes of the skeleton predicates are put on the list instead of the projections. > 280: void PhaseIdealLoop::get_skeleton_predicates(Node* predicate, Unique_Node_List& list, bool get_opaque) { I would remove the get_opaque parameter, populate the list with projections (the get_opaque false case) and have the caller retrieve the opaque node (predicate->in(0)->in(1)) if that's what it needs. src/hotspot/share/opto/loopnode.cpp line 3601: > 3599: assert(n->Opcode() == Op_Opaque4, "must be"); > 3600: if (!useful_predicates.member(n)) { // not in the useful list > 3601: C->remove_skeleton_predicate_opaque4_node(idx); Usually when nodes are kept in a global list, when a node dies, the node is removed from the list. It's the case of Compile::_predicate_opaqs for instance. So when the logic here iterates over _predicate_opaqs and removes some of them from the graph, the node is automatically removed from the _predicate_opaqs list. I don't see similar logic for skeleton Opaque4 nodes. I think it's a problem because you could end up with a node in the list that was removed from the graph (because that part of the graph is dead) and freed from memory (which could cause a crash). ------------- PR: https://git.openjdk.java.net/jdk/pull/2075 From thartmann at openjdk.java.net Tue Jan 19 08:55:49 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 19 Jan 2021 08:55:49 GMT Subject: RFR: 8259035: Comments for load order of hsdis should be updated In-Reply-To: References: Message-ID: <9-rJErG5y8QPIqw5h8GIE7rduADBW2-l8cMUU6ii8zE=.9bef70ff-f3cb-47c4-b325-d26f784f0cab@github.com> On Sun, 3 Jan 2021 04:46:10 GMT, Yasumasa Suenaga wrote: > Load order for hsdis is described in both src/utils/hsdis/README and src/hotspot/share/compiler/disassembler.cpp. README has been updated in [JDK-8215977](https://bugs.openjdk.java.net/browse/JDK-8215977), however disassembler.cpp has not been updated yet. Looks good and trivial to me. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1919 From thartmann at openjdk.java.net Tue Jan 19 09:00:49 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 19 Jan 2021 09:00:49 GMT Subject: RFR: 8259609: C2: optimize long range checks in long counted loops In-Reply-To: References: Message-ID: <1kBolNZOhOFBD5aNq5rLF8RheC37JN794IJFy9Tf_UM=.f25e5227-03ee-465a-97a1-3fb886b79a43@github.com> On Mon, 18 Jan 2021 13:34:16 GMT, Roland Westrelin wrote: >> I think you forgot to push the fix. > >> I think you forgot to push the fix. > > Indeed. Pushed now. I'm now seeing this with the same test at a higher tier (and therefore different flags): # Internal Error (workspace/open/src/hotspot/share/opto/loopPredicate.cpp:1154), pid=8709, tid=8726 # assert(ok) failed: must be index expression Stack: [0x00007f2f3bdfe000,0x00007f2f3beff000], sp=0x00007f2f3bef8fd0, free space=1003k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x129032b] PhaseIdealLoop::loop_predication_impl_helper(IdealLoopTree*, ProjNode*, ProjNode*, CountedLoopNode*, ConNode*, Invariance&, Deoptimization::DeoptReason)+0x74b V [libjvm.so+0x1291e0b] PhaseIdealLoop::loop_predication_impl(IdealLoopTree*) [clone .part.0]+0x81b V [libjvm.so+0x1292d09] IdealLoopTree::loop_predication(PhaseIdealLoop*)+0x109 V [libjvm.so+0x1292c28] IdealLoopTree::loop_predication(PhaseIdealLoop*)+0x28 V [libjvm.so+0x12dd182] PhaseIdealLoop::build_and_optimize(LoopOptsMode)+0x1282 V [libjvm.so+0xa1bfbb] PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x32b V [libjvm.so+0xa182a6] Compile::Optimize()+0x586 V [libjvm.so+0xa1af60] Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, DirectiveSet*)+0x1840 V [libjvm.so+0x84a6bc] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1dc V [libjvm.so+0xa2afd8] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xe88 V [libjvm.so+0xa2bc28] CompileBroker::compiler_thread_loop()+0x5a8 V [libjvm.so+0x1856b66] JavaThread::thread_main_inner()+0x256 V [libjvm.so+0x185d570] Thread::call_run()+0x100 V [libjvm.so+0x1543f46] thread_native_entry(Thread*)+0x116 ------------- PR: https://git.openjdk.java.net/jdk/pull/2045 From ysuenaga at openjdk.java.net Tue Jan 19 09:00:47 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 19 Jan 2021 09:00:47 GMT Subject: Integrated: 8259035: Comments for load order of hsdis should be updated In-Reply-To: References: Message-ID: On Sun, 3 Jan 2021 04:46:10 GMT, Yasumasa Suenaga wrote: > Load order for hsdis is described in both src/utils/hsdis/README and src/hotspot/share/compiler/disassembler.cpp. README has been updated in [JDK-8215977](https://bugs.openjdk.java.net/browse/JDK-8215977), however disassembler.cpp has not been updated yet. This pull request has now been integrated. Changeset: 139f5d33 Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/139f5d33 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod 8259035: Comments for load order of hsdis should be updated Reviewed-by: thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/1919 From thartmann at openjdk.java.net Tue Jan 19 08:50:54 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 19 Jan 2021 08:50:54 GMT Subject: RFR: JDK-8259710: Inlining trace leaks memory [v2] In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 06:06:17 GMT, Thomas Stuefe wrote: >> We see C-heap leaking, originating in C2: >> >> 1434777 [0x00007f58214af461] stringStream::stringStream(unsigned long)+0x55 >> 1434778 [0x00007f5820c6db3e] Compile::PrintInliningBuffer::PrintInliningBuffer()+0x6c >> 1434779 [0x00007f5820c724f1] GrowableArrayWithAllocator >::grow(int)+0x163 >> 1434780 [0x00007f5820c7160e] GrowableArrayWithAllocator >::insert_before(int, Compile::PrintInliningBuffer const&)+0x82 >> 1434781 [0x00007f5820c6aaf2] Compile::print_inlining_push()+0x70 >> >> accumulating over the course of days to some hundred MB at a customer site where inline tracing was active. >> >> >> Analysis: >> >> >> To build up a comprehensive inlining trace, c2 keeps trace snippets in an internal list and assembles them at print time. These are stringStream's, contained in PrintInliningBuffer: >> >> GrowableArray* _print_inlining_list; >> ... >> class PrintInliningBuffer : public ResourceObj { >> private: >> CallGenerator* _cg; >> stringStream* _ss; >> >> public: >> PrintInliningBuffer() >> : _cg(NULL) { >> _ss = new stringStream(); >> } >> >> void freeStream() { >> _ss->~stringStream(); _ss = NULL; } >> ... >> }; >> >> With [JDK-8224193](https://bugs.openjdk.java.net/browse/JDK-8224193), stringStream was changed to use C-heap instead of ResourceArea for its internal buffer. This means one cannot just omit stringStream destruction anymore - even where stringStream objects themselves live in RA, their internal buffers don't, they live in C-Heap. To clean up properly, ~stringStream() must be called. >> >> Those `PrintInliningBuffer` objects are kept _by value_ in a GrowableArray `Compile::_print_inlining_list`. Normally, if an object is kept by value, it needs to implement correct copy- and destruction-semantics. PrintInliningBuffer does not do that and instead relies on manual cleanup (`PrintInliningBuffer::freeStream()`) - I assume the authors did not want to deal with reference counting the contained stringStream on copying. >> >> That however is a problem because GrowableArray creates internally temporary objects of the item type to pre-populate its array - its whole capacity - when it grows: >> >> >> template >> void GrowableArrayWithAllocator::grow(int j) { >> >> ... >> for ( ; i < this->_len; i++) ::new ((void*)&newData[i]) E(this->_data[i]); >> for ( ; i < this->_max; i++) ::new ((void*)&newData[i]) E(); <<<<<<< >> for (i = 0; i < old_max; i++) this->_data[i].~E(); >> ... >> } >> >> this it does for the whole new capacity, which means more objects get created than have been added; if the caller does not fill the GrowableArray up to its capacity, it never knows about the excess objects created. This is normally not a problem since all these objects are destructed by GrowableArray in `void GrowableArrayWithAllocator::clear_and_deallocate()`. But since PrintInliningBuffer does not implement a destructor, this has no effect. >> >> PrintInliningBuffer instead relies on manual cleanup of the stringStreams: at the end of the compile phase, it calls `PrintInliningBuffer::freeStream()` on all buffers it thinks are contained in the array: >> >> assert(_print_inlining_list != NULL, "process_print_inlining should be called only once."); >> for (int i = 0; i < _print_inlining_list->length(); i++) { >> ss.print("%s", _print_inlining_list->adr_at(i)->ss()->as_string()); >> _print_inlining_list->at(i).freeStream(); >> } >> >> but this of course leaves the excess objects untouched (objects whose index is array length >= index >= array capacity). >> >> ----------- >> >> There are several ways to fix this: >> >> 1) implement correct destructor- and copy semantics for PrintInliningBuffer. This would work but is not optimal since we would still pay for creation of unnecessary PrintInliningBuffer objects when the array is prepopulated on grow() >> >> 2) delay construction of `PrintInliningBuffer::_ss` until the stream is actually used for writing into. This would would mean we have to check the stringStream for NULL before using it. >> >> 3) Just let the PrintInliningBuffer live in C-heap instead of the RA. Its only a small shell anywhere now that the stringStream buffer lives in C-heap. Instead, let PrintInliningBuffer contain the stringStream as a member, allocate PrintInliningBuffer from C-heap, and change the list to contain pointers to PrintInliningBuffer, not the object itself. This removes all that unnecessary copying, removes creation of temporary objects, and simplifies the code. Having to free those objects is no big deal since we free the stringStream objects manually anyway. >> >> I went with (3). I also decreased the default stringStream buffer size for this scenario since when testing I found out that many trace snippets are below 128 bytes. >> >> Note that (3) is not only simpler, but also more efficient: many of the PrintInliningBuffer objects are inserted into the middle of the _print_inlining_list; GrowableArray does shift all higher items up to provide space for the new item. If those items are simple pointers instead of whole objects, less memory is moved around. >> >> Tests: >> - github actions >> - Nightlies at SAP >> - I manually tested the patch and compared the NMT output of a tracing scenario to verify that the leak went away and no other numbers changed >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > change return parameter of Compile::print_inlining_current() Thanks for updating. Looks good but you accidentally pushed `make/hs_err_pid10680.log`, `make/replay_pid10680.log` :) Best regards, Tobias ------------- Changes requested by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2063 From stuefe at openjdk.java.net Tue Jan 19 09:22:07 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 19 Jan 2021 09:22:07 GMT Subject: RFR: JDK-8259710: Inlining trace leaks memory [v2] In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 08:47:35 GMT, Tobias Hartmann wrote: > Thanks for updating. Looks good but you accidentally pushed `make/hs_err_pid10680.log`, `make/replay_pid10680.log` :) > > Best regards, > Tobias Oops. Corrected. Not my day today :) ------------- PR: https://git.openjdk.java.net/jdk/pull/2063 From stuefe at openjdk.java.net Tue Jan 19 09:22:07 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 19 Jan 2021 09:22:07 GMT Subject: RFR: JDK-8259710: Inlining trace leaks memory [v3] In-Reply-To: References: Message-ID: > We see C-heap leaking, originating in C2: > > 1434777 [0x00007f58214af461] stringStream::stringStream(unsigned long)+0x55 > 1434778 [0x00007f5820c6db3e] Compile::PrintInliningBuffer::PrintInliningBuffer()+0x6c > 1434779 [0x00007f5820c724f1] GrowableArrayWithAllocator >::grow(int)+0x163 > 1434780 [0x00007f5820c7160e] GrowableArrayWithAllocator >::insert_before(int, Compile::PrintInliningBuffer const&)+0x82 > 1434781 [0x00007f5820c6aaf2] Compile::print_inlining_push()+0x70 > > accumulating over the course of days to some hundred MB at a customer site where inline tracing was active. > > > Analysis: > > > To build up a comprehensive inlining trace, c2 keeps trace snippets in an internal list and assembles them at print time. These are stringStream's, contained in PrintInliningBuffer: > > GrowableArray* _print_inlining_list; > ... > class PrintInliningBuffer : public ResourceObj { > private: > CallGenerator* _cg; > stringStream* _ss; > > public: > PrintInliningBuffer() > : _cg(NULL) { > _ss = new stringStream(); > } > > void freeStream() { > _ss->~stringStream(); _ss = NULL; } > ... > }; > > With [JDK-8224193](https://bugs.openjdk.java.net/browse/JDK-8224193), stringStream was changed to use C-heap instead of ResourceArea for its internal buffer. This means one cannot just omit stringStream destruction anymore - even where stringStream objects themselves live in RA, their internal buffers don't, they live in C-Heap. To clean up properly, ~stringStream() must be called. > > Those `PrintInliningBuffer` objects are kept _by value_ in a GrowableArray `Compile::_print_inlining_list`. Normally, if an object is kept by value, it needs to implement correct copy- and destruction-semantics. PrintInliningBuffer does not do that and instead relies on manual cleanup (`PrintInliningBuffer::freeStream()`) - I assume the authors did not want to deal with reference counting the contained stringStream on copying. > > That however is a problem because GrowableArray creates internally temporary objects of the item type to pre-populate its array - its whole capacity - when it grows: > > > template > void GrowableArrayWithAllocator::grow(int j) { > > ... > for ( ; i < this->_len; i++) ::new ((void*)&newData[i]) E(this->_data[i]); > for ( ; i < this->_max; i++) ::new ((void*)&newData[i]) E(); <<<<<<< > for (i = 0; i < old_max; i++) this->_data[i].~E(); > ... > } > > this it does for the whole new capacity, which means more objects get created than have been added; if the caller does not fill the GrowableArray up to its capacity, it never knows about the excess objects created. This is normally not a problem since all these objects are destructed by GrowableArray in `void GrowableArrayWithAllocator::clear_and_deallocate()`. But since PrintInliningBuffer does not implement a destructor, this has no effect. > > PrintInliningBuffer instead relies on manual cleanup of the stringStreams: at the end of the compile phase, it calls `PrintInliningBuffer::freeStream()` on all buffers it thinks are contained in the array: > > assert(_print_inlining_list != NULL, "process_print_inlining should be called only once."); > for (int i = 0; i < _print_inlining_list->length(); i++) { > ss.print("%s", _print_inlining_list->adr_at(i)->ss()->as_string()); > _print_inlining_list->at(i).freeStream(); > } > > but this of course leaves the excess objects untouched (objects whose index is array length >= index >= array capacity). > > ----------- > > There are several ways to fix this: > > 1) implement correct destructor- and copy semantics for PrintInliningBuffer. This would work but is not optimal since we would still pay for creation of unnecessary PrintInliningBuffer objects when the array is prepopulated on grow() > > 2) delay construction of `PrintInliningBuffer::_ss` until the stream is actually used for writing into. This would would mean we have to check the stringStream for NULL before using it. > > 3) Just let the PrintInliningBuffer live in C-heap instead of the RA. Its only a small shell anywhere now that the stringStream buffer lives in C-heap. Instead, let PrintInliningBuffer contain the stringStream as a member, allocate PrintInliningBuffer from C-heap, and change the list to contain pointers to PrintInliningBuffer, not the object itself. This removes all that unnecessary copying, removes creation of temporary objects, and simplifies the code. Having to free those objects is no big deal since we free the stringStream objects manually anyway. > > I went with (3). I also decreased the default stringStream buffer size for this scenario since when testing I found out that many trace snippets are below 128 bytes. > > Note that (3) is not only simpler, but also more efficient: many of the PrintInliningBuffer objects are inserted into the middle of the _print_inlining_list; GrowableArray does shift all higher items up to provide space for the new item. If those items are simple pointers instead of whole objects, less memory is moved around. > > Tests: > - github actions > - Nightlies at SAP > - I manually tested the patch and compared the NMT output of a tracing scenario to verify that the leak went away and no other numbers changed > > Thanks, Thomas Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Remove accidental adds ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2063/files - new: https://git.openjdk.java.net/jdk/pull/2063/files/b52b140b..faa1e630 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2063&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2063&range=01-02 Stats: 2365 lines in 2 files changed: 0 ins; 2365 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2063.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2063/head:pull/2063 PR: https://git.openjdk.java.net/jdk/pull/2063 From shade at openjdk.java.net Tue Jan 19 09:47:04 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 19 Jan 2021 09:47:04 GMT Subject: RFR: 8259928: compiler/{aot,jvmci} tests fail with -Xint Message-ID: I was getting Zero VM close to run tier1, and before that I wanted to see that tier{1,2} pass with -Xint. Some test are failing due to timeouts, but compiler/{aot,jvmci} tests cannot run with -Xint at all. (Zero avoids this by not having VM feature flags "aot" and "jvmci"). Additional testing: - [x] `compiler/aot`, `compiler/jvmci` with `TEST_VM_OPTS=-Xint` (now disabled) - [x] `compiler/aot`, `compiler/jvmci` with default options (still run and pass) ------------- Commit messages: - Merge branch 'master' into JDK-8259928-aot-jvmci-Xint - 8259928: compiler/{aot,jvmci} tests fail with -Xint Changes: https://git.openjdk.java.net/jdk/pull/2132/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2132&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259928 Stats: 16 lines in 1 file changed: 12 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2132.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2132/head:pull/2132 PR: https://git.openjdk.java.net/jdk/pull/2132 From rcastanedalo at openjdk.java.net Tue Jan 19 09:52:55 2021 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Tue, 19 Jan 2021 09:52:55 GMT Subject: RFR: 8258894: C2: Forbid GCM to move stores into loops Message-ID: Prevent GCM from placing memory-writing nodes (such as stores) into loops deeper than their home loop (determined by their control input). Such placements are invalid, as they cause memory definitions to interfere, and risk causing miscompilations. This change complements [JDK-8255763](https://bugs.openjdk.java.net/browse/JDK-8255763), which only addresses invalid placements in irreducible CFGs. Add control input to stores in generated stubs to ensure that all memory-writing nodes have control inputs from which their home block can be derived. Add a battery of simplified fuzzer test cases where, before this change, GCM moves stores into deeper loops. Tested functionality on: - hs-tier1-5 (windows-x64, linux-x64, linux-aarch64, and macosx-x64; release and debug mode) - hs-tier6-9 (linux-x64, debug mode) Tested performance on a set of standard benchmark suites (DaCapo, Renaissance, SPECjbb2015, SPECjbb2005, SPECjvm2008, ...) and on windows-x64, linux-x64, and macosx-x64. No regression was observed, which is expected since this change only affects the placement of memory-writing nodes (which tends to be quite constrained already), and only forbids placements which would be typically detrimental for performance anyway (moving such nodes into deeper loops). ------------- Commit messages: - 8258894: C2: Forbid GCM to move stores into loops Changes: https://git.openjdk.java.net/jdk/pull/2140/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2140&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258894 Stats: 237 lines in 6 files changed: 195 ins; 2 del; 40 mod Patch: https://git.openjdk.java.net/jdk/pull/2140.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2140/head:pull/2140 PR: https://git.openjdk.java.net/jdk/pull/2140 From rcastanedalo at openjdk.java.net Tue Jan 19 09:52:55 2021 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Tue, 19 Jan 2021 09:52:55 GMT Subject: RFR: 8258894: C2: Forbid GCM to move stores into loops In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 08:32:42 GMT, Roberto Casta?eda Lozano wrote: > Prevent GCM from placing memory-writing nodes (such as stores) into loops deeper than their home loop (determined by their control input). Such placements are invalid, as they cause memory definitions to interfere, and risk causing miscompilations. This change complements [JDK-8255763](https://bugs.openjdk.java.net/browse/JDK-8255763), which only addresses invalid placements in irreducible CFGs. > > Add control input to stores in generated stubs to ensure that all memory-writing nodes have control inputs from which their home block can be derived. > > Add a battery of simplified fuzzer test cases where, before this change, GCM moves stores into deeper loops. > > Tested functionality on: > - hs-tier1-5 (windows-x64, linux-x64, linux-aarch64, and macosx-x64; release and debug mode) > - hs-tier6-9 (linux-x64, debug mode) > > Tested performance on a set of standard benchmark suites (DaCapo, Renaissance, SPECjbb2015, SPECjbb2005, SPECjvm2008, ...) and on windows-x64, linux-x64, and macosx-x64. No regression was observed, which is expected since this change only affects the placement of memory-writing nodes (which tends to be quite constrained already), and only forbids placements which would be typically detrimental for performance anyway (moving such nodes into deeper loops). Prevent GCM from placing memory-writing nodes (such as stores) into loops deeper than their home loop (determined by their control input). Such placements are invalid, as they cause memory definitions to interfere, and risk causing miscompilations. This change complements JDK-8255763, which only addresses invalid placements in irreducible CFGs. Add control input to stores in generated stubs to ensure that all memory-writing nodes have control inputs from which their home block can be derived. Add a battery of simplified fuzzer test cases where, before this change, GCM moves stores into deeper loops. ------------- PR: https://git.openjdk.java.net/jdk/pull/2140 From kvn at openjdk.java.net Tue Jan 19 19:15:42 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 19 Jan 2021 19:15:42 GMT Subject: RFR: 8259928: compiler/{aot,jvmci} tests fail with -Xint In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 14:39:05 GMT, Aleksey Shipilev wrote: > I was getting Zero VM close to run tier1, and before that I wanted to see that tier{1,2} pass with -Xint. Some test are failing due to timeouts, but compiler/{aot,jvmci} tests cannot run with -Xint at all. (Zero avoids this by not having VM feature flags "aot" and "jvmci"). > > Additional testing: > - [x] `compiler/aot`, `compiler/jvmci` with `TEST_VM_OPTS=-Xint` (now disabled) > - [x] `compiler/aot`, `compiler/jvmci` with default options (still run and pass) I would like to hear @iignatev opinion on this. `vm.aot` and `vm.jvmci` are checks for presence of JVMCI and AOT in JDK build. And you added VM flag check. In general I am fine with it because it avoids updating a lot of tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/2132 From iignatyev at openjdk.java.net Tue Jan 19 19:31:56 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 19 Jan 2021 19:31:56 GMT Subject: RFR: 8259928: compiler/{aot,jvmci} tests fail with -Xint In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 19:12:32 GMT, Vladimir Kozlov wrote: >> I was getting Zero VM close to run tier1, and before that I wanted to see that tier{1,2} pass with -Xint. Some test are failing due to timeouts, but compiler/{aot,jvmci} tests cannot run with -Xint at all. (Zero avoids this by not having VM feature flags "aot" and "jvmci"). >> >> Additional testing: >> - [x] `compiler/aot`, `compiler/jvmci` with `TEST_VM_OPTS=-Xint` (now disabled) >> - [x] `compiler/aot`, `compiler/jvmci` with default options (still run and pass) > > I would like to hear @iignatev opinion on this. `vm.aot` and `vm.jvmci` are checks for presence of JVMCI and AOT in JDK build. And you added VM flag check. > In general I am fine with it because it avoids updating a lot of tests. I highly doubt we need to update tests within `hotspot/compiler` directory to ignore obviously incompatible configuration, `-Xint`. they are compiler tests by definitions and having all of them saying `@requires vm.compMode != "Xint"` (or its equivalent) would be, to say the least, strange. as of the change, Vladimir is right, `vm.aot` and `vm.jvmci` properties represent build compatibility, and one can still enable jvmci with `-Xint` (granted it won't be used, but that's beyond the point here) hence it shouldn't depend on `Xint`. alternative if we change hotspot to disable jvmci flags when one specifies `Xint` or reports them as conflicted, then your changes would be fine. as wrt AOT, I actually see inability to use AOT together w/ -Xint as a product bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/2132 From mchung at openjdk.java.net Tue Jan 19 19:45:55 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 19 Jan 2021 19:45:55 GMT Subject: RFR: 8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException In-Reply-To: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com> References: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com> Message-ID: On Mon, 18 Jan 2021 12:09:23 GMT, Claes Redestad wrote: > Change `MethodHandles.byteArrayViewVarHandle` to throw `ArrayIndexOutOfBoundsException` rather than the more generic `IndexArrayOutOfBoundsException`. This feels more natural, and reduces the risk for subtle behavioral mismatch when migrating code from arrays/Unsafe to VHs. > > CSR: [JDK-8259912](https://bugs.openjdk.java.net/browse/JDK-8259912) The change to AIOOBE is reasonable. Have you considered making this just as an implementation change and leave the spec as is? ------------- PR: https://git.openjdk.java.net/jdk/pull/2124 From redestad at openjdk.java.net Tue Jan 19 20:33:49 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 19 Jan 2021 20:33:49 GMT Subject: RFR: 8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException In-Reply-To: References: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com> Message-ID: On Tue, 19 Jan 2021 19:42:38 GMT, Mandy Chung wrote: > The change to AIOOBE is reasonable. Have you considered making this just as an implementation change and leave the spec as is? What would be the benefits? AFAICT the CSR is still needed since it's a small behavioral change, and updating the spec helps communicate that change. ------------- PR: https://git.openjdk.java.net/jdk/pull/2124 From mandy.chung at oracle.com Tue Jan 19 20:45:33 2021 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 19 Jan 2021 12:45:33 -0800 Subject: RFR: 8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException In-Reply-To: References: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com> Message-ID: On 1/19/21 12:33 PM, Claes Redestad wrote: > On Tue, 19 Jan 2021 19:42:38 GMT, Mandy Chung wrote: > >> The change to AIOOBE is reasonable. Have you considered making this just as an implementation change and leave the spec as is? > What would be the benefits? AFAICT the CSR is still needed since it's a small behavioral change, and updating the spec helps communicate that change. > There is no behavioral change since AIIOBE is a subtype of OOBE.? No spec change and so no CSR is needed. Mandy From redestad at openjdk.java.net Tue Jan 19 21:02:50 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 19 Jan 2021 21:02:50 GMT Subject: RFR: 8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException In-Reply-To: References: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com> Message-ID: <-XDe9bewjmDiiXLXhMk-dSK7xveyopFdNn8r0-599bk=.d2a712cd-d338-47d8-aaaa-f8fb58bd34b8@github.com> On Tue, 19 Jan 2021 20:30:46 GMT, Claes Redestad wrote: >> The change to AIOOBE is reasonable. Have you considered making this just as an implementation change and leave the spec as is? > >> The change to AIOOBE is reasonable. Have you considered making this just as an implementation change and leave the spec as is? > > What would be the benefits? AFAICT the CSR is still needed since it's a small behavioral change, and updating the spec helps communicate that change. I agree the change is allowable within the current spec. The behavior change is observable, though, and however unlikely there might be code that relies on exact class of the exception being thrown. So while perhaps not strictly needed, the spec change makes sense coming from the other way: If I have some array-based code then that will be throwing AIOOBE on OOBs. But the `byteArrayViewVarHandle` code is specified to throw IOOBE, so a developer picking it up would have to catch and rewrap exceptions or accept the compatibility risk. Harmonizing to specify AIOOBE improves the migration story. Case in point is #1855 which require changes to some tests that are expecting AIOOBE. ------------- PR: https://git.openjdk.java.net/jdk/pull/2124 From mchung at openjdk.java.net Tue Jan 19 21:31:53 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 19 Jan 2021 21:31:53 GMT Subject: RFR: 8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException In-Reply-To: <-XDe9bewjmDiiXLXhMk-dSK7xveyopFdNn8r0-599bk=.d2a712cd-d338-47d8-aaaa-f8fb58bd34b8@github.com> References: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com> <-XDe9bewjmDiiXLXhMk-dSK7xveyopFdNn8r0-599bk=.d2a712cd-d338-47d8-aaaa-f8fb58bd34b8@github.com> Message-ID: On Tue, 19 Jan 2021 20:59:24 GMT, Claes Redestad wrote: > I agree the change is allowable within the current spec. The behavior change is observable, though, and however unlikely there might be code that relies on exact class of the exception being thrown. > So while perhaps not strictly needed, the spec change makes sense coming from the other way: If I have some array-based code then that will be throwing AIOOBE on OOBs. But the `byteArrayViewVarHandle` code is specified to throw IOOBE, so a developer picking it up would have to catch and rewrap exceptions or accept the compatibility risk. Harmonizing to specify AIOOBE improves the migration story. I don't think there is any migration story. The exception type is an improved clarity. The spec change is very minor and I'm okay with or without the spec change. > Case in point is #1855 which require changes to some tests that are expecting AIOOBE. Yes, that's what I was about to ask too. ------------- PR: https://git.openjdk.java.net/jdk/pull/2124 From github.com+7991079+danlemmond at openjdk.java.net Tue Jan 19 22:04:07 2021 From: github.com+7991079+danlemmond at openjdk.java.net (Dan) Date: Tue, 19 Jan 2021 22:04:07 GMT Subject: RFR: 8255216: ciEnv::_break_at_compile isn't in use [v4] In-Reply-To: References: Message-ID: > _break_at_compile is no longer in use and can be safely removed. > No new code, and Tier1 tests succeed after code is removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 Dan has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision: - Address PR feedback + comments Move to env()->break_at_compile() in compile.cpp - 8255216: ciEnv::_break_at_compile isn't in use _break_at_compile is no longer in use and can be safely removed. No new code, and Tier1 tests succeed after code is removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1806/files - new: https://git.openjdk.java.net/jdk/pull/1806/files/efbd3e45..990634b9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1806&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1806&range=02-03 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1806.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1806/head:pull/1806 PR: https://git.openjdk.java.net/jdk/pull/1806 From lutz.schmidt at sap.com Tue Jan 19 22:57:02 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Tue, 19 Jan 2021 22:57:02 +0000 Subject: 8259383: AsyncGetCallTrace() crashes sporadically Message-ID: <6007763D-3C05-49C5-AF11-13453EF04101@sap.com> Hi Chris, thank you for your review. Per your request/recommendation, I'll cross-post to hotspot-compiler-dev. On the other hand, I've been working recently in just that corner of CodeHeap/CodeCache. As the access to VM data structures via AsyncGetCallTrace() is asynchronous (the name suggests it), you may see inconsistent states. You have to deal with such inconsistencies. Furthermore, a direct colleague of mine did in-depth research on Async Profiler. I consulted with him. Anyway, thanks again! Lutz ?On 19.01.21, 23:26, "hotspot-dev on behalf of Chris Plummer" wrote: On Mon, 11 Jan 2021 18:39:41 GMT, Lutz Schmidt wrote: > Hi, > may I please ask the community to review this small fix? It closes another hole in AsyncGetCallTrace(). > Thanks a lot! > Lutz The changes look ok to me. I think it would be good to get someone from the compiler team to verify your reasoning here. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2032 From github.com+7991079+danlemmond at openjdk.java.net Wed Jan 20 01:31:07 2021 From: github.com+7991079+danlemmond at openjdk.java.net (Dan) Date: Wed, 20 Jan 2021 01:31:07 GMT Subject: RFR: 8255216: ciEnv::_break_at_compile isn't in use [v5] In-Reply-To: References: Message-ID: > _break_at_compile is no longer in use and can be safely removed. > No new code, and Tier1 tests succeed after code is removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 Dan has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision: - Revert "8255216: ciEnv::_break_at_compile isn't in use" This reverts commit 4b783cca567ed2bb11e362144fa67bfd9d9cd043. - Address PR feedback + comments Move to env()->break_at_compile() in compile.cpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1806/files - new: https://git.openjdk.java.net/jdk/pull/1806/files/990634b9..41d01c05 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1806&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1806&range=03-04 Stats: 11 lines in 3 files changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1806.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1806/head:pull/1806 PR: https://git.openjdk.java.net/jdk/pull/1806 From xliu at openjdk.java.net Wed Jan 20 01:31:07 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 20 Jan 2021 01:31:07 GMT Subject: RFR: 8255216: ciEnv::_break_at_compile isn't in use In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 18:38:37 GMT, Dan wrote: > _break_at_compile is no longer in use and can be safely removed. > No new code, and Tier1 tests succeed after code is removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 @danlemmond , I understand Kozlov's comment. your change 36bc753 covers c2's optimization. There are another 2 places refer to _directive->BreakAtCompileOption. I think you need to change them to env()-> break_at_compile as well. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/c1/c1_Compilation.cpp#L449 https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/compile.cpp#L506 ------------- PR: https://git.openjdk.java.net/jdk/pull/1806 From github.com+1749416+apangin at openjdk.java.net Wed Jan 20 03:44:55 2021 From: github.com+1749416+apangin at openjdk.java.net (Andrei Pangin) Date: Wed, 20 Jan 2021 03:44:55 GMT Subject: RFR: 8259383: AsyncGetCallTrace() crashes sporadically In-Reply-To: References: <55VhodtLlLULjpxGm3PXOn2iFgrVIdqcZwysOSEK8rg=.d1571446-fc26-4b7d-9450-29ecacb31dda@github.com> Message-ID: On Tue, 19 Jan 2021 22:23:38 GMT, Chris Plummer wrote: >> Hi, >> may I please ask the community to review this small fix? It closes another hole in AsyncGetCallTrace(). >> Thanks a lot! >> Lutz > > The changes look ok to me. I think it would be good to get someone from the compiler team to verify your reasoning here. Hi Lutz, Thank you for working on this issue. I'm not a formal OpenJDK Reviewer, but as an author of async-profiler project (which heavily relies on AsyncGetCallTrace), I'm more or less familiar with this code. Let me leave a few comments. 1. The statement `if (candidate.pc() != NULL) return false;` looks a bit odd to me. When a profiler calls AsyncGetCallTrace, pc of the initial frame is obtained from a signal context, and it is never NULL. Returning false when pc != NULL basically invalidates the entire `if (fr->cb() == NULL)` branch. If this was intended, the branch could be simplified. 2. At the same time, returning false whenever cb == NULL, discards a fair amount of valid stack traces, e.g. when a runtime function is called from Java without switching to in_vm state. I guess, the original intention of that loop was to handle such cases, but, as you noticed, it does not currently work well because of the assertions. I'd rather prefer revising the logic of that loop then instead of dropping all those valid samples. 3. What I don't really understand from the bug report is why `if (fr->cb() == NULL)` branch is executed at all in this particular example. According to the stack trace from the crash dump, the top frame (before a signal handler) is `ThreadCritical::~ThreadCritical()`. This means, a thread is in_vm state, and its last_Java_frame should have been set. In this case AsyncGetCallTrace prefers to take last_Java_frame, and thus cb should be non-NULL. Another suspicious thing is that a frame below `ThreadCritical::~ThreadCritical()` is not a C frame. This cannot normally happen (the execution is in the middle of `ThreadCritical::~ThreadCritical()`, where the stack frame is consistent). These facts make me think something bad has already happened with the stack earlier, and the failed guarantee is probably just one manifestation of a bigger problem. ------------- PR: https://git.openjdk.java.net/jdk/pull/2032 From roland at openjdk.java.net Wed Jan 20 07:44:12 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Wed, 20 Jan 2021 07:44:12 GMT Subject: RFR: 8259609: C2: optimize long range checks in long counted loops [v3] In-Reply-To: References: Message-ID: > JDK-8255150 makes it possible for java code to explicitly perform a > range check on long values. JDK-8223051 provides a transformation of > long counted loops into loop nests with an inner int counted > loop. With this change I propose transforming long range checks that > operate on the iv of a long counted loop into range checks that > operate on the iv of the int inner loop once it has been > created. Existing range check eliminations can then kick in. > > Transformation of range checks is piggy backed on the loop nest > creation for 2 reasons: > > - pattern matching range checks is easier right before the loop nest > is created > > - the number of iterations of the inner loop is adjusted so scale * > inner_iv doesn't overflow > > C2 has logic to delay some split if transformations so they don't > break the scale * iv + offset pattern. I reused that logic for long > range checks and had to relax what's considered a range check because > initially a range check from Object.checkIndex() may include a test > for range > 0 that needs a round of loop opts to be hoisted. I realize > there's some code duplication but I didn't see a way to share logic > between IdealLoopTree::may_have_range_check() > IdealLoopTree::policy_range_check() that would feel right. > > I realize the comment in PhaseIdealLoop::transform_long_range_checks() > is scary. FWIW, it's not as complicated as it looks. I found drawing > the range covered by the entire long loop and the range covered by the > inner loop help see how range checks can be transformed. Then the > comment helps make sure all cases are covered and verify the generated > code actually covers all of them. > > One issue is overflow. I think the fact that inner_iv * scale doesn't > overflow helps simplify thing. One possible overflow is that of scale > * upper + offset which is handled by forcing all range checks in that > case to deoptimize. I don't think other case of overflow needs special > handling. > > This was tested with a Memory Segment micro benchmark (and patched > Memory Segment support to take advantage of the new checkIndex > intrinsic, both provided by Maurizio). Range checks in the micro > benchmark are properly optimized (and performance increases > significantly). Roland Westrelin has updated the pull request incrementally with two additional commits since the last revision: - min_jint overflow fix - Revert "assert(static_cast(result) == thing) fix" This reverts commit e234477df097475d503ea6f94ab6a258132d165e. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2045/files - new: https://git.openjdk.java.net/jdk/pull/2045/files/ed7390f1..afdbdea6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2045&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2045&range=01-02 Stats: 70 lines in 3 files changed: 68 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2045.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2045/head:pull/2045 PR: https://git.openjdk.java.net/jdk/pull/2045 From roland at openjdk.java.net Wed Jan 20 07:48:56 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Wed, 20 Jan 2021 07:48:56 GMT Subject: RFR: 8259609: C2: optimize long range checks in long counted loops In-Reply-To: <1kBolNZOhOFBD5aNq5rLF8RheC37JN794IJFy9Tf_UM=.f25e5227-03ee-465a-97a1-3fb886b79a43@github.com> References: <1kBolNZOhOFBD5aNq5rLF8RheC37JN794IJFy9Tf_UM=.f25e5227-03ee-465a-97a1-3fb886b79a43@github.com> Message-ID: On Tue, 19 Jan 2021 08:57:28 GMT, Tobias Hartmann wrote: > I'm now seeing this with the same test at a higher tier (and therefore different flags): Fixed and added a test case that covers this issue ------------- PR: https://git.openjdk.java.net/jdk/pull/2045 From thartmann at openjdk.java.net Wed Jan 20 08:12:51 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 20 Jan 2021 08:12:51 GMT Subject: RFR: JDK-8259710: Inlining trace leaks memory [v3] In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 09:22:07 GMT, Thomas Stuefe wrote: >> We see C-heap leaking, originating in C2: >> >> 1434777 [0x00007f58214af461] stringStream::stringStream(unsigned long)+0x55 >> 1434778 [0x00007f5820c6db3e] Compile::PrintInliningBuffer::PrintInliningBuffer()+0x6c >> 1434779 [0x00007f5820c724f1] GrowableArrayWithAllocator >::grow(int)+0x163 >> 1434780 [0x00007f5820c7160e] GrowableArrayWithAllocator >::insert_before(int, Compile::PrintInliningBuffer const&)+0x82 >> 1434781 [0x00007f5820c6aaf2] Compile::print_inlining_push()+0x70 >> >> accumulating over the course of days to some hundred MB at a customer site where inline tracing was active. >> >> >> Analysis: >> >> >> To build up a comprehensive inlining trace, c2 keeps trace snippets in an internal list and assembles them at print time. These are stringStream's, contained in PrintInliningBuffer: >> >> GrowableArray* _print_inlining_list; >> ... >> class PrintInliningBuffer : public ResourceObj { >> private: >> CallGenerator* _cg; >> stringStream* _ss; >> >> public: >> PrintInliningBuffer() >> : _cg(NULL) { >> _ss = new stringStream(); >> } >> >> void freeStream() { >> _ss->~stringStream(); _ss = NULL; } >> ... >> }; >> >> With [JDK-8224193](https://bugs.openjdk.java.net/browse/JDK-8224193), stringStream was changed to use C-heap instead of ResourceArea for its internal buffer. This means one cannot just omit stringStream destruction anymore - even where stringStream objects themselves live in RA, their internal buffers don't, they live in C-Heap. To clean up properly, ~stringStream() must be called. >> >> Those `PrintInliningBuffer` objects are kept _by value_ in a GrowableArray `Compile::_print_inlining_list`. Normally, if an object is kept by value, it needs to implement correct copy- and destruction-semantics. PrintInliningBuffer does not do that and instead relies on manual cleanup (`PrintInliningBuffer::freeStream()`) - I assume the authors did not want to deal with reference counting the contained stringStream on copying. >> >> That however is a problem because GrowableArray creates internally temporary objects of the item type to pre-populate its array - its whole capacity - when it grows: >> >> >> template >> void GrowableArrayWithAllocator::grow(int j) { >> >> ... >> for ( ; i < this->_len; i++) ::new ((void*)&newData[i]) E(this->_data[i]); >> for ( ; i < this->_max; i++) ::new ((void*)&newData[i]) E(); <<<<<<< >> for (i = 0; i < old_max; i++) this->_data[i].~E(); >> ... >> } >> >> this it does for the whole new capacity, which means more objects get created than have been added; if the caller does not fill the GrowableArray up to its capacity, it never knows about the excess objects created. This is normally not a problem since all these objects are destructed by GrowableArray in `void GrowableArrayWithAllocator::clear_and_deallocate()`. But since PrintInliningBuffer does not implement a destructor, this has no effect. >> >> PrintInliningBuffer instead relies on manual cleanup of the stringStreams: at the end of the compile phase, it calls `PrintInliningBuffer::freeStream()` on all buffers it thinks are contained in the array: >> >> assert(_print_inlining_list != NULL, "process_print_inlining should be called only once."); >> for (int i = 0; i < _print_inlining_list->length(); i++) { >> ss.print("%s", _print_inlining_list->adr_at(i)->ss()->as_string()); >> _print_inlining_list->at(i).freeStream(); >> } >> >> but this of course leaves the excess objects untouched (objects whose index is array length >= index >= array capacity). >> >> ----------- >> >> There are several ways to fix this: >> >> 1) implement correct destructor- and copy semantics for PrintInliningBuffer. This would work but is not optimal since we would still pay for creation of unnecessary PrintInliningBuffer objects when the array is prepopulated on grow() >> >> 2) delay construction of `PrintInliningBuffer::_ss` until the stream is actually used for writing into. This would would mean we have to check the stringStream for NULL before using it. >> >> 3) Just let the PrintInliningBuffer live in C-heap instead of the RA. Its only a small shell anywhere now that the stringStream buffer lives in C-heap. Instead, let PrintInliningBuffer contain the stringStream as a member, allocate PrintInliningBuffer from C-heap, and change the list to contain pointers to PrintInliningBuffer, not the object itself. This removes all that unnecessary copying, removes creation of temporary objects, and simplifies the code. Having to free those objects is no big deal since we free the stringStream objects manually anyway. >> >> I went with (3). I also decreased the default stringStream buffer size for this scenario since when testing I found out that many trace snippets are below 128 bytes. >> >> Note that (3) is not only simpler, but also more efficient: many of the PrintInliningBuffer objects are inserted into the middle of the _print_inlining_list; GrowableArray does shift all higher items up to provide space for the new item. If those items are simple pointers instead of whole objects, less memory is moved around. >> >> Tests: >> - github actions >> - Nightlies at SAP >> - I manually tested the patch and compared the NMT output of a tracing scenario to verify that the leak went away and no other numbers changed >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Remove accidental adds Marked as reviewed by thartmann (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2063 From shade at openjdk.java.net Wed Jan 20 08:26:53 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 20 Jan 2021 08:26:53 GMT Subject: RFR: 8259928: compiler/{aot,jvmci} tests fail with -Xint In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 19:29:09 GMT, Igor Ignatyev wrote: > alternative if we change hotspot to disable jvmci flags when one specifies `Xint` or reports them as conflicted, then your changes would be fine. If you run `compiler/jvmci` or `compiler/aot` tests with `-Xint`, then VM would already say: $ CONF=linux-x86_64-server-fastdebug make images run-test TEST=compiler/aot TEST_VM_OPTS=-Xint ... OpenJDK 64-Bit Server VM warning: JVMCI Compiler disabled due to -Xint. Exception in thread "main" java.lang.Error: The EnableJVMCI VM option must be true (i.e., -XX:+EnableJVMCI) to use JVMCI at jdk.internal.vm.ci/jdk.vm.ci.services.Services.checkJVMCIEnabled(Services.java:83) at jdk.internal.vm.ci/jdk.vm.ci.services.Services.getSavedProperties(Services.java:91) at jdk.internal.vm.ci/jdk.vm.ci.services.Services.getSavedProperty(Services.java:123) at jdk.internal.vm.ci/jdk.vm.ci.common.InitTimer.isEnabled(InitTimer.java:76) at jdk.internal.vm.ci/jdk.vm.ci.common.InitTimer.timer(InitTimer.java:63) at jdk.internal.vm.compiler at 17-internal/org.graalvm.compiler.hotspot.HotSpotGraalOptionValues.parseOptions(HotSpotGraalOptionValues.java:102) at jdk.internal.vm.compiler at 17-internal/org.graalvm.compiler.hotspot.HotSpotGraalOptionValues.initializeOptions(HotSpotGraalOptionValues.java:156) at jdk.internal.vm.compiler at 17-internal/org.graalvm.compiler.hotspot.HotSpotGraalOptionValues.defaultOptions(HotSpotGraalOptionValues.java:84) at jdk.aot at 17-internal/jdk.tools.jaotc.Main.run(Main.java:173) at jdk.aot at 17-internal/jdk.tools.jaotc.Main.run(Main.java:136) at jdk.aot at 17-internal/jdk.tools.jaotc.Main.main(Main.java:92) It seems to me that using AOT implies using JVMCI? ------------- PR: https://git.openjdk.java.net/jdk/pull/2132 From martin.doerr at sap.com Wed Jan 20 10:33:31 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 20 Jan 2021 10:33:31 +0000 Subject: [11u] RFR: 8247691: [aarch64] Incorrect handling of VM exceptions in C1 deopt stub/traps Message-ID: Hi, JDK-8247691 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly. I had to apply 2 parts manually: c1_Runtime1_aarch64.cpp: The code which gets replaced by this change contains differences. I've resolved it such that it matches the new version exactly. Note that aarch64 uses DEOPTIMIZE_WHEN_PATCHING so it always deoptimizes instead of performing the patching as done by other platforms. deoptimization.cpp: Integrated assertion manually due to unrelated context changes. Bug: https://bugs.openjdk.java.net/browse/JDK-8247691 Original change: https://git.openjdk.java.net/jdk/commit/7817963c 11u backport: http://cr.openjdk.java.net/~mdoerr/8247691_aarch64_11u/webrev.00/ Please review. Best regards, Martin From jiefu at openjdk.java.net Wed Jan 20 11:26:47 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 20 Jan 2021 11:26:47 GMT Subject: [jdk16] RFR: 8259775: [Vector API] Incorrect code-gen for VectorReinterpret operation In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 12:32:41 GMT, Jie Fu wrote: > Hi all, > > The code-gen for VectorReinterpret may be wrong on x86. > > Let's see the opto-assembly for the reproducer in the JBS, which was actually based on @XiaohongGong 's example in JDK-8259353 and many thanks to her. > 066 B7: # out( N1 ) <- in( B6 ) Freq: 0.999994 > 066 vector_reinterpret_expand XMM0,XMM0 ! > 066 store_vector [R12 + R11 << 3 + #16] (compressed oop addressing),XMM0 > > Please note that the dst and src [1] share the same XMM0 register and movdqu [2] should be generated for this case. > But when dst == src, movdqu actually generates nothing [3], which leads to incorrect result; > > For this case, movdqu should not be empty since the upper bits of dst should be zeroed. > The similar error also exists for vmovdqu [4]. > > I think we should also change movflt [5] to movss but I just can't understand why we have 4-byte vectors. > Isn't the shortest vectors 8-byte on x86? > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3354 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3364 > [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2490 > [4] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2515 > [5] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3379 Hi all, The reason for the wrong execution is that the upper bits of vector registers fails to be zeroed. This is because movdqu(XMMRegister dst, XMMRegister src) and vmovdqu(XMMRegister dst, XMMRegister src) were incorrectly optimized when dst == src after JDK-8223347 (Integration of Vector API, Oct 14 20:02:46 2020). So this seems to be a regression of JDK-8223347. The 4-byte vectors also be fixed by using movfltz since we are not recommended to use movss directly [1]. And the jtreg test has been added to reproduce this bug on both AVX256 and AVX512 machines. Could you please review it? Thanks. Best regards, Jie [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.hpp#L1048 ------------- PR: https://git.openjdk.java.net/jdk16/pull/122 From chagedorn at openjdk.java.net Wed Jan 20 12:16:56 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Wed, 20 Jan 2021 12:16:56 GMT Subject: RFR: 8257498: Remove useless skeleton predicates [v2] In-Reply-To: References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com> Message-ID: On Tue, 19 Jan 2021 08:19:00 GMT, Roland Westrelin wrote: >> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: >> >> Add handling of Deoptimization::Reason_profile_predicate > > src/hotspot/share/opto/loopPredicate.cpp line 280: > >> 278: // Put all skeleton predicate projections on a list, starting at 'predicate' and going up in the tree. If 'get_opaque' >> 279: // is set, then the Opaque4 nodes of the skeleton predicates are put on the list instead of the projections. >> 280: void PhaseIdealLoop::get_skeleton_predicates(Node* predicate, Unique_Node_List& list, bool get_opaque) { > > I would remove the get_opaque parameter, populate the list with projections (the get_opaque false case) and have the caller retrieve the opaque node (predicate->in(0)->in(1)) if that's what it needs. Okay, I updated it and removed the `get_opaque` flag. > src/hotspot/share/opto/loopnode.cpp line 3601: > >> 3599: assert(n->Opcode() == Op_Opaque4, "must be"); >> 3600: if (!useful_predicates.member(n)) { // not in the useful list >> 3601: C->remove_skeleton_predicate_opaque4_node(idx); > > Usually when nodes are kept in a global list, when a node dies, the node is removed from the list. It's the case of Compile::_predicate_opaqs for instance. So when the logic here iterates over _predicate_opaqs and removes some of them from the graph, the node is automatically removed from the _predicate_opaqs list. I don't see similar logic for skeleton Opaque4 nodes. I think it's a problem because you could end up with a node in the list that was removed from the graph (because that part of the graph is dead) and freed from memory (which could cause a crash). That's true. I have not considered that. I updated it to remove it in the same way as we are removing other nodes as for example expensive nodes. ------------- PR: https://git.openjdk.java.net/jdk/pull/2075 From jvernee at openjdk.java.net Wed Jan 20 12:25:47 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 20 Jan 2021 12:25:47 GMT Subject: RFR: 8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException In-Reply-To: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com> References: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com> Message-ID: On Mon, 18 Jan 2021 12:09:23 GMT, Claes Redestad wrote: > Change `MethodHandles.byteArrayViewVarHandle` to throw `ArrayIndexOutOfBoundsException` rather than the more generic `IndexArrayOutOfBoundsException`. This feels more natural, and reduces the risk for subtle behavioral mismatch when migrating code from arrays/Unsafe to VHs. > > CSR: [JDK-8259912](https://bugs.openjdk.java.net/browse/JDK-8259912) Marked as reviewed by jvernee (Committer). src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4374: > 4372: *

> 4373: * Access of bytes at a given index will result in an > 4374: * {@code ArrayIndexOutOfBoundsException} if the index is less than {@code 0} Should the copyright year of this file also be updated? ------------- PR: https://git.openjdk.java.net/jdk/pull/2124 From chagedorn at openjdk.java.net Wed Jan 20 12:30:12 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Wed, 20 Jan 2021 12:30:12 GMT Subject: RFR: 8257498: Remove useless skeleton predicates [v3] In-Reply-To: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com> References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com> Message-ID: > This enhancement removes useless skeleton predicates in the same way as we already remove normal useless predicates in `PhaseIdealLoop::eliminate_useless_predicates()`. > > Thanks, > Christian Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: Fix removal from global list and update get_skeleton_predicates ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2075/files - new: https://git.openjdk.java.net/jdk/pull/2075/files/0ed11ba9..5b716bc5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2075&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2075&range=01-02 Stats: 39 lines in 6 files changed: 23 ins; 9 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/2075.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2075/head:pull/2075 PR: https://git.openjdk.java.net/jdk/pull/2075 From rbackman at openjdk.java.net Wed Jan 20 13:36:45 2021 From: rbackman at openjdk.java.net (Rickard =?UTF-8?B?QsOkY2ttYW4=?=) Date: Wed, 20 Jan 2021 13:36:45 GMT Subject: [jdk16] RFR: 8259775: [Vector API] Incorrect code-gen for VectorReinterpret operation [v5] In-Reply-To: <5ZRm7yr18uW4HQWoMQHlI1CHdqUa70mbcj7r6PkROKU=.e5991488-7d71-4657-95c3-8a034b654db6@github.com> References: <5ZRm7yr18uW4HQWoMQHlI1CHdqUa70mbcj7r6PkROKU=.e5991488-7d71-4657-95c3-8a034b654db6@github.com> Message-ID: On Tue, 19 Jan 2021 03:57:16 GMT, Jie Fu wrote: >> Hi all, >> >> The code-gen for VectorReinterpret may be wrong on x86. >> >> Let's see the opto-assembly for the reproducer in the JBS, which was actually based on @XiaohongGong 's example in JDK-8259353 and many thanks to her. >> 066 B7: # out( N1 ) <- in( B6 ) Freq: 0.999994 >> 066 vector_reinterpret_expand XMM0,XMM0 ! >> 066 store_vector [R12 + R11 << 3 + #16] (compressed oop addressing),XMM0 >> >> Please note that the dst and src [1] share the same XMM0 register and movdqu [2] should be generated for this case. >> But when dst == src, movdqu actually generates nothing [3], which leads to incorrect result; >> >> For this case, movdqu should not be empty since the upper bits of dst should be zeroed. >> The similar error also exists for vmovdqu [4]. >> >> I think we should also change movflt [5] to movss but I just can't understand why we have 4-byte vectors. >> Isn't the shortest vectors 8-byte on x86? >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3354 >> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3364 >> [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2490 >> [4] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2515 >> [5] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3379 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Refine the test to always reproduce the bug Marked as reviewed by rbackman (Reviewer). Marked as reviewed by rbackman (Reviewer). Marked as reviewed by rbackman (Reviewer). Marked as reviewed by rbackman (Reviewer). Marked as reviewed by rbackman (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/122 From neliasso at openjdk.java.net Wed Jan 20 15:14:46 2021 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Wed, 20 Jan 2021 15:14:46 GMT Subject: [jdk16] RFR: 8259775: [Vector API] Incorrect code-gen for VectorReinterpret operation [v5] In-Reply-To: <5ZRm7yr18uW4HQWoMQHlI1CHdqUa70mbcj7r6PkROKU=.e5991488-7d71-4657-95c3-8a034b654db6@github.com> References: <5ZRm7yr18uW4HQWoMQHlI1CHdqUa70mbcj7r6PkROKU=.e5991488-7d71-4657-95c3-8a034b654db6@github.com> Message-ID: <-5fiDFlWe8ATyjGf_S6Bb4E5HhA7aFFzm3FK8clzeuw=.c6a4980d-6d2a-4f5d-b22a-3044aa76f7a3@github.com> On Tue, 19 Jan 2021 03:57:16 GMT, Jie Fu wrote: >> Hi all, >> >> The code-gen for VectorReinterpret may be wrong on x86. >> >> Let's see the opto-assembly for the reproducer in the JBS, which was actually based on @XiaohongGong 's example in JDK-8259353 and many thanks to her. >> 066 B7: # out( N1 ) <- in( B6 ) Freq: 0.999994 >> 066 vector_reinterpret_expand XMM0,XMM0 ! >> 066 store_vector [R12 + R11 << 3 + #16] (compressed oop addressing),XMM0 >> >> Please note that the dst and src [1] share the same XMM0 register and movdqu [2] should be generated for this case. >> But when dst == src, movdqu actually generates nothing [3], which leads to incorrect result; >> >> For this case, movdqu should not be empty since the upper bits of dst should be zeroed. >> The similar error also exists for vmovdqu [4]. >> >> I think we should also change movflt [5] to movss but I just can't understand why we have 4-byte vectors. >> Isn't the shortest vectors 8-byte on x86? >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3354 >> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3364 >> [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2490 >> [4] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2515 >> [5] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3379 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Refine the test to always reproduce the bug Good to know that the code was introduced in 16 so that no regression is introduced. Approved. ------------- Marked as reviewed by neliasso (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/122 From iignatyev at openjdk.java.net Wed Jan 20 16:12:55 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 20 Jan 2021 16:12:55 GMT Subject: RFR: 8259928: compiler/{aot,jvmci} tests fail with -Xint In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 08:23:26 GMT, Aleksey Shipilev wrote: >> I highly doubt we need to update tests within `hotspot/compiler` directory to ignore obviously incompatible configuration, `-Xint`. they are compiler tests by definitions and having all of them saying `@requires vm.compMode != "Xint"` (or its equivalent) would be, to say the least, strange. >> >> as of the change, Vladimir is right, `vm.aot` and `vm.jvmci` properties represent build compatibility, and one can still enable jvmci with `-Xint` (granted it won't be used, but that's beyond the point here) hence it shouldn't depend on `Xint`. alternative if we change hotspot to disable jvmci flags when one specifies `Xint` or reports them as conflicted, then your changes would be fine. as wrt AOT, I actually see inability to use AOT together w/ -Xint as a product bug. > >> alternative if we change hotspot to disable jvmci flags when one specifies `Xint` or reports them as conflicted, then your changes would be fine. > > If you run `compiler/jvmci` or `compiler/aot` tests with `-Xint`, then VM would already say: > > $ CONF=linux-x86_64-server-fastdebug make images run-test TEST=compiler/aot TEST_VM_OPTS=-Xint > ... > OpenJDK 64-Bit Server VM warning: JVMCI Compiler disabled due to -Xint. > Exception in thread "main" java.lang.Error: The EnableJVMCI VM option must be true (i.e., -XX:+EnableJVMCI) to use JVMCI > at jdk.internal.vm.ci/jdk.vm.ci.services.Services.checkJVMCIEnabled(Services.java:83) > at jdk.internal.vm.ci/jdk.vm.ci.services.Services.getSavedProperties(Services.java:91) > at jdk.internal.vm.ci/jdk.vm.ci.services.Services.getSavedProperty(Services.java:123) > at jdk.internal.vm.ci/jdk.vm.ci.common.InitTimer.isEnabled(InitTimer.java:76) > at jdk.internal.vm.ci/jdk.vm.ci.common.InitTimer.timer(InitTimer.java:63) > at jdk.internal.vm.compiler at 17-internal/org.graalvm.compiler.hotspot.HotSpotGraalOptionValues.parseOptions(HotSpotGraalOptionValues.java:102) > at jdk.internal.vm.compiler at 17-internal/org.graalvm.compiler.hotspot.HotSpotGraalOptionValues.initializeOptions(HotSpotGraalOptionValues.java:156) > at jdk.internal.vm.compiler at 17-internal/org.graalvm.compiler.hotspot.HotSpotGraalOptionValues.defaultOptions(HotSpotGraalOptionValues.java:84) > at jdk.aot at 17-internal/jdk.tools.jaotc.Main.run(Main.java:173) > at jdk.aot at 17-internal/jdk.tools.jaotc.Main.run(Main.java:136) > at jdk.aot at 17-internal/jdk.tools.jaotc.Main.main(Main.java:92) > > It seems to me that using AOT implies using JVMCI, and JVMCI is disabled at runtime when `-Xint` is supplied. So the change to `vm.aot` and `vm.jvmci` reflects that? I can make it a bit cleaner by checking in `vm.aot` if `vm.jvmci` is enabled. oh, I see what happened: when I checked if you can enable jvmci w/ `-Xint`, I looked at `UseJVMCICompiler`, which you can enable by some reason, but `EnableJVMCI` will be set to false when you use `-Xint`, so I agree that `vm.jvmci` should check for `-Xint` flag. it might make sense to change this behavior and set all jvmci flags to false whenever `Xint` is used. for `vm.aot`, I still think it's a product bug if one can't run `jaotc` w/ `Xint`. @vnkozlov, what do you think? on top of that, I also think that we have a test bug, as options like `Xint` should not be passed to `jaotc` in the majority of aot tests. I'll take closer look at them later today. Cheers, -- Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/2132 From kvn at openjdk.java.net Wed Jan 20 17:04:54 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 20 Jan 2021 17:04:54 GMT Subject: RFR: 8259928: compiler/{aot,jvmci} tests fail with -Xint In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 16:10:11 GMT, Igor Ignatyev wrote: > oh, I see what happened: when I checked if you can enable jvmci w/ `-Xint`, I looked at `UseJVMCICompiler`, which you can enable by some reason, but `EnableJVMCI` will be set to false when you use `-Xint`, so I agree that `vm.jvmci` should check for `-Xint` flag. it might make sense to change this behavior and set all jvmci flags to false whenever `Xint` is used. > > for `vm.aot`, I still think it's a product bug if one can't run `jaotc` w/ `Xint`. @vnkozlov, what do you think? > on top of that, I also think that we have a test bug, as options like `Xint` should not be passed to `jaotc` in the majority of aot tests. I'll take closer look at them later today. > > Cheers, > -- Igor JAOTC tool requires JVMCI because it use it with Graal. JAOTC launcher explicitly enable JVMCI. We may need to add `-Xmixed` there: https://github.com/openjdk/jdk/blob/master/make/modules/jdk.aot/Launcher.gmk#L33 But most AOT tests use AOT compiler wrapper which sets `-Xmixed` (to avoid running with `-Xcomp`): https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/aot/AotCompiler.java#L120 So I am not sure why -Xint overwrite -Xmixed in AOT tests in your example. I used jtreg to run AOT test and it passed: $ jtreg -testjdk:/scratch/jdk15u/build/fastdebug/images/jdk/ -va -javaoptions:'-server -Xint' compiler/aot/DeoptimizationTest.java ... Command line: [/scratch/jdk15u/build/fastdebug/images/jdk/bin/jaotc -J-server -J-Xint -J-XX:-UseCompressedOops -J-classpath -J/scratch/jdk15u/open/test/hotspot/jtreg/JTwork/classes/compiler/aot/DeoptimizationTest.d:/scratch/jdk15u/open/test/hotspot/jtreg/JTwork/classes/test/lib:/scratch/jdk15u/open/test/hotspot/jtreg/JTwork/classes/testlibrary:/scratch/jdk15u/open/test/hotspot/jtreg/JTwork/classes:/scratch/jdk15u/open/test/hotspot/jtreg/compiler/aot --compile-with-assertions --info --output libDeoptimizationTest.so --compile-commands methodsList.txt --class-name compiler.aot.DeoptimizationTest -J-ea -J-esa -J-Xmixed] I can't test with JDK 16 and latest because AOT is not included anymore. There is issue with using AOTed libraries in other AOT tests which does not have `-Xmixed` in `@run` command when `-Xint` passed because `-XX:+UseAOT` is switched off in such case. ------------- PR: https://git.openjdk.java.net/jdk/pull/2132 From kvn at openjdk.java.net Wed Jan 20 17:07:55 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 20 Jan 2021 17:07:55 GMT Subject: RFR: 8259928: compiler/{aot,jvmci} tests fail with -Xint In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 17:01:50 GMT, Vladimir Kozlov wrote: >> oh, I see what happened: when I checked if you can enable jvmci w/ `-Xint`, I looked at `UseJVMCICompiler`, which you can enable by some reason, but `EnableJVMCI` will be set to false when you use `-Xint`, so I agree that `vm.jvmci` should check for `-Xint` flag. it might make sense to change this behavior and set all jvmci flags to false whenever `Xint` is used. >> >> for `vm.aot`, I still think it's a product bug if one can't run `jaotc` w/ `Xint`. @vnkozlov, what do you think? >> on top of that, I also think that we have a test bug, as options like `Xint` should not be passed to `jaotc` in the majority of aot tests. I'll take closer look at them later today. >> >> Cheers, >> -- Igor > >> oh, I see what happened: when I checked if you can enable jvmci w/ `-Xint`, I looked at `UseJVMCICompiler`, which you can enable by some reason, but `EnableJVMCI` will be set to false when you use `-Xint`, so I agree that `vm.jvmci` should check for `-Xint` flag. it might make sense to change this behavior and set all jvmci flags to false whenever `Xint` is used. >> >> for `vm.aot`, I still think it's a product bug if one can't run `jaotc` w/ `Xint`. @vnkozlov, what do you think? >> on top of that, I also think that we have a test bug, as options like `Xint` should not be passed to `jaotc` in the majority of aot tests. I'll take closer look at them later today. >> >> Cheers, >> -- Igor > > JAOTC tool requires JVMCI because it use it with Graal. JAOTC launcher explicitly enable JVMCI. We may need to add `-Xmixed` there: > > https://github.com/openjdk/jdk/blob/master/make/modules/jdk.aot/Launcher.gmk#L33 > > But most AOT tests use AOT compiler wrapper which sets `-Xmixed` (to avoid running with `-Xcomp`): > > https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/aot/AotCompiler.java#L120 > > So I am not sure why -Xint overwrite -Xmixed in AOT tests in your example. I used jtreg to run AOT test and it passed: > $ jtreg -testjdk:/scratch/jdk15u/build/fastdebug/images/jdk/ -va -javaoptions:'-server -Xint' compiler/aot/DeoptimizationTest.java > ... > Command line: [/scratch/jdk15u/build/fastdebug/images/jdk/bin/jaotc -J-server -J-Xint -J-XX:-UseCompressedOops -J-classpath -J/scratch/jdk15u/open/test/hotspot/jtreg/JTwork/classes/compiler/aot/DeoptimizationTest.d:/scratch/jdk15u/open/test/hotspot/jtreg/JTwork/classes/test/lib:/scratch/jdk15u/open/test/hotspot/jtreg/JTwork/classes/testlibrary:/scratch/jdk15u/open/test/hotspot/jtreg/JTwork/classes:/scratch/jdk15u/open/test/hotspot/jtreg/compiler/aot --compile-with-assertions --info --output libDeoptimizationTest.so --compile-commands methodsList.txt --class-name compiler.aot.DeoptimizationTest -J-ea -J-esa -J-Xmixed] > > I can't test with JDK 16 and latest because AOT is not included anymore. > > There is issue with using AOTed libraries in other AOT tests which does not have `-Xmixed` in `@run` command when `-Xint` passed because `-XX:+UseAOT` is switched off in such case. I suggest to fix only `vm.jvmci` since AOT is not part of JDK any more. ------------- PR: https://git.openjdk.java.net/jdk/pull/2132 From kvn at openjdk.java.net Wed Jan 20 17:25:43 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 20 Jan 2021 17:25:43 GMT Subject: RFR: 8255216: ciEnv::_break_at_compile isn't in use In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 18:38:37 GMT, Dan wrote: > _break_at_compile is no longer in use and can be safely removed. > No new code, and Tier1 tests succeed after code is removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 > @danlemmond , I understand Kozlov's comment. > > your change [36bc753](https://github.com/openjdk/jdk/commit/36bc753b6ae85392c3f5e34f85464c02b1c037de) covers c2's optimization. There are another 2 places refer to _directive->BreakAtCompileOption. I think you need to change them to env()-> break_at_compile as well. > > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/c1/c1_Compilation.cpp#L449 > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/compile.cpp#L506 Yes, these places should be fixed too. ------------- PR: https://git.openjdk.java.net/jdk/pull/1806 From kvn at openjdk.java.net Wed Jan 20 17:38:58 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 20 Jan 2021 17:38:58 GMT Subject: RFR: 8255216: ciEnv::_break_at_compile isn't in use In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 17:23:07 GMT, Vladimir Kozlov wrote: >> _break_at_compile is no longer in use and can be safely removed. >> No new code, and Tier1 tests succeed after code is removed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 > >> @danlemmond , I understand Kozlov's comment. >> >> your change [36bc753](https://github.com/openjdk/jdk/commit/36bc753b6ae85392c3f5e34f85464c02b1c037de) covers c2's optimization. There are another 2 places refer to _directive->BreakAtCompileOption. I think you need to change them to env()-> break_at_compile as well. >> >> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/c1/c1_Compilation.cpp#L449 >> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/compile.cpp#L506 > > Yes, these places should be fixed too. I would also suggest to change RFE (and this PR) Subject and Description if you do that. ------------- PR: https://git.openjdk.java.net/jdk/pull/1806 From kvn at openjdk.java.net Wed Jan 20 17:45:48 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 20 Jan 2021 17:45:48 GMT Subject: [jdk16] RFR: 8259775: [Vector API] Incorrect code-gen for VectorReinterpret operation [v5] In-Reply-To: <5ZRm7yr18uW4HQWoMQHlI1CHdqUa70mbcj7r6PkROKU=.e5991488-7d71-4657-95c3-8a034b654db6@github.com> References: <5ZRm7yr18uW4HQWoMQHlI1CHdqUa70mbcj7r6PkROKU=.e5991488-7d71-4657-95c3-8a034b654db6@github.com> Message-ID: On Tue, 19 Jan 2021 03:57:16 GMT, Jie Fu wrote: >> Hi all, >> >> The code-gen for VectorReinterpret may be wrong on x86. >> >> Let's see the opto-assembly for the reproducer in the JBS, which was actually based on @XiaohongGong 's example in JDK-8259353 and many thanks to her. >> 066 B7: # out( N1 ) <- in( B6 ) Freq: 0.999994 >> 066 vector_reinterpret_expand XMM0,XMM0 ! >> 066 store_vector [R12 + R11 << 3 + #16] (compressed oop addressing),XMM0 >> >> Please note that the dst and src [1] share the same XMM0 register and movdqu [2] should be generated for this case. >> But when dst == src, movdqu actually generates nothing [3], which leads to incorrect result; >> >> For this case, movdqu should not be empty since the upper bits of dst should be zeroed. >> The similar error also exists for vmovdqu [4]. >> >> I think we should also change movflt [5] to movss but I just can't understand why we have 4-byte vectors. >> Isn't the shortest vectors 8-byte on x86? >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3354 >> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3364 >> [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2490 >> [4] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2515 >> [5] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3379 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Refine the test to always reproduce the bug Don't forget to request approval for JDK 16 fix integration: http://openjdk.java.net/jeps/3#Fix-Request-Process src/hotspot/cpu/x86/macroAssembler_x86.hpp line 172: > 170: > 171: // Move with zero extension > 172: void movfltz(XMMRegister dst, XMMRegister src) { movss(dst, src); } Seems `movdbl(XMMRegister dst, XMMRegister src)` has the same issue. ------------- PR: https://git.openjdk.java.net/jdk16/pull/122 From github.com+652983+dasbrain at openjdk.java.net Wed Jan 20 18:35:10 2021 From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn) Date: Wed, 20 Jan 2021 18:35:10 GMT Subject: RFR: 8259922 MethodHandles.collectArguments does not follow its documentation Message-ID: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com> Add explicit range check to `MethodHandles.collectArgumentsCheck`. Added test case that exercises all cases. This is a behavioral change, from throwing an unspecified exception to throwing an IllegalArgumentException, as specified. No spec change needed, as the IllegalArgumentException is already specified to be thrown in those cases. Feel free to suggest a better place for the tests. ------------- Commit messages: - Fix tailing whitespace in in MethodHandles.java - Fix copyright yeahr in MethodHandles.java - Fix JDK-8259922 - Fix JDK-8259922. Changes: https://git.openjdk.java.net/jdk/pull/2171/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2171&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259922 Stats: 100 lines in 2 files changed: 99 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2171.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2171/head:pull/2171 PR: https://git.openjdk.java.net/jdk/pull/2171 From redestad at openjdk.java.net Wed Jan 20 18:47:18 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 20 Jan 2021 18:47:18 GMT Subject: RFR: 8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException [v2] In-Reply-To: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com> References: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com> Message-ID: > Change `MethodHandles.byteArrayViewVarHandle` to throw `ArrayIndexOutOfBoundsException` rather than the more generic `IndexArrayOutOfBoundsException`. This feels more natural, and reduces the risk for subtle behavioral mismatch when migrating code from arrays/Unsafe to VHs. > > CSR: [JDK-8259912](https://bugs.openjdk.java.net/browse/JDK-8259912) Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Update VarHandles tests to check for AIOOBE specifically when appropriate - Copyrights - Merge branch 'master' into vh_aioobe - byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2124/files - new: https://git.openjdk.java.net/jdk/pull/2124/files/42c9460c..9259ee3a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2124&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2124&range=00-01 Stats: 4494 lines in 166 files changed: 725 ins; 2890 del; 879 mod Patch: https://git.openjdk.java.net/jdk/pull/2124.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2124/head:pull/2124 PR: https://git.openjdk.java.net/jdk/pull/2124 From mchung at openjdk.java.net Wed Jan 20 18:52:00 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 20 Jan 2021 18:52:00 GMT Subject: RFR: 8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException [v2] In-Reply-To: References: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com> Message-ID: On Wed, 20 Jan 2021 18:47:18 GMT, Claes Redestad wrote: >> Change `MethodHandles.byteArrayViewVarHandle` to throw `ArrayIndexOutOfBoundsException` rather than the more generic `IndexArrayOutOfBoundsException`. This feels more natural, and reduces the risk for subtle behavioral mismatch when migrating code from arrays/Unsafe to VHs. >> >> CSR: [JDK-8259912](https://bugs.openjdk.java.net/browse/JDK-8259912) > > Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Update VarHandles tests to check for AIOOBE specifically when appropriate > - Copyrights > - Merge branch 'master' into vh_aioobe > - byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException Looks good. Thanks for updating the test. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2124 From iignatyev at openjdk.java.net Wed Jan 20 18:52:47 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 20 Jan 2021 18:52:47 GMT Subject: [jdk16] RFR: 8259757: add a regression test for 8259353 and 8259601 [v2] In-Reply-To: References: Message-ID: On Sat, 16 Jan 2021 02:17:50 GMT, Jie Fu wrote: >> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision: >> >> fix copyright year > > Marked as reviewed by jiefu (Committer). Thanks guys. ------------- PR: https://git.openjdk.java.net/jdk16/pull/120 From iignatyev at openjdk.java.net Wed Jan 20 18:52:49 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 20 Jan 2021 18:52:49 GMT Subject: [jdk16] Integrated: 8259757: add a regression test for 8259353 and 8259601 In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 04:03:26 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small test-only patch which adds a regression test for [8259353](https://bugs.openjdk.java.net/browse/JDK-8259353) and [8259601](https://bugs.openjdk.java.net/browse/JDK-8259353)? > > testing: > - [x] `test/hotspot/jtreg/compiler/vectorapi/Test8259353.java` against jdk-16+26 (which doesn't have fixes) : failed, as expected > - [x] `test/hotspot/jtreg/compiler/vectorapi/Test8259353.java` multiple times against jdk-16+32 : passed > > Thanks, > -- Igor This pull request has now been integrated. Changeset: 0408b23b Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk16/commit/0408b23b Stats: 82 lines in 1 file changed: 82 ins; 0 del; 0 mod 8259757: add a regression test for 8259353 and 8259601 Co-authored-by: Xiaohong Gong Co-authored-by: Igor Ignatyev Reviewed-by: kvn, jiefu ------------- PR: https://git.openjdk.java.net/jdk16/pull/120 From redestad at openjdk.java.net Wed Jan 20 23:45:49 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 20 Jan 2021 23:45:49 GMT Subject: Integrated: 8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException In-Reply-To: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com> References: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com> Message-ID: On Mon, 18 Jan 2021 12:09:23 GMT, Claes Redestad wrote: > Change `MethodHandles.byteArrayViewVarHandle` to throw `ArrayIndexOutOfBoundsException` rather than the more generic `IndexArrayOutOfBoundsException`. This feels more natural, and reduces the risk for subtle behavioral mismatch when migrating code from arrays/Unsafe to VHs. > > CSR: [JDK-8259912](https://bugs.openjdk.java.net/browse/JDK-8259912) This pull request has now been integrated. Changeset: 27cc62a5 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/27cc62a5 Stats: 534 lines in 30 files changed: 13 ins; 0 del; 521 mod 8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException Reviewed-by: jvernee, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/2124 From jiefu at openjdk.java.net Thu Jan 21 00:03:43 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 21 Jan 2021 00:03:43 GMT Subject: [jdk16] RFR: 8259775: [Vector API] Incorrect code-gen for VectorReinterpret operation [v5] In-Reply-To: References: <5ZRm7yr18uW4HQWoMQHlI1CHdqUa70mbcj7r6PkROKU=.e5991488-7d71-4657-95c3-8a034b654db6@github.com> Message-ID: On Wed, 20 Jan 2021 17:40:45 GMT, Vladimir Kozlov wrote: > Seems `movdbl(XMMRegister dst, XMMRegister src)` has the same issue. Good catch. I will try to make a reproducer and fix it in another pr since VectorReinterpret doesn't use it. Thanks. ------------- PR: https://git.openjdk.java.net/jdk16/pull/122 From jiefu at openjdk.java.net Thu Jan 21 00:03:43 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 21 Jan 2021 00:03:43 GMT Subject: [jdk16] RFR: 8259775: [Vector API] Incorrect code-gen for VectorReinterpret operation [v5] In-Reply-To: References: <5ZRm7yr18uW4HQWoMQHlI1CHdqUa70mbcj7r6PkROKU=.e5991488-7d71-4657-95c3-8a034b654db6@github.com> Message-ID: <8pN0w8-ir4hQJVUXmjsFpSEBcLPD5JFRuOsfrkOu3lk=.54d36e53-4765-4903-bc63-9c0e8b9e4c53@github.com> On Wed, 20 Jan 2021 13:34:00 GMT, Rickard B?ckman wrote: >> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >> >> Refine the test to always reproduce the bug > > Marked as reviewed by rbackman (Reviewer). Thanks @rickard , @neliasso and @vnkozlov for your review and comments. @vnkozlov , jdk16-fix-request has been added in the JBS. Thanks. ------------- PR: https://git.openjdk.java.net/jdk16/pull/122 From github.com+51754783+coreyashford at openjdk.java.net Thu Jan 21 01:55:51 2021 From: github.com+51754783+coreyashford at openjdk.java.net (Corey Ashford) Date: Thu, 21 Jan 2021 01:55:51 GMT Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format added in POWER10 In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 08:09:56 GMT, Kazunori Ogata wrote: > The POWER10 processor, which implements Power ISA 3.1 [1], supports new instruction formats where an instruction takes two 32bit words. The first word is called prefix, and the instructions with prefix are called prefixed instructions. With more bits in opcode and operand fields, POWER10 supports larger immediate value in an operand, as well as many new instructions. > > This is the first changes to handle prefixed instructions, and this adds support of prefixed addi (= paddi) instruction as an example of prefix usage. paddi accepts 34bit immediate value, while original addi accepts 16bit value. > > [1] https://ibm.ent.box.com/s/hhjfw0x0lrbtyzmiaffnbxh2fuo0fog0 This looks good overall. I'm looking forward to being able to utilize this capability. src/hotspot/cpu/ppc/assembler_ppc.hpp line 814: > 812: PREFIX_OPCODE_TYPEx1_MASK = PREFIX_OPCODE_TYPE_MASK | (15u << PRE_ST4_SHIFT), > 813: > 814: //Masks for each instructions Add a space after the // src/hotspot/cpu/ppc/assembler_ppc.hpp line 1112: > 1110: static int inv_bi_field(int x) { return inv_opp_u_field(x, 15, 11); } > 1111: > 1112: // support to extended opcodes (prefixed instructions) introduced by POWER10 Should this be "introduced by Power ISA 3.1"? It would be more correct, but probably inconsistent with other, similar comments. src/hotspot/cpu/ppc/assembler_ppc.hpp line 1247: > 1245: static int xxsplt_uim(int x) { return opp_u_field(x, 15, 14); } // for xxsplt* instructions > 1246: > 1247: // support to extended opcodes (prefixed instructions) introduced by POWER10 Support to->for extended opcodes ... src/hotspot/cpu/ppc/assembler_ppc.hpp line 1309: > 1307: > 1308: static void set_imm18(int* instr, int s) { > 1309: assert(PowerArchitecturePPC64 >= 10, "Prefixed instruction is supported in POWER10 and up"); I think it should be "Prefixed instructions are supported only in Power10 and up" src/hotspot/cpu/ppc/assembler_ppc.hpp line 1317: > 1315: > 1316: static int get_imm18(address a, int instruction_number) { > 1317: assert(PowerArchitecturePPC64 >= 10, "Prefixed instruction is supported in POWER10 and up"); Same comment here. src/hotspot/cpu/ppc/assembler_ppc.hpp line 1349: > 1347: > 1348: inline void emit_int32(int); // shadows AbstractAssembler::emit_int32 > 1349: inline void emit_prefix(int); // emit prefix word only (and a nop to skip 64byte boundary) 64byte -> 64-byte src/hotspot/cpu/ppc/assembler_ppc.inline.hpp line 41: > 39: "Unexpected primary opcode for prefix word"); > 40: > 41: // Add nop if a prefixed (two-word) instruction is going to cross 64-byte boundaries. ... going to cross a 64-byte boundary. src/hotspot/cpu/ppc/ppc.ad line 12053: > 12051: %} > 12052: > 12053: // POWER10 version, using prefixed addi to load 32bit constant 32bit -> 32-bit src/hotspot/cpu/ppc/ppc.ad line 12060: > 12058: ins_cost(3 * DEFAULT_COST); > 12059: > 12060: format %{ "(nop if crossing 64byte boundary)\n\t" 64byte -> 64-byte src/hotspot/cpu/ppc/ppc.ad line 8721: > 8719: ins_cost(DEFAULT_COST+1); > 8720: > 8721: format %{ "(nop if crossing 64byte boundary)\n\t" 64byte -> 64-byte src/hotspot/cpu/ppc/ppc.ad line 5845: > 5843: size(12); > 5844: ins_encode %{ > 5845: // TODO: PPC port $archOpcode(ppc64Opcode_paddi); I'm not clear of the meaning of this and the other TODOs. ppc640opcode_paddi doesn't seem to be defined anywhere. src/hotspot/cpu/ppc/assembler_ppc.hpp line 1533: > 1531: int32_t* p_inst = (int32_t*)p; > 1532: > 1533: if (is_aligned(reinterpret_cast(p_inst+1), 64) && is_nop(*p_inst)) { This test is a bit confusing. Shouldn't is_paddi return false if p points at a nop (even if it precedes the paddi)? src/hotspot/cpu/ppc/assembler_ppc.hpp line 1543: > 1541: } > 1542: } > 1543: static bool is_pli(const int* p) { return is_paddi(p, true); } is_pli() is defined, but not used, as far as I can tell. src/hotspot/cpu/ppc/ppc.ad line 5925: > 5923: instruct loadConL34(iRegLdst dst, immL34 src) %{ > 5924: match(Set dst src); > 5925: ins_cost(DEFAULT_COST+1); There's no predicate for >= POWER10. I can see how this works because of the immL34 operand having its own predicate, but in later instructs, e.g. addL_reg_imm34 even though the operand is immI32, you still add the explicit predicate. I'd rather there be an explicit POWER10 predicate in this instruct. src/hotspot/cpu/ppc/assembler_ppc.inline.hpp line 209: > 207: inline void Assembler::psubi(Register d, Register a, long si34) { Assembler::paddi( d, a, -si34, false); } > 208: > 209: inline void Assembler::pli_or_li(Register d, long si34) { Defined but not used. src/hotspot/cpu/ppc/assembler_ppc.inline.hpp line 157: > 155: } > 156: > 157: inline void Assembler::paddi_or_addi(Register d, Register a, long si34) { defined but not used. src/hotspot/cpu/ppc/assembler_ppc.cpp line 63: > 61: Thread* thread = Thread::current(); > 62: > 63: if(!thread->is_Compiler_thread()) return false; add space after "if" ------------- PR: https://git.openjdk.java.net/jdk/pull/2095 From fyang at openjdk.java.net Thu Jan 21 02:20:10 2021 From: fyang at openjdk.java.net (Fei Yang) Date: Thu, 21 Jan 2021 02:20:10 GMT Subject: RFR: 8260029: aarch64: fix typo in verify_oop_array Message-ID: In aarch64 verify_oop_array, we scan over array at 'a' for 'count' oops, verifying each one. The step for the loop should be one for each oop instead of 'size'. We may miss verifying some oops in the array if we set the step to 'size'. Also, we should use 'temp' instead of r16 for the compressed oop case. Register r16 defined but not used in this function. Tier1-3 tested with linux-aarch64 fastdebug build. ------------- Commit messages: - 8260029: aarch64: fix typo in verify_oop_array Changes: https://git.openjdk.java.net/jdk/pull/2175/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2175&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260029 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2175.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2175/head:pull/2175 PR: https://git.openjdk.java.net/jdk/pull/2175 From jwilhelm at openjdk.java.net Thu Jan 21 04:41:15 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 21 Jan 2021 04:41:15 GMT Subject: RFR: Merge jdk16 Message-ID: Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8259757: add a regression test for 8259353 and 8259601 - 8259732: JDK 16 L10n resource file update - msg drop 10 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2176&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2176&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/2176/files Stats: 296 lines in 31 files changed: 200 ins; 16 del; 80 mod Patch: https://git.openjdk.java.net/jdk/pull/2176.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2176/head:pull/2176 PR: https://git.openjdk.java.net/jdk/pull/2176 From jwilhelm at openjdk.java.net Thu Jan 21 05:26:59 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 21 Jan 2021 05:26:59 GMT Subject: Integrated: Merge jdk16 In-Reply-To: References: Message-ID: <9sHQ5RFKu7eMA2dnKWQ9ZWXPzT_HnSJdXDZ2j4kX8to=.69bf5258-7371-4404-a1af-b54febf7cad7@github.com> On Thu, 21 Jan 2021 04:33:47 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: 133bcb09 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/133bcb09 Stats: 296 lines in 31 files changed: 200 ins; 16 del; 80 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/2176 From github.com+7991079+danlemmond at openjdk.java.net Thu Jan 21 07:56:14 2021 From: github.com+7991079+danlemmond at openjdk.java.net (Dan) Date: Thu, 21 Jan 2021 07:56:14 GMT Subject: RFR: 8255216: Change _directive->BreakAtCompileOption to env()->break_at_compile() [v6] In-Reply-To: References: Message-ID: > _break_at_compile was no longer in use after changes to compile.cpp. > Change compile.cpp and c1_Compilation.cpp to use env()->break_at_compile() instead > to make that code no longer dead. > No new code, and Tier1 tests succeed after code is removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 Dan has updated the pull request incrementally with one additional commit since the last revision: Remove additional _directive->BreakAtCompileOption calls Repurpose to env()->break_at_compile() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1806/files - new: https://git.openjdk.java.net/jdk/pull/1806/files/41d01c05..12eedef8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1806&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1806&range=04-05 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1806.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1806/head:pull/1806 PR: https://git.openjdk.java.net/jdk/pull/1806 From shade at openjdk.java.net Thu Jan 21 07:59:01 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 21 Jan 2021 07:59:01 GMT Subject: RFR: 8260029: aarch64: fix typo in verify_oop_array In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 02:12:47 GMT, Fei Yang wrote: > In aarch64 verify_oop_array, we scan over array at 'a' for 'count' oops, verifying each one. The step for the loop should be one for each oop instead of 'size'. We may miss verifying some oops in the array if we set the step to 'size'. Also, we should use 'temp' instead of r16 for the compressed oop case. Register r16 defined but not used in this function. > > Tier1-3 tested with linux-aarch64 fastdebug build. This makes sense to me. However, for testing, you probably need to run with `-XX:+VerifyOops` specifically, because there is only one test in the whole suite that enables it. Something like tier1 would do: `make run-test TEST=tier1 TEST_VM_OPTS=-XX:+VerifyOops`. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2175 From xliu at openjdk.java.net Thu Jan 21 08:34:57 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 21 Jan 2021 08:34:57 GMT Subject: RFR: 8255216: Change _directive->BreakAtCompileOption to env()->break_at_compile() In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 17:36:05 GMT, Vladimir Kozlov wrote: >>> @danlemmond , I understand Kozlov's comment. >>> >>> your change [36bc753](https://github.com/openjdk/jdk/commit/36bc753b6ae85392c3f5e34f85464c02b1c037de) covers c2's optimization. There are another 2 places refer to _directive->BreakAtCompileOption. I think you need to change them to env()-> break_at_compile as well. >>> >>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/c1/c1_Compilation.cpp#L449 >>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/compile.cpp#L506 >> >> Yes, these places should be fixed too. > > I would also suggest to change RFE (and this PR) Subject and Description if you do that. Currently ciEnv->break_at_compile() is set if directive->BreakAtExecuteOption || task->check_break_at_flags(); It doesn't consider `C->directive()->BreakAtCompileOption`. IMHO, [this line](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/compileBroker.cpp#L2226) should include `|| directive->BreakAtCompileOption`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1806 From xliu at openjdk.java.net Thu Jan 21 08:51:11 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 21 Jan 2021 08:51:11 GMT Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set Message-ID: Add a flag _suppress_cr to outputStream. outstream objects won't emit any CR if it's set. Correct TypeInstPtr::dump2 to make sure it only emits klass name once. Remove the comment because Klass::oop_print_on() has emitted the address of oop. Before: 689 ConP === 0 [[ 821 ]] Oop:java/lang/Stringjava.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a" :Constant:exact * After: 689 ConP === 0 [[ 821 ]] Oop:java.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a":Constant:exact * ------------- Commit messages: - 8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set Changes: https://git.openjdk.java.net/jdk/pull/2178/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2178&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260198 Stats: 29 lines in 3 files changed: 16 ins; 4 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/2178.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2178/head:pull/2178 PR: https://git.openjdk.java.net/jdk/pull/2178 From roland at openjdk.java.net Thu Jan 21 08:59:56 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Thu, 21 Jan 2021 08:59:56 GMT Subject: RFR: 8257498: Remove useless skeleton predicates [v3] In-Reply-To: References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com> Message-ID: On Wed, 20 Jan 2021 12:30:12 GMT, Christian Hagedorn wrote: >> This enhancement removes useless skeleton predicates in the same way as we already remove normal useless predicates in `PhaseIdealLoop::eliminate_useless_predicates()`. >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > Fix removal from global list and update get_skeleton_predicates Other than that, looks good to me. src/hotspot/share/opto/loopnode.cpp line 3585: > 3583: } > 3584: } > 3585: I didn't realize you would have to go through an extra list. So I guess what you had before with the get_opaque parameter was better. ------------- Marked as reviewed by roland (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2075 From aph at openjdk.java.net Thu Jan 21 09:49:46 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 21 Jan 2021 09:49:46 GMT Subject: RFR: 8260029: aarch64: fix typo in verify_oop_array In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 02:12:47 GMT, Fei Yang wrote: > In aarch64 verify_oop_array, we scan over array at 'a' for 'count' oops, verifying each one. The step for the loop should be one for each oop instead of 'size'. We may miss verifying some oops in the array if we set the step to 'size'. Also, we should use 'temp' instead of r16 for the compressed oop case. Register r16 defined but not used in this function. > > Tier1-3 tested with linux-aarch64 fastdebug build. Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2175 From shade at openjdk.java.net Thu Jan 21 09:59:15 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 21 Jan 2021 09:59:15 GMT Subject: RFR: 8259928: compiler/jvmci tests fail with -Xint [v2] In-Reply-To: References: Message-ID: > I was getting Zero VM close to run tier1, and before that I wanted to see that tier{1,2} pass with -Xint. Some test are failing due to timeouts, but compiler/jvmci tests cannot run with -Xint at all. (Zero avoids this by not having VM feature flags "jvmci"). > > If you run the VM with `-Xint` and JVMCI, this would happen: > > $ build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xint -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI > OpenJDK 64-Bit Server VM warning: JVMCI Compiler disabled due to -Xint. > > Additional testing: > - [x] `compiler/jvmci` with `TEST_VM_OPTS=-Xint` (now disabled) > - [x] `compiler/jvmci` with default options (still run and pass) Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Revert vm.aot changes - 8259928: compiler/{aot,jvmci} tests fail with -Xint ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2132/files - new: https://git.openjdk.java.net/jdk/pull/2132/files/925cf70d..b258eed1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2132&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2132&range=00-01 Stats: 3172 lines in 51 files changed: 273 ins; 2763 del; 136 mod Patch: https://git.openjdk.java.net/jdk/pull/2132.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2132/head:pull/2132 PR: https://git.openjdk.java.net/jdk/pull/2132 From shade at openjdk.java.net Thu Jan 21 09:59:16 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 21 Jan 2021 09:59:16 GMT Subject: RFR: 8259928: compiler/jvmci tests fail with -Xint In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 17:04:51 GMT, Vladimir Kozlov wrote: >>> oh, I see what happened: when I checked if you can enable jvmci w/ `-Xint`, I looked at `UseJVMCICompiler`, which you can enable by some reason, but `EnableJVMCI` will be set to false when you use `-Xint`, so I agree that `vm.jvmci` should check for `-Xint` flag. it might make sense to change this behavior and set all jvmci flags to false whenever `Xint` is used. >>> >>> for `vm.aot`, I still think it's a product bug if one can't run `jaotc` w/ `Xint`. @vnkozlov, what do you think? >>> on top of that, I also think that we have a test bug, as options like `Xint` should not be passed to `jaotc` in the majority of aot tests. I'll take closer look at them later today. >>> >>> Cheers, >>> -- Igor >> >> JAOTC tool requires JVMCI because it use it with Graal. JAOTC launcher explicitly enable JVMCI. We may need to add `-Xmixed` there: >> >> https://github.com/openjdk/jdk/blob/master/make/modules/jdk.aot/Launcher.gmk#L33 >> >> But most AOT tests use AOT compiler wrapper which sets `-Xmixed` (to avoid running with `-Xcomp`): >> >> https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/aot/AotCompiler.java#L120 >> >> So I am not sure why -Xint overwrite -Xmixed in AOT tests in your example. I used jtreg to run AOT test and it passed: >> $ jtreg -testjdk:/scratch/jdk15u/build/fastdebug/images/jdk/ -va -javaoptions:'-server -Xint' compiler/aot/DeoptimizationTest.java >> ... >> Command line: [/scratch/jdk15u/build/fastdebug/images/jdk/bin/jaotc -J-server -J-Xint -J-XX:-UseCompressedOops -J-classpath -J/scratch/jdk15u/open/test/hotspot/jtreg/JTwork/classes/compiler/aot/DeoptimizationTest.d:/scratch/jdk15u/open/test/hotspot/jtreg/JTwork/classes/test/lib:/scratch/jdk15u/open/test/hotspot/jtreg/JTwork/classes/testlibrary:/scratch/jdk15u/open/test/hotspot/jtreg/JTwork/classes:/scratch/jdk15u/open/test/hotspot/jtreg/compiler/aot --compile-with-assertions --info --output libDeoptimizationTest.so --compile-commands methodsList.txt --class-name compiler.aot.DeoptimizationTest -J-ea -J-esa -J-Xmixed] >> >> I can't test with JDK 16 and latest because AOT is not included anymore. >> >> There is issue with using AOTed libraries in other AOT tests which does not have `-Xmixed` in `@run` command when `-Xint` passed because `-XX:+UseAOT` is switched off in such case. > > I suggest to fix only `vm.jvmci` since AOT is not part of JDK any more. Okay, I reduced this PR to only handle `vm.jvmci`. Also submitted https://bugs.openjdk.java.net/browse/JDK-8260224 -- and assigned it to @iignatev. ------------- PR: https://git.openjdk.java.net/jdk/pull/2132 From martin.doerr at sap.com Thu Jan 21 10:26:42 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 21 Jan 2021 10:26:42 +0000 Subject: [11u] RFR: 8247691: [aarch64] Incorrect handling of VM exceptions in C1 deopt stub/traps In-Reply-To: References: Message-ID: This change doesn't seem to be ready for backport, yet. I've added a comment to the bug. Best regards, Martin From: Doerr, Martin Sent: Mittwoch, 20. Januar 2021 11:34 To: 'hotspot-compiler-dev at openjdk.java.net' ; jdk-updates-dev at openjdk.java.net Cc: Lindenmaier, Goetz ; Langer, Christoph Subject: [11u] RFR: 8247691: [aarch64] Incorrect handling of VM exceptions in C1 deopt stub/traps Hi, JDK-8247691 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly. I had to apply 2 parts manually: c1_Runtime1_aarch64.cpp: The code which gets replaced by this change contains differences. I've resolved it such that it matches the new version exactly. Note that aarch64 uses DEOPTIMIZE_WHEN_PATCHING so it always deoptimizes instead of performing the patching as done by other platforms. deoptimization.cpp: Integrated assertion manually due to unrelated context changes. Bug: https://bugs.openjdk.java.net/browse/JDK-8247691 Original change: https://git.openjdk.java.net/jdk/commit/7817963c 11u backport: http://cr.openjdk.java.net/~mdoerr/8247691_aarch64_11u/webrev.00/ Please review. Best regards, Martin From fyang at openjdk.java.net Thu Jan 21 12:01:52 2021 From: fyang at openjdk.java.net (Fei Yang) Date: Thu, 21 Jan 2021 12:01:52 GMT Subject: RFR: 8260029: aarch64: fix typo in verify_oop_array In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 07:55:48 GMT, Aleksey Shipilev wrote: > This makes sense to me. > > However, for testing, you probably need to run with `-XX:+VerifyOops` specifically, because there is only one test in the whole suite that enables it. Something like tier1 would do: `make run-test TEST=tier1 TEST_VM_OPTS=-XX:+VerifyOops`. Good suggestion. I performed another round of tier1-3 test with -XX:+VerifyOops. No regression witnessed. Merging. ------------- PR: https://git.openjdk.java.net/jdk/pull/2175 From fyang at openjdk.java.net Thu Jan 21 12:01:53 2021 From: fyang at openjdk.java.net (Fei Yang) Date: Thu, 21 Jan 2021 12:01:53 GMT Subject: Integrated: 8260029: aarch64: fix typo in verify_oop_array In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 02:12:47 GMT, Fei Yang wrote: > In aarch64 verify_oop_array, we scan over array at 'a' for 'count' oops, verifying each one. The step for the loop should be one for each oop instead of 'size'. We may miss verifying some oops in the array if we set the step to 'size'. Also, we should use 'temp' instead of r16 for the compressed oop case. Register r16 defined but not used in this function. > > Tier1-3 tested with linux-aarch64 fastdebug build. This pull request has now been integrated. Changeset: 4bcffeb9 Author: Fei Yang URL: https://git.openjdk.java.net/jdk/commit/4bcffeb9 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8260029: aarch64: fix typo in verify_oop_array Co-authored-by: Zhuxuan Ni Reviewed-by: shade, aph ------------- PR: https://git.openjdk.java.net/jdk/pull/2175 From eirbjo at gmail.com Thu Jan 21 15:22:50 2021 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Thu, 21 Jan 2021 16:22:50 +0100 Subject: SIGSEGV in Method::set_on_stack while running JMH benchmark Message-ID: Hi, I got a SIGSEGV while running a JMH benchmark. ( I believe it had -prof jfr and -prof gc enabled). Debugging this is above my pay grade, but I found this in Method::set_on_stack: 2301: constants()->set_on_stack(value); Could it be that constants() returns something unexpected? Another observation is that class redefinition seems to be involved,. This is no showstopper for me (In benchmark, only happened once), but perhaps a Hotspot wiz wants to take a look. I can send the entire hs_err file on request. Cheers, Eirik. --------------- S U M M A R Y ------------ Command Line: -Dfile.encoding=UTF-8 -XX:+UnlockDiagnosticVMOptions -XX:+DebugNonSafepoints -XX:CompileCommandFile=/var/folders/1n/jtwrr03x6_x8sw39jpl8qr_r0000gn/T/jmh7169653786094403218compilecommand org.openjdk.jmh.runner.ForkedMain 127.0.0.1 56682 Host: MacBookPro13,3 x86_64 2600 MHz, 8 cores, 16G, Darwin 20.2.0, macOS 10.16 (20C69) Time: Wed Jan 20 00:15:32 2021 CET elapsed time: 55.183476 seconds (0d 0h 0m 55s) --------------- T H R E A D --------------- Current thread (0x00007ffc90e0a4e0): VMThread "VM Thread" [stack: 0x000070000e50f000,0x000070000e60f000] [id=14339] Stack: [0x000070000e50f000,0x000070000e60f000], sp=0x000070000e60ea60, free space=1022k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.dylib+0x853fe8] Method::set_on_stack(bool)+0x18 V [libjvm.dylib+0xa9bceb] ThreadHandlesClosure::do_thread(Thread*)+0x3b V [libjvm.dylib+0xa9a63e] Threads::metadata_handles_do(void (*)(Metadata*))+0x7e V [libjvm.dylib+0x840fbc] MetadataOnStackMark::MetadataOnStackMark(bool, bool)+0x1c V [libjvm.dylib+0x6f78fc] VM_RedefineClasses::doit()+0x4c V [libjvm.dylib+0xb12756] VM_Operation::evaluate()+0xd6 V [libjvm.dylib+0xb17b27] VMThread::evaluate_operation(VM_Operation*)+0x157 V [libjvm.dylib+0xb183e4] VMThread::inner_execute(VM_Operation*)+0x194 V [libjvm.dylib+0xb1776c] VMThread::run()+0xbc V [libjvm.dylib+0xa91cf1] Thread::call_run()+0x71 V [libjvm.dylib+0x8ae387] thread_native_entry(Thread*)+0x157 C [libsystem_pthread.dylib+0x6950] _pthread_start+0xe0 C [libsystem_pthread.dylib+0x247b] thread_start+0xf siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000000 From shade at redhat.com Thu Jan 21 16:35:51 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 Jan 2021 17:35:51 +0100 Subject: SIGSEGV in Method::set_on_stack while running JMH benchmark In-Reply-To: References: Message-ID: On 1/21/21 4:22 PM, Eirik Bj?rsn?s wrote: > Debugging this is above my pay grade, but I found this in > Method::set_on_stack: > > 2301: constants()->set_on_stack(value); > > Could it be that constants() returns something unexpected? si_addr = 0x0 kinda hints that we tried to dereference NULL. > Another observation is that class redefinition seems to be involved,. > > This is no showstopper for me (In benchmark, only happened once), but > perhaps a Hotspot wiz wants to take a look. I can send the entire hs_err > file on request. Might be one of these things: https://bugs.openjdk.java.net/browse/JDK-8226690 https://bugs.openjdk.java.net/browse/JDK-8222004 Run with fastdebug JDK build, if you can. -- Thanks, -Aleksey From kvn at openjdk.java.net Thu Jan 21 18:07:31 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 21 Jan 2021 18:07:31 GMT Subject: RFR: 8255216: Change _directive->BreakAtCompileOption to env()->break_at_compile() [v6] In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 07:56:14 GMT, Dan wrote: >> _break_at_compile was no longer in use after changes to compile.cpp. >> Change compile.cpp and c1_Compilation.cpp to use env()->break_at_compile() instead >> to make that code no longer dead. >> No new code, and Tier1 tests succeed after code is removed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 > > Dan has updated the pull request incrementally with one additional commit since the last revision: > > Remove additional _directive->BreakAtCompileOption calls > > Repurpose to env()->break_at_compile() Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1806 From kvn at openjdk.java.net Thu Jan 21 18:34:19 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 21 Jan 2021 18:34:19 GMT Subject: RFR: 8255216: Change _directive->BreakAtCompileOption to env()->break_at_compile() [v6] In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 07:56:14 GMT, Dan wrote: >> _break_at_compile was no longer in use after changes to compile.cpp. >> Change compile.cpp and c1_Compilation.cpp to use env()->break_at_compile() instead >> to make that code no longer dead. >> No new code, and Tier1 tests succeed after code is removed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 > > Dan has updated the pull request incrementally with one additional commit since the last revision: > > Remove additional _directive->BreakAtCompileOption calls > > Repurpose to env()->break_at_compile() Need additional change in compileBroker.cpp ------------- PR: https://git.openjdk.java.net/jdk/pull/1806 From kvn at openjdk.java.net Thu Jan 21 18:34:30 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 21 Jan 2021 18:34:30 GMT Subject: RFR: 8259928: compiler/jvmci tests fail with -Xint [v2] In-Reply-To: References: Message-ID: <3hpEy8hKaMlNxEwVZqFQRb7KXxwuxkU37Vgu3PGOhe0=.08513092-1bce-4445-b6f3-4dc9ef1678a2@github.com> On Thu, 21 Jan 2021 09:59:15 GMT, Aleksey Shipilev wrote: >> I was getting Zero VM close to run tier1, and before that I wanted to see that tier{1,2} pass with -Xint. Some test are failing due to timeouts, but compiler/jvmci tests cannot run with -Xint at all. (Zero avoids this by not having VM feature flags "jvmci"). >> >> If you run the VM with `-Xint` and JVMCI, this would happen: >> >> $ build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xint -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI >> OpenJDK 64-Bit Server VM warning: JVMCI Compiler disabled due to -Xint. >> >> Additional testing: >> - [x] `compiler/jvmci` with `TEST_VM_OPTS=-Xint` (now disabled) >> - [x] `compiler/jvmci` with default options (still run and pass) > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Revert vm.aot changes > - 8259928: compiler/{aot,jvmci} tests fail with -Xint Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2132 From kvn at openjdk.java.net Thu Jan 21 18:34:19 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 21 Jan 2021 18:34:19 GMT Subject: RFR: 8255216: Change _directive->BreakAtCompileOption to env()->break_at_compile() [v6] In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 18:05:20 GMT, Vladimir Kozlov wrote: >> Dan has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove additional _directive->BreakAtCompileOption calls >> >> Repurpose to env()->break_at_compile() > > Good. > Currently ciEnv->break_at_compile() is set if directive->BreakAtExecuteOption || task->check_break_at_flags(); > It doesn't consider `C->directive()->BreakAtCompileOption`. IMHO, [this line](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/compileBroker.cpp#L2226) should include `|| directive->BreakAtCompileOption`. Okay. This is totally messed up :( BreakAtExecuteOption should be only used in https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/output.cpp#L376 to set break point in compiled code. Pointed [compileBroker.cpp#L2226](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/compileBroker.cpp#L2226) line should use BreakAtCompileOption instead of BreakAtExecuteOption. @danlemmond you need additional change in compileBroker.cpp to replace BreakAtExecuteOption with BreakAtCompileOption. ------------- PR: https://git.openjdk.java.net/jdk/pull/1806 From iignatyev at openjdk.java.net Thu Jan 21 18:38:34 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 21 Jan 2021 18:38:34 GMT Subject: RFR: 8259928: compiler/jvmci tests fail with -Xint [v2] In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 09:59:15 GMT, Aleksey Shipilev wrote: >> I was getting Zero VM close to run tier1, and before that I wanted to see that tier{1,2} pass with -Xint. Some test are failing due to timeouts, but compiler/jvmci tests cannot run with -Xint at all. (Zero avoids this by not having VM feature flags "jvmci"). >> >> If you run the VM with `-Xint` and JVMCI, this would happen: >> >> $ build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xint -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI >> OpenJDK 64-Bit Server VM warning: JVMCI Compiler disabled due to -Xint. >> >> Additional testing: >> - [x] `compiler/jvmci` with `TEST_VM_OPTS=-Xint` (now disabled) >> - [x] `compiler/jvmci` with default options (still run and pass) > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Revert vm.aot changes > - 8259928: compiler/{aot,jvmci} tests fail with -Xint Marked as reviewed by iignatyev (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2132 From shade at openjdk.java.net Thu Jan 21 19:00:37 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 21 Jan 2021 19:00:37 GMT Subject: RFR: 8260250: Duplicate check in DebugInformationRecorder::recorders_frozen Message-ID: <0yPlSZxEU9rt7Lk-Pt5UxklpDCCpWB-DpLzvgx4gYts=.caa2d7d2-607c-4e2a-8408-85133d3186fc@github.com> SonarCloud instance reports the bug here: Identical sub-expressions on both sides of operator "||". bool DebugInformationRecorder::recorders_frozen() { return _oop_recorder->is_complete() || _oop_recorder->is_complete(); } It seems to be this way since JDK-6964458. I don't see why it is this way. I think the intent was to check and freeze these two recorders: class OopRecorder : public ResourceObj { private: ValueRecorder _oops; ValueRecorder _metadata; ...but they are in `OopRecorder` already, and so we already get what we want with a single call: #ifdef ASSERT bool is_complete() { assert(_oops.is_complete() == _metadata.is_complete(), "must agree"); return _oops.is_complete(); } #endif ------------- Commit messages: - 8260250: Duplicate check in DebugInformationRecorder::recorders_frozen Changes: https://git.openjdk.java.net/jdk/pull/2187/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2187&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260250 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2187.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2187/head:pull/2187 PR: https://git.openjdk.java.net/jdk/pull/2187 From mchung at openjdk.java.net Thu Jan 21 23:10:34 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 21 Jan 2021 23:10:34 GMT Subject: RFR: 8259922 MethodHandles.collectArguments does not follow its documentation In-Reply-To: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com> References: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com> Message-ID: On Wed, 20 Jan 2021 18:29:00 GMT, Johannes Kuhn wrote: > Add explicit range check to `MethodHandles.collectArgumentsCheck`. > Added test case that exercises all cases. > > This is a behavioral change, from throwing an unspecified exception to throwing an IllegalArgumentException, as specified. > No spec change needed, as the IllegalArgumentException is already specified to be thrown in those cases. > > Feel free to suggest a better place for the tests. Thanks for fixing this. I can sponsor this for you. src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 5753: > 5751: if (pos < 0 || pos > targetType.parameterCount() || > 5752: // a filter with void return is fine at pos == targetType.parameterCount(); > 5753: (rtype != void.class && pos >= targetType.parameterCount())) { Nit: adding `rtype == void.class` may make it clearer than the comment as that matches what `@throws` describes Suggestion: if (pos < 0 || (rtype == void.class && pos > targetType.parameterCount()) || (rtype != void.class && pos >= targetType.parameterCount())) { test/jdk/java/lang/invoke/8259922/TestMethodHandlesCollectArgs.java line 37: > 35: import static org.testng.Assert.*; > 36: > 37: public class TestMethodHandlesCollectArgs { I suggest to rename this test in `test/jdk/java/lang/invoke/MethodHandlesCollectArgsTest.java` matching existing convention and `CollectArgsTest.java` is also fine with me. The bug ID is already in @bug and I find the directory with bug ID adds noise. test/jdk/java/lang/invoke/8259922/TestMethodHandlesCollectArgs.java line 51: > 49: // expected - pass > 50: } > 51: } This can be simplified: @Test(expected = IllegalArgumentException.class) public void nonVoidIllegalPos() { MethodHandles.collectArguments(TARGET, 2, FILTER_INT); } Same applies to other negative test cases. I suggest to put all negative test cases in a data provider and test them in one single `@Test` like this: `@Test(dataProvider="illegalPos", expected = IllegalArgumentException.class)` with the index and filter as the method argument. ------------- PR: https://git.openjdk.java.net/jdk/pull/2171 From github.com+652983+dasbrain at openjdk.java.net Thu Jan 21 23:25:42 2021 From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn) Date: Thu, 21 Jan 2021 23:25:42 GMT Subject: RFR: 8259922 MethodHandles.collectArguments does not follow its documentation In-Reply-To: References: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com> Message-ID: On Thu, 21 Jan 2021 22:54:56 GMT, Mandy Chung wrote: >> Add explicit range check to `MethodHandles.collectArgumentsCheck`. >> Added test case that exercises all cases. >> >> This is a behavioral change, from throwing an unspecified exception to throwing an IllegalArgumentException, as specified. >> No spec change needed, as the IllegalArgumentException is already specified to be thrown in those cases. >> >> Feel free to suggest a better place for the tests. > > test/jdk/java/lang/invoke/8259922/TestMethodHandlesCollectArgs.java line 37: > >> 35: import static org.testng.Assert.*; >> 36: >> 37: public class TestMethodHandlesCollectArgs { > > I suggest to rename this test in `test/jdk/java/lang/invoke/MethodHandlesCollectArgsTest.java` matching existing convention and `CollectArgsTest.java` is also fine with me. The bug ID is already in @bug and I find the directory with bug ID adds noise. Yeah, still learning where to put tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/2171 From jiefu at openjdk.java.net Thu Jan 21 23:29:16 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 21 Jan 2021 23:29:16 GMT Subject: [jdk16] RFR: 8259775: [Vector API] Incorrect code-gen for VectorReinterpret operation [v5] In-Reply-To: <8pN0w8-ir4hQJVUXmjsFpSEBcLPD5JFRuOsfrkOu3lk=.54d36e53-4765-4903-bc63-9c0e8b9e4c53@github.com> References: <5ZRm7yr18uW4HQWoMQHlI1CHdqUa70mbcj7r6PkROKU=.e5991488-7d71-4657-95c3-8a034b654db6@github.com> <8pN0w8-ir4hQJVUXmjsFpSEBcLPD5JFRuOsfrkOu3lk=.54d36e53-4765-4903-bc63-9c0e8b9e4c53@github.com> Message-ID: On Thu, 21 Jan 2021 00:00:26 GMT, Jie Fu wrote: >> Marked as reviewed by rbackman (Reviewer). > > Thanks @rickard , @neliasso and @vnkozlov for your review and comments. > > @vnkozlov , jdk16-fix-request has been added in the JBS. > Thanks. Will integrate it later since the jdk16-fix-request will be approved after PR is finished. Thanks. ------------- PR: https://git.openjdk.java.net/jdk16/pull/122 From kvn at openjdk.java.net Thu Jan 21 23:51:13 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 21 Jan 2021 23:51:13 GMT Subject: [jdk16] RFR: 8259775: [Vector API] Incorrect code-gen for VectorReinterpret operation [v5] In-Reply-To: <5ZRm7yr18uW4HQWoMQHlI1CHdqUa70mbcj7r6PkROKU=.e5991488-7d71-4657-95c3-8a034b654db6@github.com> References: <5ZRm7yr18uW4HQWoMQHlI1CHdqUa70mbcj7r6PkROKU=.e5991488-7d71-4657-95c3-8a034b654db6@github.com> Message-ID: <_AdtVcr8q3sHB2yl0TvS84ggZ4vGe1XIJ7__jn4-WVc=.a9db17ae-26f0-4854-a4dd-fbbc6d13e9ed@github.com> On Tue, 19 Jan 2021 03:57:16 GMT, Jie Fu wrote: >> Hi all, >> >> The code-gen for VectorReinterpret may be wrong on x86. >> >> Let's see the opto-assembly for the reproducer in the JBS, which was actually based on @XiaohongGong 's example in JDK-8259353 and many thanks to her. >> 066 B7: # out( N1 ) <- in( B6 ) Freq: 0.999994 >> 066 vector_reinterpret_expand XMM0,XMM0 ! >> 066 store_vector [R12 + R11 << 3 + #16] (compressed oop addressing),XMM0 >> >> Please note that the dst and src [1] share the same XMM0 register and movdqu [2] should be generated for this case. >> But when dst == src, movdqu actually generates nothing [3], which leads to incorrect result; >> >> For this case, movdqu should not be empty since the upper bits of dst should be zeroed. >> The similar error also exists for vmovdqu [4]. >> >> I think we should also change movflt [5] to movss but I just can't understand why we have 4-byte vectors. >> Isn't the shortest vectors 8-byte on x86? >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3354 >> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3364 >> [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2490 >> [4] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2515 >> [5] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3379 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Refine the test to always reproduce the bug I approved this fix for JDK 16. I misread your comment and thought you will also fix movdbl() here. I am fine with fixing it in separate PR. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/122 From jiefu at openjdk.java.net Fri Jan 22 00:17:32 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 22 Jan 2021 00:17:32 GMT Subject: [jdk16] Integrated: 8259775: [Vector API] Incorrect code-gen for VectorReinterpret operation In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 12:32:41 GMT, Jie Fu wrote: > Hi all, > > The code-gen for VectorReinterpret may be wrong on x86. > > Let's see the opto-assembly for the reproducer in the JBS, which was actually based on @XiaohongGong 's example in JDK-8259353 and many thanks to her. > 066 B7: # out( N1 ) <- in( B6 ) Freq: 0.999994 > 066 vector_reinterpret_expand XMM0,XMM0 ! > 066 store_vector [R12 + R11 << 3 + #16] (compressed oop addressing),XMM0 > > Please note that the dst and src [1] share the same XMM0 register and movdqu [2] should be generated for this case. > But when dst == src, movdqu actually generates nothing [3], which leads to incorrect result; > > For this case, movdqu should not be empty since the upper bits of dst should be zeroed. > The similar error also exists for vmovdqu [4]. > > I think we should also change movflt [5] to movss but I just can't understand why we have 4-byte vectors. > Isn't the shortest vectors 8-byte on x86? > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3354 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3364 > [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2490 > [4] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2515 > [5] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L3379 This pull request has now been integrated. Changeset: d90e06af Author: Jie Fu URL: https://git.openjdk.java.net/jdk16/commit/d90e06af Stats: 83 lines in 4 files changed: 80 ins; 2 del; 1 mod 8259775: [Vector API] Incorrect code-gen for VectorReinterpret operation Reviewed-by: rbackman, neliasso, kvn ------------- PR: https://git.openjdk.java.net/jdk16/pull/122 From github.com+652983+dasbrain at openjdk.java.net Fri Jan 22 00:33:16 2021 From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn) Date: Fri, 22 Jan 2021 00:33:16 GMT Subject: RFR: 8259922 MethodHandles.collectArguments does not follow its documentation [v2] In-Reply-To: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com> References: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com> Message-ID: <9b-7_CwHqXw-s72aTwKSO9wSwm9wP-vUG4bGtjIad3w=.69638c8d-8d29-4f5c-bad7-f1643944c17f@github.com> > Add explicit range check to `MethodHandles.collectArgumentsCheck`. > Added test case that exercises all cases. > > This is a behavioral change, from throwing an unspecified exception to throwing an IllegalArgumentException, as specified. > No spec change needed, as the IllegalArgumentException is already specified to be thrown in those cases. > > Feel free to suggest a better place for the tests. Johannes Kuhn has updated the pull request incrementally with one additional commit since the last revision: Implement suggestions by Mandy Chung. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2171/files - new: https://git.openjdk.java.net/jdk/pull/2171/files/4f74e2df..f01fefaa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2171&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2171&range=00-01 Stats: 179 lines in 3 files changed: 82 ins; 95 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2171.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2171/head:pull/2171 PR: https://git.openjdk.java.net/jdk/pull/2171 From mchung at openjdk.java.net Fri Jan 22 00:47:49 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 22 Jan 2021 00:47:49 GMT Subject: RFR: 8259922 MethodHandles.collectArguments does not follow its documentation [v2] In-Reply-To: <9b-7_CwHqXw-s72aTwKSO9wSwm9wP-vUG4bGtjIad3w=.69638c8d-8d29-4f5c-bad7-f1643944c17f@github.com> References: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com> <9b-7_CwHqXw-s72aTwKSO9wSwm9wP-vUG4bGtjIad3w=.69638c8d-8d29-4f5c-bad7-f1643944c17f@github.com> Message-ID: On Fri, 22 Jan 2021 00:33:16 GMT, Johannes Kuhn wrote: >> Add explicit range check to `MethodHandles.collectArgumentsCheck`. >> Added test case that exercises all cases. >> >> This is a behavioral change, from throwing an unspecified exception to throwing an IllegalArgumentException, as specified. >> No spec change needed, as the IllegalArgumentException is already specified to be thrown in those cases. >> >> Feel free to suggest a better place for the tests. > > Johannes Kuhn has updated the pull request incrementally with one additional commit since the last revision: > > Implement suggestions by Mandy Chung. Looks good. What tests have you ran? ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2171 From github.com+652983+dasbrain at openjdk.java.net Fri Jan 22 00:54:15 2021 From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn) Date: Fri, 22 Jan 2021 00:54:15 GMT Subject: RFR: 8259922 MethodHandles.collectArguments does not follow its documentation [v2] In-Reply-To: References: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com> <9b-7_CwHqXw-s72aTwKSO9wSwm9wP-vUG4bGtjIad3w=.69638c8d-8d29-4f5c-bad7-f1643944c17f@github.com> Message-ID: On Fri, 22 Jan 2021 00:44:12 GMT, Mandy Chung wrote: >> Johannes Kuhn has updated the pull request incrementally with one additional commit since the last revision: >> >> Implement suggestions by Mandy Chung. > > Looks good. What tests have you ran? On the latest commit, only my own test. On the previous commit (4f74e2d) I did run the full tier1. Currently a full test tier1 run on my machine and github actions is in progress. ------------- PR: https://git.openjdk.java.net/jdk/pull/2171 From iveresov at openjdk.java.net Fri Jan 22 01:47:28 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 01:47:28 GMT Subject: RFR: 8260250: Duplicate check in DebugInformationRecorder::recorders_frozen In-Reply-To: <0yPlSZxEU9rt7Lk-Pt5UxklpDCCpWB-DpLzvgx4gYts=.caa2d7d2-607c-4e2a-8408-85133d3186fc@github.com> References: <0yPlSZxEU9rt7Lk-Pt5UxklpDCCpWB-DpLzvgx4gYts=.caa2d7d2-607c-4e2a-8408-85133d3186fc@github.com> Message-ID: <2Mebmmr8JSmROKUvj0rcIdnL60cja3ZVQoe4wgopVco=.9076c256-7db3-4ba5-8ec5-f9e4589fa6b6@github.com> On Thu, 21 Jan 2021 18:43:26 GMT, Aleksey Shipilev wrote: > SonarCloud instance reports the bug here: > Identical sub-expressions on both sides of operator "||". > > bool DebugInformationRecorder::recorders_frozen() { > return _oop_recorder->is_complete() || _oop_recorder->is_complete(); > } > > It seems to be this way since JDK-6964458. I don't see why it is this way. I think the intent was to check and freeze these two recorders: > > class OopRecorder : public ResourceObj { > private: > ValueRecorder _oops; > ValueRecorder _metadata; > > ...but they are in `OopRecorder` already, and so we already get what we want with a single call: > > #ifdef ASSERT > bool is_complete() { > assert(_oops.is_complete() == _metadata.is_complete(), "must agree"); > return _oops.is_complete(); > } > #endif Marked as reviewed by iveresov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2187 From kvn at openjdk.java.net Fri Jan 22 01:48:46 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 01:48:46 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 05:04:11 GMT, Igor Veresov wrote: >> This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> >> I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. >> >> Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Check legacy flags validity before deriving flag values for emulation mode. I would also suggest to do performance runs. Ask Eric for help. Changes are significant and may affect performance due to some typo. src/hotspot/share/compiler/compilerDefinitions.hpp line 234: > 232: static bool is_interpreter_only() { > 233: return Arguments::is_interpreter_only() || TieredStopAtLevel == CompLevel_none; > 234: } Can you move these functions after has_*() functions? They are used before. src/hotspot/share/compiler/compilerDefinitions.hpp line 179: > 177: } > 178: // Is the JVM in a configuration that permits only c2-compiled methods? > 179: // JVMCI compiler replaces C2. The comment `JVMCI compiler replaces C2.` should be removed or moved to `is_jvmci_compiler_only()` where it is make more sense. src/hotspot/share/compiler/compilerDefinitions.hpp line 171: > 169: } > 170: > 171: static bool is_c2_available() { For me `_available` suffix sounds similar to `has_`. May be `_enabled` is better. At least it is less confusing where it is called. src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp line 1414: > 1412: // use LD;DMB but stores use STLR. This can happen if C2 compiles > 1413: // the stores in one method and C1 compiles the loads in another. > 1414: if (!CompilerConfig::is_c1_or_interpreter_only_no_aot_or_jvmci()) { It is C1 code which should not be executed in -Xint. Why check `interpreter_only`? src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp line 54: > 52: ShenandoahBarrierSet::assembler()->cmpxchg_oop(masm->masm(), addr, cmpval, newval, /*acquire*/ true, /*release*/ true, /*is_cae*/ false, result); > 53: > 54: if (CompilerConfig::is_c1_or_interpreter_only_no_aot_or_jvmci()) { Again about `interpreter_only` check. src/hotspot/share/compiler/compilerDefinitions.hpp line 243: > 241: static bool is_c1_only_no_aot_or_jvmci() { > 242: return is_c1_only() && !is_aot() && !is_jvmci(); > 243: } These names are a little confusing: what about C2, why only no AOT and JVMCI. I understand that you want to check if JVMCI or AOT can install their compiled code. May be `is_c1_nmethods_only`, `is_c1_nmethods_or_interpreter_only` ? src/hotspot/share/oops/method.cpp line 1013: > 1011: return false; > 1012: if (comp_level == CompLevel_any) > 1013: return is_not_c1_compilable() && is_not_c2_compilable(); Was it bug before? src/hotspot/share/compiler/compilerDefinitions.cpp line 62: > 60: } > 61: } else if (strcmp(CompilationMode, "high-only") == 0) { > 62: if (!CompilerConfig::has_c2() && !CompilerConfig::is_jvmci_compiler()) { Is using `!is_c2_or_jvmci_compiler_available()` better here? All flags should be processed at this point. And we could have some `TieredStopAtLevel` flags. It looks like you have cross dependency between CompilerConfig and CompilationModeFlag which make using `is_c2_or_jvmci_compiler_available()` impossible here. src/hotspot/share/compiler/compilerDefinitions.cpp line 84: > 82: } else if (CompilerConfig::is_c2_or_jvmci_compiler_only()) { > 83: _mode = Mode::HIGH_ONLY; > 84: } else if (CompilerConfig::is_jvmci_compiler() && !TieredCompilation) { Should you check `CompilerConfig::is_tiered()` instead of `TieredCompilation` flag? ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Fri Jan 22 01:48:49 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 01:48:49 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 23:06:19 GMT, Igor Veresov wrote: >> This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> >> I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. >> >> Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Fix another s390 compilation failure src/hotspot/share/aot/aotCodeHeap.cpp line 194: > 192: // AOT libs are loaded before heap initialized so shift values are not set. > 193: // It is okay since ObjectAlignmentInBytes flag which defines shifts value is set before AOT libs are loaded. > 194: // Set shifts value based on first AOT library config. Why this code is removed? src/hotspot/share/compiler/compileBroker.cpp line 972: > 970: > 971: // Initialize the compilation queue > 972: if (_c2_count > 0) { Is ZERO treated as `is_interpreter_only()` ? How this change works with ZERO? src/hotspot/share/runtime/vmStructs.cpp line 296: > 294: JVMTI_ONLY(nonstatic_field(MethodCounters, _number_of_breakpoints, u2)) \ > 295: nonstatic_field(MethodCounters, _invocation_counter, InvocationCounter) \ > 296: nonstatic_field(MethodCounters, _backedge_counter, InvocationCounter) \ You need to fix SA agent: https://github.com/openjdk/jdk/blob/master/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodCounters.java#L52 src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 229: > 227: JVMTI_ONLY(nonstatic_field(MethodCounters, _number_of_breakpoints, u2)) \ > 228: nonstatic_field(MethodCounters, _invocation_counter, InvocationCounter) \ > 229: nonstatic_field(MethodCounters, _backedge_counter, InvocationCounter) \ I don't see Java JVMCI changes. Do you need them? test/hotspot/jtreg/TEST.quick-groups line 1787: > 1785: vmTestbase/jit/t/t112/t112.java \ > 1786: vmTestbase/jit/t/t113/t113.java \ > 1787: vmTestbase/jit/verifier/VerifyInitLocal/VerifyInitLocal.java \ Why this test removed? ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From github.com+652983+dasbrain at openjdk.java.net Fri Jan 22 03:26:44 2021 From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn) Date: Fri, 22 Jan 2021 03:26:44 GMT Subject: RFR: 8259922 MethodHandles.collectArguments does not throw IAE if pos is outside the arity range [v2] In-Reply-To: References: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com> <9b-7_CwHqXw-s72aTwKSO9wSwm9wP-vUG4bGtjIad3w=.69638c8d-8d29-4f5c-bad7-f1643944c17f@github.com> Message-ID: On Fri, 22 Jan 2021 00:48:51 GMT, Johannes Kuhn wrote: >> Looks good. What tests have you ran? > > On the latest commit, only my own test. > On the previous commit (4f74e2d) I did run the full tier1. > > Currently a full test tier1 run on my machine and github actions is in progress. Tests did run successfully on my machine (win 64) and github actions. Let me know if there should be additional tests that I should run. ------------- PR: https://git.openjdk.java.net/jdk/pull/2171 From shade at openjdk.java.net Fri Jan 22 07:13:50 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 22 Jan 2021 07:13:50 GMT Subject: Integrated: 8259928: compiler/jvmci tests fail with -Xint In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 14:39:05 GMT, Aleksey Shipilev wrote: > I was getting Zero VM close to run tier1, and before that I wanted to see that tier{1,2} pass with -Xint. Some test are failing due to timeouts, but compiler/jvmci tests cannot run with -Xint at all. (Zero avoids this by not having VM feature flags "jvmci"). > > If you run the VM with `-Xint` and JVMCI, this would happen: > > $ build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xint -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI > OpenJDK 64-Bit Server VM warning: JVMCI Compiler disabled due to -Xint. > > Additional testing: > - [x] `compiler/jvmci` with `TEST_VM_OPTS=-Xint` (now disabled) > - [x] `compiler/jvmci` with default options (still run and pass) This pull request has now been integrated. Changeset: a70acf2c Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/a70acf2c Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8259928: compiler/jvmci tests fail with -Xint Reviewed-by: kvn, iignatyev ------------- PR: https://git.openjdk.java.net/jdk/pull/2132 From github.com+7991079+danlemmond at openjdk.java.net Fri Jan 22 09:39:06 2021 From: github.com+7991079+danlemmond at openjdk.java.net (Dan) Date: Fri, 22 Jan 2021 09:39:06 GMT Subject: RFR: 8255216: Change _directive->BreakAtCompileOption to env()->break_at_compile() [v7] In-Reply-To: References: Message-ID: > _break_at_compile was no longer in use after changes to compile.cpp. > Change compile.cpp and c1_Compilation.cpp to use env()->break_at_compile() instead > to make that code no longer dead. > No new code, and Tier1 tests succeed after code is removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 Dan has updated the pull request incrementally with one additional commit since the last revision: Update compileBroker to use BreakAtCompileOption BreakAtExecuteOption should not be used here, instead use BreakAtCompileOption ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1806/files - new: https://git.openjdk.java.net/jdk/pull/1806/files/12eedef8..783635d2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1806&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1806&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1806.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1806/head:pull/1806 PR: https://git.openjdk.java.net/jdk/pull/1806 From chagedorn at openjdk.java.net Fri Jan 22 10:51:14 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Fri, 22 Jan 2021 10:51:14 GMT Subject: RFR: 8257498: Remove useless skeleton predicates [v4] In-Reply-To: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com> References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com> Message-ID: > This enhancement removes useless skeleton predicates in the same way as we already remove normal useless predicates in `PhaseIdealLoop::eliminate_useless_predicates()`. > > Thanks, > Christian Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: Revert get_skeleton_predicates again ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2075/files - new: https://git.openjdk.java.net/jdk/pull/2075/files/5b716bc5..84723004 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2075&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2075&range=02-03 Stats: 26 lines in 3 files changed: 7 ins; 13 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2075.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2075/head:pull/2075 PR: https://git.openjdk.java.net/jdk/pull/2075 From chagedorn at openjdk.java.net Fri Jan 22 10:51:15 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Fri, 22 Jan 2021 10:51:15 GMT Subject: RFR: 8257498: Remove useless skeleton predicates [v3] In-Reply-To: References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com> Message-ID: <5sZOTiLLhvLuYXpa95nRVUt6bANFdDq4kuUaqhKe4-4=.1a097a09-c516-4886-b3e2-3c040e4c5344@github.com> On Thu, 21 Jan 2021 08:56:53 GMT, Roland Westrelin wrote: >> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix removal from global list and update get_skeleton_predicates > > src/hotspot/share/opto/loopnode.cpp line 3585: > >> 3583: } >> 3584: } >> 3585: > > I didn't realize you would have to go through an extra list. So I guess what you had before with the get_opaque parameter was better. Yes, we need an extra one. I reverted that part back again. ------------- PR: https://git.openjdk.java.net/jdk/pull/2075 From thartmann at openjdk.java.net Fri Jan 22 12:10:00 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 22 Jan 2021 12:10:00 GMT Subject: RFR: 8260250: Duplicate check in DebugInformationRecorder::recorders_frozen In-Reply-To: <0yPlSZxEU9rt7Lk-Pt5UxklpDCCpWB-DpLzvgx4gYts=.caa2d7d2-607c-4e2a-8408-85133d3186fc@github.com> References: <0yPlSZxEU9rt7Lk-Pt5UxklpDCCpWB-DpLzvgx4gYts=.caa2d7d2-607c-4e2a-8408-85133d3186fc@github.com> Message-ID: On Thu, 21 Jan 2021 18:43:26 GMT, Aleksey Shipilev wrote: > SonarCloud instance reports the bug here: > Identical sub-expressions on both sides of operator "||". > > bool DebugInformationRecorder::recorders_frozen() { > return _oop_recorder->is_complete() || _oop_recorder->is_complete(); > } > > It seems to be this way since JDK-6964458. I don't see why it is this way. I think the intent was to check and freeze these two recorders: > > class OopRecorder : public ResourceObj { > private: > ValueRecorder _oops; > ValueRecorder _metadata; > > ...but they are in `OopRecorder` already, and so we already get what we want with a single call: > > #ifdef ASSERT > bool is_complete() { > assert(_oops.is_complete() == _metadata.is_complete(), "must agree"); > return _oops.is_complete(); > } > #endif Marked as reviewed by thartmann (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2187 From chagedorn at openjdk.java.net Fri Jan 22 14:14:07 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Fri, 22 Jan 2021 14:14:07 GMT Subject: [jdk16] RFR: 8260284: C2: assert(_base == Int) failed: Not an Int Message-ID: `PhaseIterGVN::no_dependent_zero_check()` does not handle the case when the divisor `n->in(2)` is top when a Div/Mod node is dying. As a result, we hit the assertion in `is_int()` because the type is top. The fix is straight forward to handle this case and just return false to avoid any further redundant optimization on a dead node. Thanks, Christian ------------- Commit messages: - 8260284: C2: assert(_base == Int) failed: Not an Int Changes: https://git.openjdk.java.net/jdk16/pull/129/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=129&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260284 Stats: 94 lines in 2 files changed: 94 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/129.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/129/head:pull/129 PR: https://git.openjdk.java.net/jdk16/pull/129 From thartmann at openjdk.java.net Fri Jan 22 14:40:56 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 22 Jan 2021 14:40:56 GMT Subject: [jdk16] RFR: 8260284: C2: assert(_base == Int) failed: Not an Int In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 14:09:06 GMT, Christian Hagedorn wrote: > `PhaseIterGVN::no_dependent_zero_check()` does not handle the case when the divisor `n->in(2)` is top when a Div/Mod node is dying. As a result, we hit the assertion in `is_int()` because the type is top. > > The fix is straight forward to handle this case and just return false to avoid any further redundant optimization on a dead node. > > Thanks, > Christian Looks good to me. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/129 From chagedorn at openjdk.java.net Fri Jan 22 14:40:56 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Fri, 22 Jan 2021 14:40:56 GMT Subject: [jdk16] RFR: 8260284: C2: assert(_base == Int) failed: Not an Int In-Reply-To: References: Message-ID: <-_Ia89BDJj4kj32EPwvD3i9G0XisTSt6xTBV0yvSCq0=.f6484027-30ff-4261-8028-937d6b4e18e9@github.com> On Fri, 22 Jan 2021 14:16:35 GMT, Tobias Hartmann wrote: >> `PhaseIterGVN::no_dependent_zero_check()` does not handle the case when the divisor `n->in(2)` is top when a Div/Mod node is dying. As a result, we hit the assertion in `is_int()` because the type is top. >> >> The fix is straight forward to handle this case and just return false to avoid any further redundant optimization on a dead node. >> >> Thanks, >> Christian > > Looks good to me. Thank you Tobias for your review! ------------- PR: https://git.openjdk.java.net/jdk16/pull/129 From roland at openjdk.java.net Fri Jan 22 14:43:58 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Fri, 22 Jan 2021 14:43:58 GMT Subject: RFR: 8260296: SA's dumpreplaydata fails Message-ID: I noticed that the SA's dumpreplaydata command fails with: java.lang.AssertionError: CLHSDB wasn't run successfully: Opening core file, please wait... hsdb> Exception in thread "main" java.lang.InternalError: ciMetadata does not appear to be polymorphic with a simple test program. This happens because the SA can't find the vtable symbol for ciMetadata (build produced by gcc 9.2.1). AFAIU, there's nothing in our build system that hides that symbol. I had to move one method's definition from the header file to the cpp file for the symbol to be visible again. We have a test that checks dumpreplaydata but it doesn't catch that problem. The test produces a replay file from a core file with the SA by running a simple test with -Xcomp and CICrash=1. So the replay data has very little or no profile data (which is what causes the problem above). I propose running a slightly more complicated test method and crashing after the method has had time to run for long enough to collect profile data. The other shortcoming of the test is that it doesn't look at the content of the replay file. It only warns if they differ. The replay file produced by the VM and the one produced by the SA should be identical (except for comment lines). So I propose we check that. Finally, I can't run that test on my system because core files are handled by systemd (I'm running some recent version of fedora). I suppose, the system can be configured differently but having the test work out the box is nice. I extended the test case to handle that. With the improved test, there are a few differences between the VM and SA replay files caused by VM changes that were not mirrored in the SA. I fixed those. ------------- Commit messages: - whitespaces - SA fixes - VM fix - test Changes: https://git.openjdk.java.net/jdk/pull/2195/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2195&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260296 Stats: 195 lines in 13 files changed: 153 ins; 3 del; 39 mod Patch: https://git.openjdk.java.net/jdk/pull/2195.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2195/head:pull/2195 PR: https://git.openjdk.java.net/jdk/pull/2195 From lucy at openjdk.java.net Fri Jan 22 15:00:47 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Fri, 22 Jan 2021 15:00:47 GMT Subject: RFR: 8259383: AsyncGetCallTrace() crashes sporadically In-Reply-To: References: <55VhodtLlLULjpxGm3PXOn2iFgrVIdqcZwysOSEK8rg=.d1571446-fc26-4b7d-9450-29ecacb31dda@github.com> Message-ID: On Wed, 20 Jan 2021 03:36:52 GMT, Andrei Pangin wrote: >> The changes look ok to me. I think it would be good to get someone from the compiler team to verify your reasoning here. > > Hi Lutz, > > Thank you for working on this issue. > I'm not a formal OpenJDK Reviewer, but as an author of async-profiler project (which heavily relies on AsyncGetCallTrace), I'm more or less familiar with this code. Let me leave a few comments. > > 1. The statement `if (candidate.pc() != NULL) return false;` looks a bit odd to me. When a profiler calls AsyncGetCallTrace, pc of the initial frame is obtained from a signal context, and it is never NULL. Returning false when pc != NULL basically invalidates the entire `if (fr->cb() == NULL)` branch. If this was intended, the branch could be simplified. > 2. At the same time, returning false whenever cb == NULL, discards a fair amount of valid stack traces, e.g. when a runtime function is called from Java without switching to in_vm state. I guess, the original intention of that loop was to handle such cases, but, as you noticed, it does not currently work well because of the assertions. I'd rather prefer revising the logic of that loop then instead of dropping all those valid samples. > 3. What I don't really understand from the bug report is why `if (fr->cb() == NULL)` branch is executed at all in this particular example. According to the stack trace from the crash dump, the top frame (before a signal handler) is `ThreadCritical::~ThreadCritical()`. This means, a thread is in_vm state, and its last_Java_frame should have been set. In this case AsyncGetCallTrace prefers to take last_Java_frame, and thus cb should be non-NULL. Another suspicious thing is that a frame below `ThreadCritical::~ThreadCritical()` is not a C frame. This cannot normally happen (the execution is in the middle of `ThreadCritical::~ThreadCritical()`, where the stack frame is consistent). These facts make me think something bad has already happened with the stack earlier, and the failed guarantee is probably just one manifestation of a bigger problem. Spent a lot fo time and many thoughts. Finally, I found out it was all for nothing. The failure doesn't occur at the location I was sure it would. Will invest more time and more thoughts... I'll be back! ------------- PR: https://git.openjdk.java.net/jdk/pull/2032 From iveresov at openjdk.java.net Fri Jan 22 15:22:50 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 15:22:50 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 19:51:11 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Check legacy flags validity before deriving flag values for emulation mode. > > src/hotspot/share/compiler/compilerDefinitions.hpp line 234: > >> 232: static bool is_interpreter_only() { >> 233: return Arguments::is_interpreter_only() || TieredStopAtLevel == CompLevel_none; >> 234: } > > Can you move these functions after has_*() functions? They are used before. Right now has_() functions are defined before uses. Do you want them to be after the uses? Please confirm. > src/hotspot/share/compiler/compilerDefinitions.hpp line 179: > >> 177: } >> 178: // Is the JVM in a configuration that permits only c2-compiled methods? >> 179: // JVMCI compiler replaces C2. > > The comment `JVMCI compiler replaces C2.` should be removed or moved to `is_jvmci_compiler_only()` where it is make more sense. I removed the comment, it does seem to be out of context. I'm not sure why I put it there. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 17:02:48 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 17:02:48 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 20:17:48 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Check legacy flags validity before deriving flag values for emulation mode. > > src/hotspot/share/compiler/compilerDefinitions.hpp line 171: > >> 169: } >> 170: >> 171: static bool is_c2_available() { > > For me `_available` suffix sounds similar to `has_`. May be `_enabled` is better. At least it is less confusing where it is called. Ok, I'll do that. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 17:09:52 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 17:09:52 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: <-XgAzg034eEEPCuR342rrb4r6X-2yLRxGbr2QJgXoLw=.c1926204-ba05-4b70-891d-fd1765cc9778@github.com> On Wed, 20 Jan 2021 20:28:34 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Check legacy flags validity before deriving flag values for emulation mode. > > src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp line 1414: > >> 1412: // use LD;DMB but stores use STLR. This can happen if C2 compiles >> 1413: // the stores in one method and C1 compiles the loads in another. >> 1414: if (!CompilerConfig::is_c1_or_interpreter_only_no_aot_or_jvmci()) { > > It is C1 code which should not be executed in -Xint. Why check `interpreter_only`? Good point, I'll fix that. > src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp line 54: > >> 52: ShenandoahBarrierSet::assembler()->cmpxchg_oop(masm->masm(), addr, cmpval, newval, /*acquire*/ true, /*release*/ true, /*is_cae*/ false, result); >> 53: >> 54: if (CompilerConfig::is_c1_or_interpreter_only_no_aot_or_jvmci()) { > > Again about `interpreter_only` check. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 17:16:45 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 17:16:45 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 20:36:35 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix another s390 compilation failure > > src/hotspot/share/aot/aotCodeHeap.cpp line 194: > >> 192: // AOT libs are loaded before heap initialized so shift values are not set. >> 193: // It is okay since ObjectAlignmentInBytes flag which defines shifts value is set before AOT libs are loaded. >> 194: // Set shifts value based on first AOT library config. > > Why this code is removed? It's always running with the tiered policy now. Prior to this change if you attempted to run an AOT library with tiered-style profiling compiled in with the non-tiered policy it wouldn't work correctly. That's why we had this check. Now tiered is the only policy, so it will work correctly whether you have the AOT code with profiling or not. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From github.com+652983+dasbrain at openjdk.java.net Fri Jan 22 17:21:43 2021 From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn) Date: Fri, 22 Jan 2021 17:21:43 GMT Subject: Integrated: 8259922 MethodHandles.collectArguments does not throw IAE if pos is outside the arity range In-Reply-To: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com> References: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com> Message-ID: On Wed, 20 Jan 2021 18:29:00 GMT, Johannes Kuhn wrote: > Add explicit range check to `MethodHandles.collectArgumentsCheck`. > Added test case that exercises all cases. > > This is a behavioral change, from throwing an unspecified exception to throwing an IllegalArgumentException, as specified. > No spec change needed, as the IllegalArgumentException is already specified to be thrown in those cases. > > Feel free to suggest a better place for the tests. This pull request has now been integrated. Changeset: bf5e8015 Author: Johannes Kuhn Committer: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/bf5e8015 Stats: 86 lines in 2 files changed: 86 ins; 0 del; 0 mod 8259922: MethodHandles.collectArguments does not throw IAE if pos is outside the arity range Reviewed-by: mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/2171 From shade at openjdk.java.net Fri Jan 22 17:22:41 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 22 Jan 2021 17:22:41 GMT Subject: Integrated: 8260250: Duplicate check in DebugInformationRecorder::recorders_frozen In-Reply-To: <0yPlSZxEU9rt7Lk-Pt5UxklpDCCpWB-DpLzvgx4gYts=.caa2d7d2-607c-4e2a-8408-85133d3186fc@github.com> References: <0yPlSZxEU9rt7Lk-Pt5UxklpDCCpWB-DpLzvgx4gYts=.caa2d7d2-607c-4e2a-8408-85133d3186fc@github.com> Message-ID: On Thu, 21 Jan 2021 18:43:26 GMT, Aleksey Shipilev wrote: > SonarCloud instance reports the bug here: > Identical sub-expressions on both sides of operator "||". > > bool DebugInformationRecorder::recorders_frozen() { > return _oop_recorder->is_complete() || _oop_recorder->is_complete(); > } > > It seems to be this way since JDK-6964458. I don't see why it is this way. I think the intent was to check and freeze these two recorders: > > class OopRecorder : public ResourceObj { > private: > ValueRecorder _oops; > ValueRecorder _metadata; > > ...but they are in `OopRecorder` already, and so we already get what we want with a single call: > > #ifdef ASSERT > bool is_complete() { > assert(_oops.is_complete() == _metadata.is_complete(), "must agree"); > return _oops.is_complete(); > } > #endif This pull request has now been integrated. Changeset: c5ad713e Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/c5ad713e Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8260250: Duplicate check in DebugInformationRecorder::recorders_frozen Reviewed-by: iveresov, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/2187 From iveresov at openjdk.java.net Fri Jan 22 17:23:47 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 17:23:47 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 20:52:31 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Check legacy flags validity before deriving flag values for emulation mode. > > src/hotspot/share/compiler/compilerDefinitions.hpp line 243: > >> 241: static bool is_c1_only_no_aot_or_jvmci() { >> 242: return is_c1_only() && !is_aot() && !is_jvmci(); >> 243: } > > These names are a little confusing: what about C2, why only no AOT and JVMCI. I understand that you want to check if JVMCI or AOT can install their compiled code. > May be `is_c1_nmethods_only`, `is_c1_nmethods_or_interpreter_only` ? I guess it's a matter of naming convention. What I tried to make the CompilerConfig API about is to check if compilers are present/enabled and in which combination. Of course presence of a compiler implies that we're going to see nmethod produced by it. I'd like to keep the current naming if it's not a huge eyesore for you. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 17:35:52 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 17:35:52 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 00:43:29 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Check legacy flags validity before deriving flag values for emulation mode. > > src/hotspot/share/oops/method.cpp line 1013: > >> 1011: return false; >> 1012: if (comp_level == CompLevel_any) >> 1013: return is_not_c1_compilable() && is_not_c2_compilable(); > > Was it bug before? Yup. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 17:35:48 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 17:35:48 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 00:24:34 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix another s390 compilation failure > > src/hotspot/share/compiler/compileBroker.cpp line 972: > >> 970: >> 971: // Initialize the compilation queue >> 972: if (_c2_count > 0) { > > Is ZERO treated as `is_interpreter_only()` ? How this change works with ZERO? I forgot why I removed that. Let me put it back and run it through testing again. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Fri Jan 22 17:38:48 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 17:38:48 GMT Subject: RFR: 8255216: Change _directive->BreakAtCompileOption to env()->break_at_compile() [v7] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 09:39:06 GMT, Dan wrote: >> _break_at_compile was no longer in use after changes to compile.cpp. >> Change compile.cpp and c1_Compilation.cpp to use env()->break_at_compile() instead >> to make that code no longer dead. >> No new code, and Tier1 tests succeed after code is removed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 > > Dan has updated the pull request incrementally with one additional commit since the last revision: > > Update compileBroker to use BreakAtCompileOption > > BreakAtExecuteOption should not be used here, instead use > BreakAtCompileOption Good. Finally. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1806 From kvn at openjdk.java.net Fri Jan 22 17:41:50 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 17:41:50 GMT Subject: [jdk16] RFR: 8260284: C2: assert(_base == Int) failed: Not an Int In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 14:09:06 GMT, Christian Hagedorn wrote: > `PhaseIterGVN::no_dependent_zero_check()` does not handle the case when the divisor `n->in(2)` is top when a Div/Mod node is dying. As a result, we hit the assertion in `is_int()` because the type is top. > > The fix is straight forward to handle this case and just return false to avoid any further redundant optimization on a dead node. > > Thanks, > Christian Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/129 From kvn at openjdk.java.net Fri Jan 22 17:47:41 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 17:47:41 GMT Subject: RFR: 8260296: SA's dumpreplaydata fails In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 14:21:52 GMT, Roland Westrelin wrote: > I noticed that the SA's dumpreplaydata command fails with: > > java.lang.AssertionError: CLHSDB wasn't run successfully: Opening core file, please wait... > hsdb> Exception in thread "main" java.lang.InternalError: ciMetadata does not appear to be polymorphic > > with a simple test program. This happens because the SA can't find the > vtable symbol for ciMetadata (build produced by gcc 9.2.1). AFAIU, > there's nothing in our build system that hides that symbol. I had to > move one method's definition from the header file to the cpp file for > the symbol to be visible again. > > We have a test that checks dumpreplaydata but it doesn't catch that > problem. The test produces a replay file from a core file with the SA > by running a simple test with -Xcomp and CICrash=1. So the replay data > has very little or no profile data (which is what causes the problem > above). I propose running a slightly more complicated test method and > crashing after the method has had time to run for long enough to > collect profile data. > > The other shortcoming of the test is that it doesn't look at the > content of the replay file. It only warns if they differ. The replay > file produced by the VM and the one produced by the SA should be > identical (except for comment lines). So I propose we check that. > > Finally, I can't run that test on my system because core files are > handled by systemd (I'm running some recent version of fedora). I > suppose, the system can be configured differently but having the test > work out the box is nice. I extended the test case to handle that. > > With the improved test, there are a few differences between the VM and > SA replay files caused by VM changes that were not mirrored in the > SA. I fixed those. Looks good to me. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2195 From iveresov at openjdk.java.net Fri Jan 22 17:55:47 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 17:55:47 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 00:56:16 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix another s390 compilation failure > > src/hotspot/share/runtime/vmStructs.cpp line 296: > >> 294: JVMTI_ONLY(nonstatic_field(MethodCounters, _number_of_breakpoints, u2)) \ >> 295: nonstatic_field(MethodCounters, _invocation_counter, InvocationCounter) \ >> 296: nonstatic_field(MethodCounters, _backedge_counter, InvocationCounter) \ > > You need to fix SA agent: > https://github.com/openjdk/jdk/blob/master/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodCounters.java#L52 Good point. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Fri Jan 22 18:22:08 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 18:22:08 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 15:19:39 GMT, Igor Veresov wrote: >> src/hotspot/share/compiler/compilerDefinitions.hpp line 234: >> >>> 232: static bool is_interpreter_only() { >>> 233: return Arguments::is_interpreter_only() || TieredStopAtLevel == CompLevel_none; >>> 234: } >> >> Can you move these functions after has_*() functions? They are used before. > > Right now has_() functions are defined before uses. Do you want them to be after the uses? Please confirm. Don't touch has_() - they are in correct place. I am asking only to move these 4 is_() functions between has_() and is_c1_only() function. >> src/hotspot/share/compiler/compilerDefinitions.hpp line 243: >> >>> 241: static bool is_c1_only_no_aot_or_jvmci() { >>> 242: return is_c1_only() && !is_aot() && !is_jvmci(); >>> 243: } >> >> These names are a little confusing: what about C2, why only no AOT and JVMCI. I understand that you want to check if JVMCI or AOT can install their compiled code. >> May be `is_c1_nmethods_only`, `is_c1_nmethods_or_interpreter_only` ? > > I guess it's a matter of naming convention. What I tried to make the CompilerConfig API about is to check if compilers are present/enabled and in which combination. Of course presence of a compiler implies that we're going to see nmethod produced by it. I'd like to keep the current naming if it's not a huge eyesore for you. Hmm, may be we don't need these funxctions. Seems is_c1_only() will be true only when JVMCI is off. Right? We can also reinforce it to exclude AOT too. And AOT and JVMCI are disabled with -Xint. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 18:22:09 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 18:22:09 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 01:11:33 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix another s390 compilation failure > > src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 229: > >> 227: JVMTI_ONLY(nonstatic_field(MethodCounters, _number_of_breakpoints, u2)) \ >> 228: nonstatic_field(MethodCounters, _invocation_counter, InvocationCounter) \ >> 229: nonstatic_field(MethodCounters, _backedge_counter, InvocationCounter) \ > > I don't see Java JVMCI changes. Do you need them? I haven't found any uses of it. > test/hotspot/jtreg/TEST.quick-groups line 1787: > >> 1785: vmTestbase/jit/t/t112/t112.java \ >> 1786: vmTestbase/jit/t/t113/t113.java \ >> 1787: vmTestbase/jit/verifier/VerifyInitLocal/VerifyInitLocal.java \ > > Why this test removed? It was an odd test that check if the -XX:+PrintTieredEvents flag didn't work with -XX:-TieredCompilation. Since now it always works that test doesn't make much sense anymore. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Fri Jan 22 18:22:10 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 18:22:10 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: <3tY1BN0Q7o5K4cFcRH_KRk8djNOlMOpzU9yY3XpeaRc=.8128e81c-74b0-43c0-b96b-2eeee24d660d@github.com> On Fri, 22 Jan 2021 17:14:15 GMT, Igor Veresov wrote: >> src/hotspot/share/aot/aotCodeHeap.cpp line 194: >> >>> 192: // AOT libs are loaded before heap initialized so shift values are not set. >>> 193: // It is okay since ObjectAlignmentInBytes flag which defines shifts value is set before AOT libs are loaded. >>> 194: // Set shifts value based on first AOT library config. >> >> Why this code is removed? > > It's always running with the tiered policy now. Prior to this change if you attempted to run an AOT library with tiered-style profiling compiled in with the non-tiered policy it wouldn't work correctly. That's why we had this check. Now tiered is the only policy, so it will work correctly whether you have the AOT code with profiling or not. Okay. Got it ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 18:22:10 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 18:22:10 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 17:51:36 GMT, Vladimir Kozlov wrote: >> Right now has_() functions are defined before uses. Do you want them to be after the uses? Please confirm. > > Don't touch has_() - they are in correct place. I am asking only to move these 4 is_() functions between has_() and is_c1_only() function. I understand what you mean now. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 18:22:11 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 18:22:11 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 01:25:25 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Check legacy flags validity before deriving flag values for emulation mode. > > src/hotspot/share/compiler/compilerDefinitions.cpp line 62: > >> 60: } >> 61: } else if (strcmp(CompilationMode, "high-only") == 0) { >> 62: if (!CompilerConfig::has_c2() && !CompilerConfig::is_jvmci_compiler()) { > > Is using `!is_c2_or_jvmci_compiler_available()` better here? All flags should be processed at this point. And we could have some `TieredStopAtLevel` flags. > It looks like you have cross dependency between CompilerConfig and CompilationModeFlag which make using `is_c2_or_jvmci_compiler_available()` impossible here. Yes, there is an unfortunate cross dependency. It would probably work fine since ```_mode``` is initialized to ```NORMAL``` before parsing the flag. But I wanted to not use any function that would depend on the value of the ```_mode``` during parsing. It could create trouble in the future. I'll put more comments about that. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 18:29:48 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 18:29:48 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 18:04:54 GMT, Vladimir Kozlov wrote: >> I guess it's a matter of naming convention. What I tried to make the CompilerConfig API about is to check if compilers are present/enabled and in which combination. Of course presence of a compiler implies that we're going to see nmethod produced by it. I'd like to keep the current naming if it's not a huge eyesore for you. > > Hmm, may be we don't need these funxctions. > Seems is_c1_only() will be true only when JVMCI is off. Right? We can also reinforce it to exclude AOT too. > And AOT and JVMCI are disabled with -Xint. It's not so easy. You can have AOT or JVMCI enabled with -Xint. JVMCI code installs can be initiated not only as a result of method going through the compiler broker. Remember that you can run Graal in "host" mode, where it is a normal C1/C2 system (or may be just an interpreter); Truffle can work in a mode like that. And you can totally run with AOT and interpreter (without any JIT). ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 20:02:55 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 20:02:55 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 01:37:53 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Check legacy flags validity before deriving flag values for emulation mode. > > src/hotspot/share/compiler/compilerDefinitions.cpp line 84: > >> 82: } else if (CompilerConfig::is_c2_or_jvmci_compiler_only()) { >> 83: _mode = Mode::HIGH_ONLY; >> 84: } else if (CompilerConfig::is_jvmci_compiler() && !TieredCompilation) { > > Should you check `CompilerConfig::is_tiered()` instead of `TieredCompilation` flag? I wanted to be explicit about what's happening here. I'd like it to be obvious that the we're switching to ```HIGH_ONLY_QUICK_INTERNAL``` mode as a result of the user specifying -XX:-TieredCompilation on the command line. There is a bug on this line however. I should be checking if c1 is present and enabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Fri Jan 22 20:07:51 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 20:07:51 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 18:15:40 GMT, Igor Veresov wrote: >> src/hotspot/share/compiler/compilerDefinitions.cpp line 62: >> >>> 60: } >>> 61: } else if (strcmp(CompilationMode, "high-only") == 0) { >>> 62: if (!CompilerConfig::has_c2() && !CompilerConfig::is_jvmci_compiler()) { >> >> Is using `!is_c2_or_jvmci_compiler_available()` better here? All flags should be processed at this point. And we could have some `TieredStopAtLevel` flags. >> It looks like you have cross dependency between CompilerConfig and CompilationModeFlag which make using `is_c2_or_jvmci_compiler_available()` impossible here. > > Yes, there is an unfortunate cross dependency. It would probably work fine since ```_mode``` is initialized to ```NORMAL``` before parsing the flag. But I wanted to not use any function that would depend on the value of the ```_mode``` during parsing. It could create trouble in the future. I'll put more comments about that. okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Fri Jan 22 20:10:53 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 20:10:53 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 18:26:43 GMT, Igor Veresov wrote: >> Hmm, may be we don't need these funxctions. >> Seems is_c1_only() will be true only when JVMCI is off. Right? We can also reinforce it to exclude AOT too. >> And AOT and JVMCI are disabled with -Xint. > > It's not so easy. You can have AOT or JVMCI enabled with -Xint. JVMCI code installs can be initiated not only as a result of method going through the compiler broker. Remember that you can run Graal in "host" mode, where it is a normal C1/C2 system (or may be just an interpreter); Truffle can work in a mode like that. And you can totally run with AOT and interpreter (without any JIT). I don't think so: > java -Xint -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -version Java HotSpot(TM) 64-Bit Server VM warning: JVMCI Compiler disabled due to -Xint. > java -Xint -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -XX:+PrintAOT -version Java HotSpot(TM) 64-Bit Server VM warning: -Xint is not compatible with AOT (switching AOT off) ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Fri Jan 22 20:14:49 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 20:14:49 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 19:50:48 GMT, Igor Veresov wrote: >> src/hotspot/share/compiler/compilerDefinitions.cpp line 84: >> >>> 82: } else if (CompilerConfig::is_c2_or_jvmci_compiler_only()) { >>> 83: _mode = Mode::HIGH_ONLY; >>> 84: } else if (CompilerConfig::is_jvmci_compiler() && !TieredCompilation) { >> >> Should you check `CompilerConfig::is_tiered()` instead of `TieredCompilation` flag? > > I wanted to be explicit about what's happening here. I'd like it to be obvious that the we're switching to ```HIGH_ONLY_QUICK_INTERNAL``` mode as a result of the user specifying -XX:-TieredCompilation on the command line. > > There is a bug on this line however. I should be checking if c1 is present and enabled. okay ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 20:19:49 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 20:19:49 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 20:08:17 GMT, Vladimir Kozlov wrote: >> It's not so easy. You can have AOT or JVMCI enabled with -Xint. JVMCI code installs can be initiated not only as a result of method going through the compiler broker. Remember that you can run Graal in "host" mode, where it is a normal C1/C2 system (or may be just an interpreter); Truffle can work in a mode like that. And you can totally run with AOT and interpreter (without any JIT). > > I don't think so: >> java -Xint -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -version > Java HotSpot(TM) 64-Bit Server VM warning: JVMCI Compiler disabled due to -Xint. > >> java -Xint -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -XX:+PrintAOT -version > Java HotSpot(TM) 64-Bit Server VM warning: -Xint is not compatible with AOT (switching AOT off) You're right. Perhaps I was overly defensive. It doesn't hurt though, less potential surprises in the future (as you correctly noticed those are used to make sure there are no nmethods produced by any other compiler but C1). Also you still can have a C1 and AOT combination. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Fri Jan 22 20:31:50 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 20:31:50 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 20:17:24 GMT, Igor Veresov wrote: >> I don't think so: >>> java -Xint -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -version >> Java HotSpot(TM) 64-Bit Server VM warning: JVMCI Compiler disabled due to -Xint. >> >>> java -Xint -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -XX:+PrintAOT -version >> Java HotSpot(TM) 64-Bit Server VM warning: -Xint is not compatible with AOT (switching AOT off) > > You're right. Perhaps I was overly defensive. It doesn't hurt though, less potential surprises in the future (as you correctly noticed those are used to make sure there are no nmethods produced by any other compiler but C1). > Also you still can have a C1 and AOT combination. Yes. You can have C1 in combination with AOT and JVMCI (hosted). I looked on use cases for these 4 methods and it seems it will be hard to only use one. Okay. Leave them as it is. May be add comments to explain why you needs these variants. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From phh at openjdk.java.net Fri Jan 22 20:36:45 2021 From: phh at openjdk.java.net (Paul Hohensee) Date: Fri, 22 Jan 2021 20:36:45 GMT Subject: RFR: 8255216: Change _directive->BreakAtCompileOption to env()->break_at_compile() [v7] In-Reply-To: References: Message-ID: <2GZ1NB0hEC1YgnIwBO3Ehiy8qb0WuqVDKwntmG7-KK8=.0f0d41d2-7d07-44a4-8d0a-fbb1bf8eb82a@github.com> On Fri, 22 Jan 2021 09:39:06 GMT, Dan wrote: >> _break_at_compile was no longer in use after changes to compile.cpp. >> Change compile.cpp and c1_Compilation.cpp to use env()->break_at_compile() instead >> to make that code no longer dead. >> No new code, and Tier1 tests succeed after code is removed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 > > Dan has updated the pull request incrementally with one additional commit since the last revision: > > Update compileBroker to use BreakAtCompileOption > > BreakAtExecuteOption should not be used here, instead use > BreakAtCompileOption Marked as reviewed by phh (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1806 From github.com+7991079+danlemmond at openjdk.java.net Fri Jan 22 20:36:47 2021 From: github.com+7991079+danlemmond at openjdk.java.net (Dan) Date: Fri, 22 Jan 2021 20:36:47 GMT Subject: Integrated: 8255216: Change _directive->BreakAtCompileOption to env()->break_at_compile() In-Reply-To: References: Message-ID: <7VOeA7xc2ALgQFwdGGElezkmGngoEphhxqyJh-0DX-4=.cbb55d71-8f0e-42fe-ad60-26e7983c154b@github.com> On Wed, 16 Dec 2020 18:38:37 GMT, Dan wrote: > _break_at_compile was no longer in use after changes to compile.cpp. > Change compile.cpp and c1_Compilation.cpp to use env()->break_at_compile() instead > to make that code no longer dead. > No new code, and Tier1 tests succeed after code is removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8255216 This pull request has now been integrated. Changeset: 7be9113b Author: Dan Lemmond Committer: Paul Hohensee URL: https://git.openjdk.java.net/jdk/commit/7be9113b Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod 8255216: Change _directive->BreakAtCompileOption to env()->break_at_compile() Reviewed-by: kvn, phh ------------- PR: https://git.openjdk.java.net/jdk/pull/1806 From ecaspole at openjdk.java.net Fri Jan 22 21:35:57 2021 From: ecaspole at openjdk.java.net (Eric Caspole) Date: Fri, 22 Jan 2021 21:35:57 GMT Subject: RFR: 8260169: LogCompilation: Unexpected method mismatch Message-ID: This change checks the phase and scopes so the call stack model is preserved correctly as we process the compilation log. Tested with various JDK 8 and 17, +/-TieredCompilation, with Renaissance, jvm2008, dacapo etc logs as inputs. ------------- Commit messages: - 8260169: LogCompilation: Unexpected method mismatch from org.renaissance.neo4j.JmhNeo4jAnalytics Changes: https://git.openjdk.java.net/jdk/pull/2205/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2205&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260169 Stats: 48 lines in 2 files changed: 17 ins; 9 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/2205.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2205/head:pull/2205 PR: https://git.openjdk.java.net/jdk/pull/2205 From cjplummer at openjdk.java.net Fri Jan 22 22:27:50 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 22 Jan 2021 22:27:50 GMT Subject: RFR: 8260296: SA's dumpreplaydata fails In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 14:21:52 GMT, Roland Westrelin wrote: > I noticed that the SA's dumpreplaydata command fails with: > > java.lang.AssertionError: CLHSDB wasn't run successfully: Opening core file, please wait... > hsdb> Exception in thread "main" java.lang.InternalError: ciMetadata does not appear to be polymorphic > > with a simple test program. This happens because the SA can't find the > vtable symbol for ciMetadata (build produced by gcc 9.2.1). AFAIU, > there's nothing in our build system that hides that symbol. I had to > move one method's definition from the header file to the cpp file for > the symbol to be visible again. > > We have a test that checks dumpreplaydata but it doesn't catch that > problem. The test produces a replay file from a core file with the SA > by running a simple test with -Xcomp and CICrash=1. So the replay data > has very little or no profile data (which is what causes the problem > above). I propose running a slightly more complicated test method and > crashing after the method has had time to run for long enough to > collect profile data. > > The other shortcoming of the test is that it doesn't look at the > content of the replay file. It only warns if they differ. The replay > file produced by the VM and the one produced by the SA should be > identical (except for comment lines). So I propose we check that. > > Finally, I can't run that test on my system because core files are > handled by systemd (I'm running some recent version of fedora). I > suppose, the system can be configured differently but having the test > work out the box is nice. I extended the test case to handle that. > > With the improved test, there are a few differences between the VM and > SA replay files caused by VM changes that were not mirrored in the > SA. I fixed those. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ProfileData.java line 54: > 52: > 53: // Low-level accessors for underlying data > 54: long intptrAt(int index) { How did this ever work if it was returning an int? test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java line 179: > 177: } > 178: if (needCoreDump) { > 179: String coreFileLocation = getCoreFileLocation(crashOutputString, pid); Please see the comments I just added to JDK-8259501. This test should be using the new core file support in CoreUtils.java. I think this means you don't need any of the ProcessTools.java changes. test/hotspot/jtreg/compiler/ciReplay/SABase.java line 144: > 142: System.out.println("1: " + l1); > 143: System.out.println("2: " + l2); > 144: failure = true; Don't we want to break out of the loop at this point? test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java line 314: > 312: // file. It can take a few seconds for the system to > 313: // process the just produced core file so we may need to > 314: // retry a few times. If this is really the case, shouldn't all the SA core file tests be running into this problem? Perhaps the following in CoreUtils.java is why they don't: } else if (Platform.isLinux()) { // Check if a crash report tool is installed. File corePatternFile = new File(CORE_PATTERN_FILE_NAME); try (Scanner scanner = new Scanner(corePatternFile)) { while (scanner.hasNextLine()) { String line = scanner.nextLine(); line = line.trim(); System.out.println(line); if (line.startsWith("|")) { System.out.println( "\nThis system uses a crash report tool ($cat /proc/sys/kernel/core_pattern).\n" + "Core files might not be generated. Please reset /proc/sys/kernel/core_pattern\n" + "to enable core generation. Skipping this test."); throw new SkippedException("This system uses a crash report tool"); } } } } ------------- PR: https://git.openjdk.java.net/jdk/pull/2195 From vlivanov at openjdk.java.net Fri Jan 22 22:37:57 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 22 Jan 2021 22:37:57 GMT Subject: [jdk16] RFR: 8259276: C2: Empty expression stack when reexecuting tableswitch/lookupswitch instructions after deoptimization Message-ID: During parsing of `lookupswitch` and `tableswitch` instructions C2 may insert a safepoint. Corresponding JVM state has always re-execute bit set since the interpreter will unconditionally re-execute the instruction after deoptimization is over (see `AbstractInterpreter::bytecode_should_reexecute` for the full list of instructions). But `Parse::do_tableswitch()`/`Parse::do_lookupswitch()` attach wrong JVM state: it describes the state **after** the instruction since the first thing they do is they pop the operand from the expression stack. Instead, the JVM state **before** the instruction should be used to respect the re-execution in the interpreter. The bug manifests as a stack corruption after deoptimization at a broken safepoint. The fix is to keep the initial JVM state (before the instruction) intact until all the safepoints at the particular instruction are inserted. Testing: - [ ] hs-tier1 - hs-tier7 (in progress) - [ ] Kitchensink24h w/ -XX:+DeoptimizeALot (in progress) ------------- Commit messages: - 8259276: C2: Empty expression stack when reexecuting tableswitch/lookupswitch instructions after deoptimization Changes: https://git.openjdk.java.net/jdk16/pull/130/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=130&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259276 Stats: 20 lines in 2 files changed: 13 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk16/pull/130.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/130/head:pull/130 PR: https://git.openjdk.java.net/jdk16/pull/130 From dlong at openjdk.java.net Fri Jan 22 22:48:41 2021 From: dlong at openjdk.java.net (Dean Long) Date: Fri, 22 Jan 2021 22:48:41 GMT Subject: [jdk16] RFR: 8259276: C2: Empty expression stack when reexecuting tableswitch/lookupswitch instructions after deoptimization In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 21:59:29 GMT, Vladimir Ivanov wrote: > During parsing of `lookupswitch` and `tableswitch` instructions C2 may insert a safepoint. Corresponding JVM state has always re-execute bit set since the interpreter will unconditionally re-execute the instruction after deoptimization is over (see `AbstractInterpreter::bytecode_should_reexecute` for the full list of instructions). > > But `Parse::do_tableswitch()`/`Parse::do_lookupswitch()` attach wrong JVM state: it describes the state **after** the instruction since the first thing they do is they pop the operand from the expression stack. Instead, the JVM state **before** the instruction should be used to respect the re-execution in the interpreter. > > The bug manifests as a stack corruption after deoptimization at a broken safepoint. > > The fix is to keep the initial JVM state (before the instruction) intact until all the safepoints at the particular instruction are inserted. > > Testing: > - [ ] hs-tier1 - hs-tier7 (in progress) > - [ ] Kitchensink24h w/ -XX:+DeoptimizeALot (in progress) Marked as reviewed by dlong (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/130 From duke at openjdk.java.net Fri Jan 22 22:57:42 2021 From: duke at openjdk.java.net (duke) Date: Fri, 22 Jan 2021 22:57:42 GMT Subject: Withdrawn: 8256368: Avoid repeated upcalls into Java to re-resolve MH/VH linkers/invokers In-Reply-To: References: Message-ID: On Thu, 26 Nov 2020 13:10:02 GMT, Vladimir Ivanov wrote: > Method linkage of `invokehandle` instructions involve an upcall into Java (`MethodHandleNatives::linkMethod`), but the result is not cached. Unless the upcall behaves idempotently (which is highly desirable, but not guaranteed), repeated invokehandle resolution attempts enter a vicious cycle in tiered mode: switching to a higher tier involves call site re-resolution in generated code, but re-resolution installs a fresh method which puts execution back into interpreter. > > (Another prerequisite is no inlining through a `invokehandle` which doesn't normally happen in practice - relevant methods are marked w/ `@ForceInline` - except some testing modes, `-Xcomp` in particular.) > > Proposed fix is to inspect `ConstantPoolCache` first. Previous resolution attempts from interpreter and C1 records their results there and it stabilises the execution. > > Testing: > - failing test > - tier1-4 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1453 From github.com+61068077+lutkerd at openjdk.java.net Fri Jan 22 23:46:48 2021 From: github.com+61068077+lutkerd at openjdk.java.net (Dan Lutker) Date: Fri, 22 Jan 2021 23:46:48 GMT Subject: RFR: 8260308: Update LogCompilation junit to 4.13.1 Message-ID: Build and tested on Centos8. ------------- Commit messages: - 8260308: Update LogCompilation junit to 4.13.1 Changes: https://git.openjdk.java.net/jdk/pull/2199/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2199&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260308 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2199.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2199/head:pull/2199 PR: https://git.openjdk.java.net/jdk/pull/2199 From kvn at openjdk.java.net Fri Jan 22 23:48:41 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 23:48:41 GMT Subject: RFR: 8260169: LogCompilation: Unexpected method mismatch In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 21:31:22 GMT, Eric Caspole wrote: > This change checks the phase and scopes so the call stack model is preserved correctly as we process the compilation log. Tested with various JDK 8 and 17, +/-TieredCompilation, with Renaissance, jvm2008, dacapo etc logs as inputs. Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2205 From kvn at openjdk.java.net Fri Jan 22 23:52:48 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 23:52:48 GMT Subject: [jdk16] RFR: 8259276: C2: Empty expression stack when reexecuting tableswitch/lookupswitch instructions after deoptimization In-Reply-To: References: Message-ID: <8bOuMK_eYt27A2Kcr-NJPlVsLIcQ_YwMbuwq2HGmFnU=.06878f3e-08b9-4b10-99f4-d1df10d57e6d@github.com> On Fri, 22 Jan 2021 21:59:29 GMT, Vladimir Ivanov wrote: > During parsing of `lookupswitch` and `tableswitch` instructions C2 may insert a safepoint. Corresponding JVM state has always re-execute bit set since the interpreter will unconditionally re-execute the instruction after deoptimization is over (see `AbstractInterpreter::bytecode_should_reexecute` for the full list of instructions). > > But `Parse::do_tableswitch()`/`Parse::do_lookupswitch()` attach wrong JVM state: it describes the state **after** the instruction since the first thing they do is they pop the operand from the expression stack. Instead, the JVM state **before** the instruction should be used to respect the re-execution in the interpreter. > > The bug manifests as a stack corruption after deoptimization at a broken safepoint. > > The fix is to keep the initial JVM state (before the instruction) intact until all the safepoints at the particular instruction are inserted. > > Testing: > - [ ] hs-tier1 - hs-tier7 (in progress) > - [ ] Kitchensink24h w/ -XX:+DeoptimizeALot (in progress) Make sense. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/130 From kvn at openjdk.java.net Fri Jan 22 23:52:48 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 23:52:48 GMT Subject: [jdk16] RFR: 8259276: C2: Empty expression stack when reexecuting tableswitch/lookupswitch instructions after deoptimization In-Reply-To: <8bOuMK_eYt27A2Kcr-NJPlVsLIcQ_YwMbuwq2HGmFnU=.06878f3e-08b9-4b10-99f4-d1df10d57e6d@github.com> References: <8bOuMK_eYt27A2Kcr-NJPlVsLIcQ_YwMbuwq2HGmFnU=.06878f3e-08b9-4b10-99f4-d1df10d57e6d@github.com> Message-ID: On Fri, 22 Jan 2021 23:49:06 GMT, Vladimir Kozlov wrote: >> During parsing of `lookupswitch` and `tableswitch` instructions C2 may insert a safepoint. Corresponding JVM state has always re-execute bit set since the interpreter will unconditionally re-execute the instruction after deoptimization is over (see `AbstractInterpreter::bytecode_should_reexecute` for the full list of instructions). >> >> But `Parse::do_tableswitch()`/`Parse::do_lookupswitch()` attach wrong JVM state: it describes the state **after** the instruction since the first thing they do is they pop the operand from the expression stack. Instead, the JVM state **before** the instruction should be used to respect the re-execution in the interpreter. >> >> The bug manifests as a stack corruption after deoptimization at a broken safepoint. >> >> The fix is to keep the initial JVM state (before the instruction) intact until all the safepoints at the particular instruction are inserted. >> >> Testing: >> - [ ] hs-tier1 - hs-tier7 (in progress) >> - [ ] Kitchensink24h w/ -XX:+DeoptimizeALot (in progress) > > Make sense. Add Fix request for JDK 16 to bug report. ------------- PR: https://git.openjdk.java.net/jdk16/pull/130 From iignatyev at openjdk.java.net Sat Jan 23 00:13:40 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Sat, 23 Jan 2021 00:13:40 GMT Subject: RFR: 8260308: Update LogCompilation junit to 4.13.1 In-Reply-To: References: Message-ID: <_8bFEVclR4FHNAAkfUWy9i6rvS0J1f53rXyz-PdjenA=.385e816d-0475-493c-ab64-21dc0f2abda4@github.com> On Fri, 22 Jan 2021 18:26:09 GMT, Dan Lutker wrote: > Build and tested on Centos8. @ericcaspole, as a person who has been involved w/ LogCompilation tool recently, could you please take a look at this PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/2199 From vlivanov at openjdk.java.net Sat Jan 23 07:55:41 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Sat, 23 Jan 2021 07:55:41 GMT Subject: RFR: 8260169: LogCompilation: Unexpected method mismatch In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 21:31:22 GMT, Eric Caspole wrote: > This change checks the phase and scopes so the call stack model is preserved correctly as we process the compilation log. Tested with various JDK 8 and 17, +/-TieredCompilation, with Renaissance, jvm2008, dacapo etc logs as inputs. Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2205 From xliu at openjdk.java.net Sat Jan 23 20:36:59 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Sat, 23 Jan 2021 20:36:59 GMT Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set [v2] In-Reply-To: References: Message-ID: <2A_w7xJr6foyFMOPxTin1c5unwlG5uChpFMPdfhokmE=.ae863639-5ff1-409b-9eab-67802a521ab7@github.com> > Add a flag _suppress_cr to outputStream. outstream objects won't emit any CR if it's set. > Correct TypeInstPtr::dump2 to make sure it only emits klass name once. > Remove the comment because Klass::oop_print_on() has emitted the address of oop. > > Before: > 689 ConP === 0 [[ 821 ]] Oop:java/lang/Stringjava.lang.String > {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' > - string: "a" > :Constant:exact * > > After: > 689 ConP === 0 [[ 821 ]] Oop:java.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a":Constant:exact * Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into JDK-8260198 - 8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set Add a flag _suppress_cr to outputStream. outstream objects won't emit any CR if it's set. Correct TypeInstPtr::dump2 to make sure it only emits klass name once. Remove the comment because Klass::oop_print_on() has emitted the address of oop. Before: 689 ConP === 0 [[ 821 ]] Oop:java/lang/Stringjava.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a" :Constant:exact * After: 689 ConP === 0 [[ 821 ]] Oop:java.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a":Constant:exact * ------------- Changes: https://git.openjdk.java.net/jdk/pull/2178/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2178&range=01 Stats: 30 lines in 3 files changed: 17 ins; 4 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/2178.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2178/head:pull/2178 PR: https://git.openjdk.java.net/jdk/pull/2178 From iveresov at openjdk.java.net Sun Jan 24 03:53:00 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Sun, 24 Jan 2021 03:53:00 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v5] In-Reply-To: References: Message-ID: > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. > > Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: Address Vladimir's review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1985/files - new: https://git.openjdk.java.net/jdk/pull/1985/files/82dffbe9..74ebbcb5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=03-04 Stats: 78 lines in 20 files changed: 21 ins; 26 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/1985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1985/head:pull/1985 PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Sun Jan 24 03:56:48 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Sun, 24 Jan 2021 03:56:48 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 17:32:09 GMT, Igor Veresov wrote: >> src/hotspot/share/compiler/compileBroker.cpp line 972: >> >>> 970: >>> 971: // Initialize the compilation queue >>> 972: if (_c2_count > 0) { >> >> Is ZERO treated as `is_interpreter_only()` ? How this change works with ZERO? > > I forgot why I removed that. Let me put it back and run it through testing again. So the reason for that was an awkward possibility of ending up with 0 compilers. That was because during the argument check in ```CompilerConfig::check_args_consistency()``` We checked for ```Arguments::is_interpreter_only()``` instead of ```CompilerConfig::is_interpreter_only()```. The former doesn't check if ```TieredStopAtLevel=0``` is present. Anyways, I fixed the check and reverted this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From xliu at openjdk.java.net Sun Jan 24 19:22:53 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Sun, 24 Jan 2021 19:22:53 GMT Subject: RFR: 8260334: Remove deprecated sv_for_node_id() from Compile Message-ID: static member function sv_for_node_id() has moved to PhaseOutput. It is safe to remove the declaration from Compile. Also move the comment to PhaseOutput::sv_for_node_id(). Put both sv_for_node_id() and set_sv_for_object_node back to static. ------------- Commit messages: - 8260334: Remove deprecated sv_for_node_id() from Compile Changes: https://git.openjdk.java.net/jdk/pull/2211/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2211&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260334 Stats: 8 lines in 2 files changed: 1 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2211.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2211/head:pull/2211 PR: https://git.openjdk.java.net/jdk/pull/2211 From ysuenaga at openjdk.java.net Mon Jan 25 04:30:46 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 25 Jan 2021 04:30:46 GMT Subject: RFR: 8260338: Some fields in HaltNode is not cloned Message-ID: I got strange log as following. Contents in `CodeString` is garbled. It seems not to be initialized. [3.155s][trace][codestrings ] Created CodeString [ d??] (0x7f3804a150) `HaltNode` has two fields - `_reachable` and `_halt_reason`, but they would not be cloned at Node::clone. ------------- Commit messages: - 8260338: Some fields in HaltNode is not cloned Changes: https://git.openjdk.java.net/jdk/pull/2213/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2213&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260338 Stats: 10 lines in 3 files changed: 7 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2213.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2213/head:pull/2213 PR: https://git.openjdk.java.net/jdk/pull/2213 From xliu at openjdk.java.net Mon Jan 25 06:25:41 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Mon, 25 Jan 2021 06:25:41 GMT Subject: RFR: 8260338: Some fields in HaltNode is not cloned In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 01:53:56 GMT, Yasumasa Suenaga wrote: > I got strange log as following. Contents in `CodeString` is garbled. It seems not to be initialized. > > [3.155s][trace][codestrings ] Created CodeString [ d??] (0x7f3804a150) > > `HaltNode` has two fields - `_reachable` and `_halt_reason`, but they would not be cloned at Node::clone. src/hotspot/share/opto/node.cpp line 571: > 569: n->as_SafePoint()->clone_replaced_nodes(); > 570: } > 571: if (n->is_Halt()) { This line seems unnecessary. I see HaltNode::size() increases from 0x60 to 0x70 with your patch. Memcpy at line 502 covers it, doesn't it? ------------- PR: https://git.openjdk.java.net/jdk/pull/2213 From ysuenaga at openjdk.java.net Mon Jan 25 06:34:41 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 25 Jan 2021 06:34:41 GMT Subject: RFR: 8260338: Some fields in HaltNode is not cloned In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 06:22:49 GMT, Xin Liu wrote: >> I got strange log as following. Contents in `CodeString` is garbled. It seems not to be initialized. >> >> [3.155s][trace][codestrings ] Created CodeString [ d??] (0x7f3804a150) >> >> `HaltNode` has two fields - `_reachable` and `_halt_reason`, but they would not be cloned at Node::clone. > > src/hotspot/share/opto/node.cpp line 571: > >> 569: n->as_SafePoint()->clone_replaced_nodes(); >> 570: } >> 571: if (n->is_Halt()) { > > This line seems unnecessary. I see HaltNode::size() increases from 0x60 to 0x70 with your patch. Memcpy at line 502 covers it, doesn't it? `_reachable` and `_halt_reason` are available on `HaltNode`, not `Node`, so I think this condition is necessary. L502 uses the result of `Node::size_of()`, and I overrided it in `HaltNode`. So memory allocation at L501 and memcpy at L502 are safety. ------------- PR: https://git.openjdk.java.net/jdk/pull/2213 From xliu at openjdk.java.net Mon Jan 25 07:23:39 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Mon, 25 Jan 2021 07:23:39 GMT Subject: RFR: 8260338: Some fields in HaltNode is not cloned In-Reply-To: References: Message-ID: <9X4wuF0EXNYhEsi5Dopm33loB5xR_rOwRYTTmGvTrW8=.ef723351-49f1-424d-82b5-0ea086156d41@github.com> On Mon, 25 Jan 2021 06:32:01 GMT, Yasumasa Suenaga wrote: >> src/hotspot/share/opto/node.cpp line 571: >> >>> 569: n->as_SafePoint()->clone_replaced_nodes(); >>> 570: } >>> 571: if (n->is_Halt()) { >> >> This line seems unnecessary. I see HaltNode::size() increases from 0x60 to 0x70 with your patch. Memcpy at line 502 covers it, doesn't it? > > `_reachable` and `_halt_reason` are available on `HaltNode`, not `Node`, so I think this condition is necessary. > L502 uses the result of `Node::size_of()`, and I overrided it in `HaltNode`. So memory allocation at L501 and memcpy at L502 are safety. size_of() is a virtual function. line 500 should use HaltNode::size_of(), which give you 112(0x70) bytes, right? I mean memcpy at line 502 should cover HaltNode's member variables. `Copy::conjoint_words_to_lower((HeapWord*)this, (HeapWord*)n, s);` ------------- PR: https://git.openjdk.java.net/jdk/pull/2213 From ysuenaga at openjdk.java.net Mon Jan 25 07:49:57 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 25 Jan 2021 07:49:57 GMT Subject: RFR: 8260338: Some fields in HaltNode is not cloned [v2] In-Reply-To: References: Message-ID: <9Pyv_sa_w7g4PSGvHivJGM6C9qcPFp0bg0f3sJDjiU0=.d2b632f8-73c9-453f-9989-cf05a0426d3c@github.com> > I got strange log as following. Contents in `CodeString` is garbled. It seems not to be initialized. > > [3.155s][trace][codestrings ] Created CodeString [ d??] (0x7f3804a150) > > `HaltNode` has two fields - `_reachable` and `_halt_reason`, but they would not be cloned at Node::clone. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Revert change for node.cpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2213/files - new: https://git.openjdk.java.net/jdk/pull/2213/files/6fa9730c..88e63277 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2213&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2213&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2213.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2213/head:pull/2213 PR: https://git.openjdk.java.net/jdk/pull/2213 From ysuenaga at openjdk.java.net Mon Jan 25 07:49:57 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 25 Jan 2021 07:49:57 GMT Subject: RFR: 8260338: Some fields in HaltNode is not cloned [v2] In-Reply-To: <9X4wuF0EXNYhEsi5Dopm33loB5xR_rOwRYTTmGvTrW8=.ef723351-49f1-424d-82b5-0ea086156d41@github.com> References: <9X4wuF0EXNYhEsi5Dopm33loB5xR_rOwRYTTmGvTrW8=.ef723351-49f1-424d-82b5-0ea086156d41@github.com> Message-ID: On Mon, 25 Jan 2021 07:21:10 GMT, Xin Liu wrote: >> `_reachable` and `_halt_reason` are available on `HaltNode`, not `Node`, so I think this condition is necessary. >> L502 uses the result of `Node::size_of()`, and I overrided it in `HaltNode`. So memory allocation at L501 and memcpy at L502 are safety. > > size_of() is a virtual function. line 500 should use HaltNode::size_of(), which give you 112(0x70) bytes, right? > I mean memcpy at line 502 should cover HaltNode's member variables. > `Copy::conjoint_words_to_lower((HeapWord*)this, (HeapWord*)n, s);` Ah, you are right, thanks! I reverted the change for node.cpp. ------------- PR: https://git.openjdk.java.net/jdk/pull/2213 From thartmann at openjdk.java.net Mon Jan 25 08:04:48 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 25 Jan 2021 08:04:48 GMT Subject: [jdk16] RFR: 8259276: C2: Empty expression stack when reexecuting tableswitch/lookupswitch instructions after deoptimization In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 21:59:29 GMT, Vladimir Ivanov wrote: > During parsing of `lookupswitch` and `tableswitch` instructions C2 may insert a safepoint. Corresponding JVM state has always re-execute bit set since the interpreter will unconditionally re-execute the instruction after deoptimization is over (see `AbstractInterpreter::bytecode_should_reexecute` for the full list of instructions). > > But `Parse::do_tableswitch()`/`Parse::do_lookupswitch()` attach wrong JVM state: it describes the state **after** the instruction since the first thing they do is they pop the operand from the expression stack. Instead, the JVM state **before** the instruction should be used to respect the re-execution in the interpreter. > > The bug manifests as a stack corruption after deoptimization at a broken safepoint. > > The fix is to keep the initial JVM state (before the instruction) intact until all the safepoints at the particular instruction are inserted. > > Testing: > - [ ] hs-tier1 - hs-tier7 (in progress) > - [ ] Kitchensink24h w/ -XX:+DeoptimizeALot (in progress) Looks good. Just wondering, although this triggers with stress testing, should we still add a targeted regression test? (Can be done later, since this is for JDK 16). ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/130 From xliu at openjdk.java.net Mon Jan 25 08:16:43 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Mon, 25 Jan 2021 08:16:43 GMT Subject: RFR: 8260338: Some fields in HaltNode is not cloned [v2] In-Reply-To: <9Pyv_sa_w7g4PSGvHivJGM6C9qcPFp0bg0f3sJDjiU0=.d2b632f8-73c9-453f-9989-cf05a0426d3c@github.com> References: <9Pyv_sa_w7g4PSGvHivJGM6C9qcPFp0bg0f3sJDjiU0=.d2b632f8-73c9-453f-9989-cf05a0426d3c@github.com> Message-ID: <2oiohNeg4gn71ckqtiUEA9nMhj8TB0rIJ3KKP4Qdd3I=.abf5d278-da9e-4d8d-9d72-ca2693a1581e@github.com> On Mon, 25 Jan 2021 07:49:57 GMT, Yasumasa Suenaga wrote: >> I got strange log as following. Contents in `CodeString` is garbled. It seems not to be initialized. >> >> [3.155s][trace][codestrings ] Created CodeString [ d??] (0x7f3804a150) >> >> `HaltNode` has two fields - `_reachable` and `_halt_reason`, but they would not be cloned at Node::clone. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Revert change for node.cpp LGTM, but still need a reviewer's approval. ------------- Marked as reviewed by xliu (no project role). PR: https://git.openjdk.java.net/jdk/pull/2213 From chagedorn at openjdk.java.net Mon Jan 25 08:28:46 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 25 Jan 2021 08:28:46 GMT Subject: [jdk16] RFR: 8260284: C2: assert(_base == Int) failed: Not an Int In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 17:39:26 GMT, Vladimir Kozlov wrote: >> `PhaseIterGVN::no_dependent_zero_check()` does not handle the case when the divisor `n->in(2)` is top when a Div/Mod node is dying. As a result, we hit the assertion in `is_int()` because the type is top. >> >> The fix is straight forward to handle this case and just return false to avoid any further redundant optimization on a dead node. >> >> Thanks, >> Christian > > Good. Thanks Vladimir for your review! ------------- PR: https://git.openjdk.java.net/jdk16/pull/129 From neliasso at openjdk.java.net Mon Jan 25 08:29:41 2021 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Mon, 25 Jan 2021 08:29:41 GMT Subject: RFR: 8260338: Some fields in HaltNode is not cloned [v2] In-Reply-To: <9Pyv_sa_w7g4PSGvHivJGM6C9qcPFp0bg0f3sJDjiU0=.d2b632f8-73c9-453f-9989-cf05a0426d3c@github.com> References: <9Pyv_sa_w7g4PSGvHivJGM6C9qcPFp0bg0f3sJDjiU0=.d2b632f8-73c9-453f-9989-cf05a0426d3c@github.com> Message-ID: <8bCtGAVUZj-IyDlkaDQ-cfnLCjqLffWGIYVaQnIYfjg=.a96f68c3-a639-4f48-870c-b45b56b56cfa@github.com> On Mon, 25 Jan 2021 07:49:57 GMT, Yasumasa Suenaga wrote: >> I got strange log as following. Contents in `CodeString` is garbled. It seems not to be initialized. >> >> [3.155s][trace][codestrings ] Created CodeString [ d??] (0x7f3804a150) >> >> `HaltNode` has two fields - `_reachable` and `_halt_reason`, but they would not be cloned at Node::clone. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Revert change for node.cpp Looks good. ------------- Marked as reviewed by neliasso (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2213 From neliasso at openjdk.java.net Mon Jan 25 08:44:41 2021 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Mon, 25 Jan 2021 08:44:41 GMT Subject: RFR: 8260334: Remove deprecated sv_for_node_id() from Compile In-Reply-To: References: Message-ID: <8O6SCYeHm6deJ_zFo4cB5okecGObi2AAcjmso4gBOIc=.5ed71078-e85d-456d-b96d-382cebe0e6b8@github.com> On Sun, 24 Jan 2021 19:18:58 GMT, Xin Liu wrote: > static member function sv_for_node_id() has moved to PhaseOutput. It is safe to > remove the declaration from Compile. > Also move the comment to PhaseOutput::sv_for_node_id(). > Put both sv_for_node_id() and set_sv_for_object_node back to static. Looks good. ------------- Marked as reviewed by neliasso (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2211 From thartmann at openjdk.java.net Mon Jan 25 08:50:46 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 25 Jan 2021 08:50:46 GMT Subject: RFR: 8258894: C2: Forbid GCM to move stores into loops In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 08:32:42 GMT, Roberto Casta?eda Lozano wrote: > Prevent GCM from placing memory-writing nodes (such as stores) into loops deeper than their home loop (determined by their control input). Such placements are invalid, as they cause memory definitions to interfere, and risk causing miscompilations. This change complements [JDK-8255763](https://bugs.openjdk.java.net/browse/JDK-8255763), which only addresses invalid placements in irreducible CFGs. > > Add control input to stores in generated stubs to ensure that all memory-writing nodes have control inputs from which their home block can be derived. > > Add a battery of simplified fuzzer test cases where, before this change, GCM moves stores into deeper loops. > > Tested functionality on: > - hs-tier1-5 (windows-x64, linux-x64, linux-aarch64, and macosx-x64; release and debug mode) > - hs-tier6-9 (linux-x64, debug mode) > > Tested performance on a set of standard benchmark suites (DaCapo, Renaissance, SPECjbb2015, SPECjbb2005, SPECjvm2008, ...) and on windows-x64, linux-x64, and macosx-x64. No regression was observed, which is expected since this change only affects the placement of memory-writing nodes (which tends to be quite constrained already), and only forbids placements which would be typically detrimental for performance anyway (moving such nodes into deeper loops). Looks good to me. Just to clarify, with JDK-8255763 in place, incorrect placement in the reducible CFG case is always prevented by the frequency estimation heuristic, right? I.e. without this patch, your newly added tests wouldn't fail? Would it make sense to run the test with `StressGCM` to trigger actual failures? src/hotspot/share/opto/block.cpp line 1211: > 1209: } > 1210: > 1211: void PhaseCFG::verify_memory_writer_placement(const Block* b, const Node* n) const { You could wrap the entire method in `#ifdef ASSERT` and use `NOT_DEBUG_RETURN` in the .hpp (similar to `verify_strip_mined`). src/hotspot/share/opto/block.cpp line 1241: > 1239: } > 1240: if (n->is_memory_writer()) { > 1241: verify_memory_writer_placement(block, n); Other calls to this method are guarded by `#ifdef ASSERT`. Would it make sense to move the `n->is_memory_writer()` into the method, always call it and define it as `NOT_DEBUG_RETURN`? ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2140 From thartmann at openjdk.java.net Mon Jan 25 09:09:44 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 25 Jan 2021 09:09:44 GMT Subject: RFR: 8260338: Some fields in HaltNode is not cloned [v2] In-Reply-To: <9Pyv_sa_w7g4PSGvHivJGM6C9qcPFp0bg0f3sJDjiU0=.d2b632f8-73c9-453f-9989-cf05a0426d3c@github.com> References: <9Pyv_sa_w7g4PSGvHivJGM6C9qcPFp0bg0f3sJDjiU0=.d2b632f8-73c9-453f-9989-cf05a0426d3c@github.com> Message-ID: On Mon, 25 Jan 2021 07:49:57 GMT, Yasumasa Suenaga wrote: >> I got strange log as following. Contents in `CodeString` is garbled. It seems not to be initialized. >> >> [3.155s][trace][codestrings ] Created CodeString [ d??] (0x7f3804a150) >> >> `HaltNode` has two fields - `_reachable` and `_halt_reason`, but they would not be cloned at Node::clone. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Revert change for node.cpp Marked as reviewed by thartmann (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2213 From ysuenaga at openjdk.java.net Mon Jan 25 09:15:41 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 25 Jan 2021 09:15:41 GMT Subject: Integrated: 8260338: Some fields in HaltNode is not cloned In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 01:53:56 GMT, Yasumasa Suenaga wrote: > I got strange log as following. Contents in `CodeString` is garbled. It seems not to be initialized. > > [3.155s][trace][codestrings ] Created CodeString [ d??] (0x7f3804a150) > > `HaltNode` has two fields - `_reachable` and `_halt_reason`, but they would not be cloned at Node::clone. This pull request has now been integrated. Changeset: 09489e28 Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/09489e28 Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod 8260338: Some fields in HaltNode is not cloned Reviewed-by: xliu, neliasso, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/2213 From chagedorn at openjdk.java.net Mon Jan 25 09:16:41 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 25 Jan 2021 09:16:41 GMT Subject: RFR: 8260334: Remove deprecated sv_for_node_id() from Compile In-Reply-To: References: Message-ID: <8DHfY3Ay7wO990urV38IOnYuoLuevaZYJ2Bpt5KDbws=.f07051d9-87b2-4afa-82e8-80574da05449@github.com> On Sun, 24 Jan 2021 19:18:58 GMT, Xin Liu wrote: > static member function sv_for_node_id() has moved to PhaseOutput. It is safe to > remove the declaration from Compile. > Also move the comment to PhaseOutput::sv_for_node_id(). > Put both sv_for_node_id() and set_sv_for_object_node back to static. Looks good. ------------- Marked as reviewed by chagedorn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2211 From thartmann at openjdk.java.net Mon Jan 25 09:23:42 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 25 Jan 2021 09:23:42 GMT Subject: RFR: 8260338: Some fields in HaltNode is not cloned In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 01:53:56 GMT, Yasumasa Suenaga wrote: > I got strange log as following. Contents in `CodeString` is garbled. It seems not to be initialized. > > [3.155s][trace][codestrings ] Created CodeString [ d??] (0x7f3804a150) > > `HaltNode` has two fields - `_reachable` and `_halt_reason`, but they would not be cloned at Node::clone. @YaSuenag For future PRs, please wait for at least 24 hours before integrating a non-trivial change. A change is only considered trivial if it's explicitly stated by a reviewer in the PR (see **trivial** in [OpenJDK Developers? Guide](https://openjdk.java.net/guide/#glossary). Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2213 From thartmann at openjdk.java.net Mon Jan 25 09:26:42 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 25 Jan 2021 09:26:42 GMT Subject: RFR: 8260334: Remove deprecated sv_for_node_id() from Compile In-Reply-To: References: Message-ID: On Sun, 24 Jan 2021 19:18:58 GMT, Xin Liu wrote: > static member function sv_for_node_id() has moved to PhaseOutput. It is safe to > remove the declaration from Compile. > Also move the comment to PhaseOutput::sv_for_node_id(). > Put both sv_for_node_id() and set_sv_for_object_node back to static. Marked as reviewed by thartmann (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2211 From ysuenaga at openjdk.java.net Mon Jan 25 09:27:40 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 25 Jan 2021 09:27:40 GMT Subject: RFR: 8260338: Some fields in HaltNode is not cloned In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 01:53:56 GMT, Yasumasa Suenaga wrote: > I got strange log as following. Contents in `CodeString` is garbled. It seems not to be initialized. > > [3.155s][trace][codestrings ] Created CodeString [ d??] (0x7f3804a150) > > `HaltNode` has two fields - `_reachable` and `_halt_reason`, but they would not be cloned at Node::clone. > @YaSuenag For future PRs, please wait for at least 24 hours before integrating a non-trivial change. A change is only considered trivial if it's explicitly stated by a reviewer in the PR (see **trivial** in [OpenJDK Developers? Guide](https://openjdk.java.net/guide/#glossary). Thanks. Sorry, I got it. ------------- PR: https://git.openjdk.java.net/jdk/pull/2213 From neliasso at openjdk.java.net Mon Jan 25 09:27:41 2021 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Mon, 25 Jan 2021 09:27:41 GMT Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set In-Reply-To: References: Message-ID: <1lfc5MjMIFUx-Q19CkfKJvP4yYoM6B5APuRsvevpuk8=.3ba9c333-74b6-4ba4-bb3c-66c4583701fb@github.com> On Thu, 21 Jan 2021 08:47:13 GMT, Xin Liu wrote: > Add a flag _suppress_cr to outputStream. outstream objects won't emit any CR if it's set. > Correct TypeInstPtr::dump2 to make sure it only emits klass name once. > Remove the comment because Klass::oop_print_on() has emitted the address of oop. > > Before: > 689 ConP === 0 [[ 821 ]] Oop:java/lang/Stringjava.lang.String > {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' > - string: "a" > :Constant:exact * > > After: > 689 ConP === 0 [[ 821 ]] Oop:java.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a":Constant:exact * The result your are trying to achieve is good, but I'm not sure pushing supress_cr into outputstream is the right thing. I would like to just not emit the cr's instead - but do also I see that isn't simple, because adding an extra bool to print_on would cascade into the entire codebase. ------------- PR: https://git.openjdk.java.net/jdk/pull/2178 From roland at openjdk.java.net Mon Jan 25 09:34:03 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Mon, 25 Jan 2021 09:34:03 GMT Subject: RFR: 8260296: SA's dumpreplaydata fails [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 21:28:33 GMT, Chris Plummer wrote: >> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision: >> >> use CoreUtils > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ProfileData.java line 54: > >> 52: >> 53: // Low-level accessors for underlying data >> 54: long intptrAt(int index) { > > How did this ever work if it was returning an int? Only the least significant bits are ever looked at so it must have worked but still, seems pretty straightforward to fix. > test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java line 179: > >> 177: } >> 178: if (needCoreDump) { >> 179: String coreFileLocation = getCoreFileLocation(crashOutputString, pid); > > Please see the comments I just added to JDK-8259501. This test should be using the new core file support in CoreUtils.java. I think this means you don't need any of the ProcessTools.java changes. Thanks for the pointer. I pushed a new change that refactors the test so it takes advantage of CoreUtils. > test/hotspot/jtreg/compiler/ciReplay/SABase.java line 144: > >> 142: System.out.println("1: " + l1); >> 143: System.out.println("2: " + l2); >> 144: failure = true; > > Don't we want to break out of the loop at this point? I thought maybe going over the whole files could help diagnose a failure in case, for instance, the only difference would be 2 lines that were swapped. > test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java line 314: > >> 312: // file. It can take a few seconds for the system to >> 313: // process the just produced core file so we may need to >> 314: // retry a few times. > > If this is really the case, shouldn't all the SA core file tests be running into this problem? Perhaps the following in CoreUtils.java is why they don't: > } else if (Platform.isLinux()) { > // Check if a crash report tool is installed. > File corePatternFile = new File(CORE_PATTERN_FILE_NAME); > try (Scanner scanner = new Scanner(corePatternFile)) { > while (scanner.hasNextLine()) { > String line = scanner.nextLine(); > line = line.trim(); > System.out.println(line); > if (line.startsWith("|")) { > System.out.println( > "\nThis system uses a crash report tool ($cat /proc/sys/kernel/core_pattern).\n" + > "Core files might not be generated. Please reset /proc/sys/kernel/core_pattern\n" + > "to enable core generation. Skipping this test."); > throw new SkippedException("This system uses a crash report tool"); > } > } > } > } Right. But I still think it's easy enough and useful to support systemd. See the updated change. ------------- PR: https://git.openjdk.java.net/jdk/pull/2195 From roland at openjdk.java.net Mon Jan 25 09:34:00 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Mon, 25 Jan 2021 09:34:00 GMT Subject: RFR: 8260296: SA's dumpreplaydata fails [v2] In-Reply-To: References: Message-ID: <16SQMU3YXDN1LM9OnuT9_3kim-JBltWEoT63tQNPWgI=.c14df656-06dc-4d00-80e3-2df5acaaf58a@github.com> > I noticed that the SA's dumpreplaydata command fails with: > > java.lang.AssertionError: CLHSDB wasn't run successfully: Opening core file, please wait... > hsdb> Exception in thread "main" java.lang.InternalError: ciMetadata does not appear to be polymorphic > > with a simple test program. This happens because the SA can't find the > vtable symbol for ciMetadata (build produced by gcc 9.2.1). AFAIU, > there's nothing in our build system that hides that symbol. I had to > move one method's definition from the header file to the cpp file for > the symbol to be visible again. > > We have a test that checks dumpreplaydata but it doesn't catch that > problem. The test produces a replay file from a core file with the SA > by running a simple test with -Xcomp and CICrash=1. So the replay data > has very little or no profile data (which is what causes the problem > above). I propose running a slightly more complicated test method and > crashing after the method has had time to run for long enough to > collect profile data. > > The other shortcoming of the test is that it doesn't look at the > content of the replay file. It only warns if they differ. The replay > file produced by the VM and the one produced by the SA should be > identical (except for comment lines). So I propose we check that. > > Finally, I can't run that test on my system because core files are > handled by systemd (I'm running some recent version of fedora). I > suppose, the system can be configured differently but having the test > work out the box is nice. I extended the test case to handle that. > > With the improved test, there are a few differences between the VM and > SA replay files caused by VM changes that were not mirrored in the > SA. I fixed those. Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision: use CoreUtils ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2195/files - new: https://git.openjdk.java.net/jdk/pull/2195/files/19c3cbce..8221f04b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2195&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2195&range=00-01 Stats: 108 lines in 2 files changed: 30 ins; 73 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2195.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2195/head:pull/2195 PR: https://git.openjdk.java.net/jdk/pull/2195 From neliasso at openjdk.java.net Mon Jan 25 09:39:42 2021 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Mon, 25 Jan 2021 09:39:42 GMT Subject: RFR: JDK-8259710: Inlining trace leaks memory [v3] In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 09:22:07 GMT, Thomas Stuefe wrote: >> We see C-heap leaking, originating in C2: >> >> 1434777 [0x00007f58214af461] stringStream::stringStream(unsigned long)+0x55 >> 1434778 [0x00007f5820c6db3e] Compile::PrintInliningBuffer::PrintInliningBuffer()+0x6c >> 1434779 [0x00007f5820c724f1] GrowableArrayWithAllocator >::grow(int)+0x163 >> 1434780 [0x00007f5820c7160e] GrowableArrayWithAllocator >::insert_before(int, Compile::PrintInliningBuffer const&)+0x82 >> 1434781 [0x00007f5820c6aaf2] Compile::print_inlining_push()+0x70 >> >> accumulating over the course of days to some hundred MB at a customer site where inline tracing was active. >> >> >> Analysis: >> >> >> To build up a comprehensive inlining trace, c2 keeps trace snippets in an internal list and assembles them at print time. These are stringStream's, contained in PrintInliningBuffer: >> >> GrowableArray* _print_inlining_list; >> ... >> class PrintInliningBuffer : public ResourceObj { >> private: >> CallGenerator* _cg; >> stringStream* _ss; >> >> public: >> PrintInliningBuffer() >> : _cg(NULL) { >> _ss = new stringStream(); >> } >> >> void freeStream() { >> _ss->~stringStream(); _ss = NULL; } >> ... >> }; >> >> With [JDK-8224193](https://bugs.openjdk.java.net/browse/JDK-8224193), stringStream was changed to use C-heap instead of ResourceArea for its internal buffer. This means one cannot just omit stringStream destruction anymore - even where stringStream objects themselves live in RA, their internal buffers don't, they live in C-Heap. To clean up properly, ~stringStream() must be called. >> >> Those `PrintInliningBuffer` objects are kept _by value_ in a GrowableArray `Compile::_print_inlining_list`. Normally, if an object is kept by value, it needs to implement correct copy- and destruction-semantics. PrintInliningBuffer does not do that and instead relies on manual cleanup (`PrintInliningBuffer::freeStream()`) - I assume the authors did not want to deal with reference counting the contained stringStream on copying. >> >> That however is a problem because GrowableArray creates internally temporary objects of the item type to pre-populate its array - its whole capacity - when it grows: >> >> >> template >> void GrowableArrayWithAllocator::grow(int j) { >> >> ... >> for ( ; i < this->_len; i++) ::new ((void*)&newData[i]) E(this->_data[i]); >> for ( ; i < this->_max; i++) ::new ((void*)&newData[i]) E(); <<<<<<< >> for (i = 0; i < old_max; i++) this->_data[i].~E(); >> ... >> } >> >> this it does for the whole new capacity, which means more objects get created than have been added; if the caller does not fill the GrowableArray up to its capacity, it never knows about the excess objects created. This is normally not a problem since all these objects are destructed by GrowableArray in `void GrowableArrayWithAllocator::clear_and_deallocate()`. But since PrintInliningBuffer does not implement a destructor, this has no effect. >> >> PrintInliningBuffer instead relies on manual cleanup of the stringStreams: at the end of the compile phase, it calls `PrintInliningBuffer::freeStream()` on all buffers it thinks are contained in the array: >> >> assert(_print_inlining_list != NULL, "process_print_inlining should be called only once."); >> for (int i = 0; i < _print_inlining_list->length(); i++) { >> ss.print("%s", _print_inlining_list->adr_at(i)->ss()->as_string()); >> _print_inlining_list->at(i).freeStream(); >> } >> >> but this of course leaves the excess objects untouched (objects whose index is array length >= index >= array capacity). >> >> ----------- >> >> There are several ways to fix this: >> >> 1) implement correct destructor- and copy semantics for PrintInliningBuffer. This would work but is not optimal since we would still pay for creation of unnecessary PrintInliningBuffer objects when the array is prepopulated on grow() >> >> 2) delay construction of `PrintInliningBuffer::_ss` until the stream is actually used for writing into. This would would mean we have to check the stringStream for NULL before using it. >> >> 3) Just let the PrintInliningBuffer live in C-heap instead of the RA. Its only a small shell anywhere now that the stringStream buffer lives in C-heap. Instead, let PrintInliningBuffer contain the stringStream as a member, allocate PrintInliningBuffer from C-heap, and change the list to contain pointers to PrintInliningBuffer, not the object itself. This removes all that unnecessary copying, removes creation of temporary objects, and simplifies the code. Having to free those objects is no big deal since we free the stringStream objects manually anyway. >> >> I went with (3). I also decreased the default stringStream buffer size for this scenario since when testing I found out that many trace snippets are below 128 bytes. >> >> Note that (3) is not only simpler, but also more efficient: many of the PrintInliningBuffer objects are inserted into the middle of the _print_inlining_list; GrowableArray does shift all higher items up to provide space for the new item. If those items are simple pointers instead of whole objects, less memory is moved around. >> >> Tests: >> - github actions >> - Nightlies at SAP >> - I manually tested the patch and compared the NMT output of a tracing scenario to verify that the leak went away and no other numbers changed >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Remove accidental adds Looks good. ------------- Marked as reviewed by neliasso (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2063 From chagedorn at openjdk.java.net Mon Jan 25 09:45:52 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 25 Jan 2021 09:45:52 GMT Subject: RFR: 8257498: Remove useless skeleton predicates [v5] In-Reply-To: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com> References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com> Message-ID: <0b8S2styHDRZrn44pfLVDrfic04y__ThIpGfjokpQqk=.89f76fec-adc2-4d51-9697-69be7773f832@github.com> > This enhancement removes useless skeleton predicates in the same way as we already remove normal useless predicates in `PhaseIdealLoop::eliminate_useless_predicates()`. > > Thanks, > Christian Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge master due to conflict - Revert get_skeleton_predicates again - Fix removal from global list and update get_skeleton_predicates - Add handling of Deoptimization::Reason_profile_predicate - 8257498: Remove useless skeleton predicates ------------- Changes: https://git.openjdk.java.net/jdk/pull/2075/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2075&range=04 Stats: 102 lines in 6 files changed: 67 ins; 16 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/2075.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2075/head:pull/2075 PR: https://git.openjdk.java.net/jdk/pull/2075 From thartmann at openjdk.java.net Mon Jan 25 10:09:44 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 25 Jan 2021 10:09:44 GMT Subject: RFR: 8259609: C2: optimize long range checks in long counted loops [v3] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 07:44:12 GMT, Roland Westrelin wrote: >> JDK-8255150 makes it possible for java code to explicitly perform a >> range check on long values. JDK-8223051 provides a transformation of >> long counted loops into loop nests with an inner int counted >> loop. With this change I propose transforming long range checks that >> operate on the iv of a long counted loop into range checks that >> operate on the iv of the int inner loop once it has been >> created. Existing range check eliminations can then kick in. >> >> Transformation of range checks is piggy backed on the loop nest >> creation for 2 reasons: >> >> - pattern matching range checks is easier right before the loop nest >> is created >> >> - the number of iterations of the inner loop is adjusted so scale * >> inner_iv doesn't overflow >> >> C2 has logic to delay some split if transformations so they don't >> break the scale * iv + offset pattern. I reused that logic for long >> range checks and had to relax what's considered a range check because >> initially a range check from Object.checkIndex() may include a test >> for range > 0 that needs a round of loop opts to be hoisted. I realize >> there's some code duplication but I didn't see a way to share logic >> between IdealLoopTree::may_have_range_check() >> IdealLoopTree::policy_range_check() that would feel right. >> >> I realize the comment in PhaseIdealLoop::transform_long_range_checks() >> is scary. FWIW, it's not as complicated as it looks. I found drawing >> the range covered by the entire long loop and the range covered by the >> inner loop help see how range checks can be transformed. Then the >> comment helps make sure all cases are covered and verify the generated >> code actually covers all of them. >> >> One issue is overflow. I think the fact that inner_iv * scale doesn't >> overflow helps simplify thing. One possible overflow is that of scale >> * upper + offset which is handled by forcing all range checks in that >> case to deoptimize. I don't think other case of overflow needs special >> handling. >> >> This was tested with a Memory Segment micro benchmark (and patched >> Memory Segment support to take advantage of the new checkIndex >> intrinsic, both provided by Maurizio). Range checks in the micro >> benchmark are properly optimized (and performance increases >> significantly). > > Roland Westrelin has updated the pull request incrementally with two additional commits since the last revision: > > - min_jint overflow fix > - Revert "assert(static_cast(result) == thing) fix" > > This reverts commit e234477df097475d503ea6f94ab6a258132d165e. I did a first pass over the changes and added some comments but I need more time to review. src/hotspot/share/opto/loopPredicate.cpp line 611: > 609: bool IdealLoopTree::is_range_check_if(IfNode *iff, PhaseIdealLoop *phase, BasicType bt, Node *iv, Node *&range, > 610: Node *&offset, > 611: jlong &scale) const { Newline should be removed. src/hotspot/share/opto/loopPredicate.cpp line 665: > 663: } > 664: return false; > 665: } Code is hard to read because the indentation of above lines is broken. Some `*` could also be moved to the type. src/hotspot/share/opto/loopTransform.cpp line 2584: > 2582: if (p_offset != NULL) { > 2583: if (*p_scale == min_signed_integer(bt)) { > 2584: return false; I find it suspicious that this edge case needs to be handled here. Could you explain why and add a corresponding comment? src/hotspot/share/opto/loopnode.cpp line 4192: > 4190: // on just their loop-phi's for this pass of loop opts > 4191: if (SplitIfBlocks && do_split_ifs) { > 4192: if (lpt->may_have_range_check(this)) { Can be merged with above if. src/hotspot/share/opto/loopnode.cpp line 1216: > 1214: if (loop->is_range_check_if(rc, this, T_LONG, phi, range, offset, scale) && > 1215: loop->is_invariant(range) && loop->is_invariant(offset)) { > 1216: if (iters_limit_as_long / ABS(scale * stride_con) > min_iters/* && UseNewCode*/) { `UseNewCode` should be removed and if should be merged with if above. ------------- PR: https://git.openjdk.java.net/jdk/pull/2045 From thartmann at openjdk.java.net Mon Jan 25 10:19:44 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 25 Jan 2021 10:19:44 GMT Subject: RFR: 8257498: Remove useless skeleton predicates [v5] In-Reply-To: <0b8S2styHDRZrn44pfLVDrfic04y__ThIpGfjokpQqk=.89f76fec-adc2-4d51-9697-69be7773f832@github.com> References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com> <0b8S2styHDRZrn44pfLVDrfic04y__ThIpGfjokpQqk=.89f76fec-adc2-4d51-9697-69be7773f832@github.com> Message-ID: On Mon, 25 Jan 2021 09:45:52 GMT, Christian Hagedorn wrote: >> This enhancement removes useless skeleton predicates in the same way as we already remove normal useless predicates in `PhaseIdealLoop::eliminate_useless_predicates()`. >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge master due to conflict > - Revert get_skeleton_predicates again > - Fix removal from global list and update get_skeleton_predicates > - Add handling of Deoptimization::Reason_profile_predicate > - 8257498: Remove useless skeleton predicates Looks good to me. src/hotspot/share/opto/loopnode.cpp line 3597: > 3595: > 3596: for (int i = C->skeleton_predicate_count(); i > 0; i--) { > 3597: const int idx = i - 1; Could be removed for consistency with above code. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2075 From chagedorn at openjdk.java.net Mon Jan 25 10:41:45 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 25 Jan 2021 10:41:45 GMT Subject: RFR: 8257498: Remove useless skeleton predicates [v5] In-Reply-To: References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com> <0b8S2styHDRZrn44pfLVDrfic04y__ThIpGfjokpQqk=.89f76fec-adc2-4d51-9697-69be7773f832@github.com> Message-ID: On Mon, 25 Jan 2021 10:13:27 GMT, Tobias Hartmann wrote: >> Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - Merge master due to conflict >> - Revert get_skeleton_predicates again >> - Fix removal from global list and update get_skeleton_predicates >> - Add handling of Deoptimization::Reason_profile_predicate >> - 8257498: Remove useless skeleton predicates > > src/hotspot/share/opto/loopnode.cpp line 3597: > >> 3595: >> 3596: for (int i = C->skeleton_predicate_count(); i > 0; i--) { >> 3597: const int idx = i - 1; > > Could be removed for consistency with above code. Yes, that was a left over from a previous commit where we needed `idx` twice. I update that. ------------- PR: https://git.openjdk.java.net/jdk/pull/2075 From chagedorn at openjdk.java.net Mon Jan 25 10:44:59 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 25 Jan 2021 10:44:59 GMT Subject: RFR: 8257498: Remove useless skeleton predicates [v6] In-Reply-To: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com> References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com> Message-ID: > This enhancement removes useless skeleton predicates in the same way as we already remove normal useless predicates in `PhaseIdealLoop::eliminate_useless_predicates()`. > > Thanks, > Christian Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: Fix consistency ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2075/files - new: https://git.openjdk.java.net/jdk/pull/2075/files/9109b289..0e262807 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2075&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2075&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2075.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2075/head:pull/2075 PR: https://git.openjdk.java.net/jdk/pull/2075 From stuefe at openjdk.java.net Mon Jan 25 10:53:40 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 25 Jan 2021 10:53:40 GMT Subject: RFR: JDK-8259710: Inlining trace leaks memory [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 10:48:48 GMT, Thomas Stuefe wrote: >> Looks good. > >> Looks good. > > Thank you Nils! GA errors seem unrelated, and this patch runs in our SAP internal tests since a week without problems. ------------- PR: https://git.openjdk.java.net/jdk/pull/2063 From stuefe at openjdk.java.net Mon Jan 25 10:53:39 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 25 Jan 2021 10:53:39 GMT Subject: RFR: JDK-8259710: Inlining trace leaks memory [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 09:36:36 GMT, Nils Eliasson wrote: > Looks good. Thank you Nils! ------------- PR: https://git.openjdk.java.net/jdk/pull/2063 From stuefe at openjdk.java.net Mon Jan 25 10:53:41 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 25 Jan 2021 10:53:41 GMT Subject: Integrated: JDK-8259710: Inlining trace leaks memory In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 14:51:44 GMT, Thomas Stuefe wrote: > We see C-heap leaking, originating in C2: > > 1434777 [0x00007f58214af461] stringStream::stringStream(unsigned long)+0x55 > 1434778 [0x00007f5820c6db3e] Compile::PrintInliningBuffer::PrintInliningBuffer()+0x6c > 1434779 [0x00007f5820c724f1] GrowableArrayWithAllocator >::grow(int)+0x163 > 1434780 [0x00007f5820c7160e] GrowableArrayWithAllocator >::insert_before(int, Compile::PrintInliningBuffer const&)+0x82 > 1434781 [0x00007f5820c6aaf2] Compile::print_inlining_push()+0x70 > > accumulating over the course of days to some hundred MB at a customer site where inline tracing was active. > > > Analysis: > > > To build up a comprehensive inlining trace, c2 keeps trace snippets in an internal list and assembles them at print time. These are stringStream's, contained in PrintInliningBuffer: > > GrowableArray* _print_inlining_list; > ... > class PrintInliningBuffer : public ResourceObj { > private: > CallGenerator* _cg; > stringStream* _ss; > > public: > PrintInliningBuffer() > : _cg(NULL) { > _ss = new stringStream(); > } > > void freeStream() { > _ss->~stringStream(); _ss = NULL; } > ... > }; > > With [JDK-8224193](https://bugs.openjdk.java.net/browse/JDK-8224193), stringStream was changed to use C-heap instead of ResourceArea for its internal buffer. This means one cannot just omit stringStream destruction anymore - even where stringStream objects themselves live in RA, their internal buffers don't, they live in C-Heap. To clean up properly, ~stringStream() must be called. > > Those `PrintInliningBuffer` objects are kept _by value_ in a GrowableArray `Compile::_print_inlining_list`. Normally, if an object is kept by value, it needs to implement correct copy- and destruction-semantics. PrintInliningBuffer does not do that and instead relies on manual cleanup (`PrintInliningBuffer::freeStream()`) - I assume the authors did not want to deal with reference counting the contained stringStream on copying. > > That however is a problem because GrowableArray creates internally temporary objects of the item type to pre-populate its array - its whole capacity - when it grows: > > > template > void GrowableArrayWithAllocator::grow(int j) { > > ... > for ( ; i < this->_len; i++) ::new ((void*)&newData[i]) E(this->_data[i]); > for ( ; i < this->_max; i++) ::new ((void*)&newData[i]) E(); <<<<<<< > for (i = 0; i < old_max; i++) this->_data[i].~E(); > ... > } > > this it does for the whole new capacity, which means more objects get created than have been added; if the caller does not fill the GrowableArray up to its capacity, it never knows about the excess objects created. This is normally not a problem since all these objects are destructed by GrowableArray in `void GrowableArrayWithAllocator::clear_and_deallocate()`. But since PrintInliningBuffer does not implement a destructor, this has no effect. > > PrintInliningBuffer instead relies on manual cleanup of the stringStreams: at the end of the compile phase, it calls `PrintInliningBuffer::freeStream()` on all buffers it thinks are contained in the array: > > assert(_print_inlining_list != NULL, "process_print_inlining should be called only once."); > for (int i = 0; i < _print_inlining_list->length(); i++) { > ss.print("%s", _print_inlining_list->adr_at(i)->ss()->as_string()); > _print_inlining_list->at(i).freeStream(); > } > > but this of course leaves the excess objects untouched (objects whose index is array length >= index >= array capacity). > > ----------- > > There are several ways to fix this: > > 1) implement correct destructor- and copy semantics for PrintInliningBuffer. This would work but is not optimal since we would still pay for creation of unnecessary PrintInliningBuffer objects when the array is prepopulated on grow() > > 2) delay construction of `PrintInliningBuffer::_ss` until the stream is actually used for writing into. This would would mean we have to check the stringStream for NULL before using it. > > 3) Just let the PrintInliningBuffer live in C-heap instead of the RA. Its only a small shell anywhere now that the stringStream buffer lives in C-heap. Instead, let PrintInliningBuffer contain the stringStream as a member, allocate PrintInliningBuffer from C-heap, and change the list to contain pointers to PrintInliningBuffer, not the object itself. This removes all that unnecessary copying, removes creation of temporary objects, and simplifies the code. Having to free those objects is no big deal since we free the stringStream objects manually anyway. > > I went with (3). I also decreased the default stringStream buffer size for this scenario since when testing I found out that many trace snippets are below 128 bytes. > > Note that (3) is not only simpler, but also more efficient: many of the PrintInliningBuffer objects are inserted into the middle of the _print_inlining_list; GrowableArray does shift all higher items up to provide space for the new item. If those items are simple pointers instead of whole objects, less memory is moved around. > > Tests: > - github actions > - Nightlies at SAP > - I manually tested the patch and compared the NMT output of a tracing scenario to verify that the leak went away and no other numbers changed > > Thanks, Thomas This pull request has now been integrated. Changeset: ca20c63c Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/ca20c63c Stats: 32 lines in 2 files changed: 3 ins; 7 del; 22 mod 8259710: Inlining trace leaks memory Reviewed-by: thartmann, neliasso ------------- PR: https://git.openjdk.java.net/jdk/pull/2063 From thartmann at openjdk.java.net Mon Jan 25 10:57:42 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 25 Jan 2021 10:57:42 GMT Subject: RFR: 8257498: Remove useless skeleton predicates [v6] In-Reply-To: References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com> Message-ID: <57hgBgvjq3HuXyIpCDtmE_9JA_DkELqDdSFanVddk1k=.1a330884-cc32-4826-8905-ffdba9c60357@github.com> On Mon, 25 Jan 2021 10:44:59 GMT, Christian Hagedorn wrote: >> This enhancement removes useless skeleton predicates in the same way as we already remove normal useless predicates in `PhaseIdealLoop::eliminate_useless_predicates()`. >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > Fix consistency Marked as reviewed by thartmann (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2075 From vlivanov at openjdk.java.net Mon Jan 25 12:36:47 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 25 Jan 2021 12:36:47 GMT Subject: [jdk16] RFR: 8259276: C2: Empty expression stack when reexecuting tableswitch/lookupswitch instructions after deoptimization In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 08:02:08 GMT, Tobias Hartmann wrote: >> During parsing of `lookupswitch` and `tableswitch` instructions C2 may insert a safepoint. Corresponding JVM state has always re-execute bit set since the interpreter will unconditionally re-execute the instruction after deoptimization is over (see `AbstractInterpreter::bytecode_should_reexecute` for the full list of instructions). >> >> But `Parse::do_tableswitch()`/`Parse::do_lookupswitch()` attach wrong JVM state: it describes the state **after** the instruction since the first thing they do is they pop the operand from the expression stack. Instead, the JVM state **before** the instruction should be used to respect the re-execution in the interpreter. >> >> The bug manifests as a stack corruption after deoptimization at a broken safepoint. >> >> The fix is to keep the initial JVM state (before the instruction) intact until all the safepoints at the particular instruction are inserted. >> >> Testing: >> - [ ] hs-tier1 - hs-tier7 (in progress) >> - [ ] Kitchensink24h w/ -XX:+DeoptimizeALot (in progress) > > Looks good. Just wondering, although this triggers with stress testing, should we still add a targeted regression test? (Can be done later, since this is for JDK 16). Thanks for the reviews, Dean, Vladimir, and Tobias. > Just wondering, although this triggers with stress testing, should we still add a targeted regression test? (Can be done later, since this is for JDK 16). The fix introduces an assert which reliably fires during compilation with the problematic test case (Kitchensink). So, I see less value in a dedicated regression test now. ------------- PR: https://git.openjdk.java.net/jdk16/pull/130 From thartmann at openjdk.java.net Mon Jan 25 12:46:46 2021 Fr