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: <sjvHWEWASnEXv6th9DjCHGzLg8Rlr3hiwydFWEYbtV8=.9413d05f-984c-4753-b07c-69dba6bf53d3@github.com>
References: <ShTKOh2l-Hkq_fObzAILQQXT7kmwM_jYcSSom8u7uMM=.36ddac31-f424-4ae2-a00a-391848e0cf80@github.com>
 <zEcar-4s9pTmzjsuVhxwUIG2N0iLXBjvg6qFjrJ6sPs=.641afbce-e296-459a-957f-e300eb4179c7@github.com>
 <L7hCqrW5I2EAwpN0e-4fpTDCQW3nR-No_fbewR65BwY=.9b345f28-c65d-4a52-9768-04360c67daae@github.com>
 <l3aUmKUjq0JkLrldGPQGYYn47lThTBOLifn8Jq7P2LM=.39507f59-931c-4b7f-8b68-1dcd940ab61e@github.com>
 <DsUJHhHqA0b0AidE2tH798dGouiZ9VSLwCwxqAIisLk=.070208fe-9ff6-4efd-ab10-624999ccfca3@github.com>
 <sjvHWEWASnEXv6th9DjCHGzLg8Rlr3hiwydFWEYbtV8=.9413d05f-984c-4753-b07c-69dba6bf53d3@github.com>
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 <glaubitz at openjdk.org> 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 /<<PKGBUILDDIR>>/src/hotspot/share/ci/ciEnv.hpp:35,
>>                   from /<<PKGBUILDDIR>>/src/hotspot/share/ci/compilerInterface.hpp:32,
>>                   from /<<PKGBUILDDIR>>/src/hotspot/share/compiler/abstractCompiler.hpp:28,
>>                   from /<<PKGBUILDDIR>>/src/hotspot/share/compiler/abstractCompiler.cpp:25:
>> /<<PKGBUILDDIR>>/src/hotspot/share/oops/methodData.hpp: In constructor 'MethodData::CompilerCounters::CompilerCounters()':
>> /<<PKGBUILDDIR>>/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: /<<PKGBUILDDIR>>/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: <a9Y6VAl7PQHz-7sXdEXLo83i2KRyi7Ci5N5bYbw5k9c=.503d9695-9f81-4fff-834e-1bf45d650ce8@github.com>
References: <a9Y6VAl7PQHz-7sXdEXLo83i2KRyi7Ci5N5bYbw5k9c=.503d9695-9f81-4fff-834e-1bf45d650ce8@github.com>
Message-ID: <-2gv_7tJ4ThNurozFAS2Bzl80wa9Nod2FZ8YqCrd3aE=.9785f6ef-0afb-4cd1-811a-aede40593c33@github.com>

On Mon, 5 Oct 2020 17:36:14 GMT, Boris Ulasevich <bulasevich at openjdk.org> 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: <rhvFRRIHoJStEfM5h3B7zpXzq43bE85wFQ5xHmZRepk=.330e5488-bdd3-4dc8-bb42-b3c7d6cd3f76@github.com>

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: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
Message-ID: <8bFPyc33jjtDCZ3teQf14B6SmFJ1ifdD3DGp2ClHIk4=.4b861d50-8333-4fe9-b9d7-d28599e91831@github.com>

On Mon, 21 Dec 2020 10:10:10 GMT, Eric Liu <github.com+10482586+theRealELiu at openjdk.org> 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: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@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 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: <HTSsbn1ykK8RuSUMdLDsDQjv9MQuKDcYUh6Q5ucp3Jc=.cd7c4f9d-c308-47e6-9665-78e552a65b31@github.com>
References: <HTSsbn1ykK8RuSUMdLDsDQjv9MQuKDcYUh6Q5ucp3Jc=.cd7c4f9d-c308-47e6-9665-78e552a65b31@github.com>
Message-ID: <9U4p3sYZ6bnuC-TzEGJLxRGYr0vq0wZzGhvLMupBM4Y=.238b6093-5f52-4f47-80f7-66df63ea01c7@github.com>

On Mon, 28 Dec 2020 10:34:30 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> 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 <xliu at openjdk.org> 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: <gcMhMfG5e4cO_JZzEt0cBDpVNMVxPB0X_MzvrOyMc1g=.ede576f1-b585-47af-b7b8-0c1913b9f926@github.com>
References: <gcMhMfG5e4cO_JZzEt0cBDpVNMVxPB0X_MzvrOyMc1g=.ede576f1-b585-47af-b7b8-0c1913b9f926@github.com>
Message-ID: <p8uDLcxvMdA9-JOyZDYnXwTrCPy95MRelkVnV31wm5Q=.a391f529-7ac2-4ab6-b7db-8f9dad4efa6c@github.com>

On Wed, 23 Dec 2020 10:16:29 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> 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: <ojysz8M2KPCx2XNYs2yQYuGIjsuTT8JEJpDQ-BKHluM=.c103c2cd-ffd1-4e55-88d4-a38efa4f5681@github.com>
References: <ojysz8M2KPCx2XNYs2yQYuGIjsuTT8JEJpDQ-BKHluM=.c103c2cd-ffd1-4e55-88d4-a38efa4f5681@github.com>
Message-ID: <d4j4fV3BXSdZL5XyPten-hzsUpTxO6LrsYQpKfsSfbw=.16f97e4a-bcb6-4156-99bc-f602642485bc@github.com>

On Thu, 17 Dec 2020 17:58:12 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <BoDgNONUKJT3nwp_ypzBp_1RstoWYHWkfRuLSP8KLVk=.85a38c36-abcb-4739-ac62-6fa82bd48949@github.com>

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: <gcMhMfG5e4cO_JZzEt0cBDpVNMVxPB0X_MzvrOyMc1g=.ede576f1-b585-47af-b7b8-0c1913b9f926@github.com>
References: <gcMhMfG5e4cO_JZzEt0cBDpVNMVxPB0X_MzvrOyMc1g=.ede576f1-b585-47af-b7b8-0c1913b9f926@github.com>
Message-ID: <SQmyZJx53kywYdWcD58E4JYehtikboqmawjq4uPSZLY=.cef3749b-4683-4686-b5a7-b02f35613ced@github.com>

On Wed, 23 Dec 2020 10:16:29 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> 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: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
References: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
Message-ID: <K4wz-L4iULuT72-gALhlAwbYYUX4Oay9Ykru239Q9TY=.056362ec-327d-4aa8-a83a-587d4cdd074c@github.com>

On Fri, 25 Dec 2020 10:11:13 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> 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: <rQ3_-n8HVRC1IHRsiAkgJqv-S5S0gCPJbfqNEYFBxwY=.fdf8cab8-1bb0-4af3-84bc-95646c2aa7d0@github.com>

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: <yf1JZk8wdFE5JWvk4TyYeoYm2hE4ffkYOWloDXbgfzU=.ed6e74ae-2aab-4c6d-865b-2ca0c13a39f7@github.com>
References: <yf1JZk8wdFE5JWvk4TyYeoYm2hE4ffkYOWloDXbgfzU=.ed6e74ae-2aab-4c6d-865b-2ca0c13a39f7@github.com>
Message-ID: <mwa4Q5BfQHJoZCK5-UA4mT3x9HgQ-ndOV_I1C0DSrpY=.42e4bac0-9366-4fde-99ad-2381e634210b@github.com>

On Thu, 31 Dec 2020 01:47:00 GMT, Wang Huang <whuang at openjdk.org> 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: <yf1JZk8wdFE5JWvk4TyYeoYm2hE4ffkYOWloDXbgfzU=.ed6e74ae-2aab-4c6d-865b-2ca0c13a39f7@github.com>
References: <yf1JZk8wdFE5JWvk4TyYeoYm2hE4ffkYOWloDXbgfzU=.ed6e74ae-2aab-4c6d-865b-2ca0c13a39f7@github.com>
Message-ID: <y5pwPjoFzaLy_OJX9nJ5muVQLx-1IbJiKCNxZOmi3dc=.28f0ac2d-f9ac-4f0b-ad7a-37c6029f8cc7@github.com>

On Thu, 31 Dec 2020 01:47:00 GMT, Wang Huang <whuang at openjdk.org> 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: <K4wz-L4iULuT72-gALhlAwbYYUX4Oay9Ykru239Q9TY=.056362ec-327d-4aa8-a83a-587d4cdd074c@github.com>
References: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
 <K4wz-L4iULuT72-gALhlAwbYYUX4Oay9Ykru239Q9TY=.056362ec-327d-4aa8-a83a-587d4cdd074c@github.com>
Message-ID: <wx3yNSHrbln6iPSKKVCeH8Emsv0vy4dxusZTD-eLC6Y=.7b54cf4c-8ec0-425a-ba21-df447831d713@github.com>

On Mon, 4 Jan 2021 10:09:23 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
References: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
Message-ID: <i-sdRtuMdeuiz1T1RtQcitMdMApnTe2wlvRvk6X6GsQ=.0de47315-fc14-4702-9ca5-fb180ec68c53@github.com>

On Fri, 25 Dec 2020 10:11:13 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> 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: <SZXS4B0nNyyP9mUOR25D7epwECGDbym0wOsBuXhNJBU=.833f38cd-4283-4df8-98b9-42e68f6fdb93@github.com>
References: <SZXS4B0nNyyP9mUOR25D7epwECGDbym0wOsBuXhNJBU=.833f38cd-4283-4df8-98b9-42e68f6fdb93@github.com>
Message-ID: <waNa6tWrNyh4FJSbi6jatpIggHgJ8_ROggQi2H45ye0=.17caa1fe-1146-4f94-aca4-12fbc22bac06@github.com>

> 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: <HTSsbn1ykK8RuSUMdLDsDQjv9MQuKDcYUh6Q5ucp3Jc=.cd7c4f9d-c308-47e6-9665-78e552a65b31@github.com>
References: <HTSsbn1ykK8RuSUMdLDsDQjv9MQuKDcYUh6Q5ucp3Jc=.cd7c4f9d-c308-47e6-9665-78e552a65b31@github.com>
Message-ID: <tvVjU6KfTavQ-af008CkVnk_k8VvDJvR4UTR2wJUfhk=.4a4b645c-2ec2-4d57-b0a7-8896467dd192@github.com>

On Mon, 28 Dec 2020 10:34:30 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> 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: <N_u9dPBHWjh5P07Nh4t3Q55MLS6oXXDnxv7IojlV6yw=.06a93790-52dc-4004-bfbc-00d3ec479d37@github.com>

On Mon, 4 Jan 2021 02:03:13 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <rQ3_-n8HVRC1IHRsiAkgJqv-S5S0gCPJbfqNEYFBxwY=.fdf8cab8-1bb0-4af3-84bc-95646c2aa7d0@github.com>
References: <rQ3_-n8HVRC1IHRsiAkgJqv-S5S0gCPJbfqNEYFBxwY=.fdf8cab8-1bb0-4af3-84bc-95646c2aa7d0@github.com>
Message-ID: <hH8_mVATK7IbGR4TpV9aymda5_0BySfHOkNDDiPKfUI=.52298c77-e9cf-4f64-971f-dc4f6b66cd36@github.com>

On Mon, 4 Jan 2021 11:07:14 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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: <N45ei7kxBdtI2a5zTtp_yDZ3k4QjdumOPytzl3_S8A8=.728d07f9-281c-436e-8d6c-b1085064bb4e@github.com>

On Mon, 28 Dec 2020 09:48:29 GMT, Xin Liu <xliu at openjdk.org> 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: <meEImb7V3GI79gAerRN6C2VDiDEDUaVGi7alMm93S_0=.ac3f90d0-ca47-441c-bbbe-029662f3c938@github.com>
References: <meEImb7V3GI79gAerRN6C2VDiDEDUaVGi7alMm93S_0=.ac3f90d0-ca47-441c-bbbe-029662f3c938@github.com>
Message-ID: <3iuHaytq5uSeE0dN1A1gobUcCZ_-grilK2UkRy8HiBM=.ca462a1c-7faa-44e6-8ae9-6e64f9c42ab8@github.com>

On Wed, 23 Dec 2020 09:06:00 GMT, Jie Fu <jiefu at openjdk.org> 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: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>

_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: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
Message-ID: <xukGyWp2rA0Of-qG2pA-T_kNhBp0xrcpQDE6A7zP0ng=.e9de09fb-de1a-4d9f-8334-ff5c309e4c36@github.com>

On Wed, 16 Dec 2020 18:38:37 GMT, Dan <github.com+7991079+danlemmond at openjdk.org> 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: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
Message-ID: <WRavuju8n2_h4yQo_1Op35ZvrXuK1W05JWomonwofog=.60c6efcf-9722-440b-840b-b7869f265cdb@github.com>

On Wed, 16 Dec 2020 18:38:37 GMT, Dan <github.com+7991079+danlemmond at openjdk.org> 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: <WRavuju8n2_h4yQo_1Op35ZvrXuK1W05JWomonwofog=.60c6efcf-9722-440b-840b-b7869f265cdb@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
 <WRavuju8n2_h4yQo_1Op35ZvrXuK1W05JWomonwofog=.60c6efcf-9722-440b-840b-b7869f265cdb@github.com>
Message-ID: <m-RdaubhZ7QuTNRsS7LML9dNPBN1HpyNN6sZfYx2FHE=.4a5b35cb-e008-49d5-8c47-873792cdea58@github.com>

On Wed, 16 Dec 2020 21:06:20 GMT, Xin Liu <xliu at openjdk.org> 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: <i-sdRtuMdeuiz1T1RtQcitMdMApnTe2wlvRvk6X6GsQ=.0de47315-fc14-4702-9ca5-fb180ec68c53@github.com>
References: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
 <i-sdRtuMdeuiz1T1RtQcitMdMApnTe2wlvRvk6X6GsQ=.0de47315-fc14-4702-9ca5-fb180ec68c53@github.com>
Message-ID: <FEjepzjCKQu-XuZl5O2ZMTSpDiGrHDHDSSUehlVhy2A=.0eb65a7c-ae3a-4949-98b5-0d37a2f2620f@github.com>

On Mon, 4 Jan 2021 17:19:44 GMT, Ioi Lam <iklam at openjdk.org> 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: <meEImb7V3GI79gAerRN6C2VDiDEDUaVGi7alMm93S_0=.ac3f90d0-ca47-441c-bbbe-029662f3c938@github.com>
 <3iuHaytq5uSeE0dN1A1gobUcCZ_-grilK2UkRy8HiBM=.ca462a1c-7faa-44e6-8ae9-6e64f9c42ab8@github.com>
Message-ID: <hQkdjMWAWYB9k5T4k-FVvuCYgcMKC23UYtRhZJApYnc=.2e303f5f-8381-45b3-9faf-2061c5c5b1d6@github.com>

On Mon, 4 Jan 2021 18:55:20 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <meEImb7V3GI79gAerRN6C2VDiDEDUaVGi7alMm93S_0=.ac3f90d0-ca47-441c-bbbe-029662f3c938@github.com>
References: <meEImb7V3GI79gAerRN6C2VDiDEDUaVGi7alMm93S_0=.ac3f90d0-ca47-441c-bbbe-029662f3c938@github.com>
Message-ID: <rh9O64oNc64Z2z_5FLjggvw1YJX5sxlHbhW6QN403Qo=.e2c41d74-822b-454f-aebd-ce75401adf51@github.com>

On Wed, 23 Dec 2020 09:06:00 GMT, Jie Fu <jiefu at openjdk.org> 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 <jiefu at openjdk.org>
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: <FEjepzjCKQu-XuZl5O2ZMTSpDiGrHDHDSSUehlVhy2A=.0eb65a7c-ae3a-4949-98b5-0d37a2f2620f@github.com>
References: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
 <i-sdRtuMdeuiz1T1RtQcitMdMApnTe2wlvRvk6X6GsQ=.0de47315-fc14-4702-9ca5-fb180ec68c53@github.com>
 <FEjepzjCKQu-XuZl5O2ZMTSpDiGrHDHDSSUehlVhy2A=.0eb65a7c-ae3a-4949-98b5-0d37a2f2620f@github.com>
Message-ID: <NdVLUMkqVyLJ5_4GArsE-l1T8SmH8RlwhmMyA14z_Ew=.0acb5e9d-df51-45c4-a405-4b84e867fdb7@github.com>

On Mon, 4 Jan 2021 23:39:18 GMT, Jie Fu <jiefu at openjdk.org> 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: <SQmyZJx53kywYdWcD58E4JYehtikboqmawjq4uPSZLY=.cef3749b-4683-4686-b5a7-b02f35613ced@github.com>
References: <gcMhMfG5e4cO_JZzEt0cBDpVNMVxPB0X_MzvrOyMc1g=.ede576f1-b585-47af-b7b8-0c1913b9f926@github.com>
 <SQmyZJx53kywYdWcD58E4JYehtikboqmawjq4uPSZLY=.cef3749b-4683-4686-b5a7-b02f35613ced@github.com>
Message-ID: <C3qHTBZZ92KpQMNFrU_XZb5r0yzdVd7VJfMli5DYKvM=.c39ed1ba-ce56-49af-af70-2d7d86264e1c@github.com>

On Mon, 4 Jan 2021 09:35:59 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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: <aBE0Grc3Y0uclKhW-Sat4RtbvMJenZP2x9_7XbSOSLo=.5e76d0fb-c3ac-40b4-a31c-3a2e9ee28fa7@github.com>
References: <aBE0Grc3Y0uclKhW-Sat4RtbvMJenZP2x9_7XbSOSLo=.5e76d0fb-c3ac-40b4-a31c-3a2e9ee28fa7@github.com>
Message-ID: <H3vW8e4L5G85IcdeRbGinGek54kgc0hjQ8Wx9O_qAao=.15443b9d-92f0-4dcf-a10f-a9a9789763d8@github.com>

> 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: <BoDgNONUKJT3nwp_ypzBp_1RstoWYHWkfRuLSP8KLVk=.85a38c36-abcb-4739-ac62-6fa82bd48949@github.com>
References: <BoDgNONUKJT3nwp_ypzBp_1RstoWYHWkfRuLSP8KLVk=.85a38c36-abcb-4739-ac62-6fa82bd48949@github.com>
Message-ID: <IegZCc1H7xYjt2Swkph8bDV745uuNgBNFBUryXlB57k=.da9f9ac5-201c-4a03-9540-e108b1d35ca4@github.com>

On Mon, 4 Jan 2021 09:37:33 GMT, Wang Huang <whuang at openjdk.org> 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: <gcMhMfG5e4cO_JZzEt0cBDpVNMVxPB0X_MzvrOyMc1g=.ede576f1-b585-47af-b7b8-0c1913b9f926@github.com>
References: <gcMhMfG5e4cO_JZzEt0cBDpVNMVxPB0X_MzvrOyMc1g=.ede576f1-b585-47af-b7b8-0c1913b9f926@github.com>
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: <Xp_wGLLFFktMY7SIicwQ7zTe0psd_b4m5RzgJudBe3E=.dca99446-f282-4891-95d2-45c75d9df797@github.com>
References: <Xp_wGLLFFktMY7SIicwQ7zTe0psd_b4m5RzgJudBe3E=.dca99446-f282-4891-95d2-45c75d9df797@github.com>
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: <gguZcZty6CEXWtjqDX4jKXU3l604vGHOnVhdelMBAxE=.546421f0-60ff-486a-ad45-249ab22d3256@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.

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: <N_u9dPBHWjh5P07Nh4t3Q55MLS6oXXDnxv7IojlV6yw=.06a93790-52dc-4004-bfbc-00d3ec479d37@github.com>
References: <5sX7KaIfqVM3R1oMVcnKYjnwcq-Vm-tGUgu43Q1Rr00=.c90cc99c-65fd-47ac-9746-b63530eb1e26@github.com>
 <N_u9dPBHWjh5P07Nh4t3Q55MLS6oXXDnxv7IojlV6yw=.06a93790-52dc-4004-bfbc-00d3ec479d37@github.com>
Message-ID: <nbQMYs9eMyyZHfz2djbb9b6Oo1QQxrmn7ISXzep0Iv0=.46c343cb-5e7a-4f13-833a-3a208a03766e@github.com>

On Mon, 4 Jan 2021 18:44:00 GMT, Paul Sandoz <psandoz at openjdk.org> 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: <IegZCc1H7xYjt2Swkph8bDV745uuNgBNFBUryXlB57k=.da9f9ac5-201c-4a03-9540-e108b1d35ca4@github.com>
References: <BoDgNONUKJT3nwp_ypzBp_1RstoWYHWkfRuLSP8KLVk=.85a38c36-abcb-4739-ac62-6fa82bd48949@github.com>
 <IegZCc1H7xYjt2Swkph8bDV745uuNgBNFBUryXlB57k=.da9f9ac5-201c-4a03-9540-e108b1d35ca4@github.com>
Message-ID: <SMI2cdyISFr7B0OoDsvsbsBUW_EpAtKamZCj69FOaAk=.cdca4920-4449-4802-9a48-a5db8ec0bc1f@github.com>

On Tue, 5 Jan 2021 02:48:13 GMT, Ningsheng Jian <njian at openjdk.org> 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: <FS23y5v6Qg0rFlCTz_ejAJR5sJuL98-oVNm-L6V_plE=.99ebe4e1-e204-41a1-8037-b8fff7f674fe@github.com>

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: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
Message-ID: <Pn6Ld1CGjfGCfhBwEgXKOuX-JSpJHj4zivtEbA0Mpuc=.66ac0c27-cf02-48f6-8313-97a12e04169c@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:

  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: <gcMhMfG5e4cO_JZzEt0cBDpVNMVxPB0X_MzvrOyMc1g=.ede576f1-b585-47af-b7b8-0c1913b9f926@github.com>
 <42hRavCMVS6Mq3CVTiZ4mlI69kOGxvE4OxeEWqx6KMs=.454dc16b-f161-4f1e-bf9f-f409845afccd@github.com>
Message-ID: <PkMn7h5x_pA82tRKXTFLu4KX_LNVu5xkTMFoGW1Ws44=.e0c72439-6239-431f-924f-c78216cfe042@github.com>

On Tue, 5 Jan 2021 02:54:09 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> 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: <i-sdRtuMdeuiz1T1RtQcitMdMApnTe2wlvRvk6X6GsQ=.0de47315-fc14-4702-9ca5-fb180ec68c53@github.com>
References: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
 <i-sdRtuMdeuiz1T1RtQcitMdMApnTe2wlvRvk6X6GsQ=.0de47315-fc14-4702-9ca5-fb180ec68c53@github.com>
Message-ID: <7HjOk0EQl7wbAMcB-YPrZL_MzPxuexKLtWm9uxi6JFg=.cb37f275-30d7-4b82-8bcb-ea772202d967@github.com>

On Mon, 4 Jan 2021 17:19:48 GMT, Ioi Lam <iklam at openjdk.org> 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: <Xp_wGLLFFktMY7SIicwQ7zTe0psd_b4m5RzgJudBe3E=.dca99446-f282-4891-95d2-45c75d9df797@github.com>
References: <Xp_wGLLFFktMY7SIicwQ7zTe0psd_b4m5RzgJudBe3E=.dca99446-f282-4891-95d2-45c75d9df797@github.com>
Message-ID: <BrfyvKjpFJHcsFAhAo4IJw8T2J79OYd2s6iBg4Iael0=.ddc480bd-d900-4d68-b296-c1f682c7243d@github.com>

On Fri, 18 Dec 2020 07:11:11 GMT, Ningsheng Jian <njian at openjdk.org> 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: <HTSsbn1ykK8RuSUMdLDsDQjv9MQuKDcYUh6Q5ucp3Jc=.cd7c4f9d-c308-47e6-9665-78e552a65b31@github.com>
References: <HTSsbn1ykK8RuSUMdLDsDQjv9MQuKDcYUh6Q5ucp3Jc=.cd7c4f9d-c308-47e6-9665-78e552a65b31@github.com>
Message-ID: <eU75ZtMrZNtEq9gbwDUT4y5-QovME3s3QbDC9LPMuVI=.edbd5829-0a23-4889-bd59-90bf0ede911d@github.com>

> 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: <gguZcZty6CEXWtjqDX4jKXU3l604vGHOnVhdelMBAxE=.546421f0-60ff-486a-ad45-249ab22d3256@github.com>
References: <5sX7KaIfqVM3R1oMVcnKYjnwcq-Vm-tGUgu43Q1Rr00=.c90cc99c-65fd-47ac-9746-b63530eb1e26@github.com>
 <gguZcZty6CEXWtjqDX4jKXU3l604vGHOnVhdelMBAxE=.546421f0-60ff-486a-ad45-249ab22d3256@github.com>
Message-ID: <VyAiskI-2nCR4ubxN55qVFX09LdG3hk-kGFEfx3Fd0Q=.eada3eb8-a23c-469a-acd8-57d94db170f9@github.com>

On Tue, 5 Jan 2021 03:12:15 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <tvVjU6KfTavQ-af008CkVnk_k8VvDJvR4UTR2wJUfhk=.4a4b645c-2ec2-4d57-b0a7-8896467dd192@github.com>
References: <HTSsbn1ykK8RuSUMdLDsDQjv9MQuKDcYUh6Q5ucp3Jc=.cd7c4f9d-c308-47e6-9665-78e552a65b31@github.com>
 <tvVjU6KfTavQ-af008CkVnk_k8VvDJvR4UTR2wJUfhk=.4a4b645c-2ec2-4d57-b0a7-8896467dd192@github.com>
Message-ID: <SmiYx3ntrclNmh1dvS-Xme8cNktVh0o901W3LOt7Wx4=.d3615021-f7c1-4f85-8344-6a4d8da02e7c@github.com>

On Mon, 4 Jan 2021 18:28:23 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <HTSsbn1ykK8RuSUMdLDsDQjv9MQuKDcYUh6Q5ucp3Jc=.cd7c4f9d-c308-47e6-9665-78e552a65b31@github.com>
References: <HTSsbn1ykK8RuSUMdLDsDQjv9MQuKDcYUh6Q5ucp3Jc=.cd7c4f9d-c308-47e6-9665-78e552a65b31@github.com>
Message-ID: <BSJNUdQL-8MXRbXv-y3iIE36rAFpKO7Gew14SnPFeh4=.5521c3f6-30ba-4574-b218-3d4c5dc09e4b@github.com>

On Mon, 28 Dec 2020 10:34:30 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> 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 <hao.sun at arm.com>
Committer: Ningsheng Jian <njian at openjdk.org>
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: <wzJ4eytYuXreUXEP-0jctKlJJb7fAYpf0LWoORQXQ8w=.5f0db54a-fdff-41ab-a153-ba762162336d@github.com>
References: <gcMhMfG5e4cO_JZzEt0cBDpVNMVxPB0X_MzvrOyMc1g=.ede576f1-b585-47af-b7b8-0c1913b9f926@github.com>
 <42hRavCMVS6Mq3CVTiZ4mlI69kOGxvE4OxeEWqx6KMs=.454dc16b-f161-4f1e-bf9f-f409845afccd@github.com>
 <wzJ4eytYuXreUXEP-0jctKlJJb7fAYpf0LWoORQXQ8w=.5f0db54a-fdff-41ab-a153-ba762162336d@github.com>
Message-ID: <pVM33nglKZi7AgpYbNdj9S7GOzi59wgYnpY_OW0oy1Y=.c15dfb53-8fa3-46a6-a9b8-1cf49fefa9e3@github.com>

On Tue, 5 Jan 2021 08:00:50 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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: <gcMhMfG5e4cO_JZzEt0cBDpVNMVxPB0X_MzvrOyMc1g=.ede576f1-b585-47af-b7b8-0c1913b9f926@github.com>
 <42hRavCMVS6Mq3CVTiZ4mlI69kOGxvE4OxeEWqx6KMs=.454dc16b-f161-4f1e-bf9f-f409845afccd@github.com>
Message-ID: <wzJ4eytYuXreUXEP-0jctKlJJb7fAYpf0LWoORQXQ8w=.5f0db54a-fdff-41ab-a153-ba762162336d@github.com>

On Tue, 5 Jan 2021 02:54:09 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> 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: <FS23y5v6Qg0rFlCTz_ejAJR5sJuL98-oVNm-L6V_plE=.99ebe4e1-e204-41a1-8037-b8fff7f674fe@github.com>
References: <FS23y5v6Qg0rFlCTz_ejAJR5sJuL98-oVNm-L6V_plE=.99ebe4e1-e204-41a1-8037-b8fff7f674fe@github.com>
Message-ID: <Y080NQC_SD86Mg2wHPxZUrs5zejShE7BYWXTbp2KJsc=.b3258b06-846d-4a44-ad1b-f726291e3cc3@github.com>

On Tue, 5 Jan 2021 03:32:44 GMT, Wang Huang <whuang at openjdk.org> 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: <NdVLUMkqVyLJ5_4GArsE-l1T8SmH8RlwhmMyA14z_Ew=.0acb5e9d-df51-45c4-a405-4b84e867fdb7@github.com>
References: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
 <i-sdRtuMdeuiz1T1RtQcitMdMApnTe2wlvRvk6X6GsQ=.0de47315-fc14-4702-9ca5-fb180ec68c53@github.com>
 <FEjepzjCKQu-XuZl5O2ZMTSpDiGrHDHDSSUehlVhy2A=.0eb65a7c-ae3a-4949-98b5-0d37a2f2620f@github.com>
 <NdVLUMkqVyLJ5_4GArsE-l1T8SmH8RlwhmMyA14z_Ew=.0acb5e9d-df51-45c4-a405-4b84e867fdb7@github.com>
Message-ID: <07IGEyNdiB87CZXchlzhoXiv0m36gM8yc7cehVHW2t0=.41b95205-bbba-4e6f-979b-eb07fb8dfdec@github.com>

On Tue, 5 Jan 2021 00:12:58 GMT, Ioi Lam <iklam at openjdk.org> 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: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
 <i-sdRtuMdeuiz1T1RtQcitMdMApnTe2wlvRvk6X6GsQ=.0de47315-fc14-4702-9ca5-fb180ec68c53@github.com>
 <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 <github.com+16932759+shqking at openjdk.org> 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: <pVM33nglKZi7AgpYbNdj9S7GOzi59wgYnpY_OW0oy1Y=.c15dfb53-8fa3-46a6-a9b8-1cf49fefa9e3@github.com>
References: <gcMhMfG5e4cO_JZzEt0cBDpVNMVxPB0X_MzvrOyMc1g=.ede576f1-b585-47af-b7b8-0c1913b9f926@github.com>
 <42hRavCMVS6Mq3CVTiZ4mlI69kOGxvE4OxeEWqx6KMs=.454dc16b-f161-4f1e-bf9f-f409845afccd@github.com>
 <wzJ4eytYuXreUXEP-0jctKlJJb7fAYpf0LWoORQXQ8w=.5f0db54a-fdff-41ab-a153-ba762162336d@github.com>
 <pVM33nglKZi7AgpYbNdj9S7GOzi59wgYnpY_OW0oy1Y=.c15dfb53-8fa3-46a6-a9b8-1cf49fefa9e3@github.com>
Message-ID: <lQTvfbC6zjiYuShUT5tVXrqG5iJC1aPduB3Ak5edpOY=.385fb966-1e4d-4c8c-94aa-7b9611fe827c@github.com>

On Tue, 5 Jan 2021 08:20:33 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> 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: <gcMhMfG5e4cO_JZzEt0cBDpVNMVxPB0X_MzvrOyMc1g=.ede576f1-b585-47af-b7b8-0c1913b9f926@github.com>
References: <gcMhMfG5e4cO_JZzEt0cBDpVNMVxPB0X_MzvrOyMc1g=.ede576f1-b585-47af-b7b8-0c1913b9f926@github.com>
Message-ID: <vThJS4k5TKhQSeaJCFKlFFVIifgxAmcGwaQJ9WD0NYE=.5ea9ee31-9308-4f6e-be35-d11c2216afc1@github.com>

On Wed, 23 Dec 2020 10:16:29 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> 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 <hao.sun at arm.com>
Committer: Ningsheng Jian <njian at openjdk.org>
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: <SZXS4B0nNyyP9mUOR25D7epwECGDbym0wOsBuXhNJBU=.833f38cd-4283-4df8-98b9-42e68f6fdb93@github.com>
References: <SZXS4B0nNyyP9mUOR25D7epwECGDbym0wOsBuXhNJBU=.833f38cd-4283-4df8-98b9-42e68f6fdb93@github.com>
Message-ID: <9o8BbtcVezKGIMDLxEYE1UfSjRHvgTtdlvBS3qykk4w=.bc09e436-3596-459f-8511-9298e3cf3f60@github.com>

On Tue, 8 Dec 2020 10:42:08 GMT, Aleksey Shipilev <shade at openjdk.org> 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 <shade at openjdk.org>
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: <rQ3_-n8HVRC1IHRsiAkgJqv-S5S0gCPJbfqNEYFBxwY=.fdf8cab8-1bb0-4af3-84bc-95646c2aa7d0@github.com>
References: <rQ3_-n8HVRC1IHRsiAkgJqv-S5S0gCPJbfqNEYFBxwY=.fdf8cab8-1bb0-4af3-84bc-95646c2aa7d0@github.com>
Message-ID: <yQzaMt3tJzQYwh7PkMmZIhrBc-15-VApKHuUhXdKuFc=.34462c9c-94d8-4457-b427-b7d9add87c36@github.com>

On Mon, 4 Jan 2021 11:07:14 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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: <m-RdaubhZ7QuTNRsS7LML9dNPBN1HpyNN6sZfYx2FHE=.4a5b35cb-e008-49d5-8c47-873792cdea58@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
 <WRavuju8n2_h4yQo_1Op35ZvrXuK1W05JWomonwofog=.60c6efcf-9722-440b-840b-b7869f265cdb@github.com>
 <m-RdaubhZ7QuTNRsS7LML9dNPBN1HpyNN6sZfYx2FHE=.4a5b35cb-e008-49d5-8c47-873792cdea58@github.com>
Message-ID: <GT-U-BsJB95ynInLEGrf5us7qzU33dYHNyyPD3D9F90=.d737664b-441c-460b-bc02-ea990aa4c710@github.com>

On Thu, 17 Dec 2020 18:35:53 GMT, Dan <github.com+7991079+danlemmond at openjdk.org> 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: <ojysz8M2KPCx2XNYs2yQYuGIjsuTT8JEJpDQ-BKHluM=.c103c2cd-ffd1-4e55-88d4-a38efa4f5681@github.com>
References: <ojysz8M2KPCx2XNYs2yQYuGIjsuTT8JEJpDQ-BKHluM=.c103c2cd-ffd1-4e55-88d4-a38efa4f5681@github.com>
Message-ID: <Qy7llx_zjwSZxCBr8krprDFUrQNL9F3XFDebZyfleVQ=.fa7d2cce-f725-48d3-91e8-c70ffba64114@github.com>

On Thu, 17 Dec 2020 17:58:12 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <hH8_mVATK7IbGR4TpV9aymda5_0BySfHOkNDDiPKfUI=.52298c77-e9cf-4f64-971f-dc4f6b66cd36@github.com>
References: <rQ3_-n8HVRC1IHRsiAkgJqv-S5S0gCPJbfqNEYFBxwY=.fdf8cab8-1bb0-4af3-84bc-95646c2aa7d0@github.com>
 <hH8_mVATK7IbGR4TpV9aymda5_0BySfHOkNDDiPKfUI=.52298c77-e9cf-4f64-971f-dc4f6b66cd36@github.com>
Message-ID: <h7_21w5BooW8kQHC4j3sQvmBId2JXoBMUuiCPqWvESA=.f46fcfe9-d7b4-4041-9dbd-eec667cf57c8@github.com>

On Mon, 4 Jan 2021 18:45:30 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <rQ3_-n8HVRC1IHRsiAkgJqv-S5S0gCPJbfqNEYFBxwY=.fdf8cab8-1bb0-4af3-84bc-95646c2aa7d0@github.com>
References: <rQ3_-n8HVRC1IHRsiAkgJqv-S5S0gCPJbfqNEYFBxwY=.fdf8cab8-1bb0-4af3-84bc-95646c2aa7d0@github.com>
Message-ID: <p-dF9S7vf5sgwOksoIc3UATqeunJxQOggykSDmH1Dy4=.af554d15-5b2a-4127-9d69-8cab7a5d1969@github.com>

On Mon, 4 Jan 2021 11:07:14 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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 <chagedorn at openjdk.org>
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: <f1QybMIubs3lveWEaZWRziFcCZxYCBHFawJhEkp1jV4=.450bfe4f-e71a-4e60-a79c-ff8d101356f8@github.com>

> 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: <UrlX6TZ-eDrZiVlXvOzLFc12Jg1ZlDA7T4o71kupqng=.ac1a67ff-5808-4653-ab60-633c21d74a2e@github.com>

On Mon, 4 Jan 2021 07:19:55 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <N45ei7kxBdtI2a5zTtp_yDZ3k4QjdumOPytzl3_S8A8=.728d07f9-281c-436e-8d6c-b1085064bb4e@github.com>
References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com>
 <N45ei7kxBdtI2a5zTtp_yDZ3k4QjdumOPytzl3_S8A8=.728d07f9-281c-436e-8d6c-b1085064bb4e@github.com>
Message-ID: <FfC99x9gI_lCNSsSdpqPEquMMxmenp4R8L6pS1pCAD0=.8f07a714-1aa6-4b25-bdfa-7ade75ad5ab5@github.com>

On Mon, 4 Jan 2021 18:39:17 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <BrfyvKjpFJHcsFAhAo4IJw8T2J79OYd2s6iBg4Iael0=.ddc480bd-d900-4d68-b296-c1f682c7243d@github.com>
References: <Xp_wGLLFFktMY7SIicwQ7zTe0psd_b4m5RzgJudBe3E=.dca99446-f282-4891-95d2-45c75d9df797@github.com>
 <BrfyvKjpFJHcsFAhAo4IJw8T2J79OYd2s6iBg4Iael0=.ddc480bd-d900-4d68-b296-c1f682c7243d@github.com>
Message-ID: <OxdGHt8pjnzSJieAOqLCal5x5h1OT1ClS6mEqJcwvMg=.496701d6-c05f-4c91-b9c2-804b53bcce6e@github.com>

On Tue, 5 Jan 2021 05:44:36 GMT, Ningsheng Jian <njian at openjdk.org> 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: <Xp_wGLLFFktMY7SIicwQ7zTe0psd_b4m5RzgJudBe3E=.dca99446-f282-4891-95d2-45c75d9df797@github.com>
 <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 <njian at openjdk.org> 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: <OxdGHt8pjnzSJieAOqLCal5x5h1OT1ClS6mEqJcwvMg=.496701d6-c05f-4c91-b9c2-804b53bcce6e@github.com>
References: <Xp_wGLLFFktMY7SIicwQ7zTe0psd_b4m5RzgJudBe3E=.dca99446-f282-4891-95d2-45c75d9df797@github.com>
 <BrfyvKjpFJHcsFAhAo4IJw8T2J79OYd2s6iBg4Iael0=.ddc480bd-d900-4d68-b296-c1f682c7243d@github.com>
 <OxdGHt8pjnzSJieAOqLCal5x5h1OT1ClS6mEqJcwvMg=.496701d6-c05f-4c91-b9c2-804b53bcce6e@github.com>
Message-ID: <8c_83PwGl5YuRXbdHF2x0M9UrZocHav7peSPbQzPwuQ=.e8badd95-09ca-46c4-95e3-6479cab080c8@github.com>

On Tue, 5 Jan 2021 10:41:40 GMT, Andrew Dinn <adinn at openjdk.org> 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: <Pn6Ld1CGjfGCfhBwEgXKOuX-JSpJHj4zivtEbA0Mpuc=.66ac0c27-cf02-48f6-8313-97a12e04169c@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
 <Pn6Ld1CGjfGCfhBwEgXKOuX-JSpJHj4zivtEbA0Mpuc=.66ac0c27-cf02-48f6-8313-97a12e04169c@github.com>
Message-ID: <Lvt2MVmZ094pM9uluOpK6e__FIh87KxX2C352bQ9mTI=.5ea17aaa-f6da-40f8-b16a-72f163e04862@github.com>

On Tue, 5 Jan 2021 03:43:15 GMT, Dong Bo <dongbo at openjdk.org> 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: <TCbUD0mzUmsU6P_LIikrQBEtLMXYgT5aw1sQqlBx6cg=.1c0cca6d-dea9-460e-8ef8-f42ba460d9bb@github.com>
References: <TCbUD0mzUmsU6P_LIikrQBEtLMXYgT5aw1sQqlBx6cg=.1c0cca6d-dea9-460e-8ef8-f42ba460d9bb@github.com>
Message-ID: <IW5wgd9eKQOmSxH3nWwPyYM-Bd8e9KRcjqdm87pyWLA=.cee673c7-3297-436a-be2b-eb051136cb1d@github.com>

On Thu, 17 Dec 2020 08:20:20 GMT, Roland Westrelin <roland at openjdk.org> 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: <Nqi18GZiuOtp3FBfjO-hZqhKqwi9xBCNLVdh7RQN_n4=.a9c278a6-6858-4e31-894b-7adbd4337fb0@github.com>
References: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
 <Nqi18GZiuOtp3FBfjO-hZqhKqwi9xBCNLVdh7RQN_n4=.a9c278a6-6858-4e31-894b-7adbd4337fb0@github.com>
Message-ID: <rBSHjRxw8UivRuuXt1y6R1Otfz2p-q_M-i1oKQDbPo0=.fcfd8e63-50d9-4258-abe7-1c7165b67354@github.com>

On Tue, 5 Jan 2021 12:03:39 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> 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: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
References: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
Message-ID: <Nqi18GZiuOtp3FBfjO-hZqhKqwi9xBCNLVdh7RQN_n4=.a9c278a6-6858-4e31-894b-7adbd4337fb0@github.com>

> 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: <NdVLUMkqVyLJ5_4GArsE-l1T8SmH8RlwhmMyA14z_Ew=.0acb5e9d-df51-45c4-a405-4b84e867fdb7@github.com>
References: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
 <i-sdRtuMdeuiz1T1RtQcitMdMApnTe2wlvRvk6X6GsQ=.0de47315-fc14-4702-9ca5-fb180ec68c53@github.com>
 <FEjepzjCKQu-XuZl5O2ZMTSpDiGrHDHDSSUehlVhy2A=.0eb65a7c-ae3a-4949-98b5-0d37a2f2620f@github.com>
 <NdVLUMkqVyLJ5_4GArsE-l1T8SmH8RlwhmMyA14z_Ew=.0acb5e9d-df51-45c4-a405-4b84e867fdb7@github.com>
Message-ID: <mCr4sUd9UbdRUjnTXcrbFbYh6z8sevIxYidg1kJ7UPQ=.6c0cc4c6-1e9c-4c4d-98b8-df7743696c7c@github.com>

On Tue, 5 Jan 2021 00:12:58 GMT, Ioi Lam <iklam at openjdk.org> 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: <Nqi18GZiuOtp3FBfjO-hZqhKqwi9xBCNLVdh7RQN_n4=.a9c278a6-6858-4e31-894b-7adbd4337fb0@github.com>
References: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
 <Nqi18GZiuOtp3FBfjO-hZqhKqwi9xBCNLVdh7RQN_n4=.a9c278a6-6858-4e31-894b-7adbd4337fb0@github.com>
Message-ID: <aFHrZqD6Pq-J-_ccnTVkcCa4E7HdQZuF74eKTAlWzRU=.7882a870-60a0-47f3-bc2a-3c512aa1b27b@github.com>

On Tue, 5 Jan 2021 12:06:18 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> 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: <Nqi18GZiuOtp3FBfjO-hZqhKqwi9xBCNLVdh7RQN_n4=.a9c278a6-6858-4e31-894b-7adbd4337fb0@github.com>
References: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
 <Nqi18GZiuOtp3FBfjO-hZqhKqwi9xBCNLVdh7RQN_n4=.a9c278a6-6858-4e31-894b-7adbd4337fb0@github.com>
Message-ID: <sOBNaXnaGGBofABUWG2E1SXTC-yrTFTWp78mgea5xh4=.bbec603e-aecc-4fd8-b9c1-9623a5b537b4@github.com>

On Tue, 5 Jan 2021 12:06:18 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> 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: <Nqi18GZiuOtp3FBfjO-hZqhKqwi9xBCNLVdh7RQN_n4=.a9c278a6-6858-4e31-894b-7adbd4337fb0@github.com>
References: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
 <Nqi18GZiuOtp3FBfjO-hZqhKqwi9xBCNLVdh7RQN_n4=.a9c278a6-6858-4e31-894b-7adbd4337fb0@github.com>
Message-ID: <4rHg312dxhxqEjOcUre5nFomMw6LKC_5IzXJCa6rTYM=.6f73c059-dc04-4b31-98f7-6e2b102db4bf@github.com>

On Tue, 5 Jan 2021 12:06:18 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> 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: <IW5wgd9eKQOmSxH3nWwPyYM-Bd8e9KRcjqdm87pyWLA=.cee673c7-3297-436a-be2b-eb051136cb1d@github.com>
References: <TCbUD0mzUmsU6P_LIikrQBEtLMXYgT5aw1sQqlBx6cg=.1c0cca6d-dea9-460e-8ef8-f42ba460d9bb@github.com>
 <IW5wgd9eKQOmSxH3nWwPyYM-Bd8e9KRcjqdm87pyWLA=.cee673c7-3297-436a-be2b-eb051136cb1d@github.com>
Message-ID: <eNnVg7pGEDteLYnQoCclmPP4z-OKmOfGvpId2pNco3A=.0d1787d4-1f0e-4cc9-ad35-343cc01bce7b@github.com>

On Tue, 5 Jan 2021 11:54:07 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <TCbUD0mzUmsU6P_LIikrQBEtLMXYgT5aw1sQqlBx6cg=.1c0cca6d-dea9-460e-8ef8-f42ba460d9bb@github.com>
References: <TCbUD0mzUmsU6P_LIikrQBEtLMXYgT5aw1sQqlBx6cg=.1c0cca6d-dea9-460e-8ef8-f42ba460d9bb@github.com>
Message-ID: <MxgdC3DbYxSPiznjiVcnDHfikCm1_VzaBqbmiF5CULk=.04ea88be-5f4b-4f44-a077-3cac887c837c@github.com>

> 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: <MxgdC3DbYxSPiznjiVcnDHfikCm1_VzaBqbmiF5CULk=.04ea88be-5f4b-4f44-a077-3cac887c837c@github.com>
References: <TCbUD0mzUmsU6P_LIikrQBEtLMXYgT5aw1sQqlBx6cg=.1c0cca6d-dea9-460e-8ef8-f42ba460d9bb@github.com>
 <MxgdC3DbYxSPiznjiVcnDHfikCm1_VzaBqbmiF5CULk=.04ea88be-5f4b-4f44-a077-3cac887c837c@github.com>
Message-ID: <ZGb2zxg1sT36mQfX5qKbDTlByEpEsiY0x2iGs7KBmWw=.6bb6a7b8-d436-4e88-b994-ff80f472a841@github.com>

On Tue, 5 Jan 2021 13:00:10 GMT, Roland Westrelin <roland at openjdk.org> 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: <IW5wgd9eKQOmSxH3nWwPyYM-Bd8e9KRcjqdm87pyWLA=.cee673c7-3297-436a-be2b-eb051136cb1d@github.com>
References: <TCbUD0mzUmsU6P_LIikrQBEtLMXYgT5aw1sQqlBx6cg=.1c0cca6d-dea9-460e-8ef8-f42ba460d9bb@github.com>
 <IW5wgd9eKQOmSxH3nWwPyYM-Bd8e9KRcjqdm87pyWLA=.cee673c7-3297-436a-be2b-eb051136cb1d@github.com>
Message-ID: <DqgoxVGYyZT-r47pX4xhpCBipaf2pWhRObbMGqTot6I=.9e0e6a53-7058-4bf7-bbb7-4d1039e5899a@github.com>

On Tue, 5 Jan 2021 11:57:18 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <s8lB9qb7EBLsGOl_qbM5vfAONPHWOxNlD_CoZOrHG3c=.48a0183c-5918-4700-bfa1-d751e67d225a@github.com>
References: <TCbUD0mzUmsU6P_LIikrQBEtLMXYgT5aw1sQqlBx6cg=.1c0cca6d-dea9-460e-8ef8-f42ba460d9bb@github.com>
 <s8lB9qb7EBLsGOl_qbM5vfAONPHWOxNlD_CoZOrHG3c=.48a0183c-5918-4700-bfa1-d751e67d225a@github.com>
Message-ID: <IFKBwbq5RkwBu4_EXuZSRH8bSwomVir5uXivDlZlIPU=.b98b1173-701c-470f-a7dc-03e5b2b8ba88@github.com>

On Mon, 21 Dec 2020 15:31:35 GMT, Roman Kennke <rkennke at openjdk.org> 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: <TCbUD0mzUmsU6P_LIikrQBEtLMXYgT5aw1sQqlBx6cg=.1c0cca6d-dea9-460e-8ef8-f42ba460d9bb@github.com>
References: <TCbUD0mzUmsU6P_LIikrQBEtLMXYgT5aw1sQqlBx6cg=.1c0cca6d-dea9-460e-8ef8-f42ba460d9bb@github.com>
Message-ID: <mApSf28_ItaxUkA8eHkVIh322tUPVxd50_7cJ9eChCM=.7fff5599-c2ed-464e-999b-2b43c501ecf9@github.com>

On Thu, 17 Dec 2020 08:20:20 GMT, Roland Westrelin <roland at openjdk.org> 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 <roland at openjdk.org>
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: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
Message-ID: <RNU-tanbO6-6vkeQ8yVg2mAa0yzWgCAw3kI5uO8iFow=.7ea55a0f-f60e-4c80-b390-8b990536bde4@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:

  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: <Lvt2MVmZ094pM9uluOpK6e__FIh87KxX2C352bQ9mTI=.5ea17aaa-f6da-40f8-b16a-72f163e04862@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
 <Pn6Ld1CGjfGCfhBwEgXKOuX-JSpJHj4zivtEbA0Mpuc=.66ac0c27-cf02-48f6-8313-97a12e04169c@github.com>
 <Lvt2MVmZ094pM9uluOpK6e__FIh87KxX2C352bQ9mTI=.5ea17aaa-f6da-40f8-b16a-72f163e04862@github.com>
Message-ID: <k8pYLvrT_Jf1bZIaJaixgg4f0ioPm-k3Umojm-JWluI=.5747f41b-9227-4221-b560-f3861aae9d5d@github.com>

On Tue, 5 Jan 2021 11:10:17 GMT, Andrew Haley <aph at openjdk.org> 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: <rBSHjRxw8UivRuuXt1y6R1Otfz2p-q_M-i1oKQDbPo0=.fcfd8e63-50d9-4258-abe7-1c7165b67354@github.com>
References: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
 <Nqi18GZiuOtp3FBfjO-hZqhKqwi9xBCNLVdh7RQN_n4=.a9c278a6-6858-4e31-894b-7adbd4337fb0@github.com>
 <rBSHjRxw8UivRuuXt1y6R1Otfz2p-q_M-i1oKQDbPo0=.fcfd8e63-50d9-4258-abe7-1c7165b67354@github.com>
Message-ID: <SdYGsfg324yOlh7FFxbNcLWhcwBHPXEUp4h_8bTYfe8=.d9a83589-2fbd-4841-bf05-e0d57c938d12@github.com>

On Tue, 5 Jan 2021 12:03:05 GMT, Jie Fu <jiefu at openjdk.org> 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: <u63dzrUDn4R6VGbnwvqs6ORVQLQarz8s5dUWUgHeUZA=.e1745a7b-a8b3-442d-87d2-c6aa075adaeb@github.com>

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: <VyAiskI-2nCR4ubxN55qVFX09LdG3hk-kGFEfx3Fd0Q=.eada3eb8-a23c-469a-acd8-57d94db170f9@github.com>
References: <5sX7KaIfqVM3R1oMVcnKYjnwcq-Vm-tGUgu43Q1Rr00=.c90cc99c-65fd-47ac-9746-b63530eb1e26@github.com>
 <gguZcZty6CEXWtjqDX4jKXU3l604vGHOnVhdelMBAxE=.546421f0-60ff-486a-ad45-249ab22d3256@github.com>
 <VyAiskI-2nCR4ubxN55qVFX09LdG3hk-kGFEfx3Fd0Q=.eada3eb8-a23c-469a-acd8-57d94db170f9@github.com>
Message-ID: <FyG8fc7pTkvFSu_jFgBW7LUMPSB6dlQzT60LFOvTLoM=.3cbe971c-cb9e-489f-bf7c-b333025cb867@github.com>

On Tue, 5 Jan 2021 08:18:44 GMT, Ningsheng Jian <njian at openjdk.org> 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: <u63dzrUDn4R6VGbnwvqs6ORVQLQarz8s5dUWUgHeUZA=.e1745a7b-a8b3-442d-87d2-c6aa075adaeb@github.com>
References: <u63dzrUDn4R6VGbnwvqs6ORVQLQarz8s5dUWUgHeUZA=.e1745a7b-a8b3-442d-87d2-c6aa075adaeb@github.com>
Message-ID: <VKtfGSJUpIrQDH0z9bD6NHrnM3IOelYShVMlvbZokg0=.71660fb3-bf08-496d-9563-cdefad1aa525@github.com>

On Tue, 5 Jan 2021 15:12:31 GMT, Claes Redestad <redestad at openjdk.org> 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: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
References: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
Message-ID: <zwAUscNKXIyu8Yv6W0PtS2TieU0R0uso98zKsyD23W4=.224abfce-1324-4992-84fa-dcc94022cd98@github.com>

On Fri, 25 Dec 2020 10:11:13 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> 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 <hao.sun at arm.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
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: <SdYGsfg324yOlh7FFxbNcLWhcwBHPXEUp4h_8bTYfe8=.d9a83589-2fbd-4841-bf05-e0d57c938d12@github.com>
References: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
 <Nqi18GZiuOtp3FBfjO-hZqhKqwi9xBCNLVdh7RQN_n4=.a9c278a6-6858-4e31-894b-7adbd4337fb0@github.com>
 <rBSHjRxw8UivRuuXt1y6R1Otfz2p-q_M-i1oKQDbPo0=.fcfd8e63-50d9-4258-abe7-1c7165b67354@github.com>
 <SdYGsfg324yOlh7FFxbNcLWhcwBHPXEUp4h_8bTYfe8=.d9a83589-2fbd-4841-bf05-e0d57c938d12@github.com>
Message-ID: <SXdyk7UoRVkkM8W-GMXnS4MfrJpqE6G4HUDQPC_AQRo=.c94f2bc2-f44e-409a-bcfe-4964887304b6@github.com>

On Tue, 5 Jan 2021 14:28:14 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> 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: <VKtfGSJUpIrQDH0z9bD6NHrnM3IOelYShVMlvbZokg0=.71660fb3-bf08-496d-9563-cdefad1aa525@github.com>
References: <u63dzrUDn4R6VGbnwvqs6ORVQLQarz8s5dUWUgHeUZA=.e1745a7b-a8b3-442d-87d2-c6aa075adaeb@github.com>
 <VKtfGSJUpIrQDH0z9bD6NHrnM3IOelYShVMlvbZokg0=.71660fb3-bf08-496d-9563-cdefad1aa525@github.com>
Message-ID: <apiht8_RYPHeQenoDFTJMYCe8UbhXa9aEwLRUfPK484=.b8e6bb0f-35a0-4af7-9944-5772cc93921b@github.com>

On Tue, 5 Jan 2021 15:49:21 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <u63dzrUDn4R6VGbnwvqs6ORVQLQarz8s5dUWUgHeUZA=.e1745a7b-a8b3-442d-87d2-c6aa075adaeb@github.com>
References: <u63dzrUDn4R6VGbnwvqs6ORVQLQarz8s5dUWUgHeUZA=.e1745a7b-a8b3-442d-87d2-c6aa075adaeb@github.com>
Message-ID: <BgxEL5-M-vLISkBEG68mVEjGtPKeYIDY9spc7qfgqac=.789128f3-b1d2-4365-8555-df62c2ce8323@github.com>

On Tue, 5 Jan 2021 15:12:31 GMT, Claes Redestad <redestad at openjdk.org> 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 <redestad at openjdk.org>
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: <ojysz8M2KPCx2XNYs2yQYuGIjsuTT8JEJpDQ-BKHluM=.c103c2cd-ffd1-4e55-88d4-a38efa4f5681@github.com>
References: <ojysz8M2KPCx2XNYs2yQYuGIjsuTT8JEJpDQ-BKHluM=.c103c2cd-ffd1-4e55-88d4-a38efa4f5681@github.com>
Message-ID: <FuSq8lDqClEOqrV310_0C1L4SlSW224qENguReqtgf8=.636bd509-b51e-4f2d-b663-c13434d78bac@github.com>

On Thu, 17 Dec 2020 17:58:12 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <f1QybMIubs3lveWEaZWRziFcCZxYCBHFawJhEkp1jV4=.450bfe4f-e71a-4e60-a79c-ff8d101356f8@github.com>
References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com>
 <f1QybMIubs3lveWEaZWRziFcCZxYCBHFawJhEkp1jV4=.450bfe4f-e71a-4e60-a79c-ff8d101356f8@github.com>
Message-ID: <20vLJN4hQGRFCYYV6TeIFfC3tNPlNBIV7-cizHLMo50=.c2780d75-060d-4a43-840e-86de2c43c664@github.com>

On Tue, 5 Jan 2021 10:11:11 GMT, Xin Liu <xliu at openjdk.org> 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>
 <f1QybMIubs3lveWEaZWRziFcCZxYCBHFawJhEkp1jV4=.450bfe4f-e71a-4e60-a79c-ff8d101356f8@github.com>
 <20vLJN4hQGRFCYYV6TeIFfC3tNPlNBIV7-cizHLMo50=.c2780d75-060d-4a43-840e-86de2c43c664@github.com>
Message-ID: <DNn5wdqOeKN5IS2sr7Zkl-NaxMxop0eeyJh5b1YE18k=.356f046c-99cd-47ee-98f9-c6d454ec0565@github.com>

On Tue, 5 Jan 2021 16:49:25 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <GT-U-BsJB95ynInLEGrf5us7qzU33dYHNyyPD3D9F90=.d737664b-441c-460b-bc02-ea990aa4c710@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
 <WRavuju8n2_h4yQo_1Op35ZvrXuK1W05JWomonwofog=.60c6efcf-9722-440b-840b-b7869f265cdb@github.com>
 <m-RdaubhZ7QuTNRsS7LML9dNPBN1HpyNN6sZfYx2FHE=.4a5b35cb-e008-49d5-8c47-873792cdea58@github.com>
 <GT-U-BsJB95ynInLEGrf5us7qzU33dYHNyyPD3D9F90=.d737664b-441c-460b-bc02-ea990aa4c710@github.com>
Message-ID: <TvZEd0GLdEoIlPn5l-0DPpeV9N0nHYRDBtGp4DRbuvk=.bcaf7fc7-bdca-4add-bf0a-8a9e5a3f2092@github.com>

On Tue, 5 Jan 2021 09:00:37 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <HE1PR02MB3147D7854979C336ED826FCD8ADE0@HE1PR02MB3147.eurprd02.prod.outlook.com>
References: <BYAPR11MB3543A4E3B2EDC63F7D21FC96EFCB0@BYAPR11MB3543.namprd11.prod.outlook.com>
 <a94871ad-b933-61f6-e6c8-a6dd44cc80f1@oracle.com>
 <BYAPR11MB354369AFC70C230143B7B55DEFCB0@BYAPR11MB3543.namprd11.prod.outlook.com>
 <HE1PR02MB3147D7854979C336ED826FCD8ADE0@HE1PR02MB3147.eurprd02.prod.outlook.com>
Message-ID: <BYAPR11MB354355B4EBF78EEC4B8C5064EFD10@BYAPR11MB3543.namprd11.prod.outlook.com>

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 <christoph.langer at sap.com> 
Sent: Wednesday, December 23, 2020 5:10 AM
To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Doerr, Martin <martin.doerr at sap.com>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Andrew Haley <aph at redhat.com>
Cc: Vladimir Kozlov <vladimir.kozlov at oracle.com>; 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 <jdk-updates-dev-retn at openjdk.java.net> On 
> Behalf Of Viswanathan, Sandhya
> Sent: Freitag, 11. Dezember 2020 00:47
> To: Vladimir Kozlov <vladimir.kozlov at oracle.com>; 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 <vladimir.kozlov at oracle.com>
> Sent: Thursday, December 10, 2020 3:07 PM
> To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; 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: <E8N9_oQod5qITPNLV35pC-hVxg1GwCZIyAOQHmdKVQg=.e740d14e-2aab-4a5f-99bd-8efe893df33d@github.com>

On Mon, 4 Jan 2021 02:03:13 GMT, Xiaohong Gong <xgong at openjdk.org> 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 <xgong at openjdk.org>
Committer: Ningsheng Jian <njian at openjdk.org>
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: <yf1JZk8wdFE5JWvk4TyYeoYm2hE4ffkYOWloDXbgfzU=.ed6e74ae-2aab-4c6d-865b-2ca0c13a39f7@github.com>
References: <yf1JZk8wdFE5JWvk4TyYeoYm2hE4ffkYOWloDXbgfzU=.ed6e74ae-2aab-4c6d-865b-2ca0c13a39f7@github.com>
Message-ID: <g6YKFRw4GnLbWNuokddw_vEJ9FFWDC-RHMnuviKzJrM=.7a4ccc54-910b-437d-a1c9-f99b6f5d3d79@github.com>

On Thu, 31 Dec 2020 01:47:00 GMT, Wang Huang <whuang at openjdk.org> 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 <whuang at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
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 <hexuejin2 at huawei.com>
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: <vVyo7Q52z1vIEAOB6HG8Rcf5wcSm8JNtEe2U2VqjEEM=.4dccf8a9-e80f-4c96-a298-058d1f353415@github.com>

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: <f1QybMIubs3lveWEaZWRziFcCZxYCBHFawJhEkp1jV4=.450bfe4f-e71a-4e60-a79c-ff8d101356f8@github.com>
References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com>
 <f1QybMIubs3lveWEaZWRziFcCZxYCBHFawJhEkp1jV4=.450bfe4f-e71a-4e60-a79c-ff8d101356f8@github.com>
Message-ID: <LW0hD47qKg4sxuy5fTqCtt18mFGr1ek-IZ-aLphE5Ug=.c24e6919-3155-436e-8565-443996fe2537@github.com>

On Tue, 5 Jan 2021 10:11:11 GMT, Xin Liu <xliu at openjdk.org> 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: <TvZEd0GLdEoIlPn5l-0DPpeV9N0nHYRDBtGp4DRbuvk=.bcaf7fc7-bdca-4add-bf0a-8a9e5a3f2092@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
 <WRavuju8n2_h4yQo_1Op35ZvrXuK1W05JWomonwofog=.60c6efcf-9722-440b-840b-b7869f265cdb@github.com>
 <m-RdaubhZ7QuTNRsS7LML9dNPBN1HpyNN6sZfYx2FHE=.4a5b35cb-e008-49d5-8c47-873792cdea58@github.com>
 <GT-U-BsJB95ynInLEGrf5us7qzU33dYHNyyPD3D9F90=.d737664b-441c-460b-bc02-ea990aa4c710@github.com>
 <TvZEd0GLdEoIlPn5l-0DPpeV9N0nHYRDBtGp4DRbuvk=.bcaf7fc7-bdca-4add-bf0a-8a9e5a3f2092@github.com>
Message-ID: <gm-1CuIsMo8XEQIJa9fNg7VTrQQDaXMiV9Kbl3lg3sQ=.771d1f80-0f50-4066-8663-8efe0ddde158@github.com>

On Tue, 5 Jan 2021 22:20:14 GMT, Dean Long <dlong at openjdk.org> 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: <vVyo7Q52z1vIEAOB6HG8Rcf5wcSm8JNtEe2U2VqjEEM=.4dccf8a9-e80f-4c96-a298-058d1f353415@github.com>
References: <vVyo7Q52z1vIEAOB6HG8Rcf5wcSm8JNtEe2U2VqjEEM=.4dccf8a9-e80f-4c96-a298-058d1f353415@github.com>
Message-ID: <50vuEMO5ruxr0b8lgAsQYXP_cYxBo2gMZSp1nrqIeV8=.b7f13fa9-cfc5-436f-b1ac-b772d9ee8c16@github.com>

On Wed, 6 Jan 2021 02:14:19 GMT, Xin Liu <xliu at openjdk.org> 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: <vVyo7Q52z1vIEAOB6HG8Rcf5wcSm8JNtEe2U2VqjEEM=.4dccf8a9-e80f-4c96-a298-058d1f353415@github.com>
References: <vVyo7Q52z1vIEAOB6HG8Rcf5wcSm8JNtEe2U2VqjEEM=.4dccf8a9-e80f-4c96-a298-058d1f353415@github.com>
Message-ID: <3jZAa8TpOvpo7TzlAlEAcogfFkPLWSwwiQXrZcuj0rQ=.d512814f-7673-44d0-a5bf-fbda8a46dcb5@github.com>

On Wed, 6 Jan 2021 02:14:19 GMT, Xin Liu <xliu at openjdk.org> 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: <FfC99x9gI_lCNSsSdpqPEquMMxmenp4R8L6pS1pCAD0=.8f07a714-1aa6-4b25-bdfa-7ade75ad5ab5@github.com>
References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com>
 <N45ei7kxBdtI2a5zTtp_yDZ3k4QjdumOPytzl3_S8A8=.728d07f9-281c-436e-8d6c-b1085064bb4e@github.com>
 <FfC99x9gI_lCNSsSdpqPEquMMxmenp4R8L6pS1pCAD0=.8f07a714-1aa6-4b25-bdfa-7ade75ad5ab5@github.com>
Message-ID: <BCI7d4vgk4epJ3PWmLuXW1kFAuE_ZpZcZSUxwWMLUkc=.d5f96ec7-8e9d-46cd-a254-4352aba2e7ea@github.com>

On Tue, 5 Jan 2021 10:10:57 GMT, Xin Liu <xliu at openjdk.org> 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: <dL12DPzReQs6D9xtPwcJ-p-Bfxok0XmlwKuHUgTqkG0=.0b8a5191-e576-4b0c-befe-f4375c4cf4ec@github.com>

> 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 <xliu at openjdk.org> 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: <X5GnkHCqy99Q3C1HvhilvglCCdCEoy1dFWgnIbSpMMk=.3c47249e-c712-4cff-9ef7-e075977e40f5@github.com>

On Wed, 6 Jan 2021 09:15:24 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <vVyo7Q52z1vIEAOB6HG8Rcf5wcSm8JNtEe2U2VqjEEM=.4dccf8a9-e80f-4c96-a298-058d1f353415@github.com>
References: <vVyo7Q52z1vIEAOB6HG8Rcf5wcSm8JNtEe2U2VqjEEM=.4dccf8a9-e80f-4c96-a298-058d1f353415@github.com>
Message-ID: <JhMNO9nAHlDvBV5sSpFs92smTKNICIEtpH16S-kaHw4=.be525cfd-a576-46fb-abaf-f867485e3bf9@github.com>

On Wed, 6 Jan 2021 02:14:19 GMT, Xin Liu <xliu at openjdk.org> 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: <JhMNO9nAHlDvBV5sSpFs92smTKNICIEtpH16S-kaHw4=.be525cfd-a576-46fb-abaf-f867485e3bf9@github.com>
References: <vVyo7Q52z1vIEAOB6HG8Rcf5wcSm8JNtEe2U2VqjEEM=.4dccf8a9-e80f-4c96-a298-058d1f353415@github.com>
 <JhMNO9nAHlDvBV5sSpFs92smTKNICIEtpH16S-kaHw4=.be525cfd-a576-46fb-abaf-f867485e3bf9@github.com>
Message-ID: <X1puGXEgk6lDYSEQzR88K55RRgm3a9VmEXoTkveDhZg=.230c9725-b32a-4e57-8999-b1d8ae8a5b37@github.com>

On Wed, 6 Jan 2021 09:46:01 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <vVyo7Q52z1vIEAOB6HG8Rcf5wcSm8JNtEe2U2VqjEEM=.4dccf8a9-e80f-4c96-a298-058d1f353415@github.com>
References: <vVyo7Q52z1vIEAOB6HG8Rcf5wcSm8JNtEe2U2VqjEEM=.4dccf8a9-e80f-4c96-a298-058d1f353415@github.com>
Message-ID: <xkBLgOIOuY5j9W5yG5LCX-ib-GC3iaZH6eOEmQGh0No=.ee64cad9-41ec-479b-9607-09539d27ecb6@github.com>

On Wed, 6 Jan 2021 02:14:19 GMT, Xin Liu <xliu at openjdk.org> wrote:

> I think the intention is to have constant member functions.

This pull request has now been integrated.

Changeset: e3b9da14
Author:    Xin Liu <xliu at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
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: <HE1PR02MB3147D7854979C336ED826FCD8ADE0@HE1PR02MB3147.eurprd02.prod.outlook.com>
References: <BYAPR11MB3543A4E3B2EDC63F7D21FC96EFCB0@BYAPR11MB3543.namprd11.prod.outlook.com>
 <a94871ad-b933-61f6-e6c8-a6dd44cc80f1@oracle.com>
 <BYAPR11MB354369AFC70C230143B7B55DEFCB0@BYAPR11MB3543.namprd11.prod.outlook.com>
 <HE1PR02MB3147D7854979C336ED826FCD8ADE0@HE1PR02MB3147.eurprd02.prod.outlook.com>
Message-ID: <d2907a4a-3265-441e-24fc-f17edd92dbc8@redhat.com>

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://www.redhat.com>
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: <ojysz8M2KPCx2XNYs2yQYuGIjsuTT8JEJpDQ-BKHluM=.c103c2cd-ffd1-4e55-88d4-a38efa4f5681@github.com>
References: <ojysz8M2KPCx2XNYs2yQYuGIjsuTT8JEJpDQ-BKHluM=.c103c2cd-ffd1-4e55-88d4-a38efa4f5681@github.com>
Message-ID: <brbE38AIA3u2eYo3qYSGcWOvGG4W-7IAwiToPOid-y8=.147fd3ca-41e5-4940-b893-418e54ef1990@github.com>

On Thu, 17 Dec 2020 17:58:12 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <tJS2pUqfN3j3EpfXvXm9PtSIWnlvN_tuD2dZS72IxI8=.0b18e0a6-14b0-4876-9aff-5d9a5a449381@github.com>

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: <uMjWNI_SX4ZLVcx1NHWL-XEjPaIxawYxxpGTGz_m6vw=.96d0671b-5bb6-48bb-a841-5f57b54b552b@github.com>

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: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
Message-ID: <tqXajUQZRGi6L7HCSqSStQe9YXUSLNQoGIovUEm-x7M=.272ccd9c-c5ec-4116-a39d-eaf09b738f73@github.com>

On Wed, 16 Dec 2020 18:38:37 GMT, Dan <github.com+7991079+danlemmond at openjdk.org> 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: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
Message-ID: <5q-Tvy6wwLlLJi1MM86hCS-eW2OGg0FDCYh_hW2LyhY=.2cddf2b1-369d-493a-b1d5-cbf37f10b423@github.com>

On Wed, 16 Dec 2020 18:38:37 GMT, Dan <github.com+7991079+danlemmond at openjdk.org> 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: <uMjWNI_SX4ZLVcx1NHWL-XEjPaIxawYxxpGTGz_m6vw=.96d0671b-5bb6-48bb-a841-5f57b54b552b@github.com>
References: <uMjWNI_SX4ZLVcx1NHWL-XEjPaIxawYxxpGTGz_m6vw=.96d0671b-5bb6-48bb-a841-5f57b54b552b@github.com>
Message-ID: <-KTp0-ukOgFyc0kAXlCWYTZU5G-QucduLfIXHccGbpI=.0f05f809-663e-453b-9782-2928bb5490d1@github.com>

On Wed, 6 Jan 2021 17:38:00 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <tJS2pUqfN3j3EpfXvXm9PtSIWnlvN_tuD2dZS72IxI8=.0b18e0a6-14b0-4876-9aff-5d9a5a449381@github.com>
References: <tJS2pUqfN3j3EpfXvXm9PtSIWnlvN_tuD2dZS72IxI8=.0b18e0a6-14b0-4876-9aff-5d9a5a449381@github.com>
Message-ID: <gH2e6yI0uyWmsEB0e0gZG5pI5j9yDJwld2BLIZCBm78=.45503683-b62b-49ee-9010-d0b2f5a4ea55@github.com>

On Wed, 6 Jan 2021 13:43:17 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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: <d2907a4a-3265-441e-24fc-f17edd92dbc8@redhat.com>
References: <BYAPR11MB3543A4E3B2EDC63F7D21FC96EFCB0@BYAPR11MB3543.namprd11.prod.outlook.com>
 <a94871ad-b933-61f6-e6c8-a6dd44cc80f1@oracle.com>
 <BYAPR11MB354369AFC70C230143B7B55DEFCB0@BYAPR11MB3543.namprd11.prod.outlook.com>
 <HE1PR02MB3147D7854979C336ED826FCD8ADE0@HE1PR02MB3147.eurprd02.prod.outlook.com>
 <d2907a4a-3265-441e-24fc-f17edd92dbc8@redhat.com>
Message-ID: <BYAPR11MB354371517486376D6BF273F3EFD00@BYAPR11MB3543.namprd11.prod.outlook.com>

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 <aph at redhat.com> 
Sent: Wednesday, January 06, 2021 1:57 AM
To: Langer, Christoph <christoph.langer at sap.com>; Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Doerr, Martin <martin.doerr at sap.com>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Cc: Vladimir Kozlov <vladimir.kozlov at oracle.com>; 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://www.redhat.com> 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: <Lvt2MVmZ094pM9uluOpK6e__FIh87KxX2C352bQ9mTI=.5ea17aaa-f6da-40f8-b16a-72f163e04862@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
 <Pn6Ld1CGjfGCfhBwEgXKOuX-JSpJHj4zivtEbA0Mpuc=.66ac0c27-cf02-48f6-8313-97a12e04169c@github.com>
 <Lvt2MVmZ094pM9uluOpK6e__FIh87KxX2C352bQ9mTI=.5ea17aaa-f6da-40f8-b16a-72f163e04862@github.com>
Message-ID: <1uesqHOGE6FbsMN6jcbfiVWT1nYVFpfBqXfrBMTwCIk=.b94cc813-e88f-4cf0-9fe4-474e0911b01d@github.com>

On Tue, 5 Jan 2021 11:19:08 GMT, Andrew Haley <aph at openjdk.org> 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: <RNU-tanbO6-6vkeQ8yVg2mAa0yzWgCAw3kI5uO8iFow=.7ea55a0f-f60e-4c80-b390-8b990536bde4@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
 <RNU-tanbO6-6vkeQ8yVg2mAa0yzWgCAw3kI5uO8iFow=.7ea55a0f-f60e-4c80-b390-8b990536bde4@github.com>
Message-ID: <xMNxWo7rVymZ5nV7Ts47s_1rko0BAGpIKsKJ9ZIiabc=.3ea58ec1-e081-400e-9925-30154b0a15a0@github.com>

On Tue, 5 Jan 2021 13:42:21 GMT, Dong Bo <dongbo at openjdk.org> 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: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
Message-ID: <VMigfDsCwhBfFPaZjESuC7FwCuhDyW6aQoR_w-oajXk=.e1a652e0-5303-40bd-ab60-5a55b51fdc64@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:

  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: <xMNxWo7rVymZ5nV7Ts47s_1rko0BAGpIKsKJ9ZIiabc=.3ea58ec1-e081-400e-9925-30154b0a15a0@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
 <RNU-tanbO6-6vkeQ8yVg2mAa0yzWgCAw3kI5uO8iFow=.7ea55a0f-f60e-4c80-b390-8b990536bde4@github.com>
 <xMNxWo7rVymZ5nV7Ts47s_1rko0BAGpIKsKJ9ZIiabc=.3ea58ec1-e081-400e-9925-30154b0a15a0@github.com>
Message-ID: <tApKH4J-mbUew_JEh_PTg9LR2wv2__3fITFg8kiaBHQ=.043889b6-daa7-48b8-9c43-169c6a988ec0@github.com>

On Thu, 7 Jan 2021 03:03:31 GMT, Pengfei Li <pli at openjdk.org> 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: <tApKH4J-mbUew_JEh_PTg9LR2wv2__3fITFg8kiaBHQ=.043889b6-daa7-48b8-9c43-169c6a988ec0@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
 <RNU-tanbO6-6vkeQ8yVg2mAa0yzWgCAw3kI5uO8iFow=.7ea55a0f-f60e-4c80-b390-8b990536bde4@github.com>
 <xMNxWo7rVymZ5nV7Ts47s_1rko0BAGpIKsKJ9ZIiabc=.3ea58ec1-e081-400e-9925-30154b0a15a0@github.com>
 <tApKH4J-mbUew_JEh_PTg9LR2wv2__3fITFg8kiaBHQ=.043889b6-daa7-48b8-9c43-169c6a988ec0@github.com>
Message-ID: <I-szjfrfGjq3yKfF5Nl7d1B4UUHy3NSX-ZPmKF14cS8=.676a0d28-66f0-4502-ba0c-cd2e14536791@github.com>

On Thu, 7 Jan 2021 03:29:34 GMT, Dong Bo <dongbo at openjdk.org> 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: <uMjWNI_SX4ZLVcx1NHWL-XEjPaIxawYxxpGTGz_m6vw=.96d0671b-5bb6-48bb-a841-5f57b54b552b@github.com>
 <-KTp0-ukOgFyc0kAXlCWYTZU5G-QucduLfIXHccGbpI=.0f05f809-663e-453b-9782-2928bb5490d1@github.com>
Message-ID: <BhKkeAFRbVYmh7i8CnAf6tRLTLyAv-8Umuq_e9r4ncg=.75a48207-a239-4d53-a56b-f5cc5c112074@github.com>

On Wed, 6 Jan 2021 18:09:30 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <urfdDMSaLblAhKDpN9xzeI1Bu-bq5dMUTrR69s-Ijvo=.442a09a2-c461-45b1-9f63-0083836ea3d9@github.com>

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: <aImAKeZeaYkt6RalA3LOuJABA5EvS815xtBBG_9XyCc=.b4021a24-b0cf-4b84-b877-1fdae93a16f9@github.com>
References: <VZFLWY4KTWeONXFl3KtGm36yMl-hycd6W5drW3adC6o=.9b9b7045-8c25-448c-87b7-4d3139a3bcea@github.com>
 <BpafR4x9bJsPyH0Tj7u8hoWzX8H7BMDWYQGFMJT4-tg=.7a8b0979-d058-4e1e-ba0c-5d8473d1912b@github.com>
 <RgR4f2yTBtMpvLBE9P1-RomyFdYeKy1gSQABk6gRAZo=.285e4674-1811-4b2f-8355-59279155397d@github.com>
 <aImAKeZeaYkt6RalA3LOuJABA5EvS815xtBBG_9XyCc=.b4021a24-b0cf-4b84-b877-1fdae93a16f9@github.com>
Message-ID: <fmzVc05XnOv6cH86vKklb4uoBYoHlrj6yfVlAbzsoq0=.eaf1256e-3072-4879-b199-3e549173f67a@github.com>

On Tue, 22 Dec 2020 19:48:32 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> 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: <KIlIiTV_jZsIxnRaMNpm_TLRJXHlue_grhOyshAmrrI=.0f98e90f-3fb3-431b-a4c6-c5e95d7344b2@github.com>
 <K8uhUfgR_ozZHkCerRZobyCyRYsHuAfWv2bX2DE-RpY=.bd0ad721-8628-4898-aed9-4eb93bbacea5@github.com>
 <bbqvtsZbRTndDC_4Ir_42CzpKkYOr6Z9HNOEtyRfyw4=.010ccfa5-7d16-4891-86f3-40e938ce9dac@github.com>
 <JOajmfvtLp11b1tMD6qp9kwZzbKX9coi9O8dJWPbMdo=.884ca499-5ca8-4ded-aee9-17f74f03a2f9@github.com>
 <6GcibhtqhAk99Woc8TYvJA-H-vbemipbzcAC4SJt8TI=.1ddf5895-ac11-4357-bbd8-4b6e71fa5af9@github.com>
Message-ID: <Q9dSGuIRR08Qd9-p2sPct9wVQ8vPuXBS8UdPsLopeH0=.c933448f-ddc7-4c2e-8b9a-ce550de2619f@github.com>

On Wed, 2 Dec 2020 08:14:32 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> 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: <fmzVc05XnOv6cH86vKklb4uoBYoHlrj6yfVlAbzsoq0=.eaf1256e-3072-4879-b199-3e549173f67a@github.com>
References: <VZFLWY4KTWeONXFl3KtGm36yMl-hycd6W5drW3adC6o=.9b9b7045-8c25-448c-87b7-4d3139a3bcea@github.com>
 <BpafR4x9bJsPyH0Tj7u8hoWzX8H7BMDWYQGFMJT4-tg=.7a8b0979-d058-4e1e-ba0c-5d8473d1912b@github.com>
 <RgR4f2yTBtMpvLBE9P1-RomyFdYeKy1gSQABk6gRAZo=.285e4674-1811-4b2f-8355-59279155397d@github.com>
 <aImAKeZeaYkt6RalA3LOuJABA5EvS815xtBBG_9XyCc=.b4021a24-b0cf-4b84-b877-1fdae93a16f9@github.com>
 <fmzVc05XnOv6cH86vKklb4uoBYoHlrj6yfVlAbzsoq0=.eaf1256e-3072-4879-b199-3e549173f67a@github.com>
Message-ID: <dmXlSTQsebbSNxR6_15v8xaaLA3EkFRJWq1HxIcV2_Q=.3e54a5b1-381a-42ee-bdd8-1e12c7d0a95f@github.com>

On Thu, 7 Jan 2021 08:28:09 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> 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: <eZRLL9Odf3lQ0so4pSAM-gANlx2q70K_Ax9901f2aSY=.15cec8ef-6a08-413b-a722-ec03284f32c5@github.com>
References: <Rf7p_ZxEJqWwhX-scW7MRmb1hwyPRodsrwAJ2l5Uaq8=.c2afbad2-3969-4104-9434-917b7615d25e@github.com>
 <9xocwLfdmD9SYuxkUdHE7zVQ71czLjM-gDE4_ySGDZo=.04b6794c-8a24-48d0-87a6-222c4ee7d304@github.com>
 <eZRLL9Odf3lQ0so4pSAM-gANlx2q70K_Ax9901f2aSY=.15cec8ef-6a08-413b-a722-ec03284f32c5@github.com>
Message-ID: <D_XQFXuwIhxpRrgmoT4oszxcIwPA3v-aBjja5kiBaV8=.7bc3a608-2d58-4a90-9e81-48e1f9e58ef3@github.com>

On Tue, 22 Dec 2020 19:33:06 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> 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: <Rf7p_ZxEJqWwhX-scW7MRmb1hwyPRodsrwAJ2l5Uaq8=.c2afbad2-3969-4104-9434-917b7615d25e@github.com>
References: <Rf7p_ZxEJqWwhX-scW7MRmb1hwyPRodsrwAJ2l5Uaq8=.c2afbad2-3969-4104-9434-917b7615d25e@github.com>
Message-ID: <h4sWVHVqHtmHYi1NA_PD7VVNbE6zqPxPuFYb2EYXHic=.87cdd356-cf63-45d3-9930-86463ed6bdae@github.com>

> 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: <D_XQFXuwIhxpRrgmoT4oszxcIwPA3v-aBjja5kiBaV8=.7bc3a608-2d58-4a90-9e81-48e1f9e58ef3@github.com>
References: <Rf7p_ZxEJqWwhX-scW7MRmb1hwyPRodsrwAJ2l5Uaq8=.c2afbad2-3969-4104-9434-917b7615d25e@github.com>
 <9xocwLfdmD9SYuxkUdHE7zVQ71czLjM-gDE4_ySGDZo=.04b6794c-8a24-48d0-87a6-222c4ee7d304@github.com>
 <eZRLL9Odf3lQ0so4pSAM-gANlx2q70K_Ax9901f2aSY=.15cec8ef-6a08-413b-a722-ec03284f32c5@github.com>
 <D_XQFXuwIhxpRrgmoT4oszxcIwPA3v-aBjja5kiBaV8=.7bc3a608-2d58-4a90-9e81-48e1f9e58ef3@github.com>
Message-ID: <KskvoNZKhz7Z4GRKqnufp1VNVzESfEwfzPaqXHL4sBU=.8f464958-418b-42d3-8901-5bfe356e2ee4@github.com>

On Thu, 7 Jan 2021 09:35:57 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> 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: <h4sWVHVqHtmHYi1NA_PD7VVNbE6zqPxPuFYb2EYXHic=.87cdd356-cf63-45d3-9930-86463ed6bdae@github.com>
References: <Rf7p_ZxEJqWwhX-scW7MRmb1hwyPRodsrwAJ2l5Uaq8=.c2afbad2-3969-4104-9434-917b7615d25e@github.com>
 <h4sWVHVqHtmHYi1NA_PD7VVNbE6zqPxPuFYb2EYXHic=.87cdd356-cf63-45d3-9930-86463ed6bdae@github.com>
Message-ID: <XWOzDlOjvYR6ACiE6q9uvgK3u4UfiLbTjR88Ro6mk0E=.8f34b994-7a63-4c47-8125-5fdaf88007f2@github.com>

On Thu, 7 Jan 2021 10:06:26 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> 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: <h4sWVHVqHtmHYi1NA_PD7VVNbE6zqPxPuFYb2EYXHic=.87cdd356-cf63-45d3-9930-86463ed6bdae@github.com>
References: <Rf7p_ZxEJqWwhX-scW7MRmb1hwyPRodsrwAJ2l5Uaq8=.c2afbad2-3969-4104-9434-917b7615d25e@github.com>
 <h4sWVHVqHtmHYi1NA_PD7VVNbE6zqPxPuFYb2EYXHic=.87cdd356-cf63-45d3-9930-86463ed6bdae@github.com>
Message-ID: <jFogjnGMKPa8qXQh-83Vyb0__FFcBvQ_Sk1sJ5IhRdI=.10abc55b-38a5-4b17-8398-4d055658a163@github.com>

On Thu, 7 Jan 2021 10:06:26 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> 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: <gH2e6yI0uyWmsEB0e0gZG5pI5j9yDJwld2BLIZCBm78=.45503683-b62b-49ee-9010-d0b2f5a4ea55@github.com>
References: <tJS2pUqfN3j3EpfXvXm9PtSIWnlvN_tuD2dZS72IxI8=.0b18e0a6-14b0-4876-9aff-5d9a5a449381@github.com>
 <gH2e6yI0uyWmsEB0e0gZG5pI5j9yDJwld2BLIZCBm78=.45503683-b62b-49ee-9010-d0b2f5a4ea55@github.com>
Message-ID: <JqJsY1NOWi8x64DydXKgPNFw6bUQ2PjEh1apzQ98W90=.998bcbb7-b528-4076-92bc-3d6448f128d0@github.com>

On Wed, 6 Jan 2021 18:11:55 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <BYAPR11MB354371517486376D6BF273F3EFD00@BYAPR11MB3543.namprd11.prod.outlook.com>
References: <BYAPR11MB3543A4E3B2EDC63F7D21FC96EFCB0@BYAPR11MB3543.namprd11.prod.outlook.com>
 <a94871ad-b933-61f6-e6c8-a6dd44cc80f1@oracle.com>
 <BYAPR11MB354369AFC70C230143B7B55DEFCB0@BYAPR11MB3543.namprd11.prod.outlook.com>
 <HE1PR02MB3147D7854979C336ED826FCD8ADE0@HE1PR02MB3147.eurprd02.prod.outlook.com>
 <d2907a4a-3265-441e-24fc-f17edd92dbc8@redhat.com>
 <BYAPR11MB354371517486376D6BF273F3EFD00@BYAPR11MB3543.namprd11.prod.outlook.com>
Message-ID: <AM4PR02MB30571B7111304FDC8CBE4F719AAF0@AM4PR02MB3057.eurprd02.prod.outlook.com>

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 <sandhya.viswanathan at intel.com>
> Sent: Mittwoch, 6. Januar 2021 19:49
> To: Andrew Haley <aph at redhat.com>; Langer, Christoph
> <christoph.langer at sap.com>; Doerr, Martin <martin.doerr at sap.com>;
> Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: Vladimir Kozlov <vladimir.kozlov at oracle.com>; 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 <aph at redhat.com>
> Sent: Wednesday, January 06, 2021 1:57 AM
> To: Langer, Christoph <christoph.langer at sap.com>; Viswanathan, Sandhya
> <sandhya.viswanathan at intel.com>; Doerr, Martin
> <martin.doerr at sap.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>
> Cc: Vladimir Kozlov <vladimir.kozlov at oracle.com>; 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://www.redhat.com>
> 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: <tJS2pUqfN3j3EpfXvXm9PtSIWnlvN_tuD2dZS72IxI8=.0b18e0a6-14b0-4876-9aff-5d9a5a449381@github.com>
References: <tJS2pUqfN3j3EpfXvXm9PtSIWnlvN_tuD2dZS72IxI8=.0b18e0a6-14b0-4876-9aff-5d9a5a449381@github.com>
Message-ID: <j_-DKXfGD6sdXJ7A-m4-mDVTu4bCkOYiSqENXcnfl5g=.2744c06a-9f67-4de1-a531-b282e8c672c6@github.com>

On Wed, 6 Jan 2021 13:43:17 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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: <AM4PR02MB30571B7111304FDC8CBE4F719AAF0@AM4PR02MB3057.eurprd02.prod.outlook.com>
References: <BYAPR11MB3543A4E3B2EDC63F7D21FC96EFCB0@BYAPR11MB3543.namprd11.prod.outlook.com>
 <a94871ad-b933-61f6-e6c8-a6dd44cc80f1@oracle.com>
 <BYAPR11MB354369AFC70C230143B7B55DEFCB0@BYAPR11MB3543.namprd11.prod.outlook.com>
 <HE1PR02MB3147D7854979C336ED826FCD8ADE0@HE1PR02MB3147.eurprd02.prod.outlook.com>
 <d2907a4a-3265-441e-24fc-f17edd92dbc8@redhat.com>
 <BYAPR11MB354371517486376D6BF273F3EFD00@BYAPR11MB3543.namprd11.prod.outlook.com>
 <AM4PR02MB30571B7111304FDC8CBE4F719AAF0@AM4PR02MB3057.eurprd02.prod.outlook.com>
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://www.redhat.com>
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: <RNU-tanbO6-6vkeQ8yVg2mAa0yzWgCAw3kI5uO8iFow=.7ea55a0f-f60e-4c80-b390-8b990536bde4@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
 <RNU-tanbO6-6vkeQ8yVg2mAa0yzWgCAw3kI5uO8iFow=.7ea55a0f-f60e-4c80-b390-8b990536bde4@github.com>
Message-ID: <Fhb2WqqPcTDgy1QcnOkBLnxcs6VSFRCaoXRqikGdTG8=.877263e9-89d1-40f9-97d8-fa34e3b1a5b5@github.com>

On Tue, 5 Jan 2021 13:42:21 GMT, Dong Bo <dongbo at openjdk.org> 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: <J0a9NMDVRJc2s2-XYH033ySw1G5Br4FMkVKPavm7BUM=.e36253a5-e4be-46ab-ac53-9999956a1974@github.com>
References: <uMjWNI_SX4ZLVcx1NHWL-XEjPaIxawYxxpGTGz_m6vw=.96d0671b-5bb6-48bb-a841-5f57b54b552b@github.com>
 <J0a9NMDVRJc2s2-XYH033ySw1G5Br4FMkVKPavm7BUM=.e36253a5-e4be-46ab-ac53-9999956a1974@github.com>
Message-ID: <w8C3kSR4-usiaobkdTcRgjPO-KrQCxtIWeI5yNgLUcc=.8349600b-b0e6-4c87-ba84-f38621ffbb9b@github.com>

On Thu, 7 Jan 2021 12:14:14 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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: <uMjWNI_SX4ZLVcx1NHWL-XEjPaIxawYxxpGTGz_m6vw=.96d0671b-5bb6-48bb-a841-5f57b54b552b@github.com>
References: <uMjWNI_SX4ZLVcx1NHWL-XEjPaIxawYxxpGTGz_m6vw=.96d0671b-5bb6-48bb-a841-5f57b54b552b@github.com>
Message-ID: <J6Wtc1kn5YhBJFD8yr2TJDrYF3r_wwuZmU5aH36z9zA=.d23cfe72-9422-43df-aa64-0dad44432e99@github.com>

On Wed, 6 Jan 2021 17:38:00 GMT, Tobias Hartmann <thartmann at openjdk.org> 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 <thartmann at openjdk.org>
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: <uMjWNI_SX4ZLVcx1NHWL-XEjPaIxawYxxpGTGz_m6vw=.96d0671b-5bb6-48bb-a841-5f57b54b552b@github.com>
References: <uMjWNI_SX4ZLVcx1NHWL-XEjPaIxawYxxpGTGz_m6vw=.96d0671b-5bb6-48bb-a841-5f57b54b552b@github.com>
Message-ID: <J0a9NMDVRJc2s2-XYH033ySw1G5Br4FMkVKPavm7BUM=.e36253a5-e4be-46ab-ac53-9999956a1974@github.com>

On Wed, 6 Jan 2021 17:38:00 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <BYAPR11MB3543A4E3B2EDC63F7D21FC96EFCB0@BYAPR11MB3543.namprd11.prod.outlook.com>
 <a94871ad-b933-61f6-e6c8-a6dd44cc80f1@oracle.com>
 <BYAPR11MB354369AFC70C230143B7B55DEFCB0@BYAPR11MB3543.namprd11.prod.outlook.com>
 <HE1PR02MB3147D7854979C336ED826FCD8ADE0@HE1PR02MB3147.eurprd02.prod.outlook.com>
 <d2907a4a-3265-441e-24fc-f17edd92dbc8@redhat.com>
 <BYAPR11MB354371517486376D6BF273F3EFD00@BYAPR11MB3543.namprd11.prod.outlook.com>
 <AM4PR02MB30571B7111304FDC8CBE4F719AAF0@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <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:

<https://ark.intel.com/content/www/us/en/ark/products/208656/intel-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 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: <ZhyjPKtZB9HzbXsk1KcJTbr3hcUdUAmira99iB-z76Q=.a81080c6-5cfa-4af4-b9cc-81af8246271a@github.com>

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: <BB58CAF2-760C-4336-98E7-5997F8EFE7E3@amazon.com>

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 <hotspot-compiler-dev-retn at openjdk.java.net> on behalf of Florian Weimer <fweimer at redhat.com>
Date: Thursday, January 7, 2021 at 4:25 AM
To: Andrew Haley <aph at redhat.com>
Cc: "Doerr, Martin" <martin.doerr at sap.com>, "Viswanathan, Sandhya" <sandhya.viswanathan at intel.com>, "Langer, Christoph" <christoph.langer at sap.com>, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>, Vladimir Kozlov <vladimir.kozlov at oracle.com>, "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>, "hotspot-compiler-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:

<https://ark.intel.com/content/www/us/en/ark/products/208656/intel-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 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: <BB58CAF2-760C-4336-98E7-5997F8EFE7E3@amazon.com>
References: <BB58CAF2-760C-4336-98E7-5997F8EFE7E3@amazon.com>
Message-ID: <AM4PR02MB31381552DDD7046390A7FF698AAF0@AM4PR02MB3138.eurprd02.prod.outlook.com>

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 <hohensee at amazon.com>
> Sent: Donnerstag, 7. Januar 2021 15:13
> To: Florian Weimer <fweimer at redhat.com>; Andrew Haley
> <aph at redhat.com>
> Cc: Doerr, Martin <martin.doerr at sap.com>; Viswanathan, Sandhya
> <sandhya.viswanathan at intel.com>; Langer, Christoph
> <christoph.langer at sap.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; Vladimir Kozlov
> <vladimir.kozlov at oracle.com>; 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 <hotspot-compiler-dev-
> retn at openjdk.java.net> on behalf of Florian Weimer
> <fweimer at redhat.com>
> Date: Thursday, January 7, 2021 at 4:25 AM
> To: Andrew Haley <aph at redhat.com>
> Cc: "Doerr, Martin" <martin.doerr at sap.com>, "Viswanathan, Sandhya"
> <sandhya.viswanathan at intel.com>, "Langer, Christoph"
> <christoph.langer at sap.com>, "Lindenmaier, Goetz"
> <goetz.lindenmaier at sap.com>, Vladimir Kozlov
> <vladimir.kozlov at oracle.com>, "jdk-updates-dev at openjdk.java.net" <jdk-
> updates-dev at openjdk.java.net>, "hotspot-compiler-
> 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:
> 
> <https://ark.intel.com/content/www/us/en/ark/products/208656/intel-
> 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: <KStXCzhY5X1uzX2tnVctCWJMRjGFN4g12kYW3KrYRD4=.7f98985f-5b72-4b16-9071-47b9ca006d24@github.com>
References: <tJS2pUqfN3j3EpfXvXm9PtSIWnlvN_tuD2dZS72IxI8=.0b18e0a6-14b0-4876-9aff-5d9a5a449381@github.com>
 <KStXCzhY5X1uzX2tnVctCWJMRjGFN4g12kYW3KrYRD4=.7f98985f-5b72-4b16-9071-47b9ca006d24@github.com>
Message-ID: <T5tCec3aJEcZTO7HHEQBDy3RIoiRx_V_ib0efYyyFCM=.c8c77f4f-2b28-49c7-b18f-f9a23af658c6@github.com>

On Thu, 7 Jan 2021 14:53:26 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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: <j_-DKXfGD6sdXJ7A-m4-mDVTu4bCkOYiSqENXcnfl5g=.2744c06a-9f67-4de1-a531-b282e8c672c6@github.com>
References: <tJS2pUqfN3j3EpfXvXm9PtSIWnlvN_tuD2dZS72IxI8=.0b18e0a6-14b0-4876-9aff-5d9a5a449381@github.com>
 <j_-DKXfGD6sdXJ7A-m4-mDVTu4bCkOYiSqENXcnfl5g=.2744c06a-9f67-4de1-a531-b282e8c672c6@github.com>
Message-ID: <nGewzj9vcw2Ek95jbDHxEyZ2tnNjkwgoVBH7APthOAc=.2bd4c8c5-4ef0-4a2e-8451-eb7145246c1b@github.com>

On Thu, 7 Jan 2021 10:57:53 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <tJS2pUqfN3j3EpfXvXm9PtSIWnlvN_tuD2dZS72IxI8=.0b18e0a6-14b0-4876-9aff-5d9a5a449381@github.com>
References: <tJS2pUqfN3j3EpfXvXm9PtSIWnlvN_tuD2dZS72IxI8=.0b18e0a6-14b0-4876-9aff-5d9a5a449381@github.com>
Message-ID: <KStXCzhY5X1uzX2tnVctCWJMRjGFN4g12kYW3KrYRD4=.7f98985f-5b72-4b16-9071-47b9ca006d24@github.com>

> 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: <T5tCec3aJEcZTO7HHEQBDy3RIoiRx_V_ib0efYyyFCM=.c8c77f4f-2b28-49c7-b18f-f9a23af658c6@github.com>
References: <tJS2pUqfN3j3EpfXvXm9PtSIWnlvN_tuD2dZS72IxI8=.0b18e0a6-14b0-4876-9aff-5d9a5a449381@github.com>
 <KStXCzhY5X1uzX2tnVctCWJMRjGFN4g12kYW3KrYRD4=.7f98985f-5b72-4b16-9071-47b9ca006d24@github.com>
 <T5tCec3aJEcZTO7HHEQBDy3RIoiRx_V_ib0efYyyFCM=.c8c77f4f-2b28-49c7-b18f-f9a23af658c6@github.com>
Message-ID: <f4iOxyEjpnxRE1Vzg8ep-xT_kcymjYnTWxXOAr9dWeo=.47c22ba6-f18f-48ac-a1a2-4d7750820152@github.com>

On Thu, 7 Jan 2021 14:52:50 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <tJS2pUqfN3j3EpfXvXm9PtSIWnlvN_tuD2dZS72IxI8=.0b18e0a6-14b0-4876-9aff-5d9a5a449381@github.com>
References: <tJS2pUqfN3j3EpfXvXm9PtSIWnlvN_tuD2dZS72IxI8=.0b18e0a6-14b0-4876-9aff-5d9a5a449381@github.com>
Message-ID: <M6_jUhC97OTubd8bF5dTyL0qmEppJWEtFxOEwXXE_gI=.006c0ff4-e5d1-4804-8854-a0adf32e9b97@github.com>

On Wed, 6 Jan 2021 13:43:17 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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 <chagedorn at openjdk.org>
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: <AM4PR02MB31381552DDD7046390A7FF698AAF0@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <BB58CAF2-760C-4336-98E7-5997F8EFE7E3@amazon.com>
 <AM4PR02MB31381552DDD7046390A7FF698AAF0@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <f3f091f6-941d-edda-32d7-5617771c30d2@redhat.com>

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://www.redhat.com>
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: <hOACZI1gDqFXrhSdsX8SBB8QkgN2AqHvc0HNOiFV5z0=.6ffe7c79-4fea-4896-8d20-33b99c0cba11@github.com>

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: <SytAhXaavvmtXCek4iNOyjBuBA36VI6XT-KDLykilZE=.847a4f9b-078b-4800-a184-145a1e88f81e@github.com>
References: <SytAhXaavvmtXCek4iNOyjBuBA36VI6XT-KDLykilZE=.847a4f9b-078b-4800-a184-145a1e88f81e@github.com>
Message-ID: <P0AGQ4Z5yshinMFbmo2KsjjvEfA8iTXJ27J0M21Cwck=.93852cb8-b88c-4062-8d60-76802ca7220e@github.com>

On Mon, 21 Dec 2020 16:44:39 GMT, Eric Caspole <ecaspole at openjdk.org> 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: <XWOzDlOjvYR6ACiE6q9uvgK3u4UfiLbTjR88Ro6mk0E=.8f34b994-7a63-4c47-8125-5fdaf88007f2@github.com>
References: <Rf7p_ZxEJqWwhX-scW7MRmb1hwyPRodsrwAJ2l5Uaq8=.c2afbad2-3969-4104-9434-917b7615d25e@github.com>
 <h4sWVHVqHtmHYi1NA_PD7VVNbE6zqPxPuFYb2EYXHic=.87cdd356-cf63-45d3-9930-86463ed6bdae@github.com>
 <XWOzDlOjvYR6ACiE6q9uvgK3u4UfiLbTjR88Ro6mk0E=.8f34b994-7a63-4c47-8125-5fdaf88007f2@github.com>
Message-ID: <YhS2xlIjaO6HcD7m3LniqrXa0ZXGwlDylsF4HEMtaQ8=.dd64c74e-c2f6-4983-9b42-3871862ac8fa@github.com>

On Thu, 7 Jan 2021 10:13:13 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <Rf7p_ZxEJqWwhX-scW7MRmb1hwyPRodsrwAJ2l5Uaq8=.c2afbad2-3969-4104-9434-917b7615d25e@github.com>
References: <Rf7p_ZxEJqWwhX-scW7MRmb1hwyPRodsrwAJ2l5Uaq8=.c2afbad2-3969-4104-9434-917b7615d25e@github.com>
Message-ID: <5OffhvqMNt0ofpC-LhYGZScDdNaPmzCq1y0smt9fh3M=.65df502e-34b1-4b13-8307-b8a16e60c9ae@github.com>

On Tue, 22 Dec 2020 09:13:45 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> 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 <rcastanedalo at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
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: <hOACZI1gDqFXrhSdsX8SBB8QkgN2AqHvc0HNOiFV5z0=.6ffe7c79-4fea-4896-8d20-33b99c0cba11@github.com>
References: <hOACZI1gDqFXrhSdsX8SBB8QkgN2AqHvc0HNOiFV5z0=.6ffe7c79-4fea-4896-8d20-33b99c0cba11@github.com>
Message-ID: <jFnlMs4qQIaFOyGGEyhtDoHGygymRGyg7lQpkkGLfvw=.cc91bc76-7f0b-4888-9397-2da96fd2bed4@github.com>

On Thu, 7 Jan 2021 18:26:26 GMT, Coleen Phillimore <coleenp at openjdk.org> 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: <VZFLWY4KTWeONXFl3KtGm36yMl-hycd6W5drW3adC6o=.9b9b7045-8c25-448c-87b7-4d3139a3bcea@github.com>
References: <VZFLWY4KTWeONXFl3KtGm36yMl-hycd6W5drW3adC6o=.9b9b7045-8c25-448c-87b7-4d3139a3bcea@github.com>
Message-ID: <nenVi54AMnNcz6LIxlReZDol8OrHa4Tr_ZElM_5GuLg=.06bd35ec-05c9-428a-81de-ca51a8b0c8c7@github.com>

> 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: <dmXlSTQsebbSNxR6_15v8xaaLA3EkFRJWq1HxIcV2_Q=.3e54a5b1-381a-42ee-bdd8-1e12c7d0a95f@github.com>
References: <VZFLWY4KTWeONXFl3KtGm36yMl-hycd6W5drW3adC6o=.9b9b7045-8c25-448c-87b7-4d3139a3bcea@github.com>
 <BpafR4x9bJsPyH0Tj7u8hoWzX8H7BMDWYQGFMJT4-tg=.7a8b0979-d058-4e1e-ba0c-5d8473d1912b@github.com>
 <RgR4f2yTBtMpvLBE9P1-RomyFdYeKy1gSQABk6gRAZo=.285e4674-1811-4b2f-8355-59279155397d@github.com>
 <aImAKeZeaYkt6RalA3LOuJABA5EvS815xtBBG_9XyCc=.b4021a24-b0cf-4b84-b877-1fdae93a16f9@github.com>
 <fmzVc05XnOv6cH86vKklb4uoBYoHlrj6yfVlAbzsoq0=.eaf1256e-3072-4879-b199-3e549173f67a@github.com>
 <dmXlSTQsebbSNxR6_15v8xaaLA3EkFRJWq1HxIcV2_Q=.3e54a5b1-381a-42ee-bdd8-1e12c7d0a95f@github.com>
Message-ID: <eRdn5f1IFEQZRRN4kgWCyheh6Dzvv9i1m6xIRXZTux8=.8e5bb99a-2956-4bca-bacb-bc71d541f227@github.com>

On Thu, 7 Jan 2021 09:33:01 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> 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: <nenVi54AMnNcz6LIxlReZDol8OrHa4Tr_ZElM_5GuLg=.06bd35ec-05c9-428a-81de-ca51a8b0c8c7@github.com>
References: <VZFLWY4KTWeONXFl3KtGm36yMl-hycd6W5drW3adC6o=.9b9b7045-8c25-448c-87b7-4d3139a3bcea@github.com>
 <nenVi54AMnNcz6LIxlReZDol8OrHa4Tr_ZElM_5GuLg=.06bd35ec-05c9-428a-81de-ca51a8b0c8c7@github.com>
Message-ID: <d2mZdAV-ZvHVqDXnihBauCZAbo9qxXMRNYMamTkeGhA=.935a34f7-5e1f-4dc0-9439-58bb10a993b0@github.com>

On Thu, 7 Jan 2021 19:25:25 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> 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: <d2mZdAV-ZvHVqDXnihBauCZAbo9qxXMRNYMamTkeGhA=.935a34f7-5e1f-4dc0-9439-58bb10a993b0@github.com>
References: <VZFLWY4KTWeONXFl3KtGm36yMl-hycd6W5drW3adC6o=.9b9b7045-8c25-448c-87b7-4d3139a3bcea@github.com>
 <nenVi54AMnNcz6LIxlReZDol8OrHa4Tr_ZElM_5GuLg=.06bd35ec-05c9-428a-81de-ca51a8b0c8c7@github.com>
 <d2mZdAV-ZvHVqDXnihBauCZAbo9qxXMRNYMamTkeGhA=.935a34f7-5e1f-4dc0-9439-58bb10a993b0@github.com>
Message-ID: <f-OARH_dRobOEYhLeZgCRwktgg0HPP49rpRvw09gZNo=.ec6d96a7-3667-4d58-a7d0-06dc100b6560@github.com>

On Thu, 7 Jan 2021 20:02:17 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <f-OARH_dRobOEYhLeZgCRwktgg0HPP49rpRvw09gZNo=.ec6d96a7-3667-4d58-a7d0-06dc100b6560@github.com>
References: <VZFLWY4KTWeONXFl3KtGm36yMl-hycd6W5drW3adC6o=.9b9b7045-8c25-448c-87b7-4d3139a3bcea@github.com>
 <nenVi54AMnNcz6LIxlReZDol8OrHa4Tr_ZElM_5GuLg=.06bd35ec-05c9-428a-81de-ca51a8b0c8c7@github.com>
 <d2mZdAV-ZvHVqDXnihBauCZAbo9qxXMRNYMamTkeGhA=.935a34f7-5e1f-4dc0-9439-58bb10a993b0@github.com>
 <f-OARH_dRobOEYhLeZgCRwktgg0HPP49rpRvw09gZNo=.ec6d96a7-3667-4d58-a7d0-06dc100b6560@github.com>
Message-ID: <nWJjlt07EPG6A_278MFFflfOdvABQUBsyHMHgbnMRoc=.2ca590e3-4809-4c52-bfbd-08eac1aad0ba@github.com>

On Thu, 7 Jan 2021 20:04:09 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <jFnlMs4qQIaFOyGGEyhtDoHGygymRGyg7lQpkkGLfvw=.cc91bc76-7f0b-4888-9397-2da96fd2bed4@github.com>
References: <hOACZI1gDqFXrhSdsX8SBB8QkgN2AqHvc0HNOiFV5z0=.6ffe7c79-4fea-4896-8d20-33b99c0cba11@github.com>
 <jFnlMs4qQIaFOyGGEyhtDoHGygymRGyg7lQpkkGLfvw=.cc91bc76-7f0b-4888-9397-2da96fd2bed4@github.com>
Message-ID: <oIgCkwe-1HugVvJsTC27oc_UgJ_l7-ASmdkwRzDgjQk=.2864dcba-189e-4db3-900e-3160279ffe57@github.com>

On Thu, 7 Jan 2021 19:05:48 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@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!

-------------

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: <oIgCkwe-1HugVvJsTC27oc_UgJ_l7-ASmdkwRzDgjQk=.2864dcba-189e-4db3-900e-3160279ffe57@github.com>
References: <hOACZI1gDqFXrhSdsX8SBB8QkgN2AqHvc0HNOiFV5z0=.6ffe7c79-4fea-4896-8d20-33b99c0cba11@github.com>
 <jFnlMs4qQIaFOyGGEyhtDoHGygymRGyg7lQpkkGLfvw=.cc91bc76-7f0b-4888-9397-2da96fd2bed4@github.com>
 <oIgCkwe-1HugVvJsTC27oc_UgJ_l7-ASmdkwRzDgjQk=.2864dcba-189e-4db3-900e-3160279ffe57@github.com>
Message-ID: <_KyFN3um0BM8uHCiq3EOmBAkq-KnQcjtj5bO0IuDLBY=.293e1b40-9afe-4db9-94ee-30ae0bfc46ed@github.com>

On Thu, 7 Jan 2021 20:22:46 GMT, Coleen Phillimore <coleenp at openjdk.org> 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: <VZFLWY4KTWeONXFl3KtGm36yMl-hycd6W5drW3adC6o=.9b9b7045-8c25-448c-87b7-4d3139a3bcea@github.com>
References: <VZFLWY4KTWeONXFl3KtGm36yMl-hycd6W5drW3adC6o=.9b9b7045-8c25-448c-87b7-4d3139a3bcea@github.com>
Message-ID: <MST3pgTejlEF3SDt8putffoE-1EOWDYPblCW_tRBz9g=.be1031ab-afe6-4a27-88b6-c0a074764b0b@github.com>

On Mon, 14 Dec 2020 12:35:07 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> 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 <rcastanedalo at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
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: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
Message-ID: <miGttnjAmZ7WRrNW0gP-GsvV6Y0-eEq9tjE5QE-BFYY=.0f6e230c-bd98-4031-8b50-ded6979484e1@github.com>

On Thu, 7 Jan 2021 18:43:51 GMT, Igor Veresov <iveresov at openjdk.org> 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: <f3f091f6-941d-edda-32d7-5617771c30d2@redhat.com>
References: <BB58CAF2-760C-4336-98E7-5997F8EFE7E3@amazon.com>
 <AM4PR02MB31381552DDD7046390A7FF698AAF0@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <f3f091f6-941d-edda-32d7-5617771c30d2@redhat.com>
Message-ID: <MN2PR11MB355095B9CD313A3015F06890EFAF0@MN2PR11MB3550.namprd11.prod.outlook.com>

Thanks so much!

Best Regards,
Sandhya

-----Original Message-----
From: Andrew Haley <aph at redhat.com> 
Sent: Thursday, January 07, 2021 7:49 AM
To: Langer, Christoph <christoph.langer at sap.com>; Hohensee, Paul <hohensee at amazon.com>; Florian Weimer <fweimer at redhat.com>
Cc: Doerr, Martin <martin.doerr at sap.com>; Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Vladimir Kozlov <vladimir.kozlov at oracle.com>; 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://www.redhat.com> 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: <miGttnjAmZ7WRrNW0gP-GsvV6Y0-eEq9tjE5QE-BFYY=.0f6e230c-bd98-4031-8b50-ded6979484e1@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <miGttnjAmZ7WRrNW0gP-GsvV6Y0-eEq9tjE5QE-BFYY=.0f6e230c-bd98-4031-8b50-ded6979484e1@github.com>
Message-ID: <EY-sSxbCcrPyCiQf4-YhUWyacQGhTIA8UXt4KkqS8qM=.20c2e5f8-cda2-4359-a92a-671f4a99cc1b@github.com>

On Thu, 7 Jan 2021 20:50:50 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
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: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com>
Message-ID: <rq_mKqykvATt3DwDZJQ4KlRjerCdJt24wR37O2flkzg=.bc33b896-a877-46bc-a872-3930c08b5da4@github.com>

On Thu, 7 Jan 2021 21:35:10 GMT, Igor Veresov <iveresov at openjdk.org> 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: <EY-sSxbCcrPyCiQf4-YhUWyacQGhTIA8UXt4KkqS8qM=.20c2e5f8-cda2-4359-a92a-671f4a99cc1b@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <miGttnjAmZ7WRrNW0gP-GsvV6Y0-eEq9tjE5QE-BFYY=.0f6e230c-bd98-4031-8b50-ded6979484e1@github.com>
 <EY-sSxbCcrPyCiQf4-YhUWyacQGhTIA8UXt4KkqS8qM=.20c2e5f8-cda2-4359-a92a-671f4a99cc1b@github.com>
Message-ID: <1-LylT7vEKyn34M0hmOfrMckVgNK02PaHVy19Mgc_3M=.abfaf6e0-4b16-48d7-a51d-acfe4f87c95c@github.com>

On Thu, 7 Jan 2021 21:29:32 GMT, Igor Veresov <iveresov at openjdk.org> 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: <hOACZI1gDqFXrhSdsX8SBB8QkgN2AqHvc0HNOiFV5z0=.6ffe7c79-4fea-4896-8d20-33b99c0cba11@github.com>
 <jFnlMs4qQIaFOyGGEyhtDoHGygymRGyg7lQpkkGLfvw=.cc91bc76-7f0b-4888-9397-2da96fd2bed4@github.com>
 <oIgCkwe-1HugVvJsTC27oc_UgJ_l7-ASmdkwRzDgjQk=.2864dcba-189e-4db3-900e-3160279ffe57@github.com>
 <_KyFN3um0BM8uHCiq3EOmBAkq-KnQcjtj5bO0IuDLBY=.293e1b40-9afe-4db9-94ee-30ae0bfc46ed@github.com>
Message-ID: <Ja6bKhRGJ85D68bCa6djjbWiBDzqwh9PSC-3hD3r3sE=.2fc1babe-0de2-4f62-bcb7-a1f56a545521@github.com>

On Thu, 7 Jan 2021 20:42:52 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <Ja6bKhRGJ85D68bCa6djjbWiBDzqwh9PSC-3hD3r3sE=.2fc1babe-0de2-4f62-bcb7-a1f56a545521@github.com>
References: <hOACZI1gDqFXrhSdsX8SBB8QkgN2AqHvc0HNOiFV5z0=.6ffe7c79-4fea-4896-8d20-33b99c0cba11@github.com>
 <jFnlMs4qQIaFOyGGEyhtDoHGygymRGyg7lQpkkGLfvw=.cc91bc76-7f0b-4888-9397-2da96fd2bed4@github.com>
 <oIgCkwe-1HugVvJsTC27oc_UgJ_l7-ASmdkwRzDgjQk=.2864dcba-189e-4db3-900e-3160279ffe57@github.com>
 <_KyFN3um0BM8uHCiq3EOmBAkq-KnQcjtj5bO0IuDLBY=.293e1b40-9afe-4db9-94ee-30ae0bfc46ed@github.com>
 <Ja6bKhRGJ85D68bCa6djjbWiBDzqwh9PSC-3hD3r3sE=.2fc1babe-0de2-4f62-bcb7-a1f56a545521@github.com>
Message-ID: <wgMx9vPqkDUmW94HpSQCFRnf6OqSWfJfyEK19B6fFZs=.60889f82-9105-4906-a6ce-10565ad4de3b@github.com>

On Thu, 7 Jan 2021 22:14:39 GMT, Coleen Phillimore <coleenp at openjdk.org> 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: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
Message-ID: <vh3G4IDD_KXAnpsCcdK6RbFN60Oe0Tvr29vnRfF2nr8=.d7bf39b5-a33f-428f-9e58-e23a1abece75@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 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: <wgMx9vPqkDUmW94HpSQCFRnf6OqSWfJfyEK19B6fFZs=.60889f82-9105-4906-a6ce-10565ad4de3b@github.com>
References: <hOACZI1gDqFXrhSdsX8SBB8QkgN2AqHvc0HNOiFV5z0=.6ffe7c79-4fea-4896-8d20-33b99c0cba11@github.com>
 <jFnlMs4qQIaFOyGGEyhtDoHGygymRGyg7lQpkkGLfvw=.cc91bc76-7f0b-4888-9397-2da96fd2bed4@github.com>
 <oIgCkwe-1HugVvJsTC27oc_UgJ_l7-ASmdkwRzDgjQk=.2864dcba-189e-4db3-900e-3160279ffe57@github.com>
 <_KyFN3um0BM8uHCiq3EOmBAkq-KnQcjtj5bO0IuDLBY=.293e1b40-9afe-4db9-94ee-30ae0bfc46ed@github.com>
 <Ja6bKhRGJ85D68bCa6djjbWiBDzqwh9PSC-3hD3r3sE=.2fc1babe-0de2-4f62-bcb7-a1f56a545521@github.com>
 <wgMx9vPqkDUmW94HpSQCFRnf6OqSWfJfyEK19B6fFZs=.60889f82-9105-4906-a6ce-10565ad4de3b@github.com>
Message-ID: <U5VL6AyJF6M0Hz2X1yw8ZUHOpQvGd6896E-qOky5N-U=.90cfd0fd-e87f-4a71-89db-fbcf856df790@github.com>

On Thu, 7 Jan 2021 22:23:48 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <hOACZI1gDqFXrhSdsX8SBB8QkgN2AqHvc0HNOiFV5z0=.6ffe7c79-4fea-4896-8d20-33b99c0cba11@github.com>
References: <hOACZI1gDqFXrhSdsX8SBB8QkgN2AqHvc0HNOiFV5z0=.6ffe7c79-4fea-4896-8d20-33b99c0cba11@github.com>
Message-ID: <0QmW9zz6iBIsqnmo2lTZs5FjmRt9DPXYng6DT1Pb_f0=.e994d988-8479-44e2-852e-7bc90e15c58a@github.com>

On Thu, 7 Jan 2021 18:26:26 GMT, Coleen Phillimore <coleenp at openjdk.org> 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 <coleenp at openjdk.org>
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: <Fhb2WqqPcTDgy1QcnOkBLnxcs6VSFRCaoXRqikGdTG8=.877263e9-89d1-40f9-97d8-fa34e3b1a5b5@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
 <RNU-tanbO6-6vkeQ8yVg2mAa0yzWgCAw3kI5uO8iFow=.7ea55a0f-f60e-4c80-b390-8b990536bde4@github.com>
 <Fhb2WqqPcTDgy1QcnOkBLnxcs6VSFRCaoXRqikGdTG8=.877263e9-89d1-40f9-97d8-fa34e3b1a5b5@github.com>
Message-ID: <HuI3DwGPJGEFs05jSCPMRFSAM1hRnOWiLrrfveFDGus=.0faf16b5-b9a1-4322-8164-83028a21d9fa@github.com>

On Wed, 6 Jan 2021 10:04:45 GMT, Andrew Haley <aph at openjdk.org> 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: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
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: <rq_mKqykvATt3DwDZJQ4KlRjerCdJt24wR37O2flkzg=.bc33b896-a877-46bc-a872-3930c08b5da4@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com>
 <rq_mKqykvATt3DwDZJQ4KlRjerCdJt24wR37O2flkzg=.bc33b896-a877-46bc-a872-3930c08b5da4@github.com>
Message-ID: <aGYYIAEkHrorfDjBKSyAdZX71pQopwgXCdSLPtexAjA=.c50f6d27-2212-4012-9168-d93aaff1f58b@github.com>

On Thu, 7 Jan 2021 21:49:56 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <aGYYIAEkHrorfDjBKSyAdZX71pQopwgXCdSLPtexAjA=.c50f6d27-2212-4012-9168-d93aaff1f58b@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com>
 <rq_mKqykvATt3DwDZJQ4KlRjerCdJt24wR37O2flkzg=.bc33b896-a877-46bc-a872-3930c08b5da4@github.com>
 <aGYYIAEkHrorfDjBKSyAdZX71pQopwgXCdSLPtexAjA=.c50f6d27-2212-4012-9168-d93aaff1f58b@github.com>
Message-ID: <zGV0C5nyMJCwfiLX_iWRMXdlrmsnpGhVZ3VM1RDI4vw=.487b4590-f41f-44ed-8b6f-5ca39df541f0@github.com>

On Fri, 8 Jan 2021 06:07:23 GMT, Igor Veresov <iveresov at openjdk.org> 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: <urfdDMSaLblAhKDpN9xzeI1Bu-bq5dMUTrR69s-Ijvo=.442a09a2-c461-45b1-9f63-0083836ea3d9@github.com>
References: <urfdDMSaLblAhKDpN9xzeI1Bu-bq5dMUTrR69s-Ijvo=.442a09a2-c461-45b1-9f63-0083836ea3d9@github.com>
Message-ID: <ZUtY7HM-zBAQDA9ZInmcu6VFNtBFzq4IN5lYUXCfpz4=.3cfefcc2-37fd-44d1-90c4-1a6fd1a2b777@github.com>

On Thu, 7 Jan 2021 08:07:16 GMT, Eric Liu <github.com+10482586+theRealELiu at openjdk.org> 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: <urfdDMSaLblAhKDpN9xzeI1Bu-bq5dMUTrR69s-Ijvo=.442a09a2-c461-45b1-9f63-0083836ea3d9@github.com>
References: <urfdDMSaLblAhKDpN9xzeI1Bu-bq5dMUTrR69s-Ijvo=.442a09a2-c461-45b1-9f63-0083836ea3d9@github.com>
Message-ID: <Hpy0wycBa9R5-OQ_0ti6Y6J3--VpoYUN0UbODVteGU4=.ec58c5cb-9b5b-4851-b2f9-959e3a675ed5@github.com>

On Thu, 7 Jan 2021 08:07:16 GMT, Eric Liu <github.com+10482586+theRealELiu at openjdk.org> 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: <Hpy0wycBa9R5-OQ_0ti6Y6J3--VpoYUN0UbODVteGU4=.ec58c5cb-9b5b-4851-b2f9-959e3a675ed5@github.com>
References: <urfdDMSaLblAhKDpN9xzeI1Bu-bq5dMUTrR69s-Ijvo=.442a09a2-c461-45b1-9f63-0083836ea3d9@github.com>
 <Hpy0wycBa9R5-OQ_0ti6Y6J3--VpoYUN0UbODVteGU4=.ec58c5cb-9b5b-4851-b2f9-959e3a675ed5@github.com>
Message-ID: <bpqpCSsQrOmnJAKMHrwwxLoBZ0X5NgoTPLKjxUOpaiI=.e7571619-7daf-470c-a664-c1695b13cfae@github.com>

On Fri, 8 Jan 2021 08:46:18 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <bpqpCSsQrOmnJAKMHrwwxLoBZ0X5NgoTPLKjxUOpaiI=.e7571619-7daf-470c-a664-c1695b13cfae@github.com>
References: <urfdDMSaLblAhKDpN9xzeI1Bu-bq5dMUTrR69s-Ijvo=.442a09a2-c461-45b1-9f63-0083836ea3d9@github.com>
 <Hpy0wycBa9R5-OQ_0ti6Y6J3--VpoYUN0UbODVteGU4=.ec58c5cb-9b5b-4851-b2f9-959e3a675ed5@github.com>
 <bpqpCSsQrOmnJAKMHrwwxLoBZ0X5NgoTPLKjxUOpaiI=.e7571619-7daf-470c-a664-c1695b13cfae@github.com>
Message-ID: <Jf1kSpMpzqanGbsLR8vAclhG3a0xD7oAayedxFF2bQI=.6ce2e4e8-37ce-4ac7-bde2-83633f38c9ba@github.com>

On Fri, 8 Jan 2021 09:17:35 GMT, Claes Redestad <redestad at openjdk.org> 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: <HuI3DwGPJGEFs05jSCPMRFSAM1hRnOWiLrrfveFDGus=.0faf16b5-b9a1-4322-8164-83028a21d9fa@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
 <RNU-tanbO6-6vkeQ8yVg2mAa0yzWgCAw3kI5uO8iFow=.7ea55a0f-f60e-4c80-b390-8b990536bde4@github.com>
 <Fhb2WqqPcTDgy1QcnOkBLnxcs6VSFRCaoXRqikGdTG8=.877263e9-89d1-40f9-97d8-fa34e3b1a5b5@github.com>
 <HuI3DwGPJGEFs05jSCPMRFSAM1hRnOWiLrrfveFDGus=.0faf16b5-b9a1-4322-8164-83028a21d9fa@github.com>
Message-ID: <I7XO4pCkMJ9dHmlUmuncys81pmVAjwXklQHQfeqKFrU=.6b730bf4-ecdd-4c38-8fd8-fa10985cd2e2@github.com>

On Fri, 8 Jan 2021 02:51:19 GMT, Dong Bo <dongbo at openjdk.org> 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: <hjtZFzv4qJ3K7fnPPw47WMFynSi_xdhL1GlPMH7Z2Ag=.1f2fa05b-7eca-4f19-a8c4-5bdb4b5ad98b@github.com>

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: <hjtZFzv4qJ3K7fnPPw47WMFynSi_xdhL1GlPMH7Z2Ag=.1f2fa05b-7eca-4f19-a8c4-5bdb4b5ad98b@github.com>
References: <hjtZFzv4qJ3K7fnPPw47WMFynSi_xdhL1GlPMH7Z2Ag=.1f2fa05b-7eca-4f19-a8c4-5bdb4b5ad98b@github.com>
Message-ID: <HXyFuw8ptgNeQJT36PWxQ0duerJ7qz7xVDCHVAuoiYc=.cb4447e6-76a9-4773-bd37-8382f64fd42e@github.com>

On Fri, 8 Jan 2021 10:41:53 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <HXyFuw8ptgNeQJT36PWxQ0duerJ7qz7xVDCHVAuoiYc=.cb4447e6-76a9-4773-bd37-8382f64fd42e@github.com>
References: <hjtZFzv4qJ3K7fnPPw47WMFynSi_xdhL1GlPMH7Z2Ag=.1f2fa05b-7eca-4f19-a8c4-5bdb4b5ad98b@github.com>
 <HXyFuw8ptgNeQJT36PWxQ0duerJ7qz7xVDCHVAuoiYc=.cb4447e6-76a9-4773-bd37-8382f64fd42e@github.com>
Message-ID: <00aN34Yz__9sHMY6Svx6YV6mT_yrPCKwJrhSefKmP94=.a5c4b1e3-e09d-4048-831d-6565fb107cf6@github.com>

On Fri, 8 Jan 2021 10:47:58 GMT, Claes Redestad <redestad at openjdk.org> 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: <sfBwyWjAeN-MqY0z0rXFCDNjJQT25xbOCOTobS4hlWM=.1204006d-5f38-4edd-8d31-e8e7c0465261@github.com>

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: <SytAhXaavvmtXCek4iNOyjBuBA36VI6XT-KDLykilZE=.847a4f9b-078b-4800-a184-145a1e88f81e@github.com>
References: <SytAhXaavvmtXCek4iNOyjBuBA36VI6XT-KDLykilZE=.847a4f9b-078b-4800-a184-145a1e88f81e@github.com>
Message-ID: <RdCTGduMwgI8-pEVr7uVgMNZ6zjjDAiiFAWOCnbol9E=.16403447-cbd9-435b-916c-95fb3ee319c9@github.com>

On Mon, 21 Dec 2020 16:44:39 GMT, Eric Caspole <ecaspole at openjdk.org> 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 <ecaspole at openjdk.org>
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: <X5GnkHCqy99Q3C1HvhilvglCCdCEoy1dFWgnIbSpMMk=.3c47249e-c712-4cff-9ef7-e075977e40f5@github.com>
References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com>
 <08g7HiFIZyPHlhan7KLe4_w9_BGQZPpnoDxtnzraj_s=.161392a6-49d6-4d40-9b56-cb188bafad82@github.com>
 <X5GnkHCqy99Q3C1HvhilvglCCdCEoy1dFWgnIbSpMMk=.3c47249e-c712-4cff-9ef7-e075977e40f5@github.com>
Message-ID: <FkHxgZBG47EANdjrVUki6H09F_7EXMECjh82T4sK_fY=.bf99e038-d2f9-4e65-a34e-55fc602def5c@github.com>

On Wed, 6 Jan 2021 09:30:37 GMT, Xin Liu <xliu at openjdk.org> 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: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
Message-ID: <C2bH7RQyDHC685l4SUNJAU5bcw2Jc3XSS-HWv1XM1ro=.b6a5b837-5407-4cfe-8b5e-deec5ba5f6b0@github.com>

> _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: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
Message-ID: <xIwCoK2BoOXjGIDv5_Ay-Jl2UpSBfAT5YgOCEF5giLw=.47e6b767-89c7-4bd5-9f3a-d846e1973f54@github.com>

> _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: <sfBwyWjAeN-MqY0z0rXFCDNjJQT25xbOCOTobS4hlWM=.1204006d-5f38-4edd-8d31-e8e7c0465261@github.com>
References: <sfBwyWjAeN-MqY0z0rXFCDNjJQT25xbOCOTobS4hlWM=.1204006d-5f38-4edd-8d31-e8e7c0465261@github.com>
Message-ID: <0F8hu5pvEnGAS2HLvaVkjGsHqsEcF7pJS9tSwMZswfs=.b065032e-24a8-4532-9396-43ae1e7beb01@github.com>

On Fri, 8 Jan 2021 14:05:32 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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: <yRxMEs06nCUrwkzxnzAt3TT8EIFMC_5wCQN3iIaXEtI=.c0f6ebe9-6699-4f9a-a627-3c04cd32a92f@github.com>

> 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: <I7XO4pCkMJ9dHmlUmuncys81pmVAjwXklQHQfeqKFrU=.6b730bf4-ecdd-4c38-8fd8-fa10985cd2e2@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
 <RNU-tanbO6-6vkeQ8yVg2mAa0yzWgCAw3kI5uO8iFow=.7ea55a0f-f60e-4c80-b390-8b990536bde4@github.com>
 <Fhb2WqqPcTDgy1QcnOkBLnxcs6VSFRCaoXRqikGdTG8=.877263e9-89d1-40f9-97d8-fa34e3b1a5b5@github.com>
 <HuI3DwGPJGEFs05jSCPMRFSAM1hRnOWiLrrfveFDGus=.0faf16b5-b9a1-4322-8164-83028a21d9fa@github.com>
 <I7XO4pCkMJ9dHmlUmuncys81pmVAjwXklQHQfeqKFrU=.6b730bf4-ecdd-4c38-8fd8-fa10985cd2e2@github.com>
Message-ID: <SZi-GTZ3FJlhP8V0cxSc3YQVdZKf86GmiiSjF9kD4Ic=.8a62099b-1db4-421d-b25f-75b8345f7e17@github.com>

On Fri, 8 Jan 2021 09:52:02 GMT, Andrew Haley <aph at openjdk.org> 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: <aGYYIAEkHrorfDjBKSyAdZX71pQopwgXCdSLPtexAjA=.c50f6d27-2212-4012-9168-d93aaff1f58b@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com>
 <rq_mKqykvATt3DwDZJQ4KlRjerCdJt24wR37O2flkzg=.bc33b896-a877-46bc-a872-3930c08b5da4@github.com>
 <aGYYIAEkHrorfDjBKSyAdZX71pQopwgXCdSLPtexAjA=.c50f6d27-2212-4012-9168-d93aaff1f58b@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 <cjplummer at openjdk.org> 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: <zGV0C5nyMJCwfiLX_iWRMXdlrmsnpGhVZ3VM1RDI4vw=.487b4590-f41f-44ed-8b6f-5ca39df541f0@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com>
 <rq_mKqykvATt3DwDZJQ4KlRjerCdJt24wR37O2flkzg=.bc33b896-a877-46bc-a872-3930c08b5da4@github.com>
 <aGYYIAEkHrorfDjBKSyAdZX71pQopwgXCdSLPtexAjA=.c50f6d27-2212-4012-9168-d93aaff1f58b@github.com>
 <zGV0C5nyMJCwfiLX_iWRMXdlrmsnpGhVZ3VM1RDI4vw=.487b4590-f41f-44ed-8b6f-5ca39df541f0@github.com>
Message-ID: <vT4UGUi5Doh7b8OJCorIuyEoCpF_ZC5iPkZJSTFGs0c=.ca08c62b-45dc-41b0-b83e-276825fb23ed@github.com>

On Fri, 8 Jan 2021 06:29:10 GMT, Igor Veresov <iveresov at openjdk.org> 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 <cjplummer at openjdk.org> 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: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
Message-ID: <zsH2XrvqhaXZq21mY10b-t3FzC1vR6icJZVgu8hH4uk=.fb1b1c19-d0c3-4bde-ad33-64a8081cddd0@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:

  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: <SZi-GTZ3FJlhP8V0cxSc3YQVdZKf86GmiiSjF9kD4Ic=.8a62099b-1db4-421d-b25f-75b8345f7e17@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
 <RNU-tanbO6-6vkeQ8yVg2mAa0yzWgCAw3kI5uO8iFow=.7ea55a0f-f60e-4c80-b390-8b990536bde4@github.com>
 <Fhb2WqqPcTDgy1QcnOkBLnxcs6VSFRCaoXRqikGdTG8=.877263e9-89d1-40f9-97d8-fa34e3b1a5b5@github.com>
 <HuI3DwGPJGEFs05jSCPMRFSAM1hRnOWiLrrfveFDGus=.0faf16b5-b9a1-4322-8164-83028a21d9fa@github.com>
 <I7XO4pCkMJ9dHmlUmuncys81pmVAjwXklQHQfeqKFrU=.6b730bf4-ecdd-4c38-8fd8-fa10985cd2e2@github.com>
 <SZi-GTZ3FJlhP8V0cxSc3YQVdZKf86GmiiSjF9kD4Ic=.8a62099b-1db4-421d-b25f-75b8345f7e17@github.com>
Message-ID: <RNoz4RhHWJxtO4QSAJLXIZjVShQRSckAoPmH_t9NgGY=.a08b176b-8597-448e-b43b-3fd94d625ecb@github.com>

On Sat, 9 Jan 2021 08:13:45 GMT, Dong Bo <dongbo at openjdk.org> 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: <Xp_wGLLFFktMY7SIicwQ7zTe0psd_b4m5RzgJudBe3E=.dca99446-f282-4891-95d2-45c75d9df797@github.com>
 <9XtCnqp4eKcBDXlXSm18R6tUIH9mCPZUZJE3Htio2Bs=.606bf77d-fec8-434a-b1e9-6cb5484605a1@github.com>
 <4wsrcJIZMSQcI-bEYswi7vI4MznlHMCuYkxCFjzY6S4=.ec088b95-496c-4ecc-98a7-e239c7247348@github.com>
Message-ID: <YmBZiWiQYmLzlq3hP0nYE-1kUHr21IJwm_uIbT3xjVs=.17d02c97-ca40-4d4b-a9ed-c064c18c9728@github.com>

On Tue, 5 Jan 2021 10:40:11 GMT, Andrew Dinn <adinn at openjdk.org> 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: <hjtZFzv4qJ3K7fnPPw47WMFynSi_xdhL1GlPMH7Z2Ag=.1f2fa05b-7eca-4f19-a8c4-5bdb4b5ad98b@github.com>
References: <hjtZFzv4qJ3K7fnPPw47WMFynSi_xdhL1GlPMH7Z2Ag=.1f2fa05b-7eca-4f19-a8c4-5bdb4b5ad98b@github.com>
Message-ID: <_OtqO7HALzAeQ5AfDK76Xb5kMxwER_GjCSeU3p_u7yY=.9b6cda80-55bb-4511-9f7b-2a2d055db240@github.com>

On Fri, 8 Jan 2021 10:41:53 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <sfBwyWjAeN-MqY0z0rXFCDNjJQT25xbOCOTobS4hlWM=.1204006d-5f38-4edd-8d31-e8e7c0465261@github.com>
References: <sfBwyWjAeN-MqY0z0rXFCDNjJQT25xbOCOTobS4hlWM=.1204006d-5f38-4edd-8d31-e8e7c0465261@github.com>
Message-ID: <9x0eWUjv2v7GUzCoNH8wlwG5TjnEqp4dSQtYJUR8AXk=.589a6669-4d51-4bf8-954c-a8f2a3949fe2@github.com>

On Fri, 8 Jan 2021 14:05:32 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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: <YmBZiWiQYmLzlq3hP0nYE-1kUHr21IJwm_uIbT3xjVs=.17d02c97-ca40-4d4b-a9ed-c064c18c9728@github.com>
References: <Xp_wGLLFFktMY7SIicwQ7zTe0psd_b4m5RzgJudBe3E=.dca99446-f282-4891-95d2-45c75d9df797@github.com>
 <9XtCnqp4eKcBDXlXSm18R6tUIH9mCPZUZJE3Htio2Bs=.606bf77d-fec8-434a-b1e9-6cb5484605a1@github.com>
 <4wsrcJIZMSQcI-bEYswi7vI4MznlHMCuYkxCFjzY6S4=.ec088b95-496c-4ecc-98a7-e239c7247348@github.com>
 <YmBZiWiQYmLzlq3hP0nYE-1kUHr21IJwm_uIbT3xjVs=.17d02c97-ca40-4d4b-a9ed-c064c18c9728@github.com>
Message-ID: <GSu_BH9j97MSs-A4p1J3pESGy2pxp2tQhE8uiXYwq_A=.4f66ed1c-e26f-4d22-a08e-c1891f7dae20@github.com>

On Mon, 11 Jan 2021 06:39:27 GMT, Thomas Stuefe <stuefe at openjdk.org> 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: <Xp_wGLLFFktMY7SIicwQ7zTe0psd_b4m5RzgJudBe3E=.dca99446-f282-4891-95d2-45c75d9df797@github.com>
References: <Xp_wGLLFFktMY7SIicwQ7zTe0psd_b4m5RzgJudBe3E=.dca99446-f282-4891-95d2-45c75d9df797@github.com>
Message-ID: <y3l6ZBCuBDkwExPn5W745p0z8mzTsX7cT5_XaVBMSfs=.8003403e-86bd-4451-bf2b-d06b3c1c8c37@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:

  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: <Xp_wGLLFFktMY7SIicwQ7zTe0psd_b4m5RzgJudBe3E=.dca99446-f282-4891-95d2-45c75d9df797@github.com>
 <9XtCnqp4eKcBDXlXSm18R6tUIH9mCPZUZJE3Htio2Bs=.606bf77d-fec8-434a-b1e9-6cb5484605a1@github.com>
 <4wsrcJIZMSQcI-bEYswi7vI4MznlHMCuYkxCFjzY6S4=.ec088b95-496c-4ecc-98a7-e239c7247348@github.com>
Message-ID: <SVX1cEHwWBdgjQWkNO9gIsmAhmF75DGeHTwsP_LFz8o=.cb0d9380-7dc0-4b55-a026-fab04e86aac6@github.com>

On Tue, 5 Jan 2021 10:40:11 GMT, Andrew Dinn <adinn at openjdk.org> 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: <hjtZFzv4qJ3K7fnPPw47WMFynSi_xdhL1GlPMH7Z2Ag=.1f2fa05b-7eca-4f19-a8c4-5bdb4b5ad98b@github.com>
References: <hjtZFzv4qJ3K7fnPPw47WMFynSi_xdhL1GlPMH7Z2Ag=.1f2fa05b-7eca-4f19-a8c4-5bdb4b5ad98b@github.com>
Message-ID: <7nq5DtWtBS2Oi5UDTYXfj9roMD3-GX0VzwbGwFGMZWY=.716a5d06-422e-4dbe-aa08-7e5809433ef2@github.com>

On Fri, 8 Jan 2021 10:41:53 GMT, Aleksey Shipilev <shade at openjdk.org> 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 <shade at openjdk.org>
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: <SMI2cdyISFr7B0OoDsvsbsBUW_EpAtKamZCj69FOaAk=.cdca4920-4449-4802-9a48-a5db8ec0bc1f@github.com>
References: <BoDgNONUKJT3nwp_ypzBp_1RstoWYHWkfRuLSP8KLVk=.85a38c36-abcb-4739-ac62-6fa82bd48949@github.com>
 <IegZCc1H7xYjt2Swkph8bDV745uuNgBNFBUryXlB57k=.da9f9ac5-201c-4a03-9540-e108b1d35ca4@github.com>
 <SMI2cdyISFr7B0OoDsvsbsBUW_EpAtKamZCj69FOaAk=.cdca4920-4449-4802-9a48-a5db8ec0bc1f@github.com>
Message-ID: <HpK-ebv17kFlhYMMJUPxopLnAJv1JmL3p5GLC6KRQUQ=.2bf74abd-3054-4660-a07b-dcb0ed0d4307@github.com>

On Tue, 5 Jan 2021 03:17:43 GMT, Wang Huang <whuang at openjdk.org> 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: <BoDgNONUKJT3nwp_ypzBp_1RstoWYHWkfRuLSP8KLVk=.85a38c36-abcb-4739-ac62-6fa82bd48949@github.com>
References: <BoDgNONUKJT3nwp_ypzBp_1RstoWYHWkfRuLSP8KLVk=.85a38c36-abcb-4739-ac62-6fa82bd48949@github.com>
Message-ID: <Y6T9upWtvHg9fjsvUt-9C5hDoi6yiACpnBbQGz8Bk_0=.7565698d-b144-454d-83e4-c6870a29e17f@github.com>

On Mon, 4 Jan 2021 09:37:33 GMT, Wang Huang <whuang at openjdk.org> 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: <sfBwyWjAeN-MqY0z0rXFCDNjJQT25xbOCOTobS4hlWM=.1204006d-5f38-4edd-8d31-e8e7c0465261@github.com>
 <0F8hu5pvEnGAS2HLvaVkjGsHqsEcF7pJS9tSwMZswfs=.b065032e-24a8-4532-9396-43ae1e7beb01@github.com>
Message-ID: <NjbF5SWHYnDjBdZ4cU8_DN6V1qepDPJli952tL0PWfM=.f3adde96-0960-4c40-af7a-32a3090043d9@github.com>

On Fri, 8 Jan 2021 20:40:19 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <I4RxSxGUJbMCCakXI4eFpw0sZubHsB6Xz9gqT09d8MQ=.e6e7e515-fe70-4d46-bf72-3a12718dd980@github.com>
References: <I4RxSxGUJbMCCakXI4eFpw0sZubHsB6Xz9gqT09d8MQ=.e6e7e515-fe70-4d46-bf72-3a12718dd980@github.com>
Message-ID: <iK02ny_b-V8PiaTqK6U0c5SSqWXOk8gRPLXpVoY6sak=.4c63fc78-6a02-4c86-82a0-c84ca4f1d87e@github.com>

On Wed, 30 Dec 2020 09:09:37 GMT, Wang Huang <whuang at openjdk.org> 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: <vh3G4IDD_KXAnpsCcdK6RbFN60Oe0Tvr29vnRfF2nr8=.d7bf39b5-a33f-428f-9e58-e23a1abece75@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <vh3G4IDD_KXAnpsCcdK6RbFN60Oe0Tvr29vnRfF2nr8=.d7bf39b5-a33f-428f-9e58-e23a1abece75@github.com>
Message-ID: <3FqXOR8NSsGbCExqGxRWPfWOrlb0Rpl0bU3Ug__8I8g=.c74bae33-89af-47b5-b02d-6546a9f538a7@github.com>

On Thu, 7 Jan 2021 23:06:19 GMT, Igor Veresov <iveresov at openjdk.org> 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: <vT4UGUi5Doh7b8OJCorIuyEoCpF_ZC5iPkZJSTFGs0c=.ca08c62b-45dc-41b0-b83e-276825fb23ed@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com>
 <rq_mKqykvATt3DwDZJQ4KlRjerCdJt24wR37O2flkzg=.bc33b896-a877-46bc-a872-3930c08b5da4@github.com>
 <aGYYIAEkHrorfDjBKSyAdZX71pQopwgXCdSLPtexAjA=.c50f6d27-2212-4012-9168-d93aaff1f58b@github.com>
 <zGV0C5nyMJCwfiLX_iWRMXdlrmsnpGhVZ3VM1RDI4vw=.487b4590-f41f-44ed-8b6f-5ca39df541f0@github.com>
 <vT4UGUi5Doh7b8OJCorIuyEoCpF_ZC5iPkZJSTFGs0c=.ca08c62b-45dc-41b0-b83e-276825fb23ed@github.com>
Message-ID: <zMla0A1MfEsHLjT7dBYFQK7XPn_11P38mJeOPYAn6q8=.7812318e-fd1a-41c2-8f30-dd947d8e1730@github.com>

On Mon, 11 Jan 2021 02:54:02 GMT, Igor Veresov <iveresov at openjdk.org> 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 <cjplummer at openjdk.org> 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: <hzQDlMgxks1VhmrVQV6mXifje-Qr66wqR8KxsbpNAcM=.005abb6c-ff3b-4925-bb13-7648e767367a@github.com>

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: <y3l6ZBCuBDkwExPn5W745p0z8mzTsX7cT5_XaVBMSfs=.8003403e-86bd-4451-bf2b-d06b3c1c8c37@github.com>
References: <Xp_wGLLFFktMY7SIicwQ7zTe0psd_b4m5RzgJudBe3E=.dca99446-f282-4891-95d2-45c75d9df797@github.com>
 <y3l6ZBCuBDkwExPn5W745p0z8mzTsX7cT5_XaVBMSfs=.8003403e-86bd-4451-bf2b-d06b3c1c8c37@github.com>
Message-ID: <2vNAJAihgpB4q_wqeuf2Dtjbu9X-NpqfXtNMibnOOUc=.f52ed07a-702f-4d8b-9200-46986181e6a1@github.com>

On Mon, 11 Jan 2021 07:30:15 GMT, Ningsheng Jian <njian at openjdk.org> 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: <y3l6ZBCuBDkwExPn5W745p0z8mzTsX7cT5_XaVBMSfs=.8003403e-86bd-4451-bf2b-d06b3c1c8c37@github.com>
References: <Xp_wGLLFFktMY7SIicwQ7zTe0psd_b4m5RzgJudBe3E=.dca99446-f282-4891-95d2-45c75d9df797@github.com>
 <y3l6ZBCuBDkwExPn5W745p0z8mzTsX7cT5_XaVBMSfs=.8003403e-86bd-4451-bf2b-d06b3c1c8c37@github.com>
Message-ID: <ZaZi-5g7wwumWzpEmqnFfl91YfQoeTM0_GiydkaZh4Q=.abbaa25b-a71a-4aa7-95c4-5be42cb301e9@github.com>

On Mon, 11 Jan 2021 07:30:15 GMT, Ningsheng Jian <njian at openjdk.org> 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: <RNoz4RhHWJxtO4QSAJLXIZjVShQRSckAoPmH_t9NgGY=.a08b176b-8597-448e-b43b-3fd94d625ecb@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
 <RNU-tanbO6-6vkeQ8yVg2mAa0yzWgCAw3kI5uO8iFow=.7ea55a0f-f60e-4c80-b390-8b990536bde4@github.com>
 <Fhb2WqqPcTDgy1QcnOkBLnxcs6VSFRCaoXRqikGdTG8=.877263e9-89d1-40f9-97d8-fa34e3b1a5b5@github.com>
 <HuI3DwGPJGEFs05jSCPMRFSAM1hRnOWiLrrfveFDGus=.0faf16b5-b9a1-4322-8164-83028a21d9fa@github.com>
 <I7XO4pCkMJ9dHmlUmuncys81pmVAjwXklQHQfeqKFrU=.6b730bf4-ecdd-4c38-8fd8-fa10985cd2e2@github.com>
 <SZi-GTZ3FJlhP8V0cxSc3YQVdZKf86GmiiSjF9kD4Ic=.8a62099b-1db4-421d-b25f-75b8345f7e17@github.com>
 <RNoz4RhHWJxtO4QSAJLXIZjVShQRSckAoPmH_t9NgGY=.a08b176b-8597-448e-b43b-3fd94d625ecb@github.com>
Message-ID: <uvb6RoVoHhxzCMeCZhcAZC4Vqv5vffxQJ6BVHakm_6A=.a2be6b24-cab4-438d-a2a7-c6ff5d1eb951@github.com>

On Mon, 11 Jan 2021 05:14:05 GMT, Dong Bo <dongbo at openjdk.org> 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: <FS23y5v6Qg0rFlCTz_ejAJR5sJuL98-oVNm-L6V_plE=.99ebe4e1-e204-41a1-8037-b8fff7f674fe@github.com>
References: <FS23y5v6Qg0rFlCTz_ejAJR5sJuL98-oVNm-L6V_plE=.99ebe4e1-e204-41a1-8037-b8fff7f674fe@github.com>
Message-ID: <wtyzV9SSSRmyrddIankukEzYTgN4yDCGMm4XqIbjoj8=.c263cae3-3adf-4ba5-8db6-7e54410aaf4f@github.com>

On Tue, 5 Jan 2021 03:32:44 GMT, Wang Huang <whuang at openjdk.org> 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: <usidfp_4W0O2w-01JwMn2zuy1joN6mQoVUf37Pom_Bo=.4dd5e1ff-c8a5-4ffc-8bde-fe34f887befd@github.com>

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: <usidfp_4W0O2w-01JwMn2zuy1joN6mQoVUf37Pom_Bo=.4dd5e1ff-c8a5-4ffc-8bde-fe34f887befd@github.com>
References: <usidfp_4W0O2w-01JwMn2zuy1joN6mQoVUf37Pom_Bo=.4dd5e1ff-c8a5-4ffc-8bde-fe34f887befd@github.com>
Message-ID: <XOS_GVCj_nLxC32-5a6HfczNxV1vrexe1xjwCawgA5g=.6d3a915b-452e-4477-b574-ec5c13d355eb@github.com>

On Mon, 30 Nov 2020 14:26:23 GMT, Sergey Platonov <github.com+6061213+sergey-platonov at openjdk.org> 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: <XOS_GVCj_nLxC32-5a6HfczNxV1vrexe1xjwCawgA5g=.6d3a915b-452e-4477-b574-ec5c13d355eb@github.com>
References: <usidfp_4W0O2w-01JwMn2zuy1joN6mQoVUf37Pom_Bo=.4dd5e1ff-c8a5-4ffc-8bde-fe34f887befd@github.com>
 <XOS_GVCj_nLxC32-5a6HfczNxV1vrexe1xjwCawgA5g=.6d3a915b-452e-4477-b574-ec5c13d355eb@github.com>
Message-ID: <_AKtHZkLVudBwUR28MyqJ7QNyypJ_piP5cxP0xLhWDU=.5790f40a-e84f-4163-8c4c-eef9a2de5870@github.com>

On Thu, 3 Dec 2020 18:00:29 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <usidfp_4W0O2w-01JwMn2zuy1joN6mQoVUf37Pom_Bo=.4dd5e1ff-c8a5-4ffc-8bde-fe34f887befd@github.com>
 <XOS_GVCj_nLxC32-5a6HfczNxV1vrexe1xjwCawgA5g=.6d3a915b-452e-4477-b574-ec5c13d355eb@github.com>
 <_AKtHZkLVudBwUR28MyqJ7QNyypJ_piP5cxP0xLhWDU=.5790f40a-e84f-4163-8c4c-eef9a2de5870@github.com>
Message-ID: <OpaE7uB1f_SP2pxfob2FWZUc-aeoVSUUWpoFHZyTwEA=.0be91e21-e431-4b7f-933e-9ca3dbf5948b@github.com>

On Mon, 11 Jan 2021 08:33:27 GMT, Sergey Platonov <github.com+6061213+sergey-platonov at openjdk.org> 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: <OpaE7uB1f_SP2pxfob2FWZUc-aeoVSUUWpoFHZyTwEA=.0be91e21-e431-4b7f-933e-9ca3dbf5948b@github.com>
References: <usidfp_4W0O2w-01JwMn2zuy1joN6mQoVUf37Pom_Bo=.4dd5e1ff-c8a5-4ffc-8bde-fe34f887befd@github.com>
 <XOS_GVCj_nLxC32-5a6HfczNxV1vrexe1xjwCawgA5g=.6d3a915b-452e-4477-b574-ec5c13d355eb@github.com>
 <_AKtHZkLVudBwUR28MyqJ7QNyypJ_piP5cxP0xLhWDU=.5790f40a-e84f-4163-8c4c-eef9a2de5870@github.com>
 <OpaE7uB1f_SP2pxfob2FWZUc-aeoVSUUWpoFHZyTwEA=.0be91e21-e431-4b7f-933e-9ca3dbf5948b@github.com>
Message-ID: <QMBCvbGDZjXUBaW3O2MHPQyY_hVlw7ntxO_KZ1is40s=.851f4b40-0522-4f98-b80c-cdcb2f3d2d4f@github.com>

On Mon, 11 Jan 2021 09:40:14 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <QMBCvbGDZjXUBaW3O2MHPQyY_hVlw7ntxO_KZ1is40s=.851f4b40-0522-4f98-b80c-cdcb2f3d2d4f@github.com>
References: <usidfp_4W0O2w-01JwMn2zuy1joN6mQoVUf37Pom_Bo=.4dd5e1ff-c8a5-4ffc-8bde-fe34f887befd@github.com>
 <XOS_GVCj_nLxC32-5a6HfczNxV1vrexe1xjwCawgA5g=.6d3a915b-452e-4477-b574-ec5c13d355eb@github.com>
 <_AKtHZkLVudBwUR28MyqJ7QNyypJ_piP5cxP0xLhWDU=.5790f40a-e84f-4163-8c4c-eef9a2de5870@github.com>
 <OpaE7uB1f_SP2pxfob2FWZUc-aeoVSUUWpoFHZyTwEA=.0be91e21-e431-4b7f-933e-9ca3dbf5948b@github.com>
 <QMBCvbGDZjXUBaW3O2MHPQyY_hVlw7ntxO_KZ1is40s=.851f4b40-0522-4f98-b80c-cdcb2f3d2d4f@github.com>
Message-ID: <cEkkRuzZekvXuDdE196PxSs4ndkTyiPucDUewoUODQk=.60525009-3310-4c7e-a3e5-24e3dc1ffdbb@github.com>

On Mon, 11 Jan 2021 11:12:14 GMT, Sergey Platonov <github.com+6061213+sergey-platonov at openjdk.org> 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: <usidfp_4W0O2w-01JwMn2zuy1joN6mQoVUf37Pom_Bo=.4dd5e1ff-c8a5-4ffc-8bde-fe34f887befd@github.com>
References: <usidfp_4W0O2w-01JwMn2zuy1joN6mQoVUf37Pom_Bo=.4dd5e1ff-c8a5-4ffc-8bde-fe34f887befd@github.com>
Message-ID: <sxUb0oQf_EBJOENP4mhbzHGXKY-MrdMcGA_qEBrmY-I=.a2c1ba0e-1935-427d-a068-d250aaa5cac5@github.com>

On Mon, 30 Nov 2020 14:26:23 GMT, Sergey Platonov <github.com+6061213+sergey-platonov at openjdk.org> 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: <sxUb0oQf_EBJOENP4mhbzHGXKY-MrdMcGA_qEBrmY-I=.a2c1ba0e-1935-427d-a068-d250aaa5cac5@github.com>
References: <usidfp_4W0O2w-01JwMn2zuy1joN6mQoVUf37Pom_Bo=.4dd5e1ff-c8a5-4ffc-8bde-fe34f887befd@github.com>
 <sxUb0oQf_EBJOENP4mhbzHGXKY-MrdMcGA_qEBrmY-I=.a2c1ba0e-1935-427d-a068-d250aaa5cac5@github.com>
Message-ID: <5zWThs7TbqUpXyN-VcOYQTYIhqdongSSIqKXglkVpbE=.885111b2-d828-43b7-93ba-db8b2e173b82@github.com>

On Mon, 11 Jan 2021 11:24:04 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <uvb6RoVoHhxzCMeCZhcAZC4Vqv5vffxQJ6BVHakm_6A=.a2be6b24-cab4-438d-a2a7-c6ff5d1eb951@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
 <RNU-tanbO6-6vkeQ8yVg2mAa0yzWgCAw3kI5uO8iFow=.7ea55a0f-f60e-4c80-b390-8b990536bde4@github.com>
 <Fhb2WqqPcTDgy1QcnOkBLnxcs6VSFRCaoXRqikGdTG8=.877263e9-89d1-40f9-97d8-fa34e3b1a5b5@github.com>
 <HuI3DwGPJGEFs05jSCPMRFSAM1hRnOWiLrrfveFDGus=.0faf16b5-b9a1-4322-8164-83028a21d9fa@github.com>
 <I7XO4pCkMJ9dHmlUmuncys81pmVAjwXklQHQfeqKFrU=.6b730bf4-ecdd-4c38-8fd8-fa10985cd2e2@github.com>
 <SZi-GTZ3FJlhP8V0cxSc3YQVdZKf86GmiiSjF9kD4Ic=.8a62099b-1db4-421d-b25f-75b8345f7e17@github.com>
 <RNoz4RhHWJxtO4QSAJLXIZjVShQRSckAoPmH_t9NgGY=.a08b176b-8597-448e-b43b-3fd94d625ecb@github.com>
 <uvb6RoVoHhxzCMeCZhcAZC4Vqv5vffxQJ6BVHakm_6A=.a2be6b24-cab4-438d-a2a7-c6ff5d1eb951@github.com>
Message-ID: <G-8GIXO-YSqhN4zkcxltb0lv-0INXzJx3tF7HCjm93s=.71168f75-d795-4eac-ada1-3e290e0b076e@github.com>

On Mon, 11 Jan 2021 10:38:41 GMT, Andrew Haley <aph at openjdk.org> 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: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
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: <usidfp_4W0O2w-01JwMn2zuy1joN6mQoVUf37Pom_Bo=.4dd5e1ff-c8a5-4ffc-8bde-fe34f887befd@github.com>
References: <usidfp_4W0O2w-01JwMn2zuy1joN6mQoVUf37Pom_Bo=.4dd5e1ff-c8a5-4ffc-8bde-fe34f887befd@github.com>
Message-ID: <cJKcVtDm2snBNJ8eXGhJLqKehTIesFiI7E_-ovmlDNs=.7a1514a2-dfa4-4edd-96ca-fb73a9039531@github.com>

On Mon, 30 Nov 2020 14:26:23 GMT, Sergey Platonov <github.com+6061213+sergey-platonov at openjdk.org> 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: <G-8GIXO-YSqhN4zkcxltb0lv-0INXzJx3tF7HCjm93s=.71168f75-d795-4eac-ada1-3e290e0b076e@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
 <RNU-tanbO6-6vkeQ8yVg2mAa0yzWgCAw3kI5uO8iFow=.7ea55a0f-f60e-4c80-b390-8b990536bde4@github.com>
 <Fhb2WqqPcTDgy1QcnOkBLnxcs6VSFRCaoXRqikGdTG8=.877263e9-89d1-40f9-97d8-fa34e3b1a5b5@github.com>
 <HuI3DwGPJGEFs05jSCPMRFSAM1hRnOWiLrrfveFDGus=.0faf16b5-b9a1-4322-8164-83028a21d9fa@github.com>
 <I7XO4pCkMJ9dHmlUmuncys81pmVAjwXklQHQfeqKFrU=.6b730bf4-ecdd-4c38-8fd8-fa10985cd2e2@github.com>
 <SZi-GTZ3FJlhP8V0cxSc3YQVdZKf86GmiiSjF9kD4Ic=.8a62099b-1db4-421d-b25f-75b8345f7e17@github.com>
 <RNoz4RhHWJxtO4QSAJLXIZjVShQRSckAoPmH_t9NgGY=.a08b176b-8597-448e-b43b-3fd94d625ecb@github.com>
 <uvb6RoVoHhxzCMeCZhcAZC4Vqv5vffxQJ6BVHakm_6A=.a2be6b24-cab4-438d-a2a7-c6ff5d1eb951@github.com>
 <G-8GIXO-YSqhN4zkcxltb0lv-0INXzJx3tF7HCjm93s=.71168f75-d795-4eac-ada1-3e290e0b076e@github.com>
Message-ID: <hL7CQ9MspyYFl2OHQnnOcx4hBHYEKEiXp19qoC1asnA=.6041d6a4-26c3-431e-b702-6e4314457c0f@github.com>

On Mon, 11 Jan 2021 11:38:01 GMT, Dong Bo <dongbo at openjdk.org> 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: <rUj0uDd9ob-_LgX3jHOFiCwBdh08IOhWT_8zz9yJ7nQ=.d6228807-d765-483c-8f11-4912aa701059@github.com>

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: <rUj0uDd9ob-_LgX3jHOFiCwBdh08IOhWT_8zz9yJ7nQ=.d6228807-d765-483c-8f11-4912aa701059@github.com>
References: <rUj0uDd9ob-_LgX3jHOFiCwBdh08IOhWT_8zz9yJ7nQ=.d6228807-d765-483c-8f11-4912aa701059@github.com>
Message-ID: <9GQqhkvo5yxFZghj4firam7697e8lwU9XBVB8pfz6vo=.65ab8d19-e983-459d-86ea-622f17f1a54b@github.com>

On Mon, 11 Jan 2021 12:27:18 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> 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: <rUj0uDd9ob-_LgX3jHOFiCwBdh08IOhWT_8zz9yJ7nQ=.d6228807-d765-483c-8f11-4912aa701059@github.com>
References: <rUj0uDd9ob-_LgX3jHOFiCwBdh08IOhWT_8zz9yJ7nQ=.d6228807-d765-483c-8f11-4912aa701059@github.com>
Message-ID: <Qnp6rPTxlJCtAMs9NBVAdEUzRuxqjqBZSV20oUiqOLA=.4933c590-61cd-4e2c-82e6-bc988e214e4f@github.com>

On Mon, 11 Jan 2021 12:27:18 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> 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: <hzQDlMgxks1VhmrVQV6mXifje-Qr66wqR8KxsbpNAcM=.005abb6c-ff3b-4925-bb13-7648e767367a@github.com>
References: <hzQDlMgxks1VhmrVQV6mXifje-Qr66wqR8KxsbpNAcM=.005abb6c-ff3b-4925-bb13-7648e767367a@github.com>
Message-ID: <8bPOqQ22N2FDGHuRqcJ7aOsezcNYT7c4FhTD_X7RbhU=.a5112299-bdac-41fc-ad4d-9cbb19a75ee8@github.com>

On Mon, 11 Jan 2021 09:23:24 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <rUj0uDd9ob-_LgX3jHOFiCwBdh08IOhWT_8zz9yJ7nQ=.d6228807-d765-483c-8f11-4912aa701059@github.com>
References: <rUj0uDd9ob-_LgX3jHOFiCwBdh08IOhWT_8zz9yJ7nQ=.d6228807-d765-483c-8f11-4912aa701059@github.com>
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 <rcastanedalo at openjdk.org> 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: <Qnp6rPTxlJCtAMs9NBVAdEUzRuxqjqBZSV20oUiqOLA=.4933c590-61cd-4e2c-82e6-bc988e214e4f@github.com>
References: <rUj0uDd9ob-_LgX3jHOFiCwBdh08IOhWT_8zz9yJ7nQ=.d6228807-d765-483c-8f11-4912aa701059@github.com>
 <Qnp6rPTxlJCtAMs9NBVAdEUzRuxqjqBZSV20oUiqOLA=.4933c590-61cd-4e2c-82e6-bc988e214e4f@github.com>
Message-ID: <Q0kuX6dHYCrpaSlywEKEyZigxu5zlLVzKLG9bPjDYkw=.e470dd54-28cb-4ada-9a05-f54d287971f5@github.com>

On Mon, 11 Jan 2021 12:53:57 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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: <rUj0uDd9ob-_LgX3jHOFiCwBdh08IOhWT_8zz9yJ7nQ=.d6228807-d765-483c-8f11-4912aa701059@github.com>
 <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 <thartmann at openjdk.org> 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: <usidfp_4W0O2w-01JwMn2zuy1joN6mQoVUf37Pom_Bo=.4dd5e1ff-c8a5-4ffc-8bde-fe34f887befd@github.com>
References: <usidfp_4W0O2w-01JwMn2zuy1joN6mQoVUf37Pom_Bo=.4dd5e1ff-c8a5-4ffc-8bde-fe34f887befd@github.com>
Message-ID: <D_JA0V9ze8xf7iKpmHGAyGHTRXWbvAL_C-NefE4q7Ac=.06bb8fc5-8387-4e6b-8e90-8f68694c7dfb@github.com>

> 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: <cJKcVtDm2snBNJ8eXGhJLqKehTIesFiI7E_-ovmlDNs=.7a1514a2-dfa4-4edd-96ca-fb73a9039531@github.com>
References: <usidfp_4W0O2w-01JwMn2zuy1joN6mQoVUf37Pom_Bo=.4dd5e1ff-c8a5-4ffc-8bde-fe34f887befd@github.com>
 <cJKcVtDm2snBNJ8eXGhJLqKehTIesFiI7E_-ovmlDNs=.7a1514a2-dfa4-4edd-96ca-fb73a9039531@github.com>
Message-ID: <0QnuBA5eYke6BCBi1gIfhM-tNzY6rVmx0zUY0Fyyot0=.c7cd63e1-be06-43c4-b109-8a3eabe80522@github.com>

On Mon, 11 Jan 2021 11:39:56 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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: <usidfp_4W0O2w-01JwMn2zuy1joN6mQoVUf37Pom_Bo=.4dd5e1ff-c8a5-4ffc-8bde-fe34f887befd@github.com>
 <cJKcVtDm2snBNJ8eXGhJLqKehTIesFiI7E_-ovmlDNs=.7a1514a2-dfa4-4edd-96ca-fb73a9039531@github.com>
 <0QnuBA5eYke6BCBi1gIfhM-tNzY6rVmx0zUY0Fyyot0=.c7cd63e1-be06-43c4-b109-8a3eabe80522@github.com>
Message-ID: <CN6CcMV373xjBYTS22MdSMgdSwqjpMeG_kUBIrsCtsg=.e6dbad41-01dc-4750-a580-daedd8b24839@github.com>

On Mon, 11 Jan 2021 14:08:40 GMT, Sergey Platonov <github.com+6061213+sergey-platonov at openjdk.org> 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: <CN6CcMV373xjBYTS22MdSMgdSwqjpMeG_kUBIrsCtsg=.e6dbad41-01dc-4750-a580-daedd8b24839@github.com>
References: <usidfp_4W0O2w-01JwMn2zuy1joN6mQoVUf37Pom_Bo=.4dd5e1ff-c8a5-4ffc-8bde-fe34f887befd@github.com>
 <cJKcVtDm2snBNJ8eXGhJLqKehTIesFiI7E_-ovmlDNs=.7a1514a2-dfa4-4edd-96ca-fb73a9039531@github.com>
 <0QnuBA5eYke6BCBi1gIfhM-tNzY6rVmx0zUY0Fyyot0=.c7cd63e1-be06-43c4-b109-8a3eabe80522@github.com>
 <CN6CcMV373xjBYTS22MdSMgdSwqjpMeG_kUBIrsCtsg=.e6dbad41-01dc-4750-a580-daedd8b24839@github.com>
Message-ID: <yzqmpGTZMyJZBmEC0k4GK7MYSXiNSsD1RERWYQn-5qc=.94bb4b01-024f-46e9-84ae-6422ddaee583@github.com>

On Mon, 11 Jan 2021 14:10:50 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <AM4PR02MB3057903D34BC5A8F54E493AD9AAB0@AM4PR02MB3057.eurprd02.prod.outlook.com>

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: <IpTHmnH5sdGTncHsizveglw3FMxAmNukPQEVR76qh9A=.04ef74f6-e02f-4e3a-97be-bf1b4755307e@github.com>

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: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <vh3G4IDD_KXAnpsCcdK6RbFN60Oe0Tvr29vnRfF2nr8=.d7bf39b5-a33f-428f-9e58-e23a1abece75@github.com>
 <3FqXOR8NSsGbCExqGxRWPfWOrlb0Rpl0bU3Ug__8I8g=.c74bae33-89af-47b5-b02d-6546a9f538a7@github.com>
Message-ID: <c8uwj5ZFBKTP9EeKKXC7nuFeM_M9sD79jxoCfmT89-g=.41b76902-531c-49df-bccf-29d752fdfcfc@github.com>

On Mon, 11 Jan 2021 09:06:36 GMT, Boris Ulasevich <bulasevich at openjdk.org> 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: <zMla0A1MfEsHLjT7dBYFQK7XPn_11P38mJeOPYAn6q8=.7812318e-fd1a-41c2-8f30-dd947d8e1730@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com>
 <rq_mKqykvATt3DwDZJQ4KlRjerCdJt24wR37O2flkzg=.bc33b896-a877-46bc-a872-3930c08b5da4@github.com>
 <aGYYIAEkHrorfDjBKSyAdZX71pQopwgXCdSLPtexAjA=.c50f6d27-2212-4012-9168-d93aaff1f58b@github.com>
 <zGV0C5nyMJCwfiLX_iWRMXdlrmsnpGhVZ3VM1RDI4vw=.487b4590-f41f-44ed-8b6f-5ca39df541f0@github.com>
 <vT4UGUi5Doh7b8OJCorIuyEoCpF_ZC5iPkZJSTFGs0c=.ca08c62b-45dc-41b0-b83e-276825fb23ed@github.com>
 <zMla0A1MfEsHLjT7dBYFQK7XPn_11P38mJeOPYAn6q8=.7812318e-fd1a-41c2-8f30-dd947d8e1730@github.com>
Message-ID: <DKbmUc7Ls--4RLx2RGQZg1A6ENXsQTLBt-F9Bb-qcys=.403be23b-1300-41b0-895f-9ec2e0d34666@github.com>

On Mon, 11 Jan 2021 09:09:12 GMT, Boris Ulasevich <bulasevich at openjdk.org> 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: <rUj0uDd9ob-_LgX3jHOFiCwBdh08IOhWT_8zz9yJ7nQ=.d6228807-d765-483c-8f11-4912aa701059@github.com>
References: <rUj0uDd9ob-_LgX3jHOFiCwBdh08IOhWT_8zz9yJ7nQ=.d6228807-d765-483c-8f11-4912aa701059@github.com>
Message-ID: <tAxiEQmxpY9f3Rg6AUYD1RuXd6fkgQCEKwELxFkZOqk=.d237cfe2-4ca0-45c0-9521-debabe77d3f4@github.com>

On Mon, 11 Jan 2021 12:27:18 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> 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: <fyngZw6ON82cRQW-5z7VRrMr509QW1abQx9arhQiZro=.ba09a18a-45dd-4579-8f2b-eea58a95de16@github.com>

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: <fyngZw6ON82cRQW-5z7VRrMr509QW1abQx9arhQiZro=.ba09a18a-45dd-4579-8f2b-eea58a95de16@github.com>
References: <fyngZw6ON82cRQW-5z7VRrMr509QW1abQx9arhQiZro=.ba09a18a-45dd-4579-8f2b-eea58a95de16@github.com>
Message-ID: <QeFEQ4qjEuNWSbcI2q2zzIy-krvqRZD9-Y971qQ-EIw=.4a151ffc-9731-4fb1-bc30-dfc2c24b5b4f@github.com>

On Mon, 11 Jan 2021 18:37:40 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <BUmYtC26uC1ySwQP4k9cfkf99GHc9V8hx3gPfBiteHo=.67da6484-e305-4282-9f7e-73322b7b3156@github.com>

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: <F2F79CC9-0C19-443D-9E01-69D40A12C7ED@amazon.com>

Lgtm.

Thanks,
Paul

?-----Original Message-----
From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> on behalf of "Doerr, Martin" <martin.doerr at sap.com>
Date: Monday, January 11, 2021 at 7:51 AM
To: "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>, "'hotspot-compiler-dev at openjdk.java.net'" <hotspot-compiler-dev at openjdk.java.net>
Cc: "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>, "Langer, Christoph" <christoph.langer at sap.com>
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: <F2F79CC9-0C19-443D-9E01-69D40A12C7ED@amazon.com>
References: <F2F79CC9-0C19-443D-9E01-69D40A12C7ED@amazon.com>
Message-ID: <AM4PR02MB3057B6F06CBFCBA942121D999AAB0@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi Paul,

thanks for the review.

Best regards,
Martin


> -----Original Message-----
> From: Hohensee, Paul <hohensee at amazon.com>
> Sent: Montag, 11. Januar 2021 23:32
> To: Doerr, Martin <martin.doerr at sap.com>; jdk-updates-
> dev at openjdk.java.net; 'hotspot-compiler-dev at openjdk.java.net' <hotspot-
> compiler-dev at openjdk.java.net>
> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Langer, Christoph
> <christoph.langer at sap.com>
> 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 <jdk-updates-dev-retn at openjdk.java.net> on
> behalf of "Doerr, Martin" <martin.doerr at sap.com>
> Date: Monday, January 11, 2021 at 7:51 AM
> To: "jdk-updates-dev at openjdk.java.net" <jdk-updates-
> dev at openjdk.java.net>, "'hotspot-compiler-dev at openjdk.java.net'"
> <hotspot-compiler-dev at openjdk.java.net>
> Cc: "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>, "Langer,
> Christoph" <christoph.langer at sap.com>
> 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: <wtyzV9SSSRmyrddIankukEzYTgN4yDCGMm4XqIbjoj8=.c263cae3-3adf-4ba5-8db6-7e54410aaf4f@github.com>
References: <FS23y5v6Qg0rFlCTz_ejAJR5sJuL98-oVNm-L6V_plE=.99ebe4e1-e204-41a1-8037-b8fff7f674fe@github.com>
 <wtyzV9SSSRmyrddIankukEzYTgN4yDCGMm4XqIbjoj8=.c263cae3-3adf-4ba5-8db6-7e54410aaf4f@github.com>
Message-ID: <UOTzCc1yEjZJ-10qgTBIOIfwyrErMDPXAB2G0aJoAuw=.21ad1b2c-fbf3-45f2-9549-c5874b34dac9@github.com>

On Mon, 11 Jan 2021 10:41:41 GMT, Andrew Haley <aph at openjdk.org> 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: <Xp_wGLLFFktMY7SIicwQ7zTe0psd_b4m5RzgJudBe3E=.dca99446-f282-4891-95d2-45c75d9df797@github.com>
References: <Xp_wGLLFFktMY7SIicwQ7zTe0psd_b4m5RzgJudBe3E=.dca99446-f282-4891-95d2-45c75d9df797@github.com>
Message-ID: <h5QksaO8VpocE5LuOmsRD_jP9ihOnWeVE_8e6Mbm6oE=.5b1ca126-8d39-4545-8417-4c678ec7908b@github.com>

On Fri, 18 Dec 2020 07:11:11 GMT, Ningsheng Jian <njian at openjdk.org> 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 <njian at openjdk.org>
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: <Xp_wGLLFFktMY7SIicwQ7zTe0psd_b4m5RzgJudBe3E=.dca99446-f282-4891-95d2-45c75d9df797@github.com>
 <y3l6ZBCuBDkwExPn5W745p0z8mzTsX7cT5_XaVBMSfs=.8003403e-86bd-4451-bf2b-d06b3c1c8c37@github.com>
 <2vNAJAihgpB4q_wqeuf2Dtjbu9X-NpqfXtNMibnOOUc=.f52ed07a-702f-4d8b-9200-46986181e6a1@github.com>
Message-ID: <fiNiDDPIoQZ0uRW3b8ReR6johfs8tq-5RfkQTZ9aomg=.06526385-30db-46f9-b672-097c7ebc8383@github.com>

On Mon, 11 Jan 2021 09:31:51 GMT, Andrew Dinn <adinn at openjdk.org> 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: <FS23y5v6Qg0rFlCTz_ejAJR5sJuL98-oVNm-L6V_plE=.99ebe4e1-e204-41a1-8037-b8fff7f674fe@github.com>
References: <FS23y5v6Qg0rFlCTz_ejAJR5sJuL98-oVNm-L6V_plE=.99ebe4e1-e204-41a1-8037-b8fff7f674fe@github.com>
Message-ID: <42uekWro2JiKp6Ug5bnG_1rXYvnbeJIdiUxtk6KF5j4=.9583bf05-0a9c-4b97-93bd-99557615568f@github.com>

On Tue, 5 Jan 2021 03:32:44 GMT, Wang Huang <whuang at openjdk.org> 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 <whuang at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
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 <hexuejin2 at huawei.com>
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: <hzQDlMgxks1VhmrVQV6mXifje-Qr66wqR8KxsbpNAcM=.005abb6c-ff3b-4925-bb13-7648e767367a@github.com>
 <8bPOqQ22N2FDGHuRqcJ7aOsezcNYT7c4FhTD_X7RbhU=.a5112299-bdac-41fc-ad4d-9cbb19a75ee8@github.com>
Message-ID: <np_zndd-EnSac89oBZF2w7Z-00ts-fDHOx_EmzhIhIg=.b73179d7-fe69-47bb-991d-8b6aac82d4d3@github.com>

On Mon, 11 Jan 2021 12:56:17 GMT, Vladimir Ivanov <vlivanov at openjdk.org> 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: <hzQDlMgxks1VhmrVQV6mXifje-Qr66wqR8KxsbpNAcM=.005abb6c-ff3b-4925-bb13-7648e767367a@github.com>
References: <hzQDlMgxks1VhmrVQV6mXifje-Qr66wqR8KxsbpNAcM=.005abb6c-ff3b-4925-bb13-7648e767367a@github.com>
Message-ID: <L5DggYJQq7QyKWpt44CmLkBxda4K2jwee6Lq4hj6754=.6e527093-30b5-4727-913e-11d4cff7d267@github.com>

> 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: <hzQDlMgxks1VhmrVQV6mXifje-Qr66wqR8KxsbpNAcM=.005abb6c-ff3b-4925-bb13-7648e767367a@github.com>
 <8bPOqQ22N2FDGHuRqcJ7aOsezcNYT7c4FhTD_X7RbhU=.a5112299-bdac-41fc-ad4d-9cbb19a75ee8@github.com>
Message-ID: <EnkfxMcQjR5dUCmyUw3fA2WRttU4eVKj9ul6Z6Jv2hE=.256b2b03-f2c8-48a9-aace-bf55835936b9@github.com>

On Mon, 11 Jan 2021 12:56:17 GMT, Vladimir Ivanov <vlivanov at openjdk.org> 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: <ChMzFwipLPwoE0ZG0CkQppRQQ9N-1Ri28dCLMTLeezw=.c8681b50-f010-4ab7-a2f9-cd21ff165c1c@github.com>

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: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
Message-ID: <JfmmSfO9VB28J61kG9JZp8FL8xWcmrxdd1V79Q_VK9o=.28fa5ece-640c-4998-abbf-397b3ee88c72@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:

  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: <DKbmUc7Ls--4RLx2RGQZg1A6ENXsQTLBt-F9Bb-qcys=.403be23b-1300-41b0-895f-9ec2e0d34666@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com>
 <rq_mKqykvATt3DwDZJQ4KlRjerCdJt24wR37O2flkzg=.bc33b896-a877-46bc-a872-3930c08b5da4@github.com>
 <aGYYIAEkHrorfDjBKSyAdZX71pQopwgXCdSLPtexAjA=.c50f6d27-2212-4012-9168-d93aaff1f58b@github.com>
 <zGV0C5nyMJCwfiLX_iWRMXdlrmsnpGhVZ3VM1RDI4vw=.487b4590-f41f-44ed-8b6f-5ca39df541f0@github.com>
 <vT4UGUi5Doh7b8OJCorIuyEoCpF_ZC5iPkZJSTFGs0c=.ca08c62b-45dc-41b0-b83e-276825fb23ed@github.com>
 <zMla0A1MfEsHLjT7dBYFQK7XPn_11P38mJeOPYAn6q8=.7812318e-fd1a-41c2-8f30-dd947d8e1730@github.com>
 <DKbmUc7Ls--4RLx2RGQZg1A6ENXsQTLBt-F9Bb-qcys=.403be23b-1300-41b0-895f-9ec2e0d34666@github.com>
Message-ID: <_kzqYF9JIc1ten32g062993eEyhRKHBGOoKoeemvQ9w=.c98f3d6c-cea1-4a8b-b64e-b4e7108d643d@github.com>

On Mon, 11 Jan 2021 17:54:10 GMT, Igor Veresov <iveresov at openjdk.org> 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: <BUmYtC26uC1ySwQP4k9cfkf99GHc9V8hx3gPfBiteHo=.67da6484-e305-4282-9f7e-73322b7b3156@github.com>
References: <BUmYtC26uC1ySwQP4k9cfkf99GHc9V8hx3gPfBiteHo=.67da6484-e305-4282-9f7e-73322b7b3156@github.com>
Message-ID: <PNbgK2i2jK7CVn73wPZd2jBrraupXS3XJkV31ZZKwhE=.deb79431-f7f2-4dd5-82bd-56453c99edd8@github.com>

On Mon, 11 Jan 2021 19:11:51 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <fyngZw6ON82cRQW-5z7VRrMr509QW1abQx9arhQiZro=.ba09a18a-45dd-4579-8f2b-eea58a95de16@github.com>
References: <fyngZw6ON82cRQW-5z7VRrMr509QW1abQx9arhQiZro=.ba09a18a-45dd-4579-8f2b-eea58a95de16@github.com>
Message-ID: <8UxknD9oi3NVCAmeOhycbesamyNPsDXPor2dNAhvZfk=.0eef5702-d7ca-41c6-aae7-366d6a0a5fb6@github.com>

On Mon, 11 Jan 2021 18:37:40 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <BUmYtC26uC1ySwQP4k9cfkf99GHc9V8hx3gPfBiteHo=.67da6484-e305-4282-9f7e-73322b7b3156@github.com>
References: <BUmYtC26uC1ySwQP4k9cfkf99GHc9V8hx3gPfBiteHo=.67da6484-e305-4282-9f7e-73322b7b3156@github.com>
Message-ID: <dzDzrvchuJT4ZAOc9FDQU9jLsrZuSj28iKh9bKYCU6g=.fa0b45dd-5dfe-4851-b294-fb48a01f6a1e@github.com>

On Mon, 11 Jan 2021 19:11:51 GMT, Aleksey Shipilev <shade at openjdk.org> 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 <shade at openjdk.org>
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: <Yo9QZBT2BMe8Wnij08-fA6OY-yskWjvvjyvaEsKGSx4=.171566a5-fb79-4313-a4f7-269954c6ed1c@github.com>

On Mon, 11 Jan 2021 22:51:48 GMT, Nils Eliasson <neliasso at openjdk.org> 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: <sfBwyWjAeN-MqY0z0rXFCDNjJQT25xbOCOTobS4hlWM=.1204006d-5f38-4edd-8d31-e8e7c0465261@github.com>
References: <sfBwyWjAeN-MqY0z0rXFCDNjJQT25xbOCOTobS4hlWM=.1204006d-5f38-4edd-8d31-e8e7c0465261@github.com>
Message-ID: <TAHFy7R30QRCMv_BRANbI8Oi2UKEs-ECppFuZtGrS0Y=.fbdc4d5e-4033-451e-a31c-996420bb9571@github.com>

On Fri, 8 Jan 2021 14:05:32 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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 <chagedorn at openjdk.org>
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: <tAxiEQmxpY9f3Rg6AUYD1RuXd6fkgQCEKwELxFkZOqk=.d237cfe2-4ca0-45c0-9521-debabe77d3f4@github.com>
References: <rUj0uDd9ob-_LgX3jHOFiCwBdh08IOhWT_8zz9yJ7nQ=.d6228807-d765-483c-8f11-4912aa701059@github.com>
 <tAxiEQmxpY9f3Rg6AUYD1RuXd6fkgQCEKwELxFkZOqk=.d237cfe2-4ca0-45c0-9521-debabe77d3f4@github.com>
Message-ID: <7e9h0MpQ9eGQ_ji1ki8u3RdO-m6RIn_dR3c4mLOaKvI=.925ca765-48d3-43fa-bbee-7005eb55657d@github.com>

On Mon, 11 Jan 2021 18:11:07 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <ChMzFwipLPwoE0ZG0CkQppRQQ9N-1Ri28dCLMTLeezw=.c8681b50-f010-4ab7-a2f9-cd21ff165c1c@github.com>
References: <ChMzFwipLPwoE0ZG0CkQppRQQ9N-1Ri28dCLMTLeezw=.c8681b50-f010-4ab7-a2f9-cd21ff165c1c@github.com>
Message-ID: <v1-DnNsCKsEa6QqOMmL7Iknsgbn2PBURgfj1T5KRVgo=.3bbcf201-f411-4c66-8ad7-d4703a866b8d@github.com>

On Tue, 12 Jan 2021 04:02:00 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <IpTHmnH5sdGTncHsizveglw3FMxAmNukPQEVR76qh9A=.04ef74f6-e02f-4e3a-97be-bf1b4755307e@github.com>
References: <IpTHmnH5sdGTncHsizveglw3FMxAmNukPQEVR76qh9A=.04ef74f6-e02f-4e3a-97be-bf1b4755307e@github.com>
Message-ID: <yUbf1IdqqkDJEklRJBBsYUPTMhndVDH7iMqX1vmMyrM=.0d01bdca-919e-4828-b45a-78a5017dce9c@github.com>

On Mon, 11 Jan 2021 16:11:34 GMT, Erik ?sterlund <eosterlund at openjdk.org> 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: <hL7CQ9MspyYFl2OHQnnOcx4hBHYEKEiXp19qoC1asnA=.6041d6a4-26c3-431e-b702-6e4314457c0f@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
 <RNU-tanbO6-6vkeQ8yVg2mAa0yzWgCAw3kI5uO8iFow=.7ea55a0f-f60e-4c80-b390-8b990536bde4@github.com>
 <Fhb2WqqPcTDgy1QcnOkBLnxcs6VSFRCaoXRqikGdTG8=.877263e9-89d1-40f9-97d8-fa34e3b1a5b5@github.com>
 <HuI3DwGPJGEFs05jSCPMRFSAM1hRnOWiLrrfveFDGus=.0faf16b5-b9a1-4322-8164-83028a21d9fa@github.com>
 <I7XO4pCkMJ9dHmlUmuncys81pmVAjwXklQHQfeqKFrU=.6b730bf4-ecdd-4c38-8fd8-fa10985cd2e2@github.com>
 <SZi-GTZ3FJlhP8V0cxSc3YQVdZKf86GmiiSjF9kD4Ic=.8a62099b-1db4-421d-b25f-75b8345f7e17@github.com>
 <RNoz4RhHWJxtO4QSAJLXIZjVShQRSckAoPmH_t9NgGY=.a08b176b-8597-448e-b43b-3fd94d625ecb@github.com>
 <uvb6RoVoHhxzCMeCZhcAZC4Vqv5vffxQJ6BVHakm_6A=.a2be6b24-cab4-438d-a2a7-c6ff5d1eb951@github.com>
 <G-8GIXO-YSqhN4zkcxltb0lv-0INXzJx3tF7HCjm93s=.71168f75-d795-4eac-ada1-3e290e0b076e@github.com>
 <hL7CQ9MspyYFl2OHQnnOcx4hBHYEKEiXp19qoC1asnA=.6041d6a4-26c3-431e-b702-6e4314457c0f@github.com>
Message-ID: <r0FU1E9ghXqIQlrJQIjdPZWJjctsA6Br_qtj8Kam9K0=.9f927e87-7229-474f-80d8-f3f4e242a15f@github.com>

On Mon, 11 Jan 2021 12:28:57 GMT, Dong Bo <dongbo at openjdk.org> 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: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
 <4nnhdRP9gsILzFv5MvE_1usJtLBwmtoThIErfRgcftw=.277fc10e-1bc2-4a99-97e6-ca1562b625c3@github.com>
Message-ID: <a_eIa-aL2LiwBUcw_cziHV4ZtgugO8Agtxs5QjfrCK4=.6ec2af51-4df6-485c-89ea-bd061fb7e3eb@github.com>

On Mon, 11 Jan 2021 11:41:13 GMT, Dong Bo <dongbo at openjdk.org> 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: <fyngZw6ON82cRQW-5z7VRrMr509QW1abQx9arhQiZro=.ba09a18a-45dd-4579-8f2b-eea58a95de16@github.com>
 <8UxknD9oi3NVCAmeOhycbesamyNPsDXPor2dNAhvZfk=.0eef5702-d7ca-41c6-aae7-366d6a0a5fb6@github.com>
Message-ID: <qcQVd-ryLFb6-lJ4IDejmGKXEZ6WbEmD9GGuoFjq7Yk=.51528f63-fb7c-45da-9f99-899d4298811d@github.com>

On Tue, 12 Jan 2021 06:50:59 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <fyngZw6ON82cRQW-5z7VRrMr509QW1abQx9arhQiZro=.ba09a18a-45dd-4579-8f2b-eea58a95de16@github.com>
References: <fyngZw6ON82cRQW-5z7VRrMr509QW1abQx9arhQiZro=.ba09a18a-45dd-4579-8f2b-eea58a95de16@github.com>
Message-ID: <dtEIxZbanTU-99ewDRYIqyKIMeV0seQME_181GWN5F4=.5cc1819c-f368-40a3-b389-25b8122e64f1@github.com>

On Mon, 11 Jan 2021 18:37:40 GMT, Aleksey Shipilev <shade at openjdk.org> 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 <shade at openjdk.org>
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: <yzqmpGTZMyJZBmEC0k4GK7MYSXiNSsD1RERWYQn-5qc=.94bb4b01-024f-46e9-84ae-6422ddaee583@github.com>
References: <usidfp_4W0O2w-01JwMn2zuy1joN6mQoVUf37Pom_Bo=.4dd5e1ff-c8a5-4ffc-8bde-fe34f887befd@github.com>
 <cJKcVtDm2snBNJ8eXGhJLqKehTIesFiI7E_-ovmlDNs=.7a1514a2-dfa4-4edd-96ca-fb73a9039531@github.com>
 <0QnuBA5eYke6BCBi1gIfhM-tNzY6rVmx0zUY0Fyyot0=.c7cd63e1-be06-43c4-b109-8a3eabe80522@github.com>
 <CN6CcMV373xjBYTS22MdSMgdSwqjpMeG_kUBIrsCtsg=.e6dbad41-01dc-4750-a580-daedd8b24839@github.com>
 <yzqmpGTZMyJZBmEC0k4GK7MYSXiNSsD1RERWYQn-5qc=.94bb4b01-024f-46e9-84ae-6422ddaee583@github.com>
Message-ID: <2FHmvwWpa9Jc0P0X1YLE5h7LMDqeMVQ5Yrd-zhzkfMQ=.819e8c7a-9add-4939-8266-f48a5d12cbe1@github.com>

On Mon, 11 Jan 2021 14:28:17 GMT, Sergey Platonov <github.com+6061213+sergey-platonov at openjdk.org> 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: <DZ4OEcXYwAGVmzbBYoqzjBAweuctJUVgSxuAkEJcA10=.34dcd8d2-2abd-4d2f-b8c1-03589cfa82b7@github.com>

On Mon, 11 Jan 2021 22:51:48 GMT, Nils Eliasson <neliasso at openjdk.org> 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: <J0Kj7AiqCi5l8cNV1YRmcPu005hmLgeCbBCurQ2hwHc=.aaec0d99-c0f0-4b6a-b492-d08c07b46806@github.com>

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: <usidfp_4W0O2w-01JwMn2zuy1joN6mQoVUf37Pom_Bo=.4dd5e1ff-c8a5-4ffc-8bde-fe34f887befd@github.com>
References: <usidfp_4W0O2w-01JwMn2zuy1joN6mQoVUf37Pom_Bo=.4dd5e1ff-c8a5-4ffc-8bde-fe34f887befd@github.com>
Message-ID: <AICiPU814O5taAMqNZxdJrVAcEDLienlynScBsgl1T4=.ba0ede55-ec18-4f39-8992-b49ebacca169@github.com>

On Mon, 30 Nov 2020 14:26:23 GMT, Sergey Platonov <github.com+6061213+sergey-platonov at openjdk.org> 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 <sergey.platonov at gapfruit.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
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: <khEN5hxlknGz4118nTVvHhxUp1a5auJT9Ci07DYM73M=.fa98cd2b-0194-41ec-80cb-0709bc9a51e6@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`

-------------

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: <khEN5hxlknGz4118nTVvHhxUp1a5auJT9Ci07DYM73M=.fa98cd2b-0194-41ec-80cb-0709bc9a51e6@github.com>
References: <khEN5hxlknGz4118nTVvHhxUp1a5auJT9Ci07DYM73M=.fa98cd2b-0194-41ec-80cb-0709bc9a51e6@github.com>
Message-ID: <uz1N9YF-IUplO_4nJSeqOx4fs4C-AafOBtGXrhd2Pb0=.d3c8b0bf-0f80-4512-8bf5-f72eac0b9d44@github.com>

On Tue, 12 Jan 2021 12:21:15 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <khEN5hxlknGz4118nTVvHhxUp1a5auJT9Ci07DYM73M=.fa98cd2b-0194-41ec-80cb-0709bc9a51e6@github.com>
References: <khEN5hxlknGz4118nTVvHhxUp1a5auJT9Ci07DYM73M=.fa98cd2b-0194-41ec-80cb-0709bc9a51e6@github.com>
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: <khEN5hxlknGz4118nTVvHhxUp1a5auJT9Ci07DYM73M=.fa98cd2b-0194-41ec-80cb-0709bc9a51e6@github.com>
 <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 <shade at openjdk.org> 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: <uz1N9YF-IUplO_4nJSeqOx4fs4C-AafOBtGXrhd2Pb0=.d3c8b0bf-0f80-4512-8bf5-f72eac0b9d44@github.com>
References: <khEN5hxlknGz4118nTVvHhxUp1a5auJT9Ci07DYM73M=.fa98cd2b-0194-41ec-80cb-0709bc9a51e6@github.com>
 <uz1N9YF-IUplO_4nJSeqOx4fs4C-AafOBtGXrhd2Pb0=.d3c8b0bf-0f80-4512-8bf5-f72eac0b9d44@github.com>
Message-ID: <YkbHrbAlaMqaTlEdZzkHew4EjGpdQKbCl6GIQtYIuIk=.289dae91-5749-4cee-9b29-0ce6b18e6dac@github.com>

On Tue, 12 Jan 2021 12:39:04 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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: <a_eIa-aL2LiwBUcw_cziHV4ZtgugO8Agtxs5QjfrCK4=.6ec2af51-4df6-485c-89ea-bd061fb7e3eb@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
 <4nnhdRP9gsILzFv5MvE_1usJtLBwmtoThIErfRgcftw=.277fc10e-1bc2-4a99-97e6-ca1562b625c3@github.com>
 <a_eIa-aL2LiwBUcw_cziHV4ZtgugO8Agtxs5QjfrCK4=.6ec2af51-4df6-485c-89ea-bd061fb7e3eb@github.com>
Message-ID: <m8F0t0m4MSGQ-aYMv4HZWuNZ7-lw0fUD0SWl-WkyQXQ=.8e9cf5d9-7de1-4e68-8674-fa86da5d841b@github.com>

On Tue, 12 Jan 2021 10:26:39 GMT, Andrew Haley <aph at openjdk.org> 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: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
Message-ID: <Cz-UdoTc4XK-r7wLlvowB4FIPH-XEQMkZnXsS4Nr73k=.492f3ed5-498a-4382-ba68-38d411aa8903@github.com>

On Mon, 4 Jan 2021 06:23:33 GMT, Dong Bo <dongbo at openjdk.org> 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 <dongbo at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
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: <m8F0t0m4MSGQ-aYMv4HZWuNZ7-lw0fUD0SWl-WkyQXQ=.8e9cf5d9-7de1-4e68-8674-fa86da5d841b@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
 <4nnhdRP9gsILzFv5MvE_1usJtLBwmtoThIErfRgcftw=.277fc10e-1bc2-4a99-97e6-ca1562b625c3@github.com>
 <a_eIa-aL2LiwBUcw_cziHV4ZtgugO8Agtxs5QjfrCK4=.6ec2af51-4df6-485c-89ea-bd061fb7e3eb@github.com>
 <m8F0t0m4MSGQ-aYMv4HZWuNZ7-lw0fUD0SWl-WkyQXQ=.8e9cf5d9-7de1-4e68-8674-fa86da5d841b@github.com>
Message-ID: <MVSeyZDpXaJobemud6gMEOt6MliZWEXu0qA5jyKgeM0=.d24a0046-6861-431e-b69f-154ba0aba8e9@github.com>

On Tue, 12 Jan 2021 12:56:03 GMT, Dong Bo <dongbo at openjdk.org> 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: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com>
 <rq_mKqykvATt3DwDZJQ4KlRjerCdJt24wR37O2flkzg=.bc33b896-a877-46bc-a872-3930c08b5da4@github.com>
 <aGYYIAEkHrorfDjBKSyAdZX71pQopwgXCdSLPtexAjA=.c50f6d27-2212-4012-9168-d93aaff1f58b@github.com>
 <zGV0C5nyMJCwfiLX_iWRMXdlrmsnpGhVZ3VM1RDI4vw=.487b4590-f41f-44ed-8b6f-5ca39df541f0@github.com>
 <vT4UGUi5Doh7b8OJCorIuyEoCpF_ZC5iPkZJSTFGs0c=.ca08c62b-45dc-41b0-b83e-276825fb23ed@github.com>
 <zMla0A1MfEsHLjT7dBYFQK7XPn_11P38mJeOPYAn6q8=.7812318e-fd1a-41c2-8f30-dd947d8e1730@github.com>
 <DKbmUc7Ls--4RLx2RGQZg1A6ENXsQTLBt-F9Bb-qcys=.403be23b-1300-41b0-895f-9ec2e0d34666@github.com>
 <_kzqYF9JIc1ten32g062993eEyhRKHBGOoKoeemvQ9w=.c98f3d6c-cea1-4a8b-b64e-b4e7108d643d@github.com>
Message-ID: <ULPjVtRBHQi3Ri2qMPYrA-1HIhlB5eWDHSjHEuKRHn4=.0d61ff2b-92ef-4f62-8e0a-bbe6cf496482@github.com>

On Tue, 12 Jan 2021 05:03:45 GMT, Igor Veresov <iveresov at openjdk.org> 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: <IpTHmnH5sdGTncHsizveglw3FMxAmNukPQEVR76qh9A=.04ef74f6-e02f-4e3a-97be-bf1b4755307e@github.com>
References: <IpTHmnH5sdGTncHsizveglw3FMxAmNukPQEVR76qh9A=.04ef74f6-e02f-4e3a-97be-bf1b4755307e@github.com>
Message-ID: <ItLt_WglR-n45FA5RAS7rdyOD1mrw3aPE4I_LG1Zcdo=.36baa216-3972-4137-8b2e-6f49e2c17ea5@github.com>

> 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: <ItLt_WglR-n45FA5RAS7rdyOD1mrw3aPE4I_LG1Zcdo=.36baa216-3972-4137-8b2e-6f49e2c17ea5@github.com>
References: <IpTHmnH5sdGTncHsizveglw3FMxAmNukPQEVR76qh9A=.04ef74f6-e02f-4e3a-97be-bf1b4755307e@github.com>
 <ItLt_WglR-n45FA5RAS7rdyOD1mrw3aPE4I_LG1Zcdo=.36baa216-3972-4137-8b2e-6f49e2c17ea5@github.com>
Message-ID: <pCQ1jY5KrnSHA-y8Zbj8XIXhVbrh-y5dYJOUiE6HY6Q=.51e82019-d2e0-436a-b50e-dc63e78cff87@github.com>

On Tue, 12 Jan 2021 15:28:19 GMT, Erik ?sterlund <eosterlund at openjdk.org> 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: <pCQ1jY5KrnSHA-y8Zbj8XIXhVbrh-y5dYJOUiE6HY6Q=.51e82019-d2e0-436a-b50e-dc63e78cff87@github.com>
References: <IpTHmnH5sdGTncHsizveglw3FMxAmNukPQEVR76qh9A=.04ef74f6-e02f-4e3a-97be-bf1b4755307e@github.com>
 <ItLt_WglR-n45FA5RAS7rdyOD1mrw3aPE4I_LG1Zcdo=.36baa216-3972-4137-8b2e-6f49e2c17ea5@github.com>
 <pCQ1jY5KrnSHA-y8Zbj8XIXhVbrh-y5dYJOUiE6HY6Q=.51e82019-d2e0-436a-b50e-dc63e78cff87@github.com>
Message-ID: <tLU64PD6qU8ySEgPEOI4gTOISMNm5YFUw8XN0k9f5TI=.ecd0dd6a-5617-4c73-8b78-f86e3c69abec@github.com>

On Tue, 12 Jan 2021 15:42:14 GMT, Nils Eliasson <neliasso at openjdk.org> 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: <MVSeyZDpXaJobemud6gMEOt6MliZWEXu0qA5jyKgeM0=.d24a0046-6861-431e-b69f-154ba0aba8e9@github.com>
References: <b7j9LAL-NwZPnFjKRYz9NoiFEeCfwsyCdAPA7O9IckU=.907b2bd2-88fd-4b31-8040-c19e06efaec0@github.com>
 <4nnhdRP9gsILzFv5MvE_1usJtLBwmtoThIErfRgcftw=.277fc10e-1bc2-4a99-97e6-ca1562b625c3@github.com>
 <a_eIa-aL2LiwBUcw_cziHV4ZtgugO8Agtxs5QjfrCK4=.6ec2af51-4df6-485c-89ea-bd061fb7e3eb@github.com>
 <m8F0t0m4MSGQ-aYMv4HZWuNZ7-lw0fUD0SWl-WkyQXQ=.8e9cf5d9-7de1-4e68-8674-fa86da5d841b@github.com>
 <MVSeyZDpXaJobemud6gMEOt6MliZWEXu0qA5jyKgeM0=.d24a0046-6861-431e-b69f-154ba0aba8e9@github.com>
Message-ID: <-ySS8X0WKKilPfASGTraHnIkUErfiVFjOoPcFgponTg=.45a4032e-122e-4cdf-9a91-aa0afdcd90a7@github.com>

On Tue, 12 Jan 2021 14:11:07 GMT, Kim Barrett <kbarrett at openjdk.org> 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: <hB3KyLyghWzNbG4r4X8aGSp_7gc14eVWjBuo-6kBl2U=.9983f060-d5f0-41ee-8b56-7bde41c0bda0@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.

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: <f76b7679-eaf4-f2ca-4136-e0a2b1d71e36@oracle.com>

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: <khEN5hxlknGz4118nTVvHhxUp1a5auJT9Ci07DYM73M=.fa98cd2b-0194-41ec-80cb-0709bc9a51e6@github.com>
 <8Ixvi5AkRmzbkmxAYnrkU30Jla8JtykXbzkcvfz9aEw=.8982dca6-dbf2-4f14-b1e5-bbe99c534f32@github.com>
Message-ID: <QE2bqg979Ty4r4kWdBMDjTi0dsfjTV6e4ardjUQ1ajs=.5a93be17-8338-4192-94dd-2586e398ffd8@github.com>

On Tue, 12 Jan 2021 12:47:11 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <EnkfxMcQjR5dUCmyUw3fA2WRttU4eVKj9ul6Z6Jv2hE=.256b2b03-f2c8-48a9-aace-bf55835936b9@github.com>
References: <hzQDlMgxks1VhmrVQV6mXifje-Qr66wqR8KxsbpNAcM=.005abb6c-ff3b-4925-bb13-7648e767367a@github.com>
 <8bPOqQ22N2FDGHuRqcJ7aOsezcNYT7c4FhTD_X7RbhU=.a5112299-bdac-41fc-ad4d-9cbb19a75ee8@github.com>
 <EnkfxMcQjR5dUCmyUw3fA2WRttU4eVKj9ul6Z6Jv2hE=.256b2b03-f2c8-48a9-aace-bf55835936b9@github.com>
Message-ID: <HwrURaS96lUSZAJAtSeuwDkMWvwNTkNZsmRFqnqjfnY=.0cce7812-e2db-4fd2-8c10-39417d8426ca@github.com>

On Tue, 12 Jan 2021 02:49:22 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <hB3KyLyghWzNbG4r4X8aGSp_7gc14eVWjBuo-6kBl2U=.9983f060-d5f0-41ee-8b56-7bde41c0bda0@github.com>
References: <1uFiDtbFRK-a5WyMKqNVh0Tx1ospvidf6O0ExS3bRbs=.d8fa7cdf-e712-48a1-902d-77d3b35ae801@github.com>
 <hB3KyLyghWzNbG4r4X8aGSp_7gc14eVWjBuo-6kBl2U=.9983f060-d5f0-41ee-8b56-7bde41c0bda0@github.com>
Message-ID: <yEcTykHMhDYYakd_HF7aMUKPWTBs51nAg-OOPGg7FvY=.66bf6f20-ad9b-43cf-8a56-cf56349225f9@github.com>

On Tue, 12 Jan 2021 16:35:29 GMT, Nils Eliasson <neliasso at openjdk.org> 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: <MoNKFqUbC4-GQFwe2S6FX1Lu9sewd51ryo513GqmjIA=.a13b5cb7-7cf8-4fe7-a36c-5716c2a03ca0@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.

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: <MoNKFqUbC4-GQFwe2S6FX1Lu9sewd51ryo513GqmjIA=.a13b5cb7-7cf8-4fe7-a36c-5716c2a03ca0@github.com>
References: <1uFiDtbFRK-a5WyMKqNVh0Tx1ospvidf6O0ExS3bRbs=.d8fa7cdf-e712-48a1-902d-77d3b35ae801@github.com>
 <MoNKFqUbC4-GQFwe2S6FX1Lu9sewd51ryo513GqmjIA=.a13b5cb7-7cf8-4fe7-a36c-5716c2a03ca0@github.com>
Message-ID: <ebG9gqPfrnxSw26n6Br58BircvBzX4IwDjyTUjuF9gs=.92b8dbfd-366b-4940-bd4e-117dcfce89c9@github.com>

On Tue, 12 Jan 2021 21:42:23 GMT, Nils Eliasson <neliasso at openjdk.org> 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: <v1-DnNsCKsEa6QqOMmL7Iknsgbn2PBURgfj1T5KRVgo=.3bbcf201-f411-4c66-8ad7-d4703a866b8d@github.com>
References: <ChMzFwipLPwoE0ZG0CkQppRQQ9N-1Ri28dCLMTLeezw=.c8681b50-f010-4ab7-a2f9-cd21ff165c1c@github.com>
 <v1-DnNsCKsEa6QqOMmL7Iknsgbn2PBURgfj1T5KRVgo=.3bbcf201-f411-4c66-8ad7-d4703a866b8d@github.com>
Message-ID: <aX_NwskWsykhtR7F6PFTBD5gkxy8M_AMG4lr83rM_qI=.9aee5ede-842f-4c23-9180-de2cf9ffeb94@github.com>

On Tue, 12 Jan 2021 10:00:54 GMT, Andrew Dinn <adinn at openjdk.org> 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: <L5DggYJQq7QyKWpt44CmLkBxda4K2jwee6Lq4hj6754=.6e527093-30b5-4727-913e-11d4cff7d267@github.com>
References: <hzQDlMgxks1VhmrVQV6mXifje-Qr66wqR8KxsbpNAcM=.005abb6c-ff3b-4925-bb13-7648e767367a@github.com>
 <L5DggYJQq7QyKWpt44CmLkBxda4K2jwee6Lq4hj6754=.6e527093-30b5-4727-913e-11d4cff7d267@github.com>
Message-ID: <NM8l1cAiqc9aeXOQkOVcLAid5nb1SIQLEaIE8yFAnwo=.b76b61de-96f7-4740-a056-03b21d615249@github.com>

On Tue, 12 Jan 2021 02:52:13 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <ChMzFwipLPwoE0ZG0CkQppRQQ9N-1Ri28dCLMTLeezw=.c8681b50-f010-4ab7-a2f9-cd21ff165c1c@github.com>
References: <ChMzFwipLPwoE0ZG0CkQppRQQ9N-1Ri28dCLMTLeezw=.c8681b50-f010-4ab7-a2f9-cd21ff165c1c@github.com>
Message-ID: <F973ZBOct3jDuaDPnDrIXFYCAu5CnkdfR4dqltIZxWI=.a488ef9c-6e72-4f3d-930d-74ca34748857@github.com>

On Tue, 12 Jan 2021 04:02:00 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <NM8l1cAiqc9aeXOQkOVcLAid5nb1SIQLEaIE8yFAnwo=.b76b61de-96f7-4740-a056-03b21d615249@github.com>
References: <hzQDlMgxks1VhmrVQV6mXifje-Qr66wqR8KxsbpNAcM=.005abb6c-ff3b-4925-bb13-7648e767367a@github.com>
 <L5DggYJQq7QyKWpt44CmLkBxda4K2jwee6Lq4hj6754=.6e527093-30b5-4727-913e-11d4cff7d267@github.com>
 <NM8l1cAiqc9aeXOQkOVcLAid5nb1SIQLEaIE8yFAnwo=.b76b61de-96f7-4740-a056-03b21d615249@github.com>
Message-ID: <lPqC5lnuOB87gJZ3dV4BNWh1clYfAO7769Dr2SXWXVc=.b34de3ce-1ab5-4e44-bf7e-e04df5e6716a@github.com>

On Wed, 13 Jan 2021 02:34:19 GMT, Ningsheng Jian <njian at openjdk.org> 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: <hzQDlMgxks1VhmrVQV6mXifje-Qr66wqR8KxsbpNAcM=.005abb6c-ff3b-4925-bb13-7648e767367a@github.com>
References: <hzQDlMgxks1VhmrVQV6mXifje-Qr66wqR8KxsbpNAcM=.005abb6c-ff3b-4925-bb13-7648e767367a@github.com>
Message-ID: <yznQLbxs7KQt7YHpdwx_jAMqffdv_q2AbvWyjcjVXJk=.af19fbb6-0265-4156-9a71-ad4213567d14@github.com>

On Mon, 11 Jan 2021 09:23:24 GMT, Xiaohong Gong <xgong at openjdk.org> 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 <xgong at openjdk.org>
Committer: Ningsheng Jian <njian at openjdk.org>
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: <ChMzFwipLPwoE0ZG0CkQppRQQ9N-1Ri28dCLMTLeezw=.c8681b50-f010-4ab7-a2f9-cd21ff165c1c@github.com>
References: <ChMzFwipLPwoE0ZG0CkQppRQQ9N-1Ri28dCLMTLeezw=.c8681b50-f010-4ab7-a2f9-cd21ff165c1c@github.com>
Message-ID: <L9hBq4Fc8nSw0qW8n_4718BjBPU9bQRvX9Zob5Ug-J4=.8d5b0e26-38e1-4c7f-8a2e-fc176008791f@github.com>

On Tue, 12 Jan 2021 04:02:00 GMT, Xiaohong Gong <xgong at openjdk.org> 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 <xgong at openjdk.org>
Committer: Ningsheng Jian <njian at openjdk.org>
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: <rUj0uDd9ob-_LgX3jHOFiCwBdh08IOhWT_8zz9yJ7nQ=.d6228807-d765-483c-8f11-4912aa701059@github.com>
 <tAxiEQmxpY9f3Rg6AUYD1RuXd6fkgQCEKwELxFkZOqk=.d237cfe2-4ca0-45c0-9521-debabe77d3f4@github.com>
 <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 <rcastanedalo at openjdk.org> 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: <rUj0uDd9ob-_LgX3jHOFiCwBdh08IOhWT_8zz9yJ7nQ=.d6228807-d765-483c-8f11-4912aa701059@github.com>
References: <rUj0uDd9ob-_LgX3jHOFiCwBdh08IOhWT_8zz9yJ7nQ=.d6228807-d765-483c-8f11-4912aa701059@github.com>
Message-ID: <mKcUEpbTarxFnpRfxgyNT9e9cKXvEilHKz7bswPgXyg=.3a255a43-c14e-4024-830c-ced896047f4d@github.com>

On Mon, 11 Jan 2021 12:27:18 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> 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 <rcastanedalo at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
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: <f76b7679-eaf4-f2ca-4136-e0a2b1d71e36@oracle.com>
References: <87sg76a6qd.fsf@redhat.com>
 <f76b7679-eaf4-f2ca-4136-e0a2b1d71e36@oracle.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: <MoNKFqUbC4-GQFwe2S6FX1Lu9sewd51ryo513GqmjIA=.a13b5cb7-7cf8-4fe7-a36c-5716c2a03ca0@github.com>
References: <1uFiDtbFRK-a5WyMKqNVh0Tx1ospvidf6O0ExS3bRbs=.d8fa7cdf-e712-48a1-902d-77d3b35ae801@github.com>
 <MoNKFqUbC4-GQFwe2S6FX1Lu9sewd51ryo513GqmjIA=.a13b5cb7-7cf8-4fe7-a36c-5716c2a03ca0@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 <neliasso at openjdk.org> 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: <Lh2EQAvUFTK3JMPf0BAQmHmpLWOAiImhBNuA9DzVjpQ=.d5f801ba-df3c-4fc6-99d8-804708fd585a@github.com>

On Tue, 12 Jan 2021 22:16:54 GMT, Vladimir Ivanov <vlivanov at openjdk.org> 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: <Lh2EQAvUFTK3JMPf0BAQmHmpLWOAiImhBNuA9DzVjpQ=.d5f801ba-df3c-4fc6-99d8-804708fd585a@github.com>
References: <2PEWRbpWVrdRx47oZPJQVs082bVynDioRaD2GjZExqs=.3561364b-f502-416d-a0ac-1a6bc1087627@github.com>
 <Lh2EQAvUFTK3JMPf0BAQmHmpLWOAiImhBNuA9DzVjpQ=.d5f801ba-df3c-4fc6-99d8-804708fd585a@github.com>
Message-ID: <kx6RW_FhU-L5xL3uVgoqlmQjz9JB-Gy9LOql0Lic12I=.8efc3302-8e2a-49de-84dc-6557e392b132@github.com>

On Wed, 13 Jan 2021 08:00:59 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <t8-71LTyJv3mvetAKj5XNKRM3-2ljiH-hP0DfWKDMOs=.4c13ae47-a1c2-4c5a-948a-0d59b208e8b3@github.com>

On Mon, 11 Jan 2021 22:51:48 GMT, Nils Eliasson <neliasso at openjdk.org> 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 <neliasso at openjdk.org>
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: <J0Kj7AiqCi5l8cNV1YRmcPu005hmLgeCbBCurQ2hwHc=.aaec0d99-c0f0-4b6a-b492-d08c07b46806@github.com>
References: <J0Kj7AiqCi5l8cNV1YRmcPu005hmLgeCbBCurQ2hwHc=.aaec0d99-c0f0-4b6a-b492-d08c07b46806@github.com>
Message-ID: <FKJVN1xvWtlbCZsSXq6GE5FqHWxR7Yzb3id3wsFxIxQ=.dff74d7a-b81b-428f-a224-389fd902efb7@github.com>

On Tue, 12 Jan 2021 10:15:01 GMT, Roland Westrelin <roland at openjdk.org> 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<T1>(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: <QE2bqg979Ty4r4kWdBMDjTi0dsfjTV6e4ardjUQ1ajs=.5a93be17-8338-4192-94dd-2586e398ffd8@github.com>
References: <khEN5hxlknGz4118nTVvHhxUp1a5auJT9Ci07DYM73M=.fa98cd2b-0194-41ec-80cb-0709bc9a51e6@github.com>
 <8Ixvi5AkRmzbkmxAYnrkU30Jla8JtykXbzkcvfz9aEw=.8982dca6-dbf2-4f14-b1e5-bbe99c534f32@github.com>
 <QE2bqg979Ty4r4kWdBMDjTi0dsfjTV6e4ardjUQ1ajs=.5a93be17-8338-4192-94dd-2586e398ffd8@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 <kvn at openjdk.org> 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: <khEN5hxlknGz4118nTVvHhxUp1a5auJT9Ci07DYM73M=.fa98cd2b-0194-41ec-80cb-0709bc9a51e6@github.com>
References: <khEN5hxlknGz4118nTVvHhxUp1a5auJT9Ci07DYM73M=.fa98cd2b-0194-41ec-80cb-0709bc9a51e6@github.com>
Message-ID: <iSdddThJdcDRUU26j1GPCt-dlldKRlqY5UutmYyJFAE=.d2c62a68-f835-4344-bead-bd5aafd3f676@github.com>

On Tue, 12 Jan 2021 12:21:15 GMT, Aleksey Shipilev <shade at openjdk.org> 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 <shade at openjdk.org>
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: <eHKmqHS3Oob7_BbIDvlHGbfL6Sap9H-wrc-NsE7FxUg=.e0288d20-3b03-4199-80bd-3112337b837e@github.com>

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: <FKJVN1xvWtlbCZsSXq6GE5FqHWxR7Yzb3id3wsFxIxQ=.dff74d7a-b81b-428f-a224-389fd902efb7@github.com>
References: <J0Kj7AiqCi5l8cNV1YRmcPu005hmLgeCbBCurQ2hwHc=.aaec0d99-c0f0-4b6a-b492-d08c07b46806@github.com>
 <FKJVN1xvWtlbCZsSXq6GE5FqHWxR7Yzb3id3wsFxIxQ=.dff74d7a-b81b-428f-a224-389fd902efb7@github.com>
Message-ID: <rwzWXgqcVbAb2Hx8um3PxqVyhJf7kWlYl-yZhTdOsRg=.b87903d0-9685-4cc2-a2b7-b4c01b768d4e@github.com>

On Wed, 13 Jan 2021 10:44:49 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <IpTHmnH5sdGTncHsizveglw3FMxAmNukPQEVR76qh9A=.04ef74f6-e02f-4e3a-97be-bf1b4755307e@github.com>
References: <IpTHmnH5sdGTncHsizveglw3FMxAmNukPQEVR76qh9A=.04ef74f6-e02f-4e3a-97be-bf1b4755307e@github.com>
Message-ID: <7nIw7d3aYS1Ep4zySQDUGA-rvPsm6s7_h4yXpJSzfYY=.51184b46-7a12-43db-962c-795144c7882c@github.com>

On Mon, 11 Jan 2021 16:11:34 GMT, Erik ?sterlund <eosterlund at openjdk.org> 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 <eosterlund at openjdk.org>
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: <eHKmqHS3Oob7_BbIDvlHGbfL6Sap9H-wrc-NsE7FxUg=.e0288d20-3b03-4199-80bd-3112337b837e@github.com>
References: <eHKmqHS3Oob7_BbIDvlHGbfL6Sap9H-wrc-NsE7FxUg=.e0288d20-3b03-4199-80bd-3112337b837e@github.com>
Message-ID: <149_CqNhCs-Z_lF4vH3iGBbyxiG0FfpZUP0uJDays08=.67e8ea00-d896-48e1-ac99-f6e62448e150@github.com>

On Wed, 13 Jan 2021 13:07:51 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <eHKmqHS3Oob7_BbIDvlHGbfL6Sap9H-wrc-NsE7FxUg=.e0288d20-3b03-4199-80bd-3112337b837e@github.com>
References: <eHKmqHS3Oob7_BbIDvlHGbfL6Sap9H-wrc-NsE7FxUg=.e0288d20-3b03-4199-80bd-3112337b837e@github.com>
Message-ID: <Q1cd6xGPSB34lTApipH9URNWcjnjd8dXfd0sVNyGWio=.1ec5a7fa-ff66-4218-abc8-24d5093347de@github.com>

On Wed, 13 Jan 2021 13:07:51 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <eHKmqHS3Oob7_BbIDvlHGbfL6Sap9H-wrc-NsE7FxUg=.e0288d20-3b03-4199-80bd-3112337b837e@github.com>
References: <eHKmqHS3Oob7_BbIDvlHGbfL6Sap9H-wrc-NsE7FxUg=.e0288d20-3b03-4199-80bd-3112337b837e@github.com>
Message-ID: <Op9G2W9e99K23ub2DQa4BUAmV2SfF3yMmqDfOh1m4LE=.7732e249-8689-4fd7-9fb3-4330c2df666b@github.com>

On Wed, 13 Jan 2021 13:07:51 GMT, Tobias Hartmann <thartmann at openjdk.org> 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 <thartmann at openjdk.org>
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: <eHKmqHS3Oob7_BbIDvlHGbfL6Sap9H-wrc-NsE7FxUg=.e0288d20-3b03-4199-80bd-3112337b837e@github.com>
 <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 <lucy at openjdk.org> 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: <cv83E-f38PtWKwqrEZKMwbQpO52b7cS1JddP79nhBhA=.07a02fc3-8968-4883-bf81-2baf54611098@github.com>

We see C-heap leaking, originating in C2:

1434777 [0x00007f58214af461] stringStream::stringStream(unsigned long)+0x55
1434778 [0x00007f5820c6db3e] Compile::PrintInliningBuffer::PrintInliningBuffer()+0x6c
1434779 [0x00007f5820c724f1] GrowableArrayWithAllocator<Compile::PrintInliningBuffer, GrowableArray<Compile::PrintInliningBuffer> >::grow(int)+0x163
1434780 [0x00007f5820c7160e] GrowableArrayWithAllocator<Compile::PrintInliningBuffer, GrowableArray<Compile::PrintInliningBuffer> >::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<PrintInliningBuffer>* _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 <typename E, typename Derived>
void GrowableArrayWithAllocator<E, Derived>::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<E, Derived>::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: <jFnqp62fpZtr_HoVF-IFx4orbnahRPf-lzf4APbWpRw=.28f9fe45-aae3-47c4-9d25-274ef1bdd96b@github.com>

On Thu, 14 Jan 2021 08:05:25 GMT, Roland Westrelin <roland at openjdk.org> 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: <MSgZtw8VjFZvmnzIe5Fvc9-Xzy2_QONahad43rmf7Wc=.d86625ff-dac6-447b-80c7-788b6bed2af6@github.com>

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: <MSgZtw8VjFZvmnzIe5Fvc9-Xzy2_QONahad43rmf7Wc=.d86625ff-dac6-447b-80c7-788b6bed2af6@github.com>
References: <MSgZtw8VjFZvmnzIe5Fvc9-Xzy2_QONahad43rmf7Wc=.d86625ff-dac6-447b-80c7-788b6bed2af6@github.com>
Message-ID: <XqyIsyx3bBmGw95ZR8eSb4y72A7t2JdtTbIoSMWcLW4=.c3a7eb02-a61b-47c5-a343-74626ef7813b@github.com>

On Thu, 14 Jan 2021 11:41:35 GMT, Jatin Bhateja <jbhateja at openjdk.org> 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: <y2adaBFCMntCtbx60rq0MWwl0NSS2JEjDrx31F5gGW8=.0888e0df-816e-4351-b4db-d8a8ccad29b7@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

-------------

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: <j9F3HkJwMbEfyIhC2gIuPopeYVOX11fGaYay01GivBM=.44c1a553-fb06-4d65-ad66-2296c2eb4036@github.com>

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: <XqyIsyx3bBmGw95ZR8eSb4y72A7t2JdtTbIoSMWcLW4=.c3a7eb02-a61b-47c5-a343-74626ef7813b@github.com>
References: <MSgZtw8VjFZvmnzIe5Fvc9-Xzy2_QONahad43rmf7Wc=.d86625ff-dac6-447b-80c7-788b6bed2af6@github.com>
 <XqyIsyx3bBmGw95ZR8eSb4y72A7t2JdtTbIoSMWcLW4=.c3a7eb02-a61b-47c5-a343-74626ef7813b@github.com>
Message-ID: <YANysgB6lGylviE-hZOLhh0nZcKx3hcPzsAAEpZsB-g=.777ae301-929c-4fea-869c-e8d31e02c5f7@github.com>

On Thu, 14 Jan 2021 11:58:21 GMT, Vladimir Ivanov <vlivanov at openjdk.org> 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: <MSgZtw8VjFZvmnzIe5Fvc9-Xzy2_QONahad43rmf7Wc=.d86625ff-dac6-447b-80c7-788b6bed2af6@github.com>
References: <MSgZtw8VjFZvmnzIe5Fvc9-Xzy2_QONahad43rmf7Wc=.d86625ff-dac6-447b-80c7-788b6bed2af6@github.com>
Message-ID: <UOG4dFmAd_wkwvw5VaL51qhnPYEuJH1CzL1AUTiC9p8=.000914dc-fcc3-433e-bb0d-9400e0bd3a2e@github.com>

On Thu, 14 Jan 2021 11:41:35 GMT, Jatin Bhateja <jbhateja at openjdk.org> 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 <jbhateja at openjdk.org>
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: <j9F3HkJwMbEfyIhC2gIuPopeYVOX11fGaYay01GivBM=.44c1a553-fb06-4d65-ad66-2296c2eb4036@github.com>
References: <j9F3HkJwMbEfyIhC2gIuPopeYVOX11fGaYay01GivBM=.44c1a553-fb06-4d65-ad66-2296c2eb4036@github.com>
Message-ID: <GMS1ECboI_da9U_0XbzQGRW-BSkWjUjxGhBU8b-EzOY=.e7bd2fa7-2420-44bc-b858-f3d3c0817231@github.com>

On Thu, 14 Jan 2021 13:13:21 GMT, Jatin Bhateja <jbhateja at openjdk.org> 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 <roland at openjdk.org> 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: <kQYbxKPFZRCZaz79blFr4liShnhidfEA_RcidQIe5Mg=.e080c2f5-1f5f-49b2-8c77-bcb42f5ca615@github.com>

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: <obbVPzYbNfo_UecKhPIHE3sAmemPdb7j0Il9tLl-I_s=.bdb7a5ab-c823-415a-aa0a-a05a99a1c3f8@github.com>

On Tue, 12 Jan 2021 22:16:54 GMT, Vladimir Ivanov <vlivanov at openjdk.org> 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 <vlivanov at openjdk.org>
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: <GMS1ECboI_da9U_0XbzQGRW-BSkWjUjxGhBU8b-EzOY=.e7bd2fa7-2420-44bc-b858-f3d3c0817231@github.com>
References: <j9F3HkJwMbEfyIhC2gIuPopeYVOX11fGaYay01GivBM=.44c1a553-fb06-4d65-ad66-2296c2eb4036@github.com>
 <GMS1ECboI_da9U_0XbzQGRW-BSkWjUjxGhBU8b-EzOY=.e7bd2fa7-2420-44bc-b858-f3d3c0817231@github.com>
Message-ID: <Oc4TOL_dcCbyG9Vm2leK7apxJXKgTZRdE4Yz5vxB5so=.2f75b937-647d-4754-9ba5-4cfebcf94d6b@github.com>

On Thu, 14 Jan 2021 13:41:45 GMT, Vladimir Ivanov <vlivanov at openjdk.org> 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: <Oc4TOL_dcCbyG9Vm2leK7apxJXKgTZRdE4Yz5vxB5so=.2f75b937-647d-4754-9ba5-4cfebcf94d6b@github.com>
References: <j9F3HkJwMbEfyIhC2gIuPopeYVOX11fGaYay01GivBM=.44c1a553-fb06-4d65-ad66-2296c2eb4036@github.com>
 <GMS1ECboI_da9U_0XbzQGRW-BSkWjUjxGhBU8b-EzOY=.e7bd2fa7-2420-44bc-b858-f3d3c0817231@github.com>
 <Oc4TOL_dcCbyG9Vm2leK7apxJXKgTZRdE4Yz5vxB5so=.2f75b937-647d-4754-9ba5-4cfebcf94d6b@github.com>
Message-ID: <f2d87c30-2786-a5d1-f0e4-590aec79fb98@oracle.com>

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 <vlivanov at openjdk.org> 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: <kQYbxKPFZRCZaz79blFr4liShnhidfEA_RcidQIe5Mg=.e080c2f5-1f5f-49b2-8c77-bcb42f5ca615@github.com>
References: <kQYbxKPFZRCZaz79blFr4liShnhidfEA_RcidQIe5Mg=.e080c2f5-1f5f-49b2-8c77-bcb42f5ca615@github.com>
Message-ID: <maHUTm4kdcl2qE7Ao79GTQ10gnzi3GE9Dy69iQh-KGM=.f8390d42-8038-40c7-a280-8d0751a1aa91@github.com>

> 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: <vzU7IblBH2MK4VleZHOIBp8DLiZBwIdLeFkhnndolmY=.af4a6cab-3f06-4158-88ac-56b6d3e052f7@github.com>

> 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: <r18WdPo4mtljCFGoIv3zHKAPVKlqeNW1pVqurV3JpTI=.e9eec294-e662-4434-ac50-c8339b06a94e@github.com>

On Thu, 14 Jan 2021 15:37:44 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <yQhQG5dOjY55apOo9Nxjf7r0gCs51wlZ3oYEp1E1GvM=.b817cf86-5f9a-4eee-87a4-4dc21916a95d@github.com>
References: <1aDWWln8xu9qmWLSgnGJOYlllvN_QfzJsRtW5qKFjbA=.a46186b0-14ff-4306-a44c-34b943a082da@github.com>
 <jFnqp62fpZtr_HoVF-IFx4orbnahRPf-lzf4APbWpRw=.28f9fe45-aae3-47c4-9d25-274ef1bdd96b@github.com>
 <yQhQG5dOjY55apOo9Nxjf7r0gCs51wlZ3oYEp1E1GvM=.b817cf86-5f9a-4eee-87a4-4dc21916a95d@github.com>
Message-ID: <-aWQa-FWJuHcCk3h4xmp4jRxJITSa5JU3uxDzVBTFgI=.fca24c7b-bfb0-4133-be17-0c007f9c8834@github.com>

On Fri, 15 Jan 2021 08:18:07 GMT, Roland Westrelin <roland at openjdk.org> 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: <jFnqp62fpZtr_HoVF-IFx4orbnahRPf-lzf4APbWpRw=.28f9fe45-aae3-47c4-9d25-274ef1bdd96b@github.com>
References: <1aDWWln8xu9qmWLSgnGJOYlllvN_QfzJsRtW5qKFjbA=.a46186b0-14ff-4306-a44c-34b943a082da@github.com>
 <jFnqp62fpZtr_HoVF-IFx4orbnahRPf-lzf4APbWpRw=.28f9fe45-aae3-47c4-9d25-274ef1bdd96b@github.com>
Message-ID: <yQhQG5dOjY55apOo9Nxjf7r0gCs51wlZ3oYEp1E1GvM=.b817cf86-5f9a-4eee-87a4-4dc21916a95d@github.com>

On Thu, 14 Jan 2021 09:37:36 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
Message-ID: <u9ug8VY-adN6uO3Jxx_Nq7zzm20mE-OFaxz45aW_vyQ=.4629280e-f4a7-49c0-be89-d0267c42fede@github.com>

On Fri, 15 Jan 2021 08:09:56 GMT, Kazunori Ogata <ogatak at openjdk.org> 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: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>

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: <VOvdzQ5PysaUNMwlsUxVgp6xmFt8Wb32_YoE7QwPu74=.1fa26af0-160f-4cf2-86b1-79deb1193e2d@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

-------------

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: <j9F3HkJwMbEfyIhC2gIuPopeYVOX11fGaYay01GivBM=.44c1a553-fb06-4d65-ad66-2296c2eb4036@github.com>
References: <j9F3HkJwMbEfyIhC2gIuPopeYVOX11fGaYay01GivBM=.44c1a553-fb06-4d65-ad66-2296c2eb4036@github.com>
Message-ID: <b2V9szbeHIHh84rEr9u-0EsZPOoZ-DF0Lj9rOQakt3I=.7cc330d9-1b25-4c26-ba3d-f37092dbc411@github.com>

On Thu, 14 Jan 2021 13:13:21 GMT, Jatin Bhateja <jbhateja at openjdk.org> 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 <jbhateja at openjdk.org>
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: <VOvdzQ5PysaUNMwlsUxVgp6xmFt8Wb32_YoE7QwPu74=.1fa26af0-160f-4cf2-86b1-79deb1193e2d@github.com>
References: <VOvdzQ5PysaUNMwlsUxVgp6xmFt8Wb32_YoE7QwPu74=.1fa26af0-160f-4cf2-86b1-79deb1193e2d@github.com>
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: <P191VP0D-yut6hI_H0MUxcfJVp_egTPIxjUjnN9_-Bk=.f16b2ad3-de7c-4f01-bf20-c10c485ee6c6@github.com>

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: <P191VP0D-yut6hI_H0MUxcfJVp_egTPIxjUjnN9_-Bk=.f16b2ad3-de7c-4f01-bf20-c10c485ee6c6@github.com>
References: <P191VP0D-yut6hI_H0MUxcfJVp_egTPIxjUjnN9_-Bk=.f16b2ad3-de7c-4f01-bf20-c10c485ee6c6@github.com>
Message-ID: <u3YEmpSuRDd0JJFgNEjQVb49AygllVdw1w1TnwnZLpI=.80d4976b-3fa6-4bf9-a888-58b0f8f8a770@github.com>

On Fri, 15 Jan 2021 15:46:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> 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: <VXxT1b5P_CkzafEXZ7g43PAWS5JIS_31pGJa96wZY9M=.1c4fd268-af6a-4b52-b5ce-134ee0687236@github.com>

On Thu, 14 Jan 2021 08:14:18 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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: <u3YEmpSuRDd0JJFgNEjQVb49AygllVdw1w1TnwnZLpI=.80d4976b-3fa6-4bf9-a888-58b0f8f8a770@github.com>
References: <P191VP0D-yut6hI_H0MUxcfJVp_egTPIxjUjnN9_-Bk=.f16b2ad3-de7c-4f01-bf20-c10c485ee6c6@github.com>
 <u3YEmpSuRDd0JJFgNEjQVb49AygllVdw1w1TnwnZLpI=.80d4976b-3fa6-4bf9-a888-58b0f8f8a770@github.com>
Message-ID: <YWtAMz2N1xSgWgV6jJlmQBgZQzVNEN18G1NWkiJ0u58=.82570c0c-0b15-4721-a23d-443d647d832d@github.com>

On Fri, 15 Jan 2021 15:52:40 GMT, Vladimir Ivanov <vlivanov at openjdk.org> 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: <ux4GB5Gm_DlEzOHNIceUq2swBCh-2XeAc87cp6XQlYw=.7780387f-9d30-42ca-847b-eb499f97c624@github.com>
References: <P191VP0D-yut6hI_H0MUxcfJVp_egTPIxjUjnN9_-Bk=.f16b2ad3-de7c-4f01-bf20-c10c485ee6c6@github.com>
 <TgU02s_Cs08I4iCMjb-IU0jlbum9lpwwbOvPhnJ0pTs=.5e4aa014-768a-4c34-8563-82145948e4a7@github.com>
 <ux4GB5Gm_DlEzOHNIceUq2swBCh-2XeAc87cp6XQlYw=.7780387f-9d30-42ca-847b-eb499f97c624@github.com>
Message-ID: <XBpXpYMRhHrKPcauLwAFxt1Lx-Va3aieZMJaRPMP9qA=.55322859-a233-46d6-9fd9-5bb41dc2d6dd@github.com>

On Fri, 15 Jan 2021 16:26:22 GMT, Daniel D. Daugherty <dcubed at openjdk.org> 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: <TgU02s_Cs08I4iCMjb-IU0jlbum9lpwwbOvPhnJ0pTs=.5e4aa014-768a-4c34-8563-82145948e4a7@github.com>
References: <P191VP0D-yut6hI_H0MUxcfJVp_egTPIxjUjnN9_-Bk=.f16b2ad3-de7c-4f01-bf20-c10c485ee6c6@github.com>
 <TgU02s_Cs08I4iCMjb-IU0jlbum9lpwwbOvPhnJ0pTs=.5e4aa014-768a-4c34-8563-82145948e4a7@github.com>
Message-ID: <ux4GB5Gm_DlEzOHNIceUq2swBCh-2XeAc87cp6XQlYw=.7780387f-9d30-42ca-847b-eb499f97c624@github.com>

On Fri, 15 Jan 2021 16:22:56 GMT, Paul Sandoz <psandoz at openjdk.org> 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: <P191VP0D-yut6hI_H0MUxcfJVp_egTPIxjUjnN9_-Bk=.f16b2ad3-de7c-4f01-bf20-c10c485ee6c6@github.com>
References: <P191VP0D-yut6hI_H0MUxcfJVp_egTPIxjUjnN9_-Bk=.f16b2ad3-de7c-4f01-bf20-c10c485ee6c6@github.com>
Message-ID: <TgU02s_Cs08I4iCMjb-IU0jlbum9lpwwbOvPhnJ0pTs=.5e4aa014-768a-4c34-8563-82145948e4a7@github.com>

On Fri, 15 Jan 2021 15:46:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> 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: <P191VP0D-yut6hI_H0MUxcfJVp_egTPIxjUjnN9_-Bk=.f16b2ad3-de7c-4f01-bf20-c10c485ee6c6@github.com>
References: <P191VP0D-yut6hI_H0MUxcfJVp_egTPIxjUjnN9_-Bk=.f16b2ad3-de7c-4f01-bf20-c10c485ee6c6@github.com>
Message-ID: <7jdfUwB8XGEWHZzcPLimtIGTJOnU8puR4cV3XSczXes=.962b987c-2853-4730-b7b9-280492dd665b@github.com>

On Fri, 15 Jan 2021 15:46:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit a6b2162f5400b4596afa5b88219c9cb55dcdb729.

This pull request has now been integrated.

Changeset: b78cd633
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
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: <FkHxgZBG47EANdjrVUki6H09F_7EXMECjh82T4sK_fY=.bf99e038-d2f9-4e65-a34e-55fc602def5c@github.com>
References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com>
 <08g7HiFIZyPHlhan7KLe4_w9_BGQZPpnoDxtnzraj_s=.161392a6-49d6-4d40-9b56-cb188bafad82@github.com>
 <X5GnkHCqy99Q3C1HvhilvglCCdCEoy1dFWgnIbSpMMk=.3c47249e-c712-4cff-9ef7-e075977e40f5@github.com>
 <FkHxgZBG47EANdjrVUki6H09F_7EXMECjh82T4sK_fY=.bf99e038-d2f9-4e65-a34e-55fc602def5c@github.com>
Message-ID: <buRIVsYqGdbZ0gN0VeMih9vjdQB0rXT6_okN2FFg6rs=.59ba0b5c-6be7-4f00-add4-65a6dc037a00@github.com>

On Fri, 8 Jan 2021 17:30:20 GMT, Xin Liu <xliu at openjdk.org> 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: <fH9h67gWI8B8mszHYUTV6_t7X0kBJKGMnxAzXQ78i-0=.c0ebb6d6-adca-49d1-bf17-90ef5ad4adef@github.com>

On Wed, 6 Jan 2021 09:15:24 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <maHUTm4kdcl2qE7Ao79GTQ10gnzi3GE9Dy69iQh-KGM=.f8390d42-8038-40c7-a280-8d0751a1aa91@github.com>
References: <kQYbxKPFZRCZaz79blFr4liShnhidfEA_RcidQIe5Mg=.e080c2f5-1f5f-49b2-8c77-bcb42f5ca615@github.com>
 <maHUTm4kdcl2qE7Ao79GTQ10gnzi3GE9Dy69iQh-KGM=.f8390d42-8038-40c7-a280-8d0751a1aa91@github.com>
Message-ID: <8YBvI0H1IgBgW7v8mtSOxekjm1MqmgKcnKgm6yglgv8=.854cf89e-5335-4273-82c4-ba095ef657e7@github.com>

On Thu, 14 Jan 2021 19:27:28 GMT, Igor Ignatyev <iignatyev at openjdk.org> 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: <maHUTm4kdcl2qE7Ao79GTQ10gnzi3GE9Dy69iQh-KGM=.f8390d42-8038-40c7-a280-8d0751a1aa91@github.com>
References: <kQYbxKPFZRCZaz79blFr4liShnhidfEA_RcidQIe5Mg=.e080c2f5-1f5f-49b2-8c77-bcb42f5ca615@github.com>
 <maHUTm4kdcl2qE7Ao79GTQ10gnzi3GE9Dy69iQh-KGM=.f8390d42-8038-40c7-a280-8d0751a1aa91@github.com>
Message-ID: <HBsmD-4aXXxnWYe0wF-w_4Ma_mszThhd5kZFFg_jGLQ=.e088f26e-815d-4067-a7c6-6253c8dd30c8@github.com>

On Thu, 14 Jan 2021 19:27:28 GMT, Igor Ignatyev <iignatyev at openjdk.org> 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: <y2adaBFCMntCtbx60rq0MWwl0NSS2JEjDrx31F5gGW8=.0888e0df-816e-4351-b4db-d8a8ccad29b7@github.com>
References: <y2adaBFCMntCtbx60rq0MWwl0NSS2JEjDrx31F5gGW8=.0888e0df-816e-4351-b4db-d8a8ccad29b7@github.com>
Message-ID: <tc9byhpenY5EOzicOeopRwmaxqCf9btO5o7kwqTYETs=.ea5d5b24-2160-4fb6-81d5-1f0ce5521936@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:

  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: <VOvdzQ5PysaUNMwlsUxVgp6xmFt8Wb32_YoE7QwPu74=.1fa26af0-160f-4cf2-86b1-79deb1193e2d@github.com>
References: <VOvdzQ5PysaUNMwlsUxVgp6xmFt8Wb32_YoE7QwPu74=.1fa26af0-160f-4cf2-86b1-79deb1193e2d@github.com>
Message-ID: <WDiKHE6ievqP--UiIKVQ68_EvcD5M6-FwyQyq5sI5nw=.d3c29b66-dc08-4e70-ad28-d55f152a8315@github.com>

On Fri, 15 Jan 2021 13:40:04 GMT, Jie Fu <jiefu at openjdk.org> 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: <VOvdzQ5PysaUNMwlsUxVgp6xmFt8Wb32_YoE7QwPu74=.1fa26af0-160f-4cf2-86b1-79deb1193e2d@github.com>
References: <VOvdzQ5PysaUNMwlsUxVgp6xmFt8Wb32_YoE7QwPu74=.1fa26af0-160f-4cf2-86b1-79deb1193e2d@github.com>
Message-ID: <vldLVpVF9KqOZOlwK5jp0pKZSCDMirDyyxqawsmRrzE=.2c8904f9-c398-4820-8d74-47795c4c7602@github.com>

On Fri, 15 Jan 2021 13:40:04 GMT, Jie Fu <jiefu at openjdk.org> 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: <y2adaBFCMntCtbx60rq0MWwl0NSS2JEjDrx31F5gGW8=.0888e0df-816e-4351-b4db-d8a8ccad29b7@github.com>
References: <y2adaBFCMntCtbx60rq0MWwl0NSS2JEjDrx31F5gGW8=.0888e0df-816e-4351-b4db-d8a8ccad29b7@github.com>
Message-ID: <thBtSwpvUSkGgFRhcrlcexARFAPCbXDMeDfrauYj0cs=.fab34e5f-c953-474a-abdd-3f887a794bae@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:

  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: <y2adaBFCMntCtbx60rq0MWwl0NSS2JEjDrx31F5gGW8=.0888e0df-816e-4351-b4db-d8a8ccad29b7@github.com>
References: <y2adaBFCMntCtbx60rq0MWwl0NSS2JEjDrx31F5gGW8=.0888e0df-816e-4351-b4db-d8a8ccad29b7@github.com>
Message-ID: <dLrTemWSZpEagUZNo79yHqfF3KeU2mTOOn2LkZC_x-Q=.8598ddca-3e2e-41b2-950f-7fc0f1ee9853@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:

  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: <Jf1kSpMpzqanGbsLR8vAclhG3a0xD7oAayedxFF2bQI=.6ce2e4e8-37ce-4ac7-bde2-83633f38c9ba@github.com>
References: <urfdDMSaLblAhKDpN9xzeI1Bu-bq5dMUTrR69s-Ijvo=.442a09a2-c461-45b1-9f63-0083836ea3d9@github.com>
 <Hpy0wycBa9R5-OQ_0ti6Y6J3--VpoYUN0UbODVteGU4=.ec58c5cb-9b5b-4851-b2f9-959e3a675ed5@github.com>
 <bpqpCSsQrOmnJAKMHrwwxLoBZ0X5NgoTPLKjxUOpaiI=.e7571619-7daf-470c-a664-c1695b13cfae@github.com>
 <Jf1kSpMpzqanGbsLR8vAclhG3a0xD7oAayedxFF2bQI=.6ce2e4e8-37ce-4ac7-bde2-83633f38c9ba@github.com>
Message-ID: <fJ8KD7LfTJcJwE8iMrypVNTCjrGAatm7q1jwDdHxcjI=.092a4698-540b-47e4-ae67-9aaef5e7003a@github.com>

On Fri, 8 Jan 2021 09:21:31 GMT, Eric Liu <github.com+10482586+theRealELiu at openjdk.org> 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: <urfdDMSaLblAhKDpN9xzeI1Bu-bq5dMUTrR69s-Ijvo=.442a09a2-c461-45b1-9f63-0083836ea3d9@github.com>
References: <urfdDMSaLblAhKDpN9xzeI1Bu-bq5dMUTrR69s-Ijvo=.442a09a2-c461-45b1-9f63-0083836ea3d9@github.com>
Message-ID: <6jlowq1pLYpjWhNGGiYYkTHWKGbdsbb176mJvSzqpCc=.a9444615-8907-433b-ba69-12a9bba01650@github.com>

On Thu, 7 Jan 2021 08:07:16 GMT, Eric Liu <github.com+10482586+theRealELiu at openjdk.org> 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: <esNpiTcOlsg7Jmir1atOpG2TVr3itoQYfCgtYRNMw_E=.d1a6450f-f09d-4aff-9726-9415f5381108@github.com>

On Thu, 14 Jan 2021 08:05:25 GMT, Roland Westrelin <roland at openjdk.org> 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 <roland at openjdk.org>
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: <vzU7IblBH2MK4VleZHOIBp8DLiZBwIdLeFkhnndolmY=.af4a6cab-3f06-4158-88ac-56b6d3e052f7@github.com>
References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com>
 <vzU7IblBH2MK4VleZHOIBp8DLiZBwIdLeFkhnndolmY=.af4a6cab-3f06-4158-88ac-56b6d3e052f7@github.com>
Message-ID: <1D1jeHHwxAQG6IONoI01nZb8BFAyiq31OE40UJX_PKY=.2dc7fc85-68fa-4ab4-adb1-d4d75bde6332@github.com>

On Fri, 15 Jan 2021 02:13:19 GMT, Xin Liu <xliu at openjdk.org> 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: <FCDP_4_8Lz3W7aU5Db-h0gkKm7TUba4peuEyelczpEs=.02c3a15f-7535-43f1-a75e-3bd842fe106b@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 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: <VXxT1b5P_CkzafEXZ7g43PAWS5JIS_31pGJa96wZY9M=.1c4fd268-af6a-4b52-b5ce-134ee0687236@github.com>
References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com>
 <VXxT1b5P_CkzafEXZ7g43PAWS5JIS_31pGJa96wZY9M=.1c4fd268-af6a-4b52-b5ce-134ee0687236@github.com>
Message-ID: <04QzGEnxVy4JlX8wAjg9lHnB7TnTgfn5HjjNnfaIEtc=.027ec615-a810-43fb-b033-78cab38a0e73@github.com>

On Fri, 15 Jan 2021 15:54:23 GMT, Roland Westrelin <roland at openjdk.org> 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: <cv83E-f38PtWKwqrEZKMwbQpO52b7cS1JddP79nhBhA=.07a02fc3-8968-4883-bf81-2baf54611098@github.com>
References: <cv83E-f38PtWKwqrEZKMwbQpO52b7cS1JddP79nhBhA=.07a02fc3-8968-4883-bf81-2baf54611098@github.com>
Message-ID: <rTyVu0u8u5cB-V1ehaMzgJUsSVzYtguXtvSTslJiUHo=.bd515558-e491-45e9-81f0-1e8e4cd968d0@github.com>

On Wed, 13 Jan 2021 14:51:44 GMT, Thomas Stuefe <stuefe at openjdk.org> 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<Compile::PrintInliningBuffer, GrowableArray<Compile::PrintInliningBuffer> >::grow(int)+0x163
> 1434780 [0x00007f5820c7160e] GrowableArrayWithAllocator<Compile::PrintInliningBuffer, GrowableArray<Compile::PrintInliningBuffer> >::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<PrintInliningBuffer>* _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 <typename E, typename Derived>
> void GrowableArrayWithAllocator<E, Derived>::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<E, Derived>::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: <rwzWXgqcVbAb2Hx8um3PxqVyhJf7kWlYl-yZhTdOsRg=.b87903d0-9685-4cc2-a2b7-b4c01b768d4e@github.com>
References: <J0Kj7AiqCi5l8cNV1YRmcPu005hmLgeCbBCurQ2hwHc=.aaec0d99-c0f0-4b6a-b492-d08c07b46806@github.com>
 <FKJVN1xvWtlbCZsSXq6GE5FqHWxR7Yzb3id3wsFxIxQ=.dff74d7a-b81b-428f-a224-389fd902efb7@github.com>
 <rwzWXgqcVbAb2Hx8um3PxqVyhJf7kWlYl-yZhTdOsRg=.b87903d0-9685-4cc2-a2b7-b4c01b768d4e@github.com>
Message-ID: <BfKzL0wA4iGX5qNPBT8mWmJGsYFJfvoJyW9yKHXeGw8=.823ef615-5aa2-474d-a7f2-b8da145dfe92@github.com>

On Wed, 13 Jan 2021 13:40:40 GMT, Roland Westrelin <roland at openjdk.org> 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<T1>(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: <J0Kj7AiqCi5l8cNV1YRmcPu005hmLgeCbBCurQ2hwHc=.aaec0d99-c0f0-4b6a-b492-d08c07b46806@github.com>
References: <J0Kj7AiqCi5l8cNV1YRmcPu005hmLgeCbBCurQ2hwHc=.aaec0d99-c0f0-4b6a-b492-d08c07b46806@github.com>
Message-ID: <rkMQ41Li3sXxEwsgerxQ4sqsh-thIqhjIAyHXmwvWLg=.ba240daf-2a72-45cf-9c21-d1ba276ffe97@github.com>

> 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<T1>(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: <BfKzL0wA4iGX5qNPBT8mWmJGsYFJfvoJyW9yKHXeGw8=.823ef615-5aa2-474d-a7f2-b8da145dfe92@github.com>
References: <J0Kj7AiqCi5l8cNV1YRmcPu005hmLgeCbBCurQ2hwHc=.aaec0d99-c0f0-4b6a-b492-d08c07b46806@github.com>
 <FKJVN1xvWtlbCZsSXq6GE5FqHWxR7Yzb3id3wsFxIxQ=.dff74d7a-b81b-428f-a224-389fd902efb7@github.com>
 <rwzWXgqcVbAb2Hx8um3PxqVyhJf7kWlYl-yZhTdOsRg=.b87903d0-9685-4cc2-a2b7-b4c01b768d4e@github.com>
 <BfKzL0wA4iGX5qNPBT8mWmJGsYFJfvoJyW9yKHXeGw8=.823ef615-5aa2-474d-a7f2-b8da145dfe92@github.com>
Message-ID: <SFz21foygsaDNPXC6UnPhhYK-IWKDSw9eLmXXqKR03E=.78312628-c620-41f5-a45a-fa3a7a57244a@github.com>

On Mon, 18 Jan 2021 11:49:13 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <vzU7IblBH2MK4VleZHOIBp8DLiZBwIdLeFkhnndolmY=.af4a6cab-3f06-4158-88ac-56b6d3e052f7@github.com>
References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com>
 <vzU7IblBH2MK4VleZHOIBp8DLiZBwIdLeFkhnndolmY=.af4a6cab-3f06-4158-88ac-56b6d3e052f7@github.com>
Message-ID: <RhnEAW7bC4_lWXnHLIGvbqiAUJsmtTr0RGqI92_DB1w=.bfd12db4-8832-49ed-bc14-d4363217a148@github.com>

On Fri, 15 Jan 2021 02:13:19 GMT, Xin Liu <xliu at openjdk.org> 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: <p3bQhMuN7Y5E7So2ySADd9MaA2_exHdE0AeW9D8xY-0=.c62142b5-8109-4573-bbd6-f104ecbcd041@github.com>

On Mon, 28 Dec 2020 09:48:29 GMT, Xin Liu <xliu at openjdk.org> 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 <xliu at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
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: <RhnEAW7bC4_lWXnHLIGvbqiAUJsmtTr0RGqI92_DB1w=.bfd12db4-8832-49ed-bc14-d4363217a148@github.com>
References: <7drjvRBDcf1WYrfJmVyQ_OLJPGKT99A-cqdOucbKba4=.d0d5a88d-f612-441f-bb22-563291d58804@github.com>
 <vzU7IblBH2MK4VleZHOIBp8DLiZBwIdLeFkhnndolmY=.af4a6cab-3f06-4158-88ac-56b6d3e052f7@github.com>
 <RhnEAW7bC4_lWXnHLIGvbqiAUJsmtTr0RGqI92_DB1w=.bfd12db4-8832-49ed-bc14-d4363217a148@github.com>
Message-ID: <9hyUgbUuuDIw108BdCTUsWQupGNdQ949AAKblIiULxM=.b89a3302-05a9-46e0-bc10-47b9c0119af1@github.com>

On Mon, 18 Jan 2021 22:32:32 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <rhvFRRIHoJStEfM5h3B7zpXzq43bE85wFQ5xHmZRepk=.330e5488-bdd3-4dc8-bb42-b3c7d6cd3f76@github.com>
References: <rhvFRRIHoJStEfM5h3B7zpXzq43bE85wFQ5xHmZRepk=.330e5488-bdd3-4dc8-bb42-b3c7d6cd3f76@github.com>
Message-ID: <ywAR-IrSjBhoUAx-hlb2R6XpV3AtK5LR3OqxcZZk-tI=.8d8f3a32-99c0-43d9-8b0d-fdf488a59dd4@github.com>

On Sun, 3 Jan 2021 04:46:10 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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: <y2adaBFCMntCtbx60rq0MWwl0NSS2JEjDrx31F5gGW8=.0888e0df-816e-4351-b4db-d8a8ccad29b7@github.com>
References: <y2adaBFCMntCtbx60rq0MWwl0NSS2JEjDrx31F5gGW8=.0888e0df-816e-4351-b4db-d8a8ccad29b7@github.com>
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: <rTyVu0u8u5cB-V1ehaMzgJUsSVzYtguXtvSTslJiUHo=.bd515558-e491-45e9-81f0-1e8e4cd968d0@github.com>
References: <cv83E-f38PtWKwqrEZKMwbQpO52b7cS1JddP79nhBhA=.07a02fc3-8968-4883-bf81-2baf54611098@github.com>
 <rTyVu0u8u5cB-V1ehaMzgJUsSVzYtguXtvSTslJiUHo=.bd515558-e491-45e9-81f0-1e8e4cd968d0@github.com>
Message-ID: <4ONcTjZt6YQKyWyuZ87LPSe2GYVAr70qPSWq8cXoxsI=.e9b59bb5-2fbe-4710-980b-86fe142392a1@github.com>

On Mon, 18 Jan 2021 11:25:32 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <cv83E-f38PtWKwqrEZKMwbQpO52b7cS1JddP79nhBhA=.07a02fc3-8968-4883-bf81-2baf54611098@github.com>
References: <cv83E-f38PtWKwqrEZKMwbQpO52b7cS1JddP79nhBhA=.07a02fc3-8968-4883-bf81-2baf54611098@github.com>
Message-ID: <q8fwFU4vf_6Y7zsW53zjHi69iinb2X1Vyo4MlpOqTMg=.4246a623-fb83-4faa-bcc4-18b5d3e0bcb3@github.com>

> We see C-heap leaking, originating in C2:
> 
> 1434777 [0x00007f58214af461] stringStream::stringStream(unsigned long)+0x55
> 1434778 [0x00007f5820c6db3e] Compile::PrintInliningBuffer::PrintInliningBuffer()+0x6c
> 1434779 [0x00007f5820c724f1] GrowableArrayWithAllocator<Compile::PrintInliningBuffer, GrowableArray<Compile::PrintInliningBuffer> >::grow(int)+0x163
> 1434780 [0x00007f5820c7160e] GrowableArrayWithAllocator<Compile::PrintInliningBuffer, GrowableArray<Compile::PrintInliningBuffer> >::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<PrintInliningBuffer>* _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 <typename E, typename Derived>
> void GrowableArrayWithAllocator<E, Derived>::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<E, Derived>::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: <FCDP_4_8Lz3W7aU5Db-h0gkKm7TUba4peuEyelczpEs=.02c3a15f-7535-43f1-a75e-3bd842fe106b@github.com>
References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com>
 <FCDP_4_8Lz3W7aU5Db-h0gkKm7TUba4peuEyelczpEs=.02c3a15f-7535-43f1-a75e-3bd842fe106b@github.com>
Message-ID: <mJoivMI1PutzkuMzqm-HaSMjLgvcv6Pojv58Z01GKbk=.14cab893-5e35-4795-8513-4023262cf6bb@github.com>

On Mon, 18 Jan 2021 09:41:10 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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: <rhvFRRIHoJStEfM5h3B7zpXzq43bE85wFQ5xHmZRepk=.330e5488-bdd3-4dc8-bb42-b3c7d6cd3f76@github.com>
References: <rhvFRRIHoJStEfM5h3B7zpXzq43bE85wFQ5xHmZRepk=.330e5488-bdd3-4dc8-bb42-b3c7d6cd3f76@github.com>
Message-ID: <9-rJErG5y8QPIqw5h8GIE7rduADBW2-l8cMUU6ii8zE=.9bef70ff-f3cb-47c4-b325-d26f784f0cab@github.com>

On Sun, 3 Jan 2021 04:46:10 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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: <SFz21foygsaDNPXC6UnPhhYK-IWKDSw9eLmXXqKR03E=.78312628-c620-41f5-a45a-fa3a7a57244a@github.com>
References: <J0Kj7AiqCi5l8cNV1YRmcPu005hmLgeCbBCurQ2hwHc=.aaec0d99-c0f0-4b6a-b492-d08c07b46806@github.com>
 <FKJVN1xvWtlbCZsSXq6GE5FqHWxR7Yzb3id3wsFxIxQ=.dff74d7a-b81b-428f-a224-389fd902efb7@github.com>
 <rwzWXgqcVbAb2Hx8um3PxqVyhJf7kWlYl-yZhTdOsRg=.b87903d0-9685-4cc2-a2b7-b4c01b768d4e@github.com>
 <BfKzL0wA4iGX5qNPBT8mWmJGsYFJfvoJyW9yKHXeGw8=.823ef615-5aa2-474d-a7f2-b8da145dfe92@github.com>
 <SFz21foygsaDNPXC6UnPhhYK-IWKDSw9eLmXXqKR03E=.78312628-c620-41f5-a45a-fa3a7a57244a@github.com>
Message-ID: <1kBolNZOhOFBD5aNq5rLF8RheC37JN794IJFy9Tf_UM=.f25e5227-03ee-465a-97a1-3fb886b79a43@github.com>

On Mon, 18 Jan 2021 13:34:16 GMT, Roland Westrelin <roland at openjdk.org> 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: <rhvFRRIHoJStEfM5h3B7zpXzq43bE85wFQ5xHmZRepk=.330e5488-bdd3-4dc8-bb42-b3c7d6cd3f76@github.com>
References: <rhvFRRIHoJStEfM5h3B7zpXzq43bE85wFQ5xHmZRepk=.330e5488-bdd3-4dc8-bb42-b3c7d6cd3f76@github.com>
Message-ID: <vhYmTSkR5kSl7zDTtaxYbEnqVNVY8uPxDd7ImiD3Obs=.3f7db785-e436-41a8-8409-95166d77a1c6@github.com>

On Sun, 3 Jan 2021 04:46:10 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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 <ysuenaga at openjdk.org>
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: <q8fwFU4vf_6Y7zsW53zjHi69iinb2X1Vyo4MlpOqTMg=.4246a623-fb83-4faa-bcc4-18b5d3e0bcb3@github.com>
References: <cv83E-f38PtWKwqrEZKMwbQpO52b7cS1JddP79nhBhA=.07a02fc3-8968-4883-bf81-2baf54611098@github.com>
 <q8fwFU4vf_6Y7zsW53zjHi69iinb2X1Vyo4MlpOqTMg=.4246a623-fb83-4faa-bcc4-18b5d3e0bcb3@github.com>
Message-ID: <MOG2b6RWw1Ov4RZbeXApThctEC2so8y7TtbvI9gqiJs=.a969df6f-e637-49b1-980c-4e894f8dcedb@github.com>

On Tue, 19 Jan 2021 06:06:17 GMT, Thomas Stuefe <stuefe at openjdk.org> 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<Compile::PrintInliningBuffer, GrowableArray<Compile::PrintInliningBuffer> >::grow(int)+0x163
>> 1434780 [0x00007f5820c7160e] GrowableArrayWithAllocator<Compile::PrintInliningBuffer, GrowableArray<Compile::PrintInliningBuffer> >::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<PrintInliningBuffer>* _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 <typename E, typename Derived>
>> void GrowableArrayWithAllocator<E, Derived>::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<E, Derived>::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: <MOG2b6RWw1Ov4RZbeXApThctEC2so8y7TtbvI9gqiJs=.a969df6f-e637-49b1-980c-4e894f8dcedb@github.com>
References: <cv83E-f38PtWKwqrEZKMwbQpO52b7cS1JddP79nhBhA=.07a02fc3-8968-4883-bf81-2baf54611098@github.com>
 <q8fwFU4vf_6Y7zsW53zjHi69iinb2X1Vyo4MlpOqTMg=.4246a623-fb83-4faa-bcc4-18b5d3e0bcb3@github.com>
 <MOG2b6RWw1Ov4RZbeXApThctEC2so8y7TtbvI9gqiJs=.a969df6f-e637-49b1-980c-4e894f8dcedb@github.com>
Message-ID: <gKkxc20c0_6poB4avuIWNZGoCUN2KHiM1Cu7o0UnM8o=.6cae892d-22ee-4ce0-a8ae-b48ec44441ed@github.com>

On Tue, 19 Jan 2021 08:47:35 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <cv83E-f38PtWKwqrEZKMwbQpO52b7cS1JddP79nhBhA=.07a02fc3-8968-4883-bf81-2baf54611098@github.com>
References: <cv83E-f38PtWKwqrEZKMwbQpO52b7cS1JddP79nhBhA=.07a02fc3-8968-4883-bf81-2baf54611098@github.com>
Message-ID: <v9gJJ-LSgxtbPtwN79NQUjHmektOaY5-X3gpNRAgoLY=.f7ebdd2a-d5ba-4721-89ec-4ea0bba4891d@github.com>

> We see C-heap leaking, originating in C2:
> 
> 1434777 [0x00007f58214af461] stringStream::stringStream(unsigned long)+0x55
> 1434778 [0x00007f5820c6db3e] Compile::PrintInliningBuffer::PrintInliningBuffer()+0x6c
> 1434779 [0x00007f5820c724f1] GrowableArrayWithAllocator<Compile::PrintInliningBuffer, GrowableArray<Compile::PrintInliningBuffer> >::grow(int)+0x163
> 1434780 [0x00007f5820c7160e] GrowableArrayWithAllocator<Compile::PrintInliningBuffer, GrowableArray<Compile::PrintInliningBuffer> >::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<PrintInliningBuffer>* _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 <typename E, typename Derived>
> void GrowableArrayWithAllocator<E, Derived>::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<E, Derived>::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: <a-D-fJ_rL4ntXm9BRLr9MF1xdjxD8-qhzdiGGIM2uXk=.c24640e2-92f4-4518-bbba-e7f0504e8e2d@github.com>

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: <VMq5l7qqmyryiukK2Ug23hAxDyQTbACrZpV06SbGzPE=.d9198af8-dec4-4b81-b483-ccc6937733f8@github.com>

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: <VMq5l7qqmyryiukK2Ug23hAxDyQTbACrZpV06SbGzPE=.d9198af8-dec4-4b81-b483-ccc6937733f8@github.com>
References: <VMq5l7qqmyryiukK2Ug23hAxDyQTbACrZpV06SbGzPE=.d9198af8-dec4-4b81-b483-ccc6937733f8@github.com>
Message-ID: <O0O8yYnkyji3qZXGkfXkH362GwYhWKq5DZQGAXfscYA=.9e532882-7549-411d-abfd-3f6ad80f48b0@github.com>

On Tue, 19 Jan 2021 08:32:42 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> 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: <a-D-fJ_rL4ntXm9BRLr9MF1xdjxD8-qhzdiGGIM2uXk=.c24640e2-92f4-4518-bbba-e7f0504e8e2d@github.com>
References: <a-D-fJ_rL4ntXm9BRLr9MF1xdjxD8-qhzdiGGIM2uXk=.c24640e2-92f4-4518-bbba-e7f0504e8e2d@github.com>
Message-ID: <WNZYlIlhRd5RGW84k3tWJT7ODtbouMBneIkgCxsIi5s=.99f9822c-38a9-4d41-b11b-f90531f25710@github.com>

On Mon, 18 Jan 2021 14:39:05 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <WNZYlIlhRd5RGW84k3tWJT7ODtbouMBneIkgCxsIi5s=.99f9822c-38a9-4d41-b11b-f90531f25710@github.com>
References: <a-D-fJ_rL4ntXm9BRLr9MF1xdjxD8-qhzdiGGIM2uXk=.c24640e2-92f4-4518-bbba-e7f0504e8e2d@github.com>
 <WNZYlIlhRd5RGW84k3tWJT7ODtbouMBneIkgCxsIi5s=.99f9822c-38a9-4d41-b11b-f90531f25710@github.com>
Message-ID: <tnKE0aWm_qe3uoJI3S-HdyaBnOZKF7oXquR6MvgIANs=.06bb320e-7662-43d5-922e-f87525664161@github.com>

On Tue, 19 Jan 2021 19:12:32 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <m7HPpbiNt-o8XJS-EDDGsT2V4cH3UAs6Sm57Dmh2hPE=.ad3c7d7c-d473-4c5c-a626-6db46aa00a8b@github.com>

On Mon, 18 Jan 2021 12:09:23 GMT, Claes Redestad <redestad at openjdk.org> 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: <m7HPpbiNt-o8XJS-EDDGsT2V4cH3UAs6Sm57Dmh2hPE=.ad3c7d7c-d473-4c5c-a626-6db46aa00a8b@github.com>
References: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com>
 <m7HPpbiNt-o8XJS-EDDGsT2V4cH3UAs6Sm57Dmh2hPE=.ad3c7d7c-d473-4c5c-a626-6db46aa00a8b@github.com>
Message-ID: <nIC8N4izer4jmVMPxp-QgH7D3iv683xfolDk9pVwPuQ=.44998dec-701d-474f-817a-09b76061a313@github.com>

On Tue, 19 Jan 2021 19:42:38 GMT, Mandy Chung <mchung at openjdk.org> 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: <nIC8N4izer4jmVMPxp-QgH7D3iv683xfolDk9pVwPuQ=.44998dec-701d-474f-817a-09b76061a313@github.com>
References: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com>
 <m7HPpbiNt-o8XJS-EDDGsT2V4cH3UAs6Sm57Dmh2hPE=.ad3c7d7c-d473-4c5c-a626-6db46aa00a8b@github.com>
 <nIC8N4izer4jmVMPxp-QgH7D3iv683xfolDk9pVwPuQ=.44998dec-701d-474f-817a-09b76061a313@github.com>
Message-ID: <a597002b-aa4d-51a2-4c66-be4a17019ec9@oracle.com>



On 1/19/21 12:33 PM, Claes Redestad wrote:
> On Tue, 19 Jan 2021 19:42:38 GMT, Mandy Chung <mchung at openjdk.org> 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: <nIC8N4izer4jmVMPxp-QgH7D3iv683xfolDk9pVwPuQ=.44998dec-701d-474f-817a-09b76061a313@github.com>
References: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com>
 <m7HPpbiNt-o8XJS-EDDGsT2V4cH3UAs6Sm57Dmh2hPE=.ad3c7d7c-d473-4c5c-a626-6db46aa00a8b@github.com>
 <nIC8N4izer4jmVMPxp-QgH7D3iv683xfolDk9pVwPuQ=.44998dec-701d-474f-817a-09b76061a313@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 <redestad at openjdk.org> 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>
 <m7HPpbiNt-o8XJS-EDDGsT2V4cH3UAs6Sm57Dmh2hPE=.ad3c7d7c-d473-4c5c-a626-6db46aa00a8b@github.com>
 <nIC8N4izer4jmVMPxp-QgH7D3iv683xfolDk9pVwPuQ=.44998dec-701d-474f-817a-09b76061a313@github.com>
 <-XDe9bewjmDiiXLXhMk-dSK7xveyopFdNn8r0-599bk=.d2a712cd-d338-47d8-aaaa-f8fb58bd34b8@github.com>
Message-ID: <FZx04R-GCksX8rhyyWnT_YuaIVqx4q5oQ3eHUO0q9A0=.a6706018-a4af-48f0-ba47-84b96203bdb0@github.com>

On Tue, 19 Jan 2021 20:59:24 GMT, Claes Redestad <redestad at openjdk.org> 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: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
Message-ID: <cn2Uv9tsliCUf23eCS1FD_oBmhrU1eApyAfYcQso9Lo=.368bfc16-d35f-4247-ad4f-1e7892534375@github.com>

> _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" <hotspot-dev-retn at openjdk.java.net on behalf of cjplummer at openjdk.java.net> wrote:

    On Mon, 11 Jan 2021 18:39:41 GMT, Lutz Schmidt <lucy at openjdk.org> 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: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
Message-ID: <jwsbsovXCh06yPPlH9-MMt0irvcSqFy5pg2ezYDyj9Q=.3c970377-7775-4e05-a3ca-e6aa47901a27@github.com>

> _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: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
Message-ID: <F_-CQS59WBsJ6jpxNyuPyV0TQr8lepZkAGJ7icStV7M=.4c7b98d2-afc4-40e3-b1c7-f58e96170702@github.com>

On Wed, 16 Dec 2020 18:38:37 GMT, Dan <github.com+7991079+danlemmond at openjdk.org> 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: <yOa5cjD0UUG8W75oTNVsdWw20szOxED5N3PIbtn6Q6w=.34d0ff22-eee5-4b1a-b646-8abfa772b6e6@github.com>
References: <55VhodtLlLULjpxGm3PXOn2iFgrVIdqcZwysOSEK8rg=.d1571446-fc26-4b7d-9450-29ecacb31dda@github.com>
 <yOa5cjD0UUG8W75oTNVsdWw20szOxED5N3PIbtn6Q6w=.34d0ff22-eee5-4b1a-b646-8abfa772b6e6@github.com>
Message-ID: <J4NxZ64ymNBTeI-FUqj16pYG-LxIUoLqWwhcm59vZ6Q=.79d6c0ab-9512-425f-a25a-a202e1cc5fc5@github.com>

On Tue, 19 Jan 2021 22:23:38 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <J0Kj7AiqCi5l8cNV1YRmcPu005hmLgeCbBCurQ2hwHc=.aaec0d99-c0f0-4b6a-b492-d08c07b46806@github.com>
References: <J0Kj7AiqCi5l8cNV1YRmcPu005hmLgeCbBCurQ2hwHc=.aaec0d99-c0f0-4b6a-b492-d08c07b46806@github.com>
Message-ID: <iFQyPXcZCNA6TDoZUxHgLNy1t3pBuqcrONWmLkZnuw4=.c4cc12d2-a337-49d2-99ee-f567fd2295b2@github.com>

> 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<T1>(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: <J0Kj7AiqCi5l8cNV1YRmcPu005hmLgeCbBCurQ2hwHc=.aaec0d99-c0f0-4b6a-b492-d08c07b46806@github.com>
 <FKJVN1xvWtlbCZsSXq6GE5FqHWxR7Yzb3id3wsFxIxQ=.dff74d7a-b81b-428f-a224-389fd902efb7@github.com>
 <rwzWXgqcVbAb2Hx8um3PxqVyhJf7kWlYl-yZhTdOsRg=.b87903d0-9685-4cc2-a2b7-b4c01b768d4e@github.com>
 <BfKzL0wA4iGX5qNPBT8mWmJGsYFJfvoJyW9yKHXeGw8=.823ef615-5aa2-474d-a7f2-b8da145dfe92@github.com>
 <SFz21foygsaDNPXC6UnPhhYK-IWKDSw9eLmXXqKR03E=.78312628-c620-41f5-a45a-fa3a7a57244a@github.com>
 <1kBolNZOhOFBD5aNq5rLF8RheC37JN794IJFy9Tf_UM=.f25e5227-03ee-465a-97a1-3fb886b79a43@github.com>
Message-ID: <abojW-JlEPJ1k1AX4Xx6oaCvCf0u3sgOR4p1gHzhO58=.46222b9a-230b-47ec-8c83-5544e2d9bcfd@github.com>

On Tue, 19 Jan 2021 08:57:28 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <v9gJJ-LSgxtbPtwN79NQUjHmektOaY5-X3gpNRAgoLY=.f7ebdd2a-d5ba-4721-89ec-4ea0bba4891d@github.com>
References: <cv83E-f38PtWKwqrEZKMwbQpO52b7cS1JddP79nhBhA=.07a02fc3-8968-4883-bf81-2baf54611098@github.com>
 <v9gJJ-LSgxtbPtwN79NQUjHmektOaY5-X3gpNRAgoLY=.f7ebdd2a-d5ba-4721-89ec-4ea0bba4891d@github.com>
Message-ID: <QHcPppgCQLP4rsoUibJuoIImQo7gWfZ-Z_81Xkf3rto=.ec450a09-0a14-4ad7-a9fc-545803aea801@github.com>

On Tue, 19 Jan 2021 09:22:07 GMT, Thomas Stuefe <stuefe at openjdk.org> 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<Compile::PrintInliningBuffer, GrowableArray<Compile::PrintInliningBuffer> >::grow(int)+0x163
>> 1434780 [0x00007f5820c7160e] GrowableArrayWithAllocator<Compile::PrintInliningBuffer, GrowableArray<Compile::PrintInliningBuffer> >::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<PrintInliningBuffer>* _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 <typename E, typename Derived>
>> void GrowableArrayWithAllocator<E, Derived>::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<E, Derived>::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: <tnKE0aWm_qe3uoJI3S-HdyaBnOZKF7oXquR6MvgIANs=.06bb320e-7662-43d5-922e-f87525664161@github.com>
References: <a-D-fJ_rL4ntXm9BRLr9MF1xdjxD8-qhzdiGGIM2uXk=.c24640e2-92f4-4518-bbba-e7f0504e8e2d@github.com>
 <WNZYlIlhRd5RGW84k3tWJT7ODtbouMBneIkgCxsIi5s=.99f9822c-38a9-4d41-b11b-f90531f25710@github.com>
 <tnKE0aWm_qe3uoJI3S-HdyaBnOZKF7oXquR6MvgIANs=.06bb320e-7662-43d5-922e-f87525664161@github.com>
Message-ID: <jIgmrtoJDbWeP_EMh2XLzaFcCR3ivw7XtBvFsMKycBc=.9f80c468-6585-4fe8-ada5-81e8b0204aed@github.com>

On Tue, 19 Jan 2021 19:29:09 GMT, Igor Ignatyev <iignatyev at openjdk.org> 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: <AM4PR02MB3057E0F28320A6558C3D81279AA20@AM4PR02MB3057.eurprd02.prod.outlook.com>

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: <y2adaBFCMntCtbx60rq0MWwl0NSS2JEjDrx31F5gGW8=.0888e0df-816e-4351-b4db-d8a8ccad29b7@github.com>
References: <y2adaBFCMntCtbx60rq0MWwl0NSS2JEjDrx31F5gGW8=.0888e0df-816e-4351-b4db-d8a8ccad29b7@github.com>
Message-ID: <RJISoRn-O6qUcIFumVGKDUncoRBOYi718-rP6lqOnnM=.7abc8bc7-c8c5-48e1-b594-c4b3fe95fe15@github.com>

On Thu, 14 Jan 2021 12:32:41 GMT, Jie Fu <jiefu at openjdk.org> 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: <mJoivMI1PutzkuMzqm-HaSMjLgvcv6Pojv58Z01GKbk=.14cab893-5e35-4795-8513-4023262cf6bb@github.com>
References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com>
 <FCDP_4_8Lz3W7aU5Db-h0gkKm7TUba4peuEyelczpEs=.02c3a15f-7535-43f1-a75e-3bd842fe106b@github.com>
 <mJoivMI1PutzkuMzqm-HaSMjLgvcv6Pojv58Z01GKbk=.14cab893-5e35-4795-8513-4023262cf6bb@github.com>
Message-ID: <SmOM7NUvxAepuvAzcV8cc71uyJhDH5e-m6yAadFUxtE=.dbdf39e9-3d83-4b45-be51-0753cdc69cbe@github.com>

On Tue, 19 Jan 2021 08:19:00 GMT, Roland Westrelin <roland at openjdk.org> 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: <nAQgw4iJ5GmIDDUgxabTfc5KJtXIRuGZgemr4lhFKZs=.a19164d1-efd9-4e13-8743-8b674adc637d@github.com>

On Mon, 18 Jan 2021 12:09:23 GMT, Claes Redestad <redestad at openjdk.org> 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:      * <p>
> 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: <U0LblCKAABmRc_UgXT2Yc1F1ER3qDrfEyytLQzN_lMo=.a55e54ca-93ae-4e77-9c85-be8ea3538ebd@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 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: <y2adaBFCMntCtbx60rq0MWwl0NSS2JEjDrx31F5gGW8=.0888e0df-816e-4351-b4db-d8a8ccad29b7@github.com>
 <5ZRm7yr18uW4HQWoMQHlI1CHdqUa70mbcj7r6PkROKU=.e5991488-7d71-4657-95c3-8a034b654db6@github.com>
Message-ID: <QhwPoBGSVtXQMvi5ncJR4elrIcxXooooyD4ni3z7giU=.ef7cb487-13ea-4b8e-b9a1-0f9c4a24c994@github.com>

On Tue, 19 Jan 2021 03:57:16 GMT, Jie Fu <jiefu at openjdk.org> 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: <y2adaBFCMntCtbx60rq0MWwl0NSS2JEjDrx31F5gGW8=.0888e0df-816e-4351-b4db-d8a8ccad29b7@github.com>
 <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 <jiefu at openjdk.org> 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: <jIgmrtoJDbWeP_EMh2XLzaFcCR3ivw7XtBvFsMKycBc=.9f80c468-6585-4fe8-ada5-81e8b0204aed@github.com>
References: <a-D-fJ_rL4ntXm9BRLr9MF1xdjxD8-qhzdiGGIM2uXk=.c24640e2-92f4-4518-bbba-e7f0504e8e2d@github.com>
 <WNZYlIlhRd5RGW84k3tWJT7ODtbouMBneIkgCxsIi5s=.99f9822c-38a9-4d41-b11b-f90531f25710@github.com>
 <tnKE0aWm_qe3uoJI3S-HdyaBnOZKF7oXquR6MvgIANs=.06bb320e-7662-43d5-922e-f87525664161@github.com>
 <jIgmrtoJDbWeP_EMh2XLzaFcCR3ivw7XtBvFsMKycBc=.9f80c468-6585-4fe8-ada5-81e8b0204aed@github.com>
Message-ID: <NRxDZtayC6wS0h-m-lCWL9qARJSBgy0TmcVEebB9nMA=.ebedfcfe-0b5b-45bb-b5cb-256848d8654f@github.com>

On Wed, 20 Jan 2021 08:23:26 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <NRxDZtayC6wS0h-m-lCWL9qARJSBgy0TmcVEebB9nMA=.ebedfcfe-0b5b-45bb-b5cb-256848d8654f@github.com>
References: <a-D-fJ_rL4ntXm9BRLr9MF1xdjxD8-qhzdiGGIM2uXk=.c24640e2-92f4-4518-bbba-e7f0504e8e2d@github.com>
 <WNZYlIlhRd5RGW84k3tWJT7ODtbouMBneIkgCxsIi5s=.99f9822c-38a9-4d41-b11b-f90531f25710@github.com>
 <tnKE0aWm_qe3uoJI3S-HdyaBnOZKF7oXquR6MvgIANs=.06bb320e-7662-43d5-922e-f87525664161@github.com>
 <jIgmrtoJDbWeP_EMh2XLzaFcCR3ivw7XtBvFsMKycBc=.9f80c468-6585-4fe8-ada5-81e8b0204aed@github.com>
 <NRxDZtayC6wS0h-m-lCWL9qARJSBgy0TmcVEebB9nMA=.ebedfcfe-0b5b-45bb-b5cb-256848d8654f@github.com>
Message-ID: <d3Y3VkzIH3QTH-6nYAOt3Rf5zHp4huH_Vz9XAEC__P4=.a9f86f58-2932-47fb-96dd-a364424eb815@github.com>

On Wed, 20 Jan 2021 16:10:11 GMT, Igor Ignatyev <iignatyev at openjdk.org> 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: <d3Y3VkzIH3QTH-6nYAOt3Rf5zHp4huH_Vz9XAEC__P4=.a9f86f58-2932-47fb-96dd-a364424eb815@github.com>
References: <a-D-fJ_rL4ntXm9BRLr9MF1xdjxD8-qhzdiGGIM2uXk=.c24640e2-92f4-4518-bbba-e7f0504e8e2d@github.com>
 <WNZYlIlhRd5RGW84k3tWJT7ODtbouMBneIkgCxsIi5s=.99f9822c-38a9-4d41-b11b-f90531f25710@github.com>
 <tnKE0aWm_qe3uoJI3S-HdyaBnOZKF7oXquR6MvgIANs=.06bb320e-7662-43d5-922e-f87525664161@github.com>
 <jIgmrtoJDbWeP_EMh2XLzaFcCR3ivw7XtBvFsMKycBc=.9f80c468-6585-4fe8-ada5-81e8b0204aed@github.com>
 <NRxDZtayC6wS0h-m-lCWL9qARJSBgy0TmcVEebB9nMA=.ebedfcfe-0b5b-45bb-b5cb-256848d8654f@github.com>
 <d3Y3VkzIH3QTH-6nYAOt3Rf5zHp4huH_Vz9XAEC__P4=.a9f86f58-2932-47fb-96dd-a364424eb815@github.com>
Message-ID: <XVggMCten17uvuLzx4QkP5Ny7VyxR4bTWU7pQckEcFk=.bdabacd9-376c-45e4-bd9e-39a5829b57a2@github.com>

On Wed, 20 Jan 2021 17:01:50 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
Message-ID: <rdcMtAi3NaRGN_t0_C29JqZFf-EQ0D8QqcbLpIBebLY=.e2a861f4-d487-48bf-8aa4-5cace7c4b308@github.com>

On Wed, 16 Dec 2020 18:38:37 GMT, Dan <github.com+7991079+danlemmond at openjdk.org> 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: <rdcMtAi3NaRGN_t0_C29JqZFf-EQ0D8QqcbLpIBebLY=.e2a861f4-d487-48bf-8aa4-5cace7c4b308@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
 <rdcMtAi3NaRGN_t0_C29JqZFf-EQ0D8QqcbLpIBebLY=.e2a861f4-d487-48bf-8aa4-5cace7c4b308@github.com>
Message-ID: <Ld_sw-2XWz6J-_ddifzZP1quVfzWb1S4YsySz6Z-RCY=.b5523f9d-dbbd-4a3b-836e-d3c76527c8ef@github.com>

On Wed, 20 Jan 2021 17:23:07 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <y2adaBFCMntCtbx60rq0MWwl0NSS2JEjDrx31F5gGW8=.0888e0df-816e-4351-b4db-d8a8ccad29b7@github.com>
 <5ZRm7yr18uW4HQWoMQHlI1CHdqUa70mbcj7r6PkROKU=.e5991488-7d71-4657-95c3-8a034b654db6@github.com>
Message-ID: <onWg2QsyNEr9u23kdTetWp2jpsf0K4l7lzk53HB78OA=.1310a393-cd54-4ed8-af5d-5ea7e738ce9f@github.com>

On Tue, 19 Jan 2021 03:57:16 GMT, Jie Fu <jiefu at openjdk.org> 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: <PK6TM40-JKVYxxGeKJtkALtUANLcu1OKnlP14HERkkM=.51316541-6f99-4453-bdf3-1e1251176c89@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)

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: <PK6TM40-JKVYxxGeKJtkALtUANLcu1OKnlP14HERkkM=.51316541-6f99-4453-bdf3-1e1251176c89@github.com>
References: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com>
 <PK6TM40-JKVYxxGeKJtkALtUANLcu1OKnlP14HERkkM=.51316541-6f99-4453-bdf3-1e1251176c89@github.com>
Message-ID: <dBJR7SMKNOaRnJTIDBUouXm2DUfrf_UB0pa10x1tIyo=.3f305e0b-6f7a-4301-b362-61b43c719ab6@github.com>

On Wed, 20 Jan 2021 18:47:18 GMT, Claes Redestad <redestad at openjdk.org> 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: <HBsmD-4aXXxnWYe0wF-w_4Ma_mszThhd5kZFFg_jGLQ=.e088f26e-815d-4067-a7c6-6253c8dd30c8@github.com>
References: <kQYbxKPFZRCZaz79blFr4liShnhidfEA_RcidQIe5Mg=.e080c2f5-1f5f-49b2-8c77-bcb42f5ca615@github.com>
 <maHUTm4kdcl2qE7Ao79GTQ10gnzi3GE9Dy69iQh-KGM=.f8390d42-8038-40c7-a280-8d0751a1aa91@github.com>
 <HBsmD-4aXXxnWYe0wF-w_4Ma_mszThhd5kZFFg_jGLQ=.e088f26e-815d-4067-a7c6-6253c8dd30c8@github.com>
Message-ID: <b8p8nkBtu6pSnItN-SfvA-MA1dBv1bvgrBEMzlH_4Pc=.f4813980-423f-4064-8edd-124bd778a340@github.com>

On Sat, 16 Jan 2021 02:17:50 GMT, Jie Fu <jiefu at openjdk.org> 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: <kQYbxKPFZRCZaz79blFr4liShnhidfEA_RcidQIe5Mg=.e080c2f5-1f5f-49b2-8c77-bcb42f5ca615@github.com>
References: <kQYbxKPFZRCZaz79blFr4liShnhidfEA_RcidQIe5Mg=.e080c2f5-1f5f-49b2-8c77-bcb42f5ca615@github.com>
Message-ID: <l2Wr2kHkqcjSDBoonVjUlSUatozr4bbfb-kakgpqJn8=.a7dd7c8e-492e-4d2d-8578-037d0ba73d10@github.com>

On Thu, 14 Jan 2021 04:03:26 GMT, Igor Ignatyev <iignatyev at openjdk.org> 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 <iignatyev at openjdk.org>
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 <xgong at openjdk.org>
Co-authored-by: Igor Ignatyev <iignatyev at openjdk.org>
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: <fqDIGqhOEvQeVlEaFWd94iUjCq_bdWze1oOjCnUQFt4=.12c9807e-9fc8-4062-bbac-6c1324783156@github.com>

On Mon, 18 Jan 2021 12:09:23 GMT, Claes Redestad <redestad at openjdk.org> 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 <redestad at openjdk.org>
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: <onWg2QsyNEr9u23kdTetWp2jpsf0K4l7lzk53HB78OA=.1310a393-cd54-4ed8-af5d-5ea7e738ce9f@github.com>
References: <y2adaBFCMntCtbx60rq0MWwl0NSS2JEjDrx31F5gGW8=.0888e0df-816e-4351-b4db-d8a8ccad29b7@github.com>
 <5ZRm7yr18uW4HQWoMQHlI1CHdqUa70mbcj7r6PkROKU=.e5991488-7d71-4657-95c3-8a034b654db6@github.com>
 <onWg2QsyNEr9u23kdTetWp2jpsf0K4l7lzk53HB78OA=.1310a393-cd54-4ed8-af5d-5ea7e738ce9f@github.com>
Message-ID: <f0Vlb7wDbRrqfK_x9F1xE-iyWCVlNHu_rG0JYxr0iYY=.719c8296-e0ee-494a-a730-0b8c6b8e479f@github.com>

On Wed, 20 Jan 2021 17:40:45 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <QhwPoBGSVtXQMvi5ncJR4elrIcxXooooyD4ni3z7giU=.ef7cb487-13ea-4b8e-b9a1-0f9c4a24c994@github.com>
References: <y2adaBFCMntCtbx60rq0MWwl0NSS2JEjDrx31F5gGW8=.0888e0df-816e-4351-b4db-d8a8ccad29b7@github.com>
 <5ZRm7yr18uW4HQWoMQHlI1CHdqUa70mbcj7r6PkROKU=.e5991488-7d71-4657-95c3-8a034b654db6@github.com>
 <QhwPoBGSVtXQMvi5ncJR4elrIcxXooooyD4ni3z7giU=.ef7cb487-13ea-4b8e-b9a1-0f9c4a24c994@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 <rbackman at openjdk.org> 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: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
Message-ID: <AtBNdURD637gt2Uq0UtN6SGzcslSsWs7ZLC4TrOTXPQ=.65482e3d-1db6-4772-bfd2-771ec0fbbdf6@github.com>

On Fri, 15 Jan 2021 08:09:56 GMT, Kazunori Ogata <ogatak at openjdk.org> 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<uintptr_t>(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: <V0_AsWYWW9sBTwab6TuEIm_GlQoWUd-Osopg6AgAE88=.d8fb0655-c8d7-43ab-a4bb-8951359c8e79@github.com>

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: <NN4thzbqhjubg5TRbiID80k6v0JGR5OY0Dqgz1uGyAI=.814e8aac-06b7-4e64-8072-426e852e1998@github.com>

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: <NN4thzbqhjubg5TRbiID80k6v0JGR5OY0Dqgz1uGyAI=.814e8aac-06b7-4e64-8072-426e852e1998@github.com>
References: <NN4thzbqhjubg5TRbiID80k6v0JGR5OY0Dqgz1uGyAI=.814e8aac-06b7-4e64-8072-426e852e1998@github.com>
Message-ID: <9sHQ5RFKu7eMA2dnKWQ9ZWXPzT_HnSJdXDZ2j4kX8to=.69bf5258-7371-4404-a1af-b54febf7cad7@github.com>

On Thu, 21 Jan 2021 04:33:47 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: 133bcb09
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
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: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
Message-ID: <U78jHoOa0BK6qO3QH3cLnr1urE62M7IynjMx6dwKehU=.257323b5-8644-4d7a-98b2-a6ca8fcd4b78@github.com>

> _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: <V0_AsWYWW9sBTwab6TuEIm_GlQoWUd-Osopg6AgAE88=.d8fb0655-c8d7-43ab-a4bb-8951359c8e79@github.com>
References: <V0_AsWYWW9sBTwab6TuEIm_GlQoWUd-Osopg6AgAE88=.d8fb0655-c8d7-43ab-a4bb-8951359c8e79@github.com>
Message-ID: <PcC29Vd6Kt-EzKAUswMFpEFQ9zIjTBBapkhcddcKqD4=.ba7f8dd4-88d1-4ceb-8a1a-d7570e376926@github.com>

On Thu, 21 Jan 2021 02:12:47 GMT, Fei Yang <fyang at openjdk.org> 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: <Ld_sw-2XWz6J-_ddifzZP1quVfzWb1S4YsySz6Z-RCY=.b5523f9d-dbbd-4a3b-836e-d3c76527c8ef@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
 <rdcMtAi3NaRGN_t0_C29JqZFf-EQ0D8QqcbLpIBebLY=.e2a861f4-d487-48bf-8aa4-5cace7c4b308@github.com>
 <Ld_sw-2XWz6J-_ddifzZP1quVfzWb1S4YsySz6Z-RCY=.b5523f9d-dbbd-4a3b-836e-d3c76527c8ef@github.com>
Message-ID: <hHm5TgkRq2XebHe6DV2ltyDVV02BI1IMPyV68D2mkhQ=.34ef7ee2-9c33-4643-8299-e6a87e0a9498@github.com>

On Wed, 20 Jan 2021 17:36:05 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@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 *

-------------

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: <U0LblCKAABmRc_UgXT2Yc1F1ER3qDrfEyytLQzN_lMo=.a55e54ca-93ae-4e77-9c85-be8ea3538ebd@github.com>
References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com>
 <U0LblCKAABmRc_UgXT2Yc1F1ER3qDrfEyytLQzN_lMo=.a55e54ca-93ae-4e77-9c85-be8ea3538ebd@github.com>
Message-ID: <cHhIEztXuqwKYg7yTafxppQG_l0fXF39NvC4QUDTm_M=.0c353524-c299-41df-9903-56221775cdaa@github.com>

On Wed, 20 Jan 2021 12:30:12 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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: <V0_AsWYWW9sBTwab6TuEIm_GlQoWUd-Osopg6AgAE88=.d8fb0655-c8d7-43ab-a4bb-8951359c8e79@github.com>
References: <V0_AsWYWW9sBTwab6TuEIm_GlQoWUd-Osopg6AgAE88=.d8fb0655-c8d7-43ab-a4bb-8951359c8e79@github.com>
Message-ID: <gGEQZlZTPRuL0Hzl1x9gDfm6vueLpuVyGY77_oxm6EE=.6be06c3e-ca04-4cb5-b7ab-c3cb8673cdce@github.com>

On Thu, 21 Jan 2021 02:12:47 GMT, Fei Yang <fyang at openjdk.org> 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: <a-D-fJ_rL4ntXm9BRLr9MF1xdjxD8-qhzdiGGIM2uXk=.c24640e2-92f4-4518-bbba-e7f0504e8e2d@github.com>
References: <a-D-fJ_rL4ntXm9BRLr9MF1xdjxD8-qhzdiGGIM2uXk=.c24640e2-92f4-4518-bbba-e7f0504e8e2d@github.com>
Message-ID: <CZktBwZ55ROyR1xLfpfRNJ2_bSAyFOut0KxzK__pdAA=.e140e054-8e51-4e6a-af2d-ef9e2901146d@github.com>

> 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: <XVggMCten17uvuLzx4QkP5Ny7VyxR4bTWU7pQckEcFk=.bdabacd9-376c-45e4-bd9e-39a5829b57a2@github.com>
References: <a-D-fJ_rL4ntXm9BRLr9MF1xdjxD8-qhzdiGGIM2uXk=.c24640e2-92f4-4518-bbba-e7f0504e8e2d@github.com>
 <WNZYlIlhRd5RGW84k3tWJT7ODtbouMBneIkgCxsIi5s=.99f9822c-38a9-4d41-b11b-f90531f25710@github.com>
 <tnKE0aWm_qe3uoJI3S-HdyaBnOZKF7oXquR6MvgIANs=.06bb320e-7662-43d5-922e-f87525664161@github.com>
 <jIgmrtoJDbWeP_EMh2XLzaFcCR3ivw7XtBvFsMKycBc=.9f80c468-6585-4fe8-ada5-81e8b0204aed@github.com>
 <NRxDZtayC6wS0h-m-lCWL9qARJSBgy0TmcVEebB9nMA=.ebedfcfe-0b5b-45bb-b5cb-256848d8654f@github.com>
 <d3Y3VkzIH3QTH-6nYAOt3Rf5zHp4huH_Vz9XAEC__P4=.a9f86f58-2932-47fb-96dd-a364424eb815@github.com>
 <XVggMCten17uvuLzx4QkP5Ny7VyxR4bTWU7pQckEcFk=.bdabacd9-376c-45e4-bd9e-39a5829b57a2@github.com>
Message-ID: <frP65ntGYJmomu83vW_Yi73ao2I9yoBj18mW9unHHhc=.71f9ae96-41ee-4cdb-a21e-2409e47d4d1e@github.com>

On Wed, 20 Jan 2021 17:04:51 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <AM4PR02MB3057E0F28320A6558C3D81279AA20@AM4PR02MB3057.eurprd02.prod.outlook.com>
References: <AM4PR02MB3057E0F28320A6558C3D81279AA20@AM4PR02MB3057.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB3057FC293ED98B88977EB0779AA10@AM4PR02MB3057.eurprd02.prod.outlook.com>

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' <hotspot-compiler-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Langer, Christoph <christoph.langer at sap.com>
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: <PcC29Vd6Kt-EzKAUswMFpEFQ9zIjTBBapkhcddcKqD4=.ba7f8dd4-88d1-4ceb-8a1a-d7570e376926@github.com>
References: <V0_AsWYWW9sBTwab6TuEIm_GlQoWUd-Osopg6AgAE88=.d8fb0655-c8d7-43ab-a4bb-8951359c8e79@github.com>
 <PcC29Vd6Kt-EzKAUswMFpEFQ9zIjTBBapkhcddcKqD4=.ba7f8dd4-88d1-4ceb-8a1a-d7570e376926@github.com>
Message-ID: <TFXhQQtwEYChjkoRx4cKIB4AORRGp7tl9rSr1Pbqi6w=.f609cdd8-22ac-4a9f-8cd4-8c8153774c4b@github.com>

On Thu, 21 Jan 2021 07:55:48 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <V0_AsWYWW9sBTwab6TuEIm_GlQoWUd-Osopg6AgAE88=.d8fb0655-c8d7-43ab-a4bb-8951359c8e79@github.com>
References: <V0_AsWYWW9sBTwab6TuEIm_GlQoWUd-Osopg6AgAE88=.d8fb0655-c8d7-43ab-a4bb-8951359c8e79@github.com>
Message-ID: <UaRBk-KL7TLc_wOqKm3QbtIOJMx6jwEUXBpnLuLpbWw=.c32ab360-d451-4f2f-8ce1-1611aeb1e583@github.com>

On Thu, 21 Jan 2021 02:12:47 GMT, Fei Yang <fyang at openjdk.org> 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 <fyang at openjdk.org>
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 <nizhuxuan at huawei.com>
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: <CA+pBWhu_3yAdBBceTDjbbFY2qram34bne_sBgJz3q_b9JMmGnQ@mail.gmail.com>

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: <CA+pBWhu_3yAdBBceTDjbbFY2qram34bne_sBgJz3q_b9JMmGnQ@mail.gmail.com>
References: <CA+pBWhu_3yAdBBceTDjbbFY2qram34bne_sBgJz3q_b9JMmGnQ@mail.gmail.com>
Message-ID: <ccbcc8fd-d81e-9a4d-d8ea-d8d048dddfaf@redhat.com>

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: <U78jHoOa0BK6qO3QH3cLnr1urE62M7IynjMx6dwKehU=.257323b5-8644-4d7a-98b2-a6ca8fcd4b78@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
 <U78jHoOa0BK6qO3QH3cLnr1urE62M7IynjMx6dwKehU=.257323b5-8644-4d7a-98b2-a6ca8fcd4b78@github.com>
Message-ID: <ACobWQef1-UuEhtDZWetOMgS1LUyYA_r-xnQiy0azEI=.5ab3cf21-5157-43c2-95bd-71a952f20abf@github.com>

On Thu, 21 Jan 2021 07:56:14 GMT, Dan <github.com+7991079+danlemmond at openjdk.org> 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: <U78jHoOa0BK6qO3QH3cLnr1urE62M7IynjMx6dwKehU=.257323b5-8644-4d7a-98b2-a6ca8fcd4b78@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
 <U78jHoOa0BK6qO3QH3cLnr1urE62M7IynjMx6dwKehU=.257323b5-8644-4d7a-98b2-a6ca8fcd4b78@github.com>
Message-ID: <iI2gqq0nKq7q0AejWtI3hi-8iNjzl_qKlZphqFzOmUo=.b3e911f6-5dd9-4d75-aa5e-2a1137737c99@github.com>

On Thu, 21 Jan 2021 07:56:14 GMT, Dan <github.com+7991079+danlemmond at openjdk.org> 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: <CZktBwZ55ROyR1xLfpfRNJ2_bSAyFOut0KxzK__pdAA=.e140e054-8e51-4e6a-af2d-ef9e2901146d@github.com>
References: <a-D-fJ_rL4ntXm9BRLr9MF1xdjxD8-qhzdiGGIM2uXk=.c24640e2-92f4-4518-bbba-e7f0504e8e2d@github.com>
 <CZktBwZ55ROyR1xLfpfRNJ2_bSAyFOut0KxzK__pdAA=.e140e054-8e51-4e6a-af2d-ef9e2901146d@github.com>
Message-ID: <3hpEy8hKaMlNxEwVZqFQRb7KXxwuxkU37Vgu3PGOhe0=.08513092-1bce-4445-b6f3-4dc9ef1678a2@github.com>

On Thu, 21 Jan 2021 09:59:15 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <ACobWQef1-UuEhtDZWetOMgS1LUyYA_r-xnQiy0azEI=.5ab3cf21-5157-43c2-95bd-71a952f20abf@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
 <U78jHoOa0BK6qO3QH3cLnr1urE62M7IynjMx6dwKehU=.257323b5-8644-4d7a-98b2-a6ca8fcd4b78@github.com>
 <ACobWQef1-UuEhtDZWetOMgS1LUyYA_r-xnQiy0azEI=.5ab3cf21-5157-43c2-95bd-71a952f20abf@github.com>
Message-ID: <p-wYAplL0aBcs4xaSaeNSIT6XdY_POJ6Cid3S9-bewI=.24ec0863-559c-4131-937b-fe43572f66e2@github.com>

On Thu, 21 Jan 2021 18:05:20 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <CZktBwZ55ROyR1xLfpfRNJ2_bSAyFOut0KxzK__pdAA=.e140e054-8e51-4e6a-af2d-ef9e2901146d@github.com>
References: <a-D-fJ_rL4ntXm9BRLr9MF1xdjxD8-qhzdiGGIM2uXk=.c24640e2-92f4-4518-bbba-e7f0504e8e2d@github.com>
 <CZktBwZ55ROyR1xLfpfRNJ2_bSAyFOut0KxzK__pdAA=.e140e054-8e51-4e6a-af2d-ef9e2901146d@github.com>
Message-ID: <RGs8PQ1sbDpdKhjjQzwRXpe0PrmGkZoJ8b53_P0Dy4M=.bbb4b1e0-ff85-4601-9a22-0acbdb05b874@github.com>

On Thu, 21 Jan 2021 09:59:15 GMT, Aleksey Shipilev <shade at openjdk.org> 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<jobject> _oops;
  ValueRecorder<Metadata*> _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: <sv8j2NtBYgCXbCy_ITK88S8xSyEC6L40UGX-v9DdZ8Q=.c6482ff9-4514-401c-a59e-e7ae97562e4f@github.com>

On Wed, 20 Jan 2021 18:29:00 GMT, Johannes Kuhn <github.com+652983+DasBrain at openjdk.org> 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: <sv8j2NtBYgCXbCy_ITK88S8xSyEC6L40UGX-v9DdZ8Q=.c6482ff9-4514-401c-a59e-e7ae97562e4f@github.com>
References: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com>
 <sv8j2NtBYgCXbCy_ITK88S8xSyEC6L40UGX-v9DdZ8Q=.c6482ff9-4514-401c-a59e-e7ae97562e4f@github.com>
Message-ID: <OfMEUrmUfq2g2F8N0O3gxCzuyvA0flqjXl0rbwQIi5Y=.7af47a7f-4872-483b-8ec8-5c85913f95bf@github.com>

On Thu, 21 Jan 2021 22:54:56 GMT, Mandy Chung <mchung at openjdk.org> 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: <y2adaBFCMntCtbx60rq0MWwl0NSS2JEjDrx31F5gGW8=.0888e0df-816e-4351-b4db-d8a8ccad29b7@github.com>
 <5ZRm7yr18uW4HQWoMQHlI1CHdqUa70mbcj7r6PkROKU=.e5991488-7d71-4657-95c3-8a034b654db6@github.com>
 <QhwPoBGSVtXQMvi5ncJR4elrIcxXooooyD4ni3z7giU=.ef7cb487-13ea-4b8e-b9a1-0f9c4a24c994@github.com>
 <8pN0w8-ir4hQJVUXmjsFpSEBcLPD5JFRuOsfrkOu3lk=.54d36e53-4765-4903-bc63-9c0e8b9e4c53@github.com>
Message-ID: <cjVp5H0uQ7nKAp319Kk3AXUxYl2QW-ylU0oVFFSTwVE=.575dc7a1-5274-44d0-b92f-63766d76e3e3@github.com>

On Thu, 21 Jan 2021 00:00:26 GMT, Jie Fu <jiefu at openjdk.org> 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: <y2adaBFCMntCtbx60rq0MWwl0NSS2JEjDrx31F5gGW8=.0888e0df-816e-4351-b4db-d8a8ccad29b7@github.com>
 <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 <jiefu at openjdk.org> 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: <y2adaBFCMntCtbx60rq0MWwl0NSS2JEjDrx31F5gGW8=.0888e0df-816e-4351-b4db-d8a8ccad29b7@github.com>
References: <y2adaBFCMntCtbx60rq0MWwl0NSS2JEjDrx31F5gGW8=.0888e0df-816e-4351-b4db-d8a8ccad29b7@github.com>
Message-ID: <LeQPUCVrHnOGNoh3uTC90-YBce3ot7-vo6rCMJUB0MQ=.5a9fb6ce-2f8c-4f85-93d7-956afa8f0592@github.com>

On Thu, 14 Jan 2021 12:32:41 GMT, Jie Fu <jiefu at openjdk.org> 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 <jiefu at openjdk.org>
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: <R7aAtOJzFrI6oSr1ljZRzw-j7vdN7xuNVAGLc5aECF0=.c88b38ae-0349-4523-9542-9bff473e0fa7@github.com>

On Fri, 22 Jan 2021 00:33:16 GMT, Johannes Kuhn <github.com+652983+DasBrain at openjdk.org> 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: <R7aAtOJzFrI6oSr1ljZRzw-j7vdN7xuNVAGLc5aECF0=.c88b38ae-0349-4523-9542-9bff473e0fa7@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>
 <R7aAtOJzFrI6oSr1ljZRzw-j7vdN7xuNVAGLc5aECF0=.c88b38ae-0349-4523-9542-9bff473e0fa7@github.com>
Message-ID: <c58E9tqyRVTLl1flHCCEoaVKa3KKkfmItBgYrSHE5-M=.fdb81f12-e0e2-45c0-935d-d8571a2091ec@github.com>

On Fri, 22 Jan 2021 00:44:12 GMT, Mandy Chung <mchung at openjdk.org> 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 <shade at openjdk.org> 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<jobject> _oops;
>   ValueRecorder<Metadata*> _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: <JfmmSfO9VB28J61kG9JZp8FL8xWcmrxdd1V79Q_VK9o=.28fa5ece-640c-4998-abbf-397b3ee88c72@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <JfmmSfO9VB28J61kG9JZp8FL8xWcmrxdd1V79Q_VK9o=.28fa5ece-640c-4998-abbf-397b3ee88c72@github.com>
Message-ID: <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>

On Tue, 12 Jan 2021 05:04:11 GMT, Igor Veresov <iveresov at openjdk.org> 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: <vh3G4IDD_KXAnpsCcdK6RbFN60Oe0Tvr29vnRfF2nr8=.d7bf39b5-a33f-428f-9e58-e23a1abece75@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <vh3G4IDD_KXAnpsCcdK6RbFN60Oe0Tvr29vnRfF2nr8=.d7bf39b5-a33f-428f-9e58-e23a1abece75@github.com>
Message-ID: <PdLFHE89tn0uj7ldfeFnKseNRWogoH2Nok2XaLl__hw=.951a3602-64e1-4440-b8ff-6c41436f5a47@github.com>

On Thu, 7 Jan 2021 23:06:19 GMT, Igor Veresov <iveresov at openjdk.org> 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: <c58E9tqyRVTLl1flHCCEoaVKa3KKkfmItBgYrSHE5-M=.fdb81f12-e0e2-45c0-935d-d8571a2091ec@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>
 <R7aAtOJzFrI6oSr1ljZRzw-j7vdN7xuNVAGLc5aECF0=.c88b38ae-0349-4523-9542-9bff473e0fa7@github.com>
 <c58E9tqyRVTLl1flHCCEoaVKa3KKkfmItBgYrSHE5-M=.fdb81f12-e0e2-45c0-935d-d8571a2091ec@github.com>
Message-ID: <VFKpfLaCYcZF_6Tp_XUdg_QeD6UBNJmQKW98iJtNfsQ=.c15ae6e6-e94f-4bc8-be85-d58f181d0e89@github.com>

On Fri, 22 Jan 2021 00:48:51 GMT, Johannes Kuhn <github.com+652983+DasBrain at openjdk.org> 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: <a-D-fJ_rL4ntXm9BRLr9MF1xdjxD8-qhzdiGGIM2uXk=.c24640e2-92f4-4518-bbba-e7f0504e8e2d@github.com>
References: <a-D-fJ_rL4ntXm9BRLr9MF1xdjxD8-qhzdiGGIM2uXk=.c24640e2-92f4-4518-bbba-e7f0504e8e2d@github.com>
Message-ID: <C2mpv6ZWtjoUKop1Slst4KkP0ynFHq4QQPwu3KR6I_E=.9e970c7c-5990-459d-a5e2-afb5fbfe9cea@github.com>

On Mon, 18 Jan 2021 14:39:05 GMT, Aleksey Shipilev <shade at openjdk.org> 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 <shade at openjdk.org>
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: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
Message-ID: <fZG0dsMwVdr7kKTF-pg_rQKLVWa-j_Qv_KxMpOxdHaQ=.d43dde5d-d225-4492-89aa-7210d3d78ecf@github.com>

> _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: <myXqjc7-0jop-u3gJkraphZV84ErK-5oqnbazZHWERc=.2aa42d76-8c62-481a-b190-7cda47871c22@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 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: <cHhIEztXuqwKYg7yTafxppQG_l0fXF39NvC4QUDTm_M=.0c353524-c299-41df-9903-56221775cdaa@github.com>
References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com>
 <U0LblCKAABmRc_UgXT2Yc1F1ER3qDrfEyytLQzN_lMo=.a55e54ca-93ae-4e77-9c85-be8ea3538ebd@github.com>
 <cHhIEztXuqwKYg7yTafxppQG_l0fXF39NvC4QUDTm_M=.0c353524-c299-41df-9903-56221775cdaa@github.com>
Message-ID: <5sZOTiLLhvLuYXpa95nRVUt6bANFdDq4kuUaqhKe4-4=.1a097a09-c516-4886-b3e2-3c040e4c5344@github.com>

On Thu, 21 Jan 2021 08:56:53 GMT, Roland Westrelin <roland at openjdk.org> 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: <yAllc4aoP6sChXvjJtgeTNcpGlUAWeQtBoBFkkiasyg=.b23ba5c1-aef3-42d8-b916-11bc2f38254f@github.com>

On Thu, 21 Jan 2021 18:43:26 GMT, Aleksey Shipilev <shade at openjdk.org> 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<jobject> _oops;
>   ValueRecorder<Metadata*> _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: <MO7yZfbIj7NQaLORWLvrEcTqG1xVGlBUbgdRhz02xdU=.c4e5497f-15df-4ee1-a517-94db76a67b96@github.com>

`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: <MO7yZfbIj7NQaLORWLvrEcTqG1xVGlBUbgdRhz02xdU=.c4e5497f-15df-4ee1-a517-94db76a67b96@github.com>
References: <MO7yZfbIj7NQaLORWLvrEcTqG1xVGlBUbgdRhz02xdU=.c4e5497f-15df-4ee1-a517-94db76a67b96@github.com>
Message-ID: <tJmhaYK_6UA_my28BMG5H2iNFZ9jv9cPKfrtuSsb1BE=.4ddc1e15-da21-4d04-b003-4e5d3912f13a@github.com>

On Fri, 22 Jan 2021 14:09:06 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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: <tJmhaYK_6UA_my28BMG5H2iNFZ9jv9cPKfrtuSsb1BE=.4ddc1e15-da21-4d04-b003-4e5d3912f13a@github.com>
References: <MO7yZfbIj7NQaLORWLvrEcTqG1xVGlBUbgdRhz02xdU=.c4e5497f-15df-4ee1-a517-94db76a67b96@github.com>
 <tJmhaYK_6UA_my28BMG5H2iNFZ9jv9cPKfrtuSsb1BE=.4ddc1e15-da21-4d04-b003-4e5d3912f13a@github.com>
Message-ID: <-_Ia89BDJj4kj32EPwvD3i9G0XisTSt6xTBV0yvSCq0=.f6484027-30ff-4261-8028-937d6b4e18e9@github.com>

On Fri, 22 Jan 2021 14:16:35 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@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.

-------------

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: <J4NxZ64ymNBTeI-FUqj16pYG-LxIUoLqWwhcm59vZ6Q=.79d6c0ab-9512-425f-a25a-a202e1cc5fc5@github.com>
References: <55VhodtLlLULjpxGm3PXOn2iFgrVIdqcZwysOSEK8rg=.d1571446-fc26-4b7d-9450-29ecacb31dda@github.com>
 <yOa5cjD0UUG8W75oTNVsdWw20szOxED5N3PIbtn6Q6w=.34d0ff22-eee5-4b1a-b646-8abfa772b6e6@github.com>
 <J4NxZ64ymNBTeI-FUqj16pYG-LxIUoLqWwhcm59vZ6Q=.79d6c0ab-9512-425f-a25a-a202e1cc5fc5@github.com>
Message-ID: <XHrqafpdZ8lhwvpa-8WXYQttgdh6GYnu-oInYZpZHrQ=.a48eac39-11e8-4458-8b8c-d8f72d01003c@github.com>

On Wed, 20 Jan 2021 03:36:52 GMT, Andrei Pangin <apangin at openjdk.org> 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: <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <JfmmSfO9VB28J61kG9JZp8FL8xWcmrxdd1V79Q_VK9o=.28fa5ece-640c-4998-abbf-397b3ee88c72@github.com>
 <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>
Message-ID: <U_-cKRVNVvWbacXIjrb8se893sCt3sMFd6xC5o8y2Po=.28525f43-d40b-4494-9477-fd964a22eb05@github.com>

On Wed, 20 Jan 2021 19:51:11 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <JfmmSfO9VB28J61kG9JZp8FL8xWcmrxdd1V79Q_VK9o=.28fa5ece-640c-4998-abbf-397b3ee88c72@github.com>
 <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>
Message-ID: <AWnPdXoFYF7qPF7YssGQYYnI3dFu0E7XolwQt9EBxm0=.b5b02874-a5e4-45e1-8fa5-a85f2d8b317e@github.com>

On Wed, 20 Jan 2021 20:17:48 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <JfmmSfO9VB28J61kG9JZp8FL8xWcmrxdd1V79Q_VK9o=.28fa5ece-640c-4998-abbf-397b3ee88c72@github.com>
 <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>
Message-ID: <-XgAzg034eEEPCuR342rrb4r6X-2yLRxGbr2QJgXoLw=.c1926204-ba05-4b70-891d-fd1765cc9778@github.com>

On Wed, 20 Jan 2021 20:28:34 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <PdLFHE89tn0uj7ldfeFnKseNRWogoH2Nok2XaLl__hw=.951a3602-64e1-4440-b8ff-6c41436f5a47@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <vh3G4IDD_KXAnpsCcdK6RbFN60Oe0Tvr29vnRfF2nr8=.d7bf39b5-a33f-428f-9e58-e23a1abece75@github.com>
 <PdLFHE89tn0uj7ldfeFnKseNRWogoH2Nok2XaLl__hw=.951a3602-64e1-4440-b8ff-6c41436f5a47@github.com>
Message-ID: <z-nXymZGT-gfnjCpiqq4Kpca580d37ItabSsAxbaOOw=.0ab8fdd0-88f5-4c4d-81e9-04a3c4f01be7@github.com>

On Wed, 20 Jan 2021 20:36:35 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <APObwQwW3s4kw8IbLh0wbvgntg-7meNalIwZGvZd_9Q=.93befb07-824b-439c-b17c-43afbecf179c@github.com>

On Wed, 20 Jan 2021 18:29:00 GMT, Johannes Kuhn <github.com+652983+DasBrain at openjdk.org> 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 <info at j-kuhn.de>
Committer: Mandy Chung <mchung at openjdk.org>
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: <hVYYIJ9QnY4SOC7s5RQyHjBixWejo3E7DjrnhzzhDeQ=.1a183be3-4072-489b-819a-31d04411d1c4@github.com>

On Thu, 21 Jan 2021 18:43:26 GMT, Aleksey Shipilev <shade at openjdk.org> 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<jobject> _oops;
>   ValueRecorder<Metadata*> _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 <shade at openjdk.org>
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: <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <JfmmSfO9VB28J61kG9JZp8FL8xWcmrxdd1V79Q_VK9o=.28fa5ece-640c-4998-abbf-397b3ee88c72@github.com>
 <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>
Message-ID: <w_wJiCZXywAG_pPxmPeREiLDWus3PbdvNCkpsrynKIg=.a068560f-78ea-4713-9966-34dbe6d90fbe@github.com>

On Wed, 20 Jan 2021 20:52:31 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <JfmmSfO9VB28J61kG9JZp8FL8xWcmrxdd1V79Q_VK9o=.28fa5ece-640c-4998-abbf-397b3ee88c72@github.com>
 <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>
Message-ID: <M5brzVynSx7mzI7EHfoJv1XrVRrLWtcdG0UCtp55_BY=.4db39c08-7999-4726-b57a-12f290ae0d41@github.com>

On Fri, 22 Jan 2021 00:43:29 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <PdLFHE89tn0uj7ldfeFnKseNRWogoH2Nok2XaLl__hw=.951a3602-64e1-4440-b8ff-6c41436f5a47@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <vh3G4IDD_KXAnpsCcdK6RbFN60Oe0Tvr29vnRfF2nr8=.d7bf39b5-a33f-428f-9e58-e23a1abece75@github.com>
 <PdLFHE89tn0uj7ldfeFnKseNRWogoH2Nok2XaLl__hw=.951a3602-64e1-4440-b8ff-6c41436f5a47@github.com>
Message-ID: <m_wx2hf_n_KW7twlnBx-OyUbP30alZL0NQB4WIQy0e8=.906563c3-332c-4833-a308-74ae6e2a6d53@github.com>

On Fri, 22 Jan 2021 00:24:34 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <fZG0dsMwVdr7kKTF-pg_rQKLVWa-j_Qv_KxMpOxdHaQ=.d43dde5d-d225-4492-89aa-7210d3d78ecf@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
 <fZG0dsMwVdr7kKTF-pg_rQKLVWa-j_Qv_KxMpOxdHaQ=.d43dde5d-d225-4492-89aa-7210d3d78ecf@github.com>
Message-ID: <CZMOhIqAkPvQxt8-7-6upPvERbiC5FvqCLQb6m_D67c=.202b7f42-820a-4b09-bef8-503164b3ed7d@github.com>

On Fri, 22 Jan 2021 09:39:06 GMT, Dan <github.com+7991079+danlemmond at openjdk.org> 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: <MO7yZfbIj7NQaLORWLvrEcTqG1xVGlBUbgdRhz02xdU=.c4e5497f-15df-4ee1-a517-94db76a67b96@github.com>
References: <MO7yZfbIj7NQaLORWLvrEcTqG1xVGlBUbgdRhz02xdU=.c4e5497f-15df-4ee1-a517-94db76a67b96@github.com>
Message-ID: <OeNSHhXySQBIWRTC5i5588qqFloeWVNkw2ko-vEfZF8=.86f8cdc0-173f-487a-ab00-4fa3a9a50a40@github.com>

On Fri, 22 Jan 2021 14:09:06 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
Message-ID: <tEV1-slB54oXmA3j4rn-zhpMhMblOcOUCZWgNEXSga0=.b04faa82-06ed-4d3c-917f-626de33536f1@github.com>

On Fri, 22 Jan 2021 14:21:52 GMT, Roland Westrelin <roland at openjdk.org> 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: <PdLFHE89tn0uj7ldfeFnKseNRWogoH2Nok2XaLl__hw=.951a3602-64e1-4440-b8ff-6c41436f5a47@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <vh3G4IDD_KXAnpsCcdK6RbFN60Oe0Tvr29vnRfF2nr8=.d7bf39b5-a33f-428f-9e58-e23a1abece75@github.com>
 <PdLFHE89tn0uj7ldfeFnKseNRWogoH2Nok2XaLl__hw=.951a3602-64e1-4440-b8ff-6c41436f5a47@github.com>
Message-ID: <oNgFbfk9RoE64OSL1wdmjmF4BOHJdRzM8mTe4H0vnUI=.6f5aafb1-b769-4e94-8b1b-3188812df8aa@github.com>

On Fri, 22 Jan 2021 00:56:16 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <U_-cKRVNVvWbacXIjrb8se893sCt3sMFd6xC5o8y2Po=.28525f43-d40b-4494-9477-fd964a22eb05@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <JfmmSfO9VB28J61kG9JZp8FL8xWcmrxdd1V79Q_VK9o=.28fa5ece-640c-4998-abbf-397b3ee88c72@github.com>
 <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>
 <U_-cKRVNVvWbacXIjrb8se893sCt3sMFd6xC5o8y2Po=.28525f43-d40b-4494-9477-fd964a22eb05@github.com>
Message-ID: <kFDYWojKGFHPFFoMCZ_fReCI31wuGguvChT3W80ZchE=.487f6f55-ed45-40ba-9a27-7fcf9d80ad93@github.com>

On Fri, 22 Jan 2021 15:19:39 GMT, Igor Veresov <iveresov at openjdk.org> 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: <PdLFHE89tn0uj7ldfeFnKseNRWogoH2Nok2XaLl__hw=.951a3602-64e1-4440-b8ff-6c41436f5a47@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <vh3G4IDD_KXAnpsCcdK6RbFN60Oe0Tvr29vnRfF2nr8=.d7bf39b5-a33f-428f-9e58-e23a1abece75@github.com>
 <PdLFHE89tn0uj7ldfeFnKseNRWogoH2Nok2XaLl__hw=.951a3602-64e1-4440-b8ff-6c41436f5a47@github.com>
Message-ID: <EzsBr0GtXonAlKqoJRm-67i4nlWKmrjrvJavhEy27N0=.0cd850c1-6605-43d5-bd48-830dd0608fc3@github.com>

On Fri, 22 Jan 2021 01:11:33 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <z-nXymZGT-gfnjCpiqq4Kpca580d37ItabSsAxbaOOw=.0ab8fdd0-88f5-4c4d-81e9-04a3c4f01be7@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <vh3G4IDD_KXAnpsCcdK6RbFN60Oe0Tvr29vnRfF2nr8=.d7bf39b5-a33f-428f-9e58-e23a1abece75@github.com>
 <PdLFHE89tn0uj7ldfeFnKseNRWogoH2Nok2XaLl__hw=.951a3602-64e1-4440-b8ff-6c41436f5a47@github.com>
 <z-nXymZGT-gfnjCpiqq4Kpca580d37ItabSsAxbaOOw=.0ab8fdd0-88f5-4c4d-81e9-04a3c4f01be7@github.com>
Message-ID: <3tY1BN0Q7o5K4cFcRH_KRk8djNOlMOpzU9yY3XpeaRc=.8128e81c-74b0-43c0-b96b-2eeee24d660d@github.com>

On Fri, 22 Jan 2021 17:14:15 GMT, Igor Veresov <iveresov at openjdk.org> 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: <kFDYWojKGFHPFFoMCZ_fReCI31wuGguvChT3W80ZchE=.487f6f55-ed45-40ba-9a27-7fcf9d80ad93@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <JfmmSfO9VB28J61kG9JZp8FL8xWcmrxdd1V79Q_VK9o=.28fa5ece-640c-4998-abbf-397b3ee88c72@github.com>
 <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>
 <U_-cKRVNVvWbacXIjrb8se893sCt3sMFd6xC5o8y2Po=.28525f43-d40b-4494-9477-fd964a22eb05@github.com>
 <kFDYWojKGFHPFFoMCZ_fReCI31wuGguvChT3W80ZchE=.487f6f55-ed45-40ba-9a27-7fcf9d80ad93@github.com>
Message-ID: <Y5um7nWxoTKAx3DjfBFI19pRttAWWcKgy4M3m7ODuUg=.4a30cc74-efda-41dd-9b6b-47c8fe3b9534@github.com>

On Fri, 22 Jan 2021 17:51:36 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <JfmmSfO9VB28J61kG9JZp8FL8xWcmrxdd1V79Q_VK9o=.28fa5ece-640c-4998-abbf-397b3ee88c72@github.com>
 <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>
Message-ID: <okSXCdrM-QBpX7EoaemENbzMAAuz0KrbiKZVftSnigw=.f69ee345-05d8-4184-86a8-010875bb4d07@github.com>

On Fri, 22 Jan 2021 01:25:25 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <kFDYWojKGFHPFFoMCZ_fReCI31wuGguvChT3W80ZchE=.487f6f55-ed45-40ba-9a27-7fcf9d80ad93@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <JfmmSfO9VB28J61kG9JZp8FL8xWcmrxdd1V79Q_VK9o=.28fa5ece-640c-4998-abbf-397b3ee88c72@github.com>
 <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>
 <U_-cKRVNVvWbacXIjrb8se893sCt3sMFd6xC5o8y2Po=.28525f43-d40b-4494-9477-fd964a22eb05@github.com>
 <kFDYWojKGFHPFFoMCZ_fReCI31wuGguvChT3W80ZchE=.487f6f55-ed45-40ba-9a27-7fcf9d80ad93@github.com>
Message-ID: <SrQeaFipXpGIAs8EU7YY_hnJG-fRxcd9eJaU8K0NYHs=.798210fe-e386-4d35-a2a6-5fb3e8ff15b9@github.com>

On Fri, 22 Jan 2021 18:04:54 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <JfmmSfO9VB28J61kG9JZp8FL8xWcmrxdd1V79Q_VK9o=.28fa5ece-640c-4998-abbf-397b3ee88c72@github.com>
 <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>
Message-ID: <zQLn8_zY7etihCohXr_vQJS5baz39e_dD0IDBmm9hAg=.c92a7a2d-b033-4db0-93e5-93773145cd7d@github.com>

On Fri, 22 Jan 2021 01:37:53 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <okSXCdrM-QBpX7EoaemENbzMAAuz0KrbiKZVftSnigw=.f69ee345-05d8-4184-86a8-010875bb4d07@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <JfmmSfO9VB28J61kG9JZp8FL8xWcmrxdd1V79Q_VK9o=.28fa5ece-640c-4998-abbf-397b3ee88c72@github.com>
 <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>
 <okSXCdrM-QBpX7EoaemENbzMAAuz0KrbiKZVftSnigw=.f69ee345-05d8-4184-86a8-010875bb4d07@github.com>
Message-ID: <yZcOVYqpCLWco4ndH5NRsu_GbpNv7EdAjzqDMV1vwT4=.1bd89413-45b7-4026-bfc2-aa80e7468381@github.com>

On Fri, 22 Jan 2021 18:15:40 GMT, Igor Veresov <iveresov at openjdk.org> 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: <SrQeaFipXpGIAs8EU7YY_hnJG-fRxcd9eJaU8K0NYHs=.798210fe-e386-4d35-a2a6-5fb3e8ff15b9@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <JfmmSfO9VB28J61kG9JZp8FL8xWcmrxdd1V79Q_VK9o=.28fa5ece-640c-4998-abbf-397b3ee88c72@github.com>
 <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>
 <U_-cKRVNVvWbacXIjrb8se893sCt3sMFd6xC5o8y2Po=.28525f43-d40b-4494-9477-fd964a22eb05@github.com>
 <kFDYWojKGFHPFFoMCZ_fReCI31wuGguvChT3W80ZchE=.487f6f55-ed45-40ba-9a27-7fcf9d80ad93@github.com>
 <SrQeaFipXpGIAs8EU7YY_hnJG-fRxcd9eJaU8K0NYHs=.798210fe-e386-4d35-a2a6-5fb3e8ff15b9@github.com>
Message-ID: <lP9QkaiAnsicvqyou40GxQeUQfdBZ6QypmMVrVqDIpk=.c1885651-ed53-47a9-868b-2a30edf42eaa@github.com>

On Fri, 22 Jan 2021 18:26:43 GMT, Igor Veresov <iveresov at openjdk.org> 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: <zQLn8_zY7etihCohXr_vQJS5baz39e_dD0IDBmm9hAg=.c92a7a2d-b033-4db0-93e5-93773145cd7d@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <JfmmSfO9VB28J61kG9JZp8FL8xWcmrxdd1V79Q_VK9o=.28fa5ece-640c-4998-abbf-397b3ee88c72@github.com>
 <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>
 <zQLn8_zY7etihCohXr_vQJS5baz39e_dD0IDBmm9hAg=.c92a7a2d-b033-4db0-93e5-93773145cd7d@github.com>
Message-ID: <M3c9-mzuPXKLlO4H6KGNXWb_5uIARB3PMtEF5Imcpd4=.90b81179-0266-4c2d-989b-a9e3212905b6@github.com>

On Fri, 22 Jan 2021 19:50:48 GMT, Igor Veresov <iveresov at openjdk.org> 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: <lP9QkaiAnsicvqyou40GxQeUQfdBZ6QypmMVrVqDIpk=.c1885651-ed53-47a9-868b-2a30edf42eaa@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <JfmmSfO9VB28J61kG9JZp8FL8xWcmrxdd1V79Q_VK9o=.28fa5ece-640c-4998-abbf-397b3ee88c72@github.com>
 <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>
 <U_-cKRVNVvWbacXIjrb8se893sCt3sMFd6xC5o8y2Po=.28525f43-d40b-4494-9477-fd964a22eb05@github.com>
 <kFDYWojKGFHPFFoMCZ_fReCI31wuGguvChT3W80ZchE=.487f6f55-ed45-40ba-9a27-7fcf9d80ad93@github.com>
 <SrQeaFipXpGIAs8EU7YY_hnJG-fRxcd9eJaU8K0NYHs=.798210fe-e386-4d35-a2a6-5fb3e8ff15b9@github.com>
 <lP9QkaiAnsicvqyou40GxQeUQfdBZ6QypmMVrVqDIpk=.c1885651-ed53-47a9-868b-2a30edf42eaa@github.com>
Message-ID: <c3zHCWF7CGpbv1VLrwNStg428U3pXyh-0wIADv8Yo1Y=.7b78e3ee-2f3b-43ce-b892-0a7b98a3b65d@github.com>

On Fri, 22 Jan 2021 20:08:17 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <c3zHCWF7CGpbv1VLrwNStg428U3pXyh-0wIADv8Yo1Y=.7b78e3ee-2f3b-43ce-b892-0a7b98a3b65d@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <JfmmSfO9VB28J61kG9JZp8FL8xWcmrxdd1V79Q_VK9o=.28fa5ece-640c-4998-abbf-397b3ee88c72@github.com>
 <MfA8cWX5fJo8kY-Jd9SB7aVvf2J_IuQuC3QGU_enJjA=.9b0d42da-04ad-48a8-916d-dd78c2df4e67@github.com>
 <U_-cKRVNVvWbacXIjrb8se893sCt3sMFd6xC5o8y2Po=.28525f43-d40b-4494-9477-fd964a22eb05@github.com>
 <kFDYWojKGFHPFFoMCZ_fReCI31wuGguvChT3W80ZchE=.487f6f55-ed45-40ba-9a27-7fcf9d80ad93@github.com>
 <SrQeaFipXpGIAs8EU7YY_hnJG-fRxcd9eJaU8K0NYHs=.798210fe-e386-4d35-a2a6-5fb3e8ff15b9@github.com>
 <lP9QkaiAnsicvqyou40GxQeUQfdBZ6QypmMVrVqDIpk=.c1885651-ed53-47a9-868b-2a30edf42eaa@github.com>
 <c3zHCWF7CGpbv1VLrwNStg428U3pXyh-0wIADv8Yo1Y=.7b78e3ee-2f3b-43ce-b892-0a7b98a3b65d@github.com>
Message-ID: <CmENeI3LaZoRiDz5asOs0l6F2zipSZymdjK1BcuPgw8=.24dd8b0b-985f-46c5-b330-a5fe232dd37e@github.com>

On Fri, 22 Jan 2021 20:17:24 GMT, Igor Veresov <iveresov at openjdk.org> 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: <fZG0dsMwVdr7kKTF-pg_rQKLVWa-j_Qv_KxMpOxdHaQ=.d43dde5d-d225-4492-89aa-7210d3d78ecf@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
 <fZG0dsMwVdr7kKTF-pg_rQKLVWa-j_Qv_KxMpOxdHaQ=.d43dde5d-d225-4492-89aa-7210d3d78ecf@github.com>
Message-ID: <2GZ1NB0hEC1YgnIwBO3Ehiy8qb0WuqVDKwntmG7-KK8=.0f0d41d2-7d07-44a4-8d0a-fbb1bf8eb82a@github.com>

On Fri, 22 Jan 2021 09:39:06 GMT, Dan <github.com+7991079+danlemmond at openjdk.org> 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: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
References: <dlYyg2wd6SgqP7nZYrwIBjoOw6gdWKXDoQ3W6bZRHLA=.dd02f218-be3f-4bc8-b2e8-feafc5686c6f@github.com>
Message-ID: <7VOeA7xc2ALgQFwdGGElezkmGngoEphhxqyJh-0DX-4=.cbb55d71-8f0e-42fe-ad60-26e7983c154b@github.com>

On Wed, 16 Dec 2020 18:38:37 GMT, Dan <github.com+7991079+danlemmond at openjdk.org> 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 <dlemmond at amazon.com>
Committer: Paul Hohensee <phh at openjdk.org>
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: <FIDckz3BsCj9BRWWHGOtwPLD0gdB2k9LMKnvyZr2X14=.3765198a-e250-4077-98bf-8de138e12562@github.com>

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: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
Message-ID: <jC2BuNrXY3hPz7CsicbBVpQhxsWOIKZdVFpXPLVOf9g=.e847698c-49e5-4080-bae9-3b257e0c9540@github.com>

On Fri, 22 Jan 2021 14:21:52 GMT, Roland Westrelin <roland at openjdk.org> 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: <Tfj29X7JmuW8Q94arVjEdS3SmOk_x_jT0CEWYx8ze_8=.c67b483e-53dd-4f0f-a235-91f79f3d85d0@github.com>

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: <Tfj29X7JmuW8Q94arVjEdS3SmOk_x_jT0CEWYx8ze_8=.c67b483e-53dd-4f0f-a235-91f79f3d85d0@github.com>
References: <Tfj29X7JmuW8Q94arVjEdS3SmOk_x_jT0CEWYx8ze_8=.c67b483e-53dd-4f0f-a235-91f79f3d85d0@github.com>
Message-ID: <f6ckfUpc3rNcBbz7mDx4I-NadrOHIVQh3PfxxFEDeJ8=.0c40bf76-38d0-4e8b-8789-0de82187030a@github.com>

On Fri, 22 Jan 2021 21:59:29 GMT, Vladimir Ivanov <vlivanov at openjdk.org> 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: <QQXG49x-8brTFEmUPZGm6jZ_ZrUCOGxtW5yrdnoziBo=.c932a6bd-8f92-4e8d-8cb4-9cc996ba9548@github.com>
References: <QQXG49x-8brTFEmUPZGm6jZ_ZrUCOGxtW5yrdnoziBo=.c932a6bd-8f92-4e8d-8cb4-9cc996ba9548@github.com>
Message-ID: <axdZXspBbbJ8sOxf2rtssJok6tNazQns0YQhLh1caeM=.6401cb19-8a22-4dc3-adc3-2617475b8e82@github.com>

On Thu, 26 Nov 2020 13:10:02 GMT, Vladimir Ivanov <vlivanov at openjdk.org> 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: <IZvhIIOoLMY42hWKMLTNazt1j2pDTFFwG5DXKAHgKQI=.8d208b47-bfad-4f3a-af5f-887a280fbfc3@github.com>

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: <FIDckz3BsCj9BRWWHGOtwPLD0gdB2k9LMKnvyZr2X14=.3765198a-e250-4077-98bf-8de138e12562@github.com>
References: <FIDckz3BsCj9BRWWHGOtwPLD0gdB2k9LMKnvyZr2X14=.3765198a-e250-4077-98bf-8de138e12562@github.com>
Message-ID: <D4aouh38icklQC6JjmdhSb7VV2YFAcXQ2ys3ElcOKJY=.bfa8c9fe-b3be-45c7-b211-cdb384d83e5b@github.com>

On Fri, 22 Jan 2021 21:31:22 GMT, Eric Caspole <ecaspole at openjdk.org> 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: <Tfj29X7JmuW8Q94arVjEdS3SmOk_x_jT0CEWYx8ze_8=.c67b483e-53dd-4f0f-a235-91f79f3d85d0@github.com>
References: <Tfj29X7JmuW8Q94arVjEdS3SmOk_x_jT0CEWYx8ze_8=.c67b483e-53dd-4f0f-a235-91f79f3d85d0@github.com>
Message-ID: <8bOuMK_eYt27A2Kcr-NJPlVsLIcQ_YwMbuwq2HGmFnU=.06878f3e-08b9-4b10-99f4-d1df10d57e6d@github.com>

On Fri, 22 Jan 2021 21:59:29 GMT, Vladimir Ivanov <vlivanov at openjdk.org> 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: <Tfj29X7JmuW8Q94arVjEdS3SmOk_x_jT0CEWYx8ze_8=.c67b483e-53dd-4f0f-a235-91f79f3d85d0@github.com>
 <8bOuMK_eYt27A2Kcr-NJPlVsLIcQ_YwMbuwq2HGmFnU=.06878f3e-08b9-4b10-99f4-d1df10d57e6d@github.com>
Message-ID: <y6dIexYl8HRcYTg81WJMw2lDjdPzvj7aQnV1L3AAKFA=.ef04abf1-f8b5-4e2c-98cd-f5892a132c55@github.com>

On Fri, 22 Jan 2021 23:49:06 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <IZvhIIOoLMY42hWKMLTNazt1j2pDTFFwG5DXKAHgKQI=.8d208b47-bfad-4f3a-af5f-887a280fbfc3@github.com>
References: <IZvhIIOoLMY42hWKMLTNazt1j2pDTFFwG5DXKAHgKQI=.8d208b47-bfad-4f3a-af5f-887a280fbfc3@github.com>
Message-ID: <_8bFEVclR4FHNAAkfUWy9i6rvS0J1f53rXyz-PdjenA=.385e816d-0475-493c-ab64-21dc0f2abda4@github.com>

On Fri, 22 Jan 2021 18:26:09 GMT, Dan Lutker <github.com+61068077+lutkerd at openjdk.org> 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: <FIDckz3BsCj9BRWWHGOtwPLD0gdB2k9LMKnvyZr2X14=.3765198a-e250-4077-98bf-8de138e12562@github.com>
References: <FIDckz3BsCj9BRWWHGOtwPLD0gdB2k9LMKnvyZr2X14=.3765198a-e250-4077-98bf-8de138e12562@github.com>
Message-ID: <HM-4EA9gIZDKZ3SpRJGEqxbDAL1zpjl41qdbyYiWR2s=.c5d46e24-2748-4f59-a58b-e22697a83fc8@github.com>

On Fri, 22 Jan 2021 21:31:22 GMT, Eric Caspole <ecaspole at openjdk.org> 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: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
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: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
Message-ID: <j6u8qjorR4y5p5sbClq6u_0aIL0ws8fKrx2QkZSPAE0=.bf1ed84c-ef3c-4223-886c-2d281ae32784@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:

  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: <m_wx2hf_n_KW7twlnBx-OyUbP30alZL0NQB4WIQy0e8=.906563c3-332c-4833-a308-74ae6e2a6d53@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <vh3G4IDD_KXAnpsCcdK6RbFN60Oe0Tvr29vnRfF2nr8=.d7bf39b5-a33f-428f-9e58-e23a1abece75@github.com>
 <PdLFHE89tn0uj7ldfeFnKseNRWogoH2Nok2XaLl__hw=.951a3602-64e1-4440-b8ff-6c41436f5a47@github.com>
 <m_wx2hf_n_KW7twlnBx-OyUbP30alZL0NQB4WIQy0e8=.906563c3-332c-4833-a308-74ae6e2a6d53@github.com>
Message-ID: <H3PHjIn8_pCnP9jkCoP172rDQMz4koTYCeLx7UG2mdc=.14f56b36-300e-47c2-8c39-f926030399eb@github.com>

On Fri, 22 Jan 2021 17:32:09 GMT, Igor Veresov <iveresov at openjdk.org> 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: <EWFHsSIkXX2nq_tCkLQS1ZRRCarg_Y-naRLEFAmnuk4=.2abb307a-ba4b-4107-8b09-156133a54aa9@github.com>

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: <X7N3bKASgLSIalCsvBnZm1d4ICKgxiEpEqEAIgiE5a8=.4ec35901-e88e-401f-bdbd-d6e9ccfa737a@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.

-------------

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: <X7N3bKASgLSIalCsvBnZm1d4ICKgxiEpEqEAIgiE5a8=.4ec35901-e88e-401f-bdbd-d6e9ccfa737a@github.com>
References: <X7N3bKASgLSIalCsvBnZm1d4ICKgxiEpEqEAIgiE5a8=.4ec35901-e88e-401f-bdbd-d6e9ccfa737a@github.com>
Message-ID: <gu3g0_KlJYpRsm53F_evLx2ul8yXgD5mvz30xDr6Yhw=.c29037e0-cc29-446a-b58e-5bfa9109f7ff@github.com>

On Mon, 25 Jan 2021 01:53:56 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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: <gu3g0_KlJYpRsm53F_evLx2ul8yXgD5mvz30xDr6Yhw=.c29037e0-cc29-446a-b58e-5bfa9109f7ff@github.com>
References: <X7N3bKASgLSIalCsvBnZm1d4ICKgxiEpEqEAIgiE5a8=.4ec35901-e88e-401f-bdbd-d6e9ccfa737a@github.com>
 <gu3g0_KlJYpRsm53F_evLx2ul8yXgD5mvz30xDr6Yhw=.c29037e0-cc29-446a-b58e-5bfa9109f7ff@github.com>
Message-ID: <blvXJV6X2-PDzAExiQWm9Vh77C9XNiLljip00uhotY0=.61b980d1-2ab4-441c-9832-b193697b8514@github.com>

On Mon, 25 Jan 2021 06:22:49 GMT, Xin Liu <xliu at openjdk.org> 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: <blvXJV6X2-PDzAExiQWm9Vh77C9XNiLljip00uhotY0=.61b980d1-2ab4-441c-9832-b193697b8514@github.com>
References: <X7N3bKASgLSIalCsvBnZm1d4ICKgxiEpEqEAIgiE5a8=.4ec35901-e88e-401f-bdbd-d6e9ccfa737a@github.com>
 <gu3g0_KlJYpRsm53F_evLx2ul8yXgD5mvz30xDr6Yhw=.c29037e0-cc29-446a-b58e-5bfa9109f7ff@github.com>
 <blvXJV6X2-PDzAExiQWm9Vh77C9XNiLljip00uhotY0=.61b980d1-2ab4-441c-9832-b193697b8514@github.com>
Message-ID: <9X4wuF0EXNYhEsi5Dopm33loB5xR_rOwRYTTmGvTrW8=.ef723351-49f1-424d-82b5-0ea086156d41@github.com>

On Mon, 25 Jan 2021 06:32:01 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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: <X7N3bKASgLSIalCsvBnZm1d4ICKgxiEpEqEAIgiE5a8=.4ec35901-e88e-401f-bdbd-d6e9ccfa737a@github.com>
References: <X7N3bKASgLSIalCsvBnZm1d4ICKgxiEpEqEAIgiE5a8=.4ec35901-e88e-401f-bdbd-d6e9ccfa737a@github.com>
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: <X7N3bKASgLSIalCsvBnZm1d4ICKgxiEpEqEAIgiE5a8=.4ec35901-e88e-401f-bdbd-d6e9ccfa737a@github.com>
 <gu3g0_KlJYpRsm53F_evLx2ul8yXgD5mvz30xDr6Yhw=.c29037e0-cc29-446a-b58e-5bfa9109f7ff@github.com>
 <blvXJV6X2-PDzAExiQWm9Vh77C9XNiLljip00uhotY0=.61b980d1-2ab4-441c-9832-b193697b8514@github.com>
 <9X4wuF0EXNYhEsi5Dopm33loB5xR_rOwRYTTmGvTrW8=.ef723351-49f1-424d-82b5-0ea086156d41@github.com>
Message-ID: <RtNLk--lxFFG8BU_OUFgumx7he8JgoHS4ZdIFPnQ0Ag=.3ffa7475-2b10-47bf-b340-b4dff3dcb5d5@github.com>

On Mon, 25 Jan 2021 07:21:10 GMT, Xin Liu <xliu at openjdk.org> 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: <Tfj29X7JmuW8Q94arVjEdS3SmOk_x_jT0CEWYx8ze_8=.c67b483e-53dd-4f0f-a235-91f79f3d85d0@github.com>
References: <Tfj29X7JmuW8Q94arVjEdS3SmOk_x_jT0CEWYx8ze_8=.c67b483e-53dd-4f0f-a235-91f79f3d85d0@github.com>
Message-ID: <S6U_7-nVBa_NikcSVyQ-9neqvaeXnKN8nufj5M2MmXM=.867b0841-d679-4dd5-9da2-d38533db4465@github.com>

On Fri, 22 Jan 2021 21:59:29 GMT, Vladimir Ivanov <vlivanov at openjdk.org> 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: <X7N3bKASgLSIalCsvBnZm1d4ICKgxiEpEqEAIgiE5a8=.4ec35901-e88e-401f-bdbd-d6e9ccfa737a@github.com>
 <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 <ysuenaga at openjdk.org> 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: <OeNSHhXySQBIWRTC5i5588qqFloeWVNkw2ko-vEfZF8=.86f8cdc0-173f-487a-ab00-4fa3a9a50a40@github.com>
References: <MO7yZfbIj7NQaLORWLvrEcTqG1xVGlBUbgdRhz02xdU=.c4e5497f-15df-4ee1-a517-94db76a67b96@github.com>
 <OeNSHhXySQBIWRTC5i5588qqFloeWVNkw2ko-vEfZF8=.86f8cdc0-173f-487a-ab00-4fa3a9a50a40@github.com>
Message-ID: <Ib9Za0yxChF26ptYmCl4UjKUy7IHBxeUAVGoV8oiGAo=.ae2b8031-a635-42c7-ac8b-41ee0c030be2@github.com>

On Fri, 22 Jan 2021 17:39:26 GMT, Vladimir Kozlov <kvn at openjdk.org> 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: <X7N3bKASgLSIalCsvBnZm1d4ICKgxiEpEqEAIgiE5a8=.4ec35901-e88e-401f-bdbd-d6e9ccfa737a@github.com>
 <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 <ysuenaga at openjdk.org> 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: <EWFHsSIkXX2nq_tCkLQS1ZRRCarg_Y-naRLEFAmnuk4=.2abb307a-ba4b-4107-8b09-156133a54aa9@github.com>
References: <EWFHsSIkXX2nq_tCkLQS1ZRRCarg_Y-naRLEFAmnuk4=.2abb307a-ba4b-4107-8b09-156133a54aa9@github.com>
Message-ID: <8O6SCYeHm6deJ_zFo4cB5okecGObi2AAcjmso4gBOIc=.5ed71078-e85d-456d-b96d-382cebe0e6b8@github.com>

On Sun, 24 Jan 2021 19:18:58 GMT, Xin Liu <xliu at openjdk.org> 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: <VMq5l7qqmyryiukK2Ug23hAxDyQTbACrZpV06SbGzPE=.d9198af8-dec4-4b81-b483-ccc6937733f8@github.com>
References: <VMq5l7qqmyryiukK2Ug23hAxDyQTbACrZpV06SbGzPE=.d9198af8-dec4-4b81-b483-ccc6937733f8@github.com>
Message-ID: <to3oIAwUW5bHf2p_cKd1GorqC6xF5RLrTty_il3R9Z8=.5a72d4bb-6146-4134-991b-c840a2540fbd@github.com>

On Tue, 19 Jan 2021 08:32:42 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> 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: <X7N3bKASgLSIalCsvBnZm1d4ICKgxiEpEqEAIgiE5a8=.4ec35901-e88e-401f-bdbd-d6e9ccfa737a@github.com>
 <9Pyv_sa_w7g4PSGvHivJGM6C9qcPFp0bg0f3sJDjiU0=.d2b632f8-73c9-453f-9989-cf05a0426d3c@github.com>
Message-ID: <GybtnzXL4tPpaKTAbipov7V_PfRoqXOASERTpSOAMAo=.b04ebe13-d587-49d7-9d9f-23b6a9ab537e@github.com>

On Mon, 25 Jan 2021 07:49:57 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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: <X7N3bKASgLSIalCsvBnZm1d4ICKgxiEpEqEAIgiE5a8=.4ec35901-e88e-401f-bdbd-d6e9ccfa737a@github.com>
References: <X7N3bKASgLSIalCsvBnZm1d4ICKgxiEpEqEAIgiE5a8=.4ec35901-e88e-401f-bdbd-d6e9ccfa737a@github.com>
Message-ID: <Dlq9ofi_NOHy19gETJ-Zxbu3-g1WBqLLfSQ6IvZFuZE=.b71db2e7-0529-41b7-ab3b-40be398a14b9@github.com>

On Mon, 25 Jan 2021 01:53:56 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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 <ysuenaga at openjdk.org>
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: <EWFHsSIkXX2nq_tCkLQS1ZRRCarg_Y-naRLEFAmnuk4=.2abb307a-ba4b-4107-8b09-156133a54aa9@github.com>
References: <EWFHsSIkXX2nq_tCkLQS1ZRRCarg_Y-naRLEFAmnuk4=.2abb307a-ba4b-4107-8b09-156133a54aa9@github.com>
Message-ID: <8DHfY3Ay7wO990urV38IOnYuoLuevaZYJ2Bpt5KDbws=.f07051d9-87b2-4afa-82e8-80574da05449@github.com>

On Sun, 24 Jan 2021 19:18:58 GMT, Xin Liu <xliu at openjdk.org> 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: <X7N3bKASgLSIalCsvBnZm1d4ICKgxiEpEqEAIgiE5a8=.4ec35901-e88e-401f-bdbd-d6e9ccfa737a@github.com>
References: <X7N3bKASgLSIalCsvBnZm1d4ICKgxiEpEqEAIgiE5a8=.4ec35901-e88e-401f-bdbd-d6e9ccfa737a@github.com>
Message-ID: <vcYnjcaiFEijqvHBZMQO35vokI6UM836XZ_QOnqXBxo=.a3f2023e-99f2-4f5f-aefb-f078965731e7@github.com>

On Mon, 25 Jan 2021 01:53:56 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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: <EWFHsSIkXX2nq_tCkLQS1ZRRCarg_Y-naRLEFAmnuk4=.2abb307a-ba4b-4107-8b09-156133a54aa9@github.com>
References: <EWFHsSIkXX2nq_tCkLQS1ZRRCarg_Y-naRLEFAmnuk4=.2abb307a-ba4b-4107-8b09-156133a54aa9@github.com>
Message-ID: <a94wZU3FGQfrOu9EakSy8AkiMlXr6yGNVDOI1ojUIaE=.8efa44c9-26a9-48f4-9f17-575967536baa@github.com>

On Sun, 24 Jan 2021 19:18:58 GMT, Xin Liu <xliu at openjdk.org> 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: <X7N3bKASgLSIalCsvBnZm1d4ICKgxiEpEqEAIgiE5a8=.4ec35901-e88e-401f-bdbd-d6e9ccfa737a@github.com>
References: <X7N3bKASgLSIalCsvBnZm1d4ICKgxiEpEqEAIgiE5a8=.4ec35901-e88e-401f-bdbd-d6e9ccfa737a@github.com>
Message-ID: <RLXVpHRDrXxl_RQFjP0Lt00KZ76j22SFhRbTTFRaKo4=.ded60764-9ab0-4409-8bee-ded55e54be9a@github.com>

On Mon, 25 Jan 2021 01:53:56 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> 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: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
Message-ID: <1lfc5MjMIFUx-Q19CkfKJvP4yYoM6B5APuRsvevpuk8=.3ba9c333-74b6-4ba4-bb3c-66c4583701fb@github.com>

On Thu, 21 Jan 2021 08:47:13 GMT, Xin Liu <xliu at openjdk.org> 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: <jC2BuNrXY3hPz7CsicbBVpQhxsWOIKZdVFpXPLVOf9g=.e847698c-49e5-4080-bae9-3b257e0c9540@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <jC2BuNrXY3hPz7CsicbBVpQhxsWOIKZdVFpXPLVOf9g=.e847698c-49e5-4080-bae9-3b257e0c9540@github.com>
Message-ID: <FB6_gwNYUhcwa2dT-Yr8PMFXQ_vKUxoxuh2AdqSmKJU=.7ae0015a-ee39-42ba-8f4b-7f41fa709165@github.com>

On Fri, 22 Jan 2021 21:28:33 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
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: <v9gJJ-LSgxtbPtwN79NQUjHmektOaY5-X3gpNRAgoLY=.f7ebdd2a-d5ba-4721-89ec-4ea0bba4891d@github.com>
References: <cv83E-f38PtWKwqrEZKMwbQpO52b7cS1JddP79nhBhA=.07a02fc3-8968-4883-bf81-2baf54611098@github.com>
 <v9gJJ-LSgxtbPtwN79NQUjHmektOaY5-X3gpNRAgoLY=.f7ebdd2a-d5ba-4721-89ec-4ea0bba4891d@github.com>
Message-ID: <OLupP1QQ9kk2wcL9IPMZTaGGqBG7-cbQe5OnHxvOpOA=.2750e5d5-e4d3-4eec-aec4-5be552723312@github.com>

On Tue, 19 Jan 2021 09:22:07 GMT, Thomas Stuefe <stuefe at openjdk.org> 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<Compile::PrintInliningBuffer, GrowableArray<Compile::PrintInliningBuffer> >::grow(int)+0x163
>> 1434780 [0x00007f5820c7160e] GrowableArrayWithAllocator<Compile::PrintInliningBuffer, GrowableArray<Compile::PrintInliningBuffer> >::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<PrintInliningBuffer>* _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 <typename E, typename Derived>
>> void GrowableArrayWithAllocator<E, Derived>::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<E, Derived>::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: <iFQyPXcZCNA6TDoZUxHgLNy1t3pBuqcrONWmLkZnuw4=.c4cc12d2-a337-49d2-99ee-f567fd2295b2@github.com>
References: <J0Kj7AiqCi5l8cNV1YRmcPu005hmLgeCbBCurQ2hwHc=.aaec0d99-c0f0-4b6a-b492-d08c07b46806@github.com>
 <iFQyPXcZCNA6TDoZUxHgLNy1t3pBuqcrONWmLkZnuw4=.c4cc12d2-a337-49d2-99ee-f567fd2295b2@github.com>
Message-ID: <r3bRcbUoILjstUn96_s76Sk7aUa8KtOcG5NqS2oUPQc=.bc2edfa0-d3e3-4015-9441-02fb72e024c4@github.com>

On Wed, 20 Jan 2021 07:44:12 GMT, Roland Westrelin <roland at openjdk.org> 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<T1>(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: <mKCmHyk4POpzrgGe21_3D8OXBywL9L5ww3LurMUgi70=.f532439d-1177-4e52-9221-306f6b632ebd@github.com>

On Mon, 25 Jan 2021 09:45:52 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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: <mKCmHyk4POpzrgGe21_3D8OXBywL9L5ww3LurMUgi70=.f532439d-1177-4e52-9221-306f6b632ebd@github.com>
References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com>
 <0b8S2styHDRZrn44pfLVDrfic04y__ThIpGfjokpQqk=.89f76fec-adc2-4d51-9697-69be7773f832@github.com>
 <mKCmHyk4POpzrgGe21_3D8OXBywL9L5ww3LurMUgi70=.f532439d-1177-4e52-9221-306f6b632ebd@github.com>
Message-ID: <J9rC6qs4_o665xpSJenEl0rV17K3ok1AkfwzXDr8-rA=.98dcb68e-6bc3-49e2-b341-6c44c5a5b9e3@github.com>

On Mon, 25 Jan 2021 10:13:27 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <LZ3ADMv86S4qX-DQGOvvC6DgPsDlUrbfDtymusWDH_o=.73c74709-4988-4db7-add0-159ac99469e5@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 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: <XXUSIGHJECbszQ09kKwINj9H9Ocrc3wPNfNsF0eOCYY=.0819501c-9625-4536-ab8b-dd193cdb1b86@github.com>
References: <cv83E-f38PtWKwqrEZKMwbQpO52b7cS1JddP79nhBhA=.07a02fc3-8968-4883-bf81-2baf54611098@github.com>
 <v9gJJ-LSgxtbPtwN79NQUjHmektOaY5-X3gpNRAgoLY=.f7ebdd2a-d5ba-4721-89ec-4ea0bba4891d@github.com>
 <OLupP1QQ9kk2wcL9IPMZTaGGqBG7-cbQe5OnHxvOpOA=.2750e5d5-e4d3-4eec-aec4-5be552723312@github.com>
 <XXUSIGHJECbszQ09kKwINj9H9Ocrc3wPNfNsF0eOCYY=.0819501c-9625-4536-ab8b-dd193cdb1b86@github.com>
Message-ID: <nsehReJeImx3RCAjU-XOhmT8eg3QUVgna88JV97e7r4=.9fced8e2-ddeb-4069-8a2e-555d849bc59f@github.com>

On Mon, 25 Jan 2021 10:48:48 GMT, Thomas Stuefe <stuefe at openjdk.org> 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: <OLupP1QQ9kk2wcL9IPMZTaGGqBG7-cbQe5OnHxvOpOA=.2750e5d5-e4d3-4eec-aec4-5be552723312@github.com>
References: <cv83E-f38PtWKwqrEZKMwbQpO52b7cS1JddP79nhBhA=.07a02fc3-8968-4883-bf81-2baf54611098@github.com>
 <v9gJJ-LSgxtbPtwN79NQUjHmektOaY5-X3gpNRAgoLY=.f7ebdd2a-d5ba-4721-89ec-4ea0bba4891d@github.com>
 <OLupP1QQ9kk2wcL9IPMZTaGGqBG7-cbQe5OnHxvOpOA=.2750e5d5-e4d3-4eec-aec4-5be552723312@github.com>
Message-ID: <XXUSIGHJECbszQ09kKwINj9H9Ocrc3wPNfNsF0eOCYY=.0819501c-9625-4536-ab8b-dd193cdb1b86@github.com>

On Mon, 25 Jan 2021 09:36:36 GMT, Nils Eliasson <neliasso at openjdk.org> 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: <cv83E-f38PtWKwqrEZKMwbQpO52b7cS1JddP79nhBhA=.07a02fc3-8968-4883-bf81-2baf54611098@github.com>
References: <cv83E-f38PtWKwqrEZKMwbQpO52b7cS1JddP79nhBhA=.07a02fc3-8968-4883-bf81-2baf54611098@github.com>
Message-ID: <YFfvM4BWqzcDa5LUpCTgoAi3vHoI1_K4SMxDEC2alwc=.44f4b1da-2c9d-4b75-a50e-75509d3af5cb@github.com>

On Wed, 13 Jan 2021 14:51:44 GMT, Thomas Stuefe <stuefe at openjdk.org> 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<Compile::PrintInliningBuffer, GrowableArray<Compile::PrintInliningBuffer> >::grow(int)+0x163
> 1434780 [0x00007f5820c7160e] GrowableArrayWithAllocator<Compile::PrintInliningBuffer, GrowableArray<Compile::PrintInliningBuffer> >::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<PrintInliningBuffer>* _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 <typename E, typename Derived>
> void GrowableArrayWithAllocator<E, Derived>::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<E, Derived>::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 <stuefe at openjdk.org>
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: <LZ3ADMv86S4qX-DQGOvvC6DgPsDlUrbfDtymusWDH_o=.73c74709-4988-4db7-add0-159ac99469e5@github.com>
References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com>
 <LZ3ADMv86S4qX-DQGOvvC6DgPsDlUrbfDtymusWDH_o=.73c74709-4988-4db7-add0-159ac99469e5@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 <chagedorn at openjdk.org> 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: <S6U_7-nVBa_NikcSVyQ-9neqvaeXnKN8nufj5M2MmXM=.867b0841-d679-4dd5-9da2-d38533db4465@github.com>
References: <Tfj29X7JmuW8Q94arVjEdS3SmOk_x_jT0CEWYx8ze_8=.c67b483e-53dd-4f0f-a235-91f79f3d85d0@github.com>
 <S6U_7-nVBa_NikcSVyQ-9neqvaeXnKN8nufj5M2MmXM=.867b0841-d679-4dd5-9da2-d38533db4465@github.com>
Message-ID: <Nz_ntIsfPZiYJUtoV7nRA6caKLEgOn5VWvuJ2tUIq0g=.856b7fc8-b91e-4330-a918-f45dfe33800b@github.com>

On Mon, 25 Jan 2021 08:02:08 GMT, Tobias Hartmann <thartmann at openjdk.org> 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
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 25 Jan 2021 12:46:46 GMT
Subject: [jdk16] RFR: 8259276: C2: Empty expression stack when reexecuting
 tableswitch/lookupswitch instructions after deoptimization
In-Reply-To: <Nz_ntIsfPZiYJUtoV7nRA6caKLEgOn5VWvuJ2tUIq0g=.856b7fc8-b91e-4330-a918-f45dfe33800b@github.com>
References: <Tfj29X7JmuW8Q94arVjEdS3SmOk_x_jT0CEWYx8ze_8=.c67b483e-53dd-4f0f-a235-91f79f3d85d0@github.com>
 <S6U_7-nVBa_NikcSVyQ-9neqvaeXnKN8nufj5M2MmXM=.867b0841-d679-4dd5-9da2-d38533db4465@github.com>
 <Nz_ntIsfPZiYJUtoV7nRA6caKLEgOn5VWvuJ2tUIq0g=.856b7fc8-b91e-4330-a918-f45dfe33800b@github.com>
Message-ID: <qv0rHSeMkbF2UirNMCj0VGOO17ayS4ljwbpK4ApKv0I=.2aead395-bca4-44e6-8398-f7f346cf119e@github.com>

On Mon, 25 Jan 2021 12:33:40 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> 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.

Okay, fair enough.

-------------

PR: https://git.openjdk.java.net/jdk16/pull/130

From ecaspole at openjdk.java.net  Mon Jan 25 14:15:39 2021
From: ecaspole at openjdk.java.net (Eric Caspole)
Date: Mon, 25 Jan 2021 14:15:39 GMT
Subject: Integrated: 8260169: LogCompilation: Unexpected method mismatch
In-Reply-To: <FIDckz3BsCj9BRWWHGOtwPLD0gdB2k9LMKnvyZr2X14=.3765198a-e250-4077-98bf-8de138e12562@github.com>
References: <FIDckz3BsCj9BRWWHGOtwPLD0gdB2k9LMKnvyZr2X14=.3765198a-e250-4077-98bf-8de138e12562@github.com>
Message-ID: <-tQPABquQavEHUnYjok25Wesh9y4SFVXMj9A6T4MAOA=.8070483a-7d72-4c30-8dfe-a6d65ade96f6@github.com>

On Fri, 22 Jan 2021 21:31:22 GMT, Eric Caspole <ecaspole at openjdk.org> 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.

This pull request has now been integrated.

Changeset: d076977d
Author:    Eric Caspole <ecaspole at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d076977d
Stats:     48 lines in 2 files changed: 17 ins; 9 del; 22 mod

8260169: LogCompilation: Unexpected method mismatch

Reviewed-by: kvn, vlivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/2205

From ecaspole at openjdk.java.net  Mon Jan 25 15:15:41 2021
From: ecaspole at openjdk.java.net (Eric Caspole)
Date: Mon, 25 Jan 2021 15:15:41 GMT
Subject: RFR: 8260308: Update LogCompilation junit to 4.13.1
In-Reply-To: <IZvhIIOoLMY42hWKMLTNazt1j2pDTFFwG5DXKAHgKQI=.8d208b47-bfad-4f3a-af5f-887a280fbfc3@github.com>
References: <IZvhIIOoLMY42hWKMLTNazt1j2pDTFFwG5DXKAHgKQI=.8d208b47-bfad-4f3a-af5f-887a280fbfc3@github.com>
Message-ID: <5CNa8Sb6aJhOqXuJAvlMeK0noNXVNev2UTyKt3Vc0Rk=.f94ef389-0911-46ec-9aad-285834ad028e@github.com>

On Fri, 22 Jan 2021 18:26:09 GMT, Dan Lutker <github.com+61068077+lutkerd at openjdk.org> wrote:

> Build and tested on Centos8.

Good. Thanks for keeping it up to date.

-------------

Marked as reviewed by ecaspole (Committer).

PR: https://git.openjdk.java.net/jdk/pull/2199

From iignatyev at openjdk.java.net  Mon Jan 25 16:07:41 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 25 Jan 2021 16:07:41 GMT
Subject: RFR: 8260308: Update LogCompilation junit to 4.13.1
In-Reply-To: <IZvhIIOoLMY42hWKMLTNazt1j2pDTFFwG5DXKAHgKQI=.8d208b47-bfad-4f3a-af5f-887a280fbfc3@github.com>
References: <IZvhIIOoLMY42hWKMLTNazt1j2pDTFFwG5DXKAHgKQI=.8d208b47-bfad-4f3a-af5f-887a280fbfc3@github.com>
Message-ID: <gko75S0ceEQHyd42wAdCclDHm4Gf1W-1wFzjCJyBFqM=.1236ec56-bad6-4d14-a7e1-2a16d38c760c@github.com>

On Fri, 22 Jan 2021 18:26:09 GMT, Dan Lutker <github.com+61068077+lutkerd at openjdk.org> wrote:

> Build and tested on Centos8.

Marked as reviewed by iignatyev (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2199

From chagedorn at openjdk.java.net  Mon Jan 25 17:12:50 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 25 Jan 2021 17:12:50 GMT
Subject: [jdk16] Integrated: 8260284: C2: assert(_base == Int) failed: Not an
 Int
In-Reply-To: <MO7yZfbIj7NQaLORWLvrEcTqG1xVGlBUbgdRhz02xdU=.c4e5497f-15df-4ee1-a517-94db76a67b96@github.com>
References: <MO7yZfbIj7NQaLORWLvrEcTqG1xVGlBUbgdRhz02xdU=.c4e5497f-15df-4ee1-a517-94db76a67b96@github.com>
Message-ID: <u1DwAJh5PQhwU7cAir1cqbI2JXYfP_zsg0qg-ryHZKY=.1ab3e5c7-8f9c-4169-a8ab-c8e29210a82f@github.com>

On Fri, 22 Jan 2021 14:09:06 GMT, Christian Hagedorn <chagedorn at openjdk.org> 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

This pull request has now been integrated.

Changeset: c5ab7c32
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/c5ab7c32
Stats:     94 lines in 2 files changed: 94 ins; 0 del; 0 mod

8260284: C2: assert(_base == Int) failed: Not an Int

Reviewed-by: thartmann, kvn

-------------

PR: https://git.openjdk.java.net/jdk16/pull/129

From github.com+61068077+lutkerd at openjdk.java.net  Mon Jan 25 17:19:43 2021
From: github.com+61068077+lutkerd at openjdk.java.net (Dan Lutker)
Date: Mon, 25 Jan 2021 17:19:43 GMT
Subject: Integrated: 8260308: Update LogCompilation junit to 4.13.1
In-Reply-To: <IZvhIIOoLMY42hWKMLTNazt1j2pDTFFwG5DXKAHgKQI=.8d208b47-bfad-4f3a-af5f-887a280fbfc3@github.com>
References: <IZvhIIOoLMY42hWKMLTNazt1j2pDTFFwG5DXKAHgKQI=.8d208b47-bfad-4f3a-af5f-887a280fbfc3@github.com>
Message-ID: <1ddAmlkaHVIoATuWdxM63tCmHJ8ap2TFhK8OgKifYrQ=.16c9329f-80bd-4de0-9ac0-479d7a52fa93@github.com>

On Fri, 22 Jan 2021 18:26:09 GMT, Dan Lutker <github.com+61068077+lutkerd at openjdk.org> wrote:

> Build and tested on Centos8.

This pull request has now been integrated.

Changeset: ef247ab2
Author:    Dan Lutker <lutkerd at amazon.com>
Committer: Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ef247ab2
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8260308: Update LogCompilation junit to 4.13.1

Reviewed-by: ecaspole, iignatyev

-------------

PR: https://git.openjdk.java.net/jdk/pull/2199

From kvn at openjdk.java.net  Mon Jan 25 18:00:52 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 25 Jan 2021 18:00:52 GMT
Subject: RFR: 8251462: Remove legacy compilation policy [v5]
In-Reply-To: <j6u8qjorR4y5p5sbClq6u_0aIL0ws8fKrx2QkZSPAE0=.bf1ed84c-ef3c-4223-886c-2d281ae32784@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <j6u8qjorR4y5p5sbClq6u_0aIL0ws8fKrx2QkZSPAE0=.bf1ed84c-ef3c-4223-886c-2d281ae32784@github.com>
Message-ID: <Qu3sFmKcKyyY6bWJ-hcUKa9cfx_tNv5I2d1YO8pC98Q=.c672461f-2b2d-4362-a870-a861910f2b72@github.com>

On Sun, 24 Jan 2021 03:53:00 GMT, Igor Veresov <iveresov at openjdk.org> 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:
> 
>   Address Vladimir's review comments

Looks better now. I would like to see result of performance testing before approving.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1985

From iveresov at openjdk.java.net  Mon Jan 25 18:15:49 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Mon, 25 Jan 2021 18:15:49 GMT
Subject: RFR: 8251462: Remove legacy compilation policy [v5]
In-Reply-To: <Qu3sFmKcKyyY6bWJ-hcUKa9cfx_tNv5I2d1YO8pC98Q=.c672461f-2b2d-4362-a870-a861910f2b72@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <j6u8qjorR4y5p5sbClq6u_0aIL0ws8fKrx2QkZSPAE0=.bf1ed84c-ef3c-4223-886c-2d281ae32784@github.com>
 <Qu3sFmKcKyyY6bWJ-hcUKa9cfx_tNv5I2d1YO8pC98Q=.c672461f-2b2d-4362-a870-a861910f2b72@github.com>
Message-ID: <IliBxirjkus6BbQX4Fu4SjKre08650J8Ro6PYaH4Gj8=.d28798dc-bed3-422f-a21f-3746a1f173e2@github.com>

On Mon, 25 Jan 2021 17:57:29 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address Vladimir's review comments
>
> Looks better now. I would like to see result of performance testing before approving.

I asked Eric to run the benchmarks. The results should be ready on Wednesday.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1985

From vlivanov at openjdk.java.net  Mon Jan 25 20:51:49 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 25 Jan 2021 20:51:49 GMT
Subject: [jdk16] Integrated: 8259276: C2: Empty expression stack when
 reexecuting tableswitch/lookupswitch instructions after deoptimization
In-Reply-To: <Tfj29X7JmuW8Q94arVjEdS3SmOk_x_jT0CEWYx8ze_8=.c67b483e-53dd-4f0f-a235-91f79f3d85d0@github.com>
References: <Tfj29X7JmuW8Q94arVjEdS3SmOk_x_jT0CEWYx8ze_8=.c67b483e-53dd-4f0f-a235-91f79f3d85d0@github.com>
Message-ID: <CeQHmNUTT-wadI-KUEUrUwrwJ6lODIaDrJ5BX12yYvE=.7a2cf3bc-b231-4a93-9a3b-a05d2041de20@github.com>

On Fri, 22 Jan 2021 21:59:29 GMT, Vladimir Ivanov <vlivanov at openjdk.org> 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)

This pull request has now been integrated.

Changeset: 81e730e5
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/81e730e5
Stats:     20 lines in 2 files changed: 13 ins; 3 del; 4 mod

8259276: C2: Empty expression stack when reexecuting tableswitch/lookupswitch instructions after deoptimization

Reviewed-by: dlong, kvn, thartmann

-------------

PR: https://git.openjdk.java.net/jdk16/pull/130

From cjplummer at openjdk.java.net  Mon Jan 25 20:51:45 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 25 Jan 2021 20:51:45 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v2]
In-Reply-To: <16SQMU3YXDN1LM9OnuT9_3kim-JBltWEoT63tQNPWgI=.c14df656-06dc-4d00-80e3-2df5acaaf58a@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <16SQMU3YXDN1LM9OnuT9_3kim-JBltWEoT63tQNPWgI=.c14df656-06dc-4d00-80e3-2df5acaaf58a@github.com>
Message-ID: <a8145fRfX7g7-42bjfGpjOuxTAHFO2vIIBTN6dOrlvs=.8d481f21-cc2a-4f0c-a2de-36ed477a1a4a@github.com>

On Mon, 25 Jan 2021 09:34:00 GMT, Roland Westrelin <roland at openjdk.org> 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.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use CoreUtils

test/lib/jdk/test/lib/util/CoreUtils.java line 193:

> 191:     public static String getCoreFileLocation(String crashOutputString) throws IOException {
> 192:         return getCoreFileLocation(crashOutputString, -1);
> 193:     }

In order to be consistent, it seems that all users of `getCoreFileLocation()` should now be passing in the pid and we should get rid of this version that doesn't require it. That means they also all need to be converted to use `ProcessTools.executeProcessPreservePID()`.

test/lib/jdk/test/lib/util/CoreUtils.java line 176:

> 174:                                 Asserts.assertGT(coreFile.length(), 0L, "Unexpected core size");
> 175:                                 System.out.println("coredumpctl succeeded");
> 176:                                 return core;

At the start of the outermost if/else block, there is a comment that says "See if we can figure out the likely reason the core file was not found". However, now we are doing further attempts to find the core file. At the very least the comment should be updated. Maybe add something like "Recover from failure if possible."

test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java line 182:

> 180:         if (needCoreDump) {
> 181:             try {
> 182:                 String coreFileLocation = CoreUtils.getCoreFileLocation(crashOutputString);

Don't you need to pass in `pid` here?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2195

From whuang at openjdk.java.net  Tue Jan 26 02:07:53 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Tue, 26 Jan 2021 02:07:53 GMT
Subject: [jdk16] RFR: 8260339: JVM crashes when executing
 PhaseIdealLoop::match_fill_loop
Message-ID: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>

The reason is :

  BasicType t = store->as_Mem()->memory_type();
  const char* fill_name;
  if (msg == NULL &&
      StubRoutines::select_fill_function(t, false, fill_name) == NULL) {
    msg = "unsupported store";
    msg_node = store;
  }

If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. We should get the basic type from `vect_type()->element_basic_type()` .

- BasicType t = store->as_Mem()->memory_type();
+ BasicType t;
+ if (store->is_StoreVector()) {
+ t = store->as_StoreVector()->vect_type()->element_basic_type();
+ } else {
+ t = store->as_Mem()->memory_type();
+ }

-------------

Commit messages:
 - fix code style after if
 - 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop

Changes: https://git.openjdk.java.net/jdk16/pull/132/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260339
  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/132.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/132/head:pull/132

PR: https://git.openjdk.java.net/jdk16/pull/132

From whuang at openjdk.java.net  Tue Jan 26 07:14:57 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Tue, 26 Jan 2021 07:14:57 GMT
Subject: [jdk16] RFR: 8260339: JVM crashes when executing
 PhaseIdealLoop::match_fill_loop [v2]
In-Reply-To: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
References: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
Message-ID: <DakydqdbfUeRRDceUJ7N8AckAXMZ53Wmhej-Dw9BG6k=.32e91f95-f277-4e9a-9c15-5eb3361287ab@github.com>

> The reason is :
> 
>   BasicType t = store->as_Mem()->memory_type();
>   const char* fill_name;
>   if (msg == NULL &&
>       StubRoutines::select_fill_function(t, false, fill_name) == NULL) {
>     msg = "unsupported store";
>     msg_node = store;
>   }
> 
> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. We should get the basic type from `vect_type()->element_basic_type()` .
> 
> - BasicType t = store->as_Mem()->memory_type();
> + BasicType t;
> + if (store->is_StoreVector()) {
> + t = store->as_StoreVector()->vect_type()->element_basic_type();
> + } else {
> + t = store->as_Mem()->memory_type();
> + }
> 
> I fix this bug by adding new virtual method `elem_memory_type()` in memnode, for `StoreVectorNode` , it returns the basic type of elements; It will return memory_type() in other types of memnode.

Wang Huang 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:

  8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/132/files
  - new: https://git.openjdk.java.net/jdk16/pull/132/files/c1a93016..4a503063

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=00-01

  Stats: 12 lines in 3 files changed: 4 ins; 5 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/132.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/132/head:pull/132

PR: https://git.openjdk.java.net/jdk16/pull/132

From rcastanedalo at openjdk.java.net  Tue Jan 26 08:30:39 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 26 Jan 2021 08:30:39 GMT
Subject: RFR: 8258894: C2: Forbid GCM to move stores into loops
In-Reply-To: <to3oIAwUW5bHf2p_cKd1GorqC6xF5RLrTty_il3R9Z8=.5a72d4bb-6146-4134-991b-c840a2540fbd@github.com>
References: <VMq5l7qqmyryiukK2Ug23hAxDyQTbACrZpV06SbGzPE=.d9198af8-dec4-4b81-b483-ccc6937733f8@github.com>
 <to3oIAwUW5bHf2p_cKd1GorqC6xF5RLrTty_il3R9Z8=.5a72d4bb-6146-4134-991b-c840a2540fbd@github.com>
Message-ID: <7BvLr0OSNZ5IO4_YFRDrv7ddiLtov-5UlWK0jjKlqDg=.bfa1ed16-0e48-4141-803e-082e6934de87@github.com>

On Mon, 25 Jan 2021 08:48:01 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Looks good to me.

Thanks for reviewing, Tobias!

> Just to clarify, with JDK-8255763 in place, incorrect placement in the reducible CFG case is always prevented by the frequency estimation heuristic, right?

Even for reducible CFGs there are cases (e.g. `testRegularReducible[2|3|4]()`) where GCM moves stores into loops deeper than their home loop, causing memory definitions to interfere _statically_: this is what I refer to as "invalid". However, in all these cases, the inner loop into which the store is moved has a trip count of one (otherwise its estimated frequency would be higher and the store would not be placed there), so there is no _dynamic_ interference and hence no possible miscompilation.

> I.e. without this patch, your newly added tests wouldn't fail?

Right, no assertion would fail (because C2 does not verify memory liveness after GCM), and no miscompilation would happen.  

> Would it make sense to run the test with `StressGCM` to trigger actual failures?

Yes, but triggering failures would require [JDK-8257146](https://bugs.openjdk.java.net/browse/JDK-8257146), which is blocked by this issue, to be integrated. I propose to add `StressGCM` to the tests later in JDK-8257146. Does that make sense?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2140

From rcastanedalo at openjdk.java.net  Tue Jan 26 12:32:55 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 26 Jan 2021 12:32:55 GMT
Subject: RFR: 8258894: C2: Forbid GCM to move stores into loops [v2]
In-Reply-To: <VMq5l7qqmyryiukK2Ug23hAxDyQTbACrZpV06SbGzPE=.d9198af8-dec4-4b81-b483-ccc6937733f8@github.com>
References: <VMq5l7qqmyryiukK2Ug23hAxDyQTbACrZpV06SbGzPE=.d9198af8-dec4-4b81-b483-ccc6937733f8@github.com>
Message-ID: <QZR3Mai4qMA-6Sq3IRcl3yB0NrpWHtitL-LKj-ggSMY=.a798cbd5-dba8-4a31-b1df-33916b3b5117@github.com>

> 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).

Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:

  Use NOT_DEBUG_RETURN in PhaseCFG verification functions
  
  Move is_memory_writer() test into PhaseCFG::verify_memory_writer_placement(),
  mark the function as NOT_DEBUG_RETURN, and make it independent of the PRODUCT
  flag. Apply the same refactoring to PhaseCFG::verify(), for consistency.
  Simplify callers of both functions accordingly.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2140/files
  - new: https://git.openjdk.java.net/jdk/pull/2140/files/132f7582..d8ff541b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2140&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2140&range=00-01

  Stats: 29 lines in 4 files changed: 9 ins; 15 del; 5 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 26 12:32:56 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 26 Jan 2021 12:32:56 GMT
Subject: RFR: 8258894: C2: Forbid GCM to move stores into loops [v2]
In-Reply-To: <to3oIAwUW5bHf2p_cKd1GorqC6xF5RLrTty_il3R9Z8=.5a72d4bb-6146-4134-991b-c840a2540fbd@github.com>
References: <VMq5l7qqmyryiukK2Ug23hAxDyQTbACrZpV06SbGzPE=.d9198af8-dec4-4b81-b483-ccc6937733f8@github.com>
 <to3oIAwUW5bHf2p_cKd1GorqC6xF5RLrTty_il3R9Z8=.5a72d4bb-6146-4134-991b-c840a2540fbd@github.com>
Message-ID: <f5aWhJjgvWBR1hhsC14QODARHCFyEcES1rBwSStygPY=.d846796c-80ca-4fcd-9b6f-3cfbadaf2b55@github.com>

On Mon, 25 Jan 2021 08:40:57 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use NOT_DEBUG_RETURN in PhaseCFG verification functions
>>   
>>   Move is_memory_writer() test into PhaseCFG::verify_memory_writer_placement(),
>>   mark the function as NOT_DEBUG_RETURN, and make it independent of the PRODUCT
>>   flag. Apply the same refactoring to PhaseCFG::verify(), for consistency.
>>   Simplify callers of both functions accordingly.
>
> 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`).

Done, thanks!

> 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`?

Done, thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2140

From rcastanedalo at openjdk.java.net  Tue Jan 26 12:38:40 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 26 Jan 2021 12:38:40 GMT
Subject: RFR: 8258894: C2: Forbid GCM to move stores into loops [v2]
In-Reply-To: <7BvLr0OSNZ5IO4_YFRDrv7ddiLtov-5UlWK0jjKlqDg=.bfa1ed16-0e48-4141-803e-082e6934de87@github.com>
References: <VMq5l7qqmyryiukK2Ug23hAxDyQTbACrZpV06SbGzPE=.d9198af8-dec4-4b81-b483-ccc6937733f8@github.com>
 <to3oIAwUW5bHf2p_cKd1GorqC6xF5RLrTty_il3R9Z8=.5a72d4bb-6146-4134-991b-c840a2540fbd@github.com>
 <7BvLr0OSNZ5IO4_YFRDrv7ddiLtov-5UlWK0jjKlqDg=.bfa1ed16-0e48-4141-803e-082e6934de87@github.com>
Message-ID: <00-LSKYFOzhpY6GGGNKH1uVRC-2YhxkI-8zq961X0Jg=.75f968d0-c82b-46c4-ac18-b8419a576b91@github.com>

On Tue, 26 Jan 2021 08:27:37 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> 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?
>
>> Looks good to me.
> 
> Thanks for reviewing, Tobias!
> 
>> Just to clarify, with JDK-8255763 in place, incorrect placement in the reducible CFG case is always prevented by the frequency estimation heuristic, right?
> 
> Even for reducible CFGs there are cases (e.g. `testRegularReducible[2|3|4]()`) where GCM moves stores into loops deeper than their home loop, causing memory definitions to interfere _statically_: this is what I refer to as "invalid". However, in all these cases, the inner loop into which the store is moved has a trip count of one (otherwise its estimated frequency would be higher and the store would not be placed there), so there is no _dynamic_ interference and hence no possible miscompilation.
> 
>> I.e. without this patch, your newly added tests wouldn't fail?
> 
> Right, no assertion would fail (because C2 does not verify memory liveness after GCM), and no miscompilation would happen.  
> 
>> Would it make sense to run the test with `StressGCM` to trigger actual failures?
> 
> Yes, but triggering failures would require [JDK-8257146](https://bugs.openjdk.java.net/browse/JDK-8257146), which is blocked by this issue, to be integrated. I propose to add `StressGCM` to the tests later in JDK-8257146. Does that make sense?

I just applied the refactoring suggested by Tobias (commit d8ff541), re-tested on hs-tier1 (windows-x64, linux-x64, linux-aarch64, and macosx-x64; release and debug mode), and checked manually that the refactored verification code is executed in debug mode.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2140

From shade at openjdk.java.net  Tue Jan 26 12:48:46 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 26 Jan 2021 12:48:46 GMT
Subject: RFR: 8260413: x86_32 slowdebug build fails after JDK-8259894
Message-ID: <Gt4f-39t43YU9Pmz7ELIuQEOJr5HrP78LU9ZqCjJwPw=.ea56ee15-03f1-4f1d-ad4b-ba05f833507b@github.com>

$ CONF=linux-x86-server-slowdebug make clean all
...
* For target buildjdk_hotspot_variant-server_libjvm_objs_compile.o:


 4673 | jio_snprintf(output, sizeof(output), "%s:%d", CompilerPhaseTypeHelper::to_string(cpt), idx);
      | ^~~~~~~~~~~~
      | vsnprintf

 4675 | jio_snprintf(output, sizeof(output), "%s", CompilerPhaseTypeHelper::to_string(cpt));
      | ^~~~~~~~~~~~
      | vsnprintf

It is somewhat weird it only manifests on x86_32 and only in slowdebug.

Additional testing:
 - [x] Linux x86_32 slowdebug build

-------------

Commit messages:
 - 8260413: x86_32 slowdebug build fails after JDK-8259894

Changes: https://git.openjdk.java.net/jdk/pull/2237/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2237&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260413
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2237.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2237/head:pull/2237

PR: https://git.openjdk.java.net/jdk/pull/2237

From roland at openjdk.java.net  Tue Jan 26 15:19:54 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 26 Jan 2021 15:19:54 GMT
Subject: RFR: 8260407: cmp != __null && cmp->Opcode() == Op_CmpL failure with
 -XX:StressLongCountedLoop=200000000 in lucene
Message-ID: <Ud0obOyQpdKh2yyyWnQJVNQMiJu2qgTW3RE9G8bR8lI=.f839f2db-0778-4ccf-b607-7ded9d655655@github.com>

Long counted loops are transformed in 3 steps:

1- LongCountedLoopNode/LongCountedLoopEndNode are created (similar to
int counted loops)

2- a loop nest is built from the
LongCountedLoopNode/LongCountedLoopEndNode with an inner loop with a
int iv

3- the inner loop is transformed to a CountedLoop

Between 1- and 2-, the LongCountedLoopEndNode is transformed by split
if because a dominated if uses the same condition. Fix simplys applies
existing check for CountedLoopEndNode to LongCountedLoopEndNode.

-------------

Commit messages:
 - fix & test

Changes: https://git.openjdk.java.net/jdk/pull/2240/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2240&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260407
  Stats: 73 lines in 2 files changed: 72 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2240.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2240/head:pull/2240

PR: https://git.openjdk.java.net/jdk/pull/2240

From iklam at openjdk.java.net  Tue Jan 26 16:34:39 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 26 Jan 2021 16:34:39 GMT
Subject: RFR: 8260413: x86_32 debug build fails after JDK-8259894
In-Reply-To: <Gt4f-39t43YU9Pmz7ELIuQEOJr5HrP78LU9ZqCjJwPw=.ea56ee15-03f1-4f1d-ad4b-ba05f833507b@github.com>
References: <Gt4f-39t43YU9Pmz7ELIuQEOJr5HrP78LU9ZqCjJwPw=.ea56ee15-03f1-4f1d-ad4b-ba05f833507b@github.com>
Message-ID: <6ssJoYiRx6xXGAfiwiakBXQXkmwk3VGaXqRbRUy1URM=.ed5d4e31-161d-4423-b97d-ea2ab6e06c47@github.com>

On Tue, 26 Jan 2021 12:44:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> $ CONF=linux-x86-server-slowdebug make clean all
> ...
> * For target buildjdk_hotspot_variant-server_libjvm_objs_compile.o:
> 
> 
>  4673 | jio_snprintf(output, sizeof(output), "%s:%d", CompilerPhaseTypeHelper::to_string(cpt), idx);
>       | ^~~~~~~~~~~~
>       | vsnprintf
> 
>  4675 | jio_snprintf(output, sizeof(output), "%s", CompilerPhaseTypeHelper::to_string(cpt));
>       | ^~~~~~~~~~~~
>       | vsnprintf
> 
> It is somewhat weird it only manifests on x86_32.
> 
> Additional testing:
>  - [x] Linux x86_32 slowdebug build

Thanks for the fix. I think this is a trivial change.

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2237

From vlivanov at openjdk.java.net  Tue Jan 26 17:18:57 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 26 Jan 2021 17:18:57 GMT
Subject: [jdk16] RFR: 8260370: C2: LoopLimit node is not eliminated
Message-ID: <XIr8Dm4Gof2VYPtirKtd3RXdtOLbAHO5NrJ21-woU6I=.622646d9-ee51-417c-b340-ce04511542ab@github.com>

As part of JDK-8255000 `C->major_progress` check was replaced with an explicit phase check (`post_loop_opts_phase()`).
But `LoopLimit` was not covered and still relied on `C->major_progress()`. It exposed a problem: sometimes IGVN sets `major_progress` (e.g., see `LoopNode::Ideal()`) and it blocks `LoopLimit` node elimination if the node is processed later (`LoopLimitNode::Ideal()` is misled that loop opts phase is not over).         

The fix migrates `LoopLimitNode::Ideal()` to  `post_loop_opts_phase()`. 

Also, post-loop opts IGVN pass conservatively clears `major_progress()` just in case.  
   
Testing:
- [x] failing test
- [x] hs-tier1 - hs-tier4

-------------

Commit messages:
 - 8260370: C2: LoopLimit node is not eliminated

Changes: https://git.openjdk.java.net/jdk16/pull/134/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=134&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260370
  Stats: 9 lines in 2 files changed: 8 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/134.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/134/head:pull/134

PR: https://git.openjdk.java.net/jdk16/pull/134

From kvn at openjdk.java.net  Tue Jan 26 17:29:46 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 26 Jan 2021 17:29:46 GMT
Subject: [jdk16] RFR: 8260370: C2: LoopLimit node is not eliminated
In-Reply-To: <XIr8Dm4Gof2VYPtirKtd3RXdtOLbAHO5NrJ21-woU6I=.622646d9-ee51-417c-b340-ce04511542ab@github.com>
References: <XIr8Dm4Gof2VYPtirKtd3RXdtOLbAHO5NrJ21-woU6I=.622646d9-ee51-417c-b340-ce04511542ab@github.com>
Message-ID: <uHh_x4RRDfsGf_DkdyTESG6z7GOVqucgj70nfiNoVx0=.7384f959-1237-40d1-98bc-0a6fd299ce75@github.com>

On Tue, 26 Jan 2021 16:54:48 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> As part of JDK-8255000 `C->major_progress` check was replaced with an explicit phase check (`post_loop_opts_phase()`).
> But `LoopLimit` was not covered and still relied on `C->major_progress()`. It exposed a problem: sometimes IGVN sets `major_progress` (e.g., see `LoopNode::Ideal()`) and it blocks `LoopLimit` node elimination if the node is processed later (`LoopLimitNode::Ideal()` is misled that loop opts phase is not over).         
> 
> The fix migrates `LoopLimitNode::Ideal()` to  `post_loop_opts_phase()`. 
> 
> Also, post-loop opts IGVN pass conservatively clears `major_progress()` just in case.  
>    
> Testing:
> - [x] failing test
> - [x] hs-tier1 - hs-tier4

Looks good.
Do we have other places where we should replace major_progress()?

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/134

From shade at openjdk.java.net  Tue Jan 26 17:44:47 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 26 Jan 2021 17:44:47 GMT
Subject: Withdrawn: 8260413: x86_32 debug build fails after JDK-8259894
In-Reply-To: <Gt4f-39t43YU9Pmz7ELIuQEOJr5HrP78LU9ZqCjJwPw=.ea56ee15-03f1-4f1d-ad4b-ba05f833507b@github.com>
References: <Gt4f-39t43YU9Pmz7ELIuQEOJr5HrP78LU9ZqCjJwPw=.ea56ee15-03f1-4f1d-ad4b-ba05f833507b@github.com>
Message-ID: <kqGCUi15KJROnXGXFgUTyDqt2qaRdrJRCMBNXWTqIME=.3f09865d-288b-4553-a034-4793e9bebf0f@github.com>

On Tue, 26 Jan 2021 12:44:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> $ CONF=linux-x86-server-slowdebug make clean all
> ...
> * For target buildjdk_hotspot_variant-server_libjvm_objs_compile.o:
> 
> 
>  4673 | jio_snprintf(output, sizeof(output), "%s:%d", CompilerPhaseTypeHelper::to_string(cpt), idx);
>       | ^~~~~~~~~~~~
>       | vsnprintf
> 
>  4675 | jio_snprintf(output, sizeof(output), "%s", CompilerPhaseTypeHelper::to_string(cpt));
>       | ^~~~~~~~~~~~
>       | vsnprintf
> 
> It is somewhat weird it only manifests on x86_32.
> 
> Additional testing:
>  - [x] Linux x86_32 slowdebug build

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2237

From shade at openjdk.java.net  Tue Jan 26 17:44:46 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 26 Jan 2021 17:44:46 GMT
Subject: RFR: 8260413: x86_32 debug build fails after JDK-8259894
In-Reply-To: <6ssJoYiRx6xXGAfiwiakBXQXkmwk3VGaXqRbRUy1URM=.ed5d4e31-161d-4423-b97d-ea2ab6e06c47@github.com>
References: <Gt4f-39t43YU9Pmz7ELIuQEOJr5HrP78LU9ZqCjJwPw=.ea56ee15-03f1-4f1d-ad4b-ba05f833507b@github.com>
 <6ssJoYiRx6xXGAfiwiakBXQXkmwk3VGaXqRbRUy1URM=.ed5d4e31-161d-4423-b97d-ea2ab6e06c47@github.com>
Message-ID: <zicNy9BPYRXIvmW1y-0ZypTwgYeorQLKzMAHOF4R3dM=.b07faa56-2717-48ba-8088-7dea3c0a2fff@github.com>

On Tue, 26 Jan 2021 16:32:00 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> $ CONF=linux-x86-server-slowdebug make clean all
>> ...
>> * For target buildjdk_hotspot_variant-server_libjvm_objs_compile.o:
>> 
>> 
>>  4673 | jio_snprintf(output, sizeof(output), "%s:%d", CompilerPhaseTypeHelper::to_string(cpt), idx);
>>       | ^~~~~~~~~~~~
>>       | vsnprintf
>> 
>>  4675 | jio_snprintf(output, sizeof(output), "%s", CompilerPhaseTypeHelper::to_string(cpt));
>>       | ^~~~~~~~~~~~
>>       | vsnprintf
>> 
>> It is somewhat weird it only manifests on x86_32.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 slowdebug build
>
> Thanks for the fix. I think this is a trivial change.

Fully subsumed by #2232.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2237

From vlivanov at openjdk.java.net  Tue Jan 26 17:46:42 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 26 Jan 2021 17:46:42 GMT
Subject: [jdk16] RFR: 8260370: C2: LoopLimit node is not eliminated
In-Reply-To: <uHh_x4RRDfsGf_DkdyTESG6z7GOVqucgj70nfiNoVx0=.7384f959-1237-40d1-98bc-0a6fd299ce75@github.com>
References: <XIr8Dm4Gof2VYPtirKtd3RXdtOLbAHO5NrJ21-woU6I=.622646d9-ee51-417c-b340-ce04511542ab@github.com>
 <uHh_x4RRDfsGf_DkdyTESG6z7GOVqucgj70nfiNoVx0=.7384f959-1237-40d1-98bc-0a6fd299ce75@github.com>
Message-ID: <negP7eJWbCzk6UjzHkPjVgRrPYP-hcFS145fiWcNXKE=.38b70249-18f6-430d-8b5b-b5c58e7684ce@github.com>

On Tue, 26 Jan 2021 17:26:30 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of JDK-8255000 `C->major_progress` check was replaced with an explicit phase check (`post_loop_opts_phase()`).
>> But `LoopLimit` was not covered and still relied on `C->major_progress()`. It exposed a problem: sometimes IGVN sets `major_progress` (e.g., see `LoopNode::Ideal()`) and it blocks `LoopLimit` node elimination if the node is processed later (`LoopLimitNode::Ideal()` is misled that loop opts phase is not over).         
>> 
>> The fix migrates `LoopLimitNode::Ideal()` to  `post_loop_opts_phase()`. 
>> 
>> Also, post-loop opts IGVN pass conservatively clears `major_progress()` just in case.  
>>    
>> Testing:
>> - [x] failing test
>> - [x] hs-tier1 - hs-tier4
>
> Looks good.
> Do we have other places where we should replace major_progress()?

Thanks for the prompt review, Vladimir.

> Do we have other places where we should replace major_progress()?

Yes, there's at least one check left (in `SafePointNode::Identity`). I plan to address it separately.

-------------

PR: https://git.openjdk.java.net/jdk16/pull/134

From kvn at openjdk.java.net  Tue Jan 26 17:44:46 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 26 Jan 2021 17:44:46 GMT
Subject: RFR: 8258894: C2: Forbid GCM to move stores into loops [v2]
In-Reply-To: <QZR3Mai4qMA-6Sq3IRcl3yB0NrpWHtitL-LKj-ggSMY=.a798cbd5-dba8-4a31-b1df-33916b3b5117@github.com>
References: <VMq5l7qqmyryiukK2Ug23hAxDyQTbACrZpV06SbGzPE=.d9198af8-dec4-4b81-b483-ccc6937733f8@github.com>
 <QZR3Mai4qMA-6Sq3IRcl3yB0NrpWHtitL-LKj-ggSMY=.a798cbd5-dba8-4a31-b1df-33916b3b5117@github.com>
Message-ID: <Cc3p7ckhtKan6TnZ_fDBjjsLFVPgunetcYTY1-hpEXY=.be60b63c-134c-4875-8af0-6a35e033690c@github.com>

On Tue, 26 Jan 2021 12:32:55 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> 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).
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use NOT_DEBUG_RETURN in PhaseCFG verification functions
>   
>   Move is_memory_writer() test into PhaseCFG::verify_memory_writer_placement(),
>   mark the function as NOT_DEBUG_RETURN, and make it independent of the PRODUCT
>   flag. Apply the same refactoring to PhaseCFG::verify(), for consistency.
>   Simplify callers of both functions accordingly.

Nice.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2140

From ogatak at openjdk.java.net  Tue Jan 26 18:57:43 2021
From: ogatak at openjdk.java.net (Kazunori Ogata)
Date: Tue, 26 Jan 2021 18:57:43 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10
In-Reply-To: <AtBNdURD637gt2Uq0UtN6SGzcslSsWs7ZLC4TrOTXPQ=.65482e3d-1db6-4772-bfd2-771ec0fbbdf6@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <AtBNdURD637gt2Uq0UtN6SGzcslSsWs7ZLC4TrOTXPQ=.65482e3d-1db6-4772-bfd2-771ec0fbbdf6@github.com>
Message-ID: <WkG8POXO8k_j81QNw3YnpQoFphd19RjEbLEv70L7ipw=.17a355a7-1e46-4bbc-ad0c-8b0d9d8a6a55@github.com>

On Thu, 21 Jan 2021 00:28:40 GMT, Corey Ashford <github.com+51754783+CoreyAshford at openjdk.org> 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
>
> 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.

I'll leave it since other comments that refer to a specific ISA implementation use Power X. (I changed POWER10 to Power 10, though.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/2095

From ogatak at openjdk.java.net  Tue Jan 26 19:00:46 2021
From: ogatak at openjdk.java.net (Kazunori Ogata)
Date: Tue, 26 Jan 2021 19:00:46 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10
In-Reply-To: <AtBNdURD637gt2Uq0UtN6SGzcslSsWs7ZLC4TrOTXPQ=.65482e3d-1db6-4772-bfd2-771ec0fbbdf6@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <AtBNdURD637gt2Uq0UtN6SGzcslSsWs7ZLC4TrOTXPQ=.65482e3d-1db6-4772-bfd2-771ec0fbbdf6@github.com>
Message-ID: <GkXtjSm_0Jf675MmZkz_V2tpMAFIw5l1ssR-O7jp1rs=.9a174885-8956-470b-bc85-7e34a8406445@github.com>

On Thu, 21 Jan 2021 00:58:14 GMT, Corey Ashford <github.com+51754783+CoreyAshford at openjdk.org> 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
>
> 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.

This comment was simply copied from old code that was deleted in JDK-8253029.  I removed the commend in this patch, too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2095

From ogatak at openjdk.java.net  Tue Jan 26 19:10:42 2021
From: ogatak at openjdk.java.net (Kazunori Ogata)
Date: Tue, 26 Jan 2021 19:10:42 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10
In-Reply-To: <AtBNdURD637gt2Uq0UtN6SGzcslSsWs7ZLC4TrOTXPQ=.65482e3d-1db6-4772-bfd2-771ec0fbbdf6@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <AtBNdURD637gt2Uq0UtN6SGzcslSsWs7ZLC4TrOTXPQ=.65482e3d-1db6-4772-bfd2-771ec0fbbdf6@github.com>
Message-ID: <cLMlamzeU3HzSZVUMSgz0AkOIryBxRfUChh-WxX-g6M=.9358d16c-1645-4cca-8ac6-fe860cee0eba@github.com>

On Thu, 21 Jan 2021 01:17:58 GMT, Corey Ashford <github.com+51754783+CoreyAshford at openjdk.org> 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
>
> src/hotspot/cpu/ppc/assembler_ppc.hpp line 1533:
> 
>> 1531:      int32_t* p_inst = (int32_t*)p;
>> 1532: 
>> 1533:      if (is_aligned(reinterpret_cast<uintptr_t>(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)?

"is_<instr>()" are the functions for testing instructions in the generated code and they are usually called in "assert()" or complex combination of if statements.  So if this function returns false when p points at nop, the assertions or the if-conditions need to handle the nop case and the code will become difficult to read.  Since the padding nop is a non-common case, I'd like to hide the existence of nop in this function.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2095

From ogatak at openjdk.java.net  Tue Jan 26 19:17:41 2021
From: ogatak at openjdk.java.net (Kazunori Ogata)
Date: Tue, 26 Jan 2021 19:17:41 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10
In-Reply-To: <AtBNdURD637gt2Uq0UtN6SGzcslSsWs7ZLC4TrOTXPQ=.65482e3d-1db6-4772-bfd2-771ec0fbbdf6@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <AtBNdURD637gt2Uq0UtN6SGzcslSsWs7ZLC4TrOTXPQ=.65482e3d-1db6-4772-bfd2-771ec0fbbdf6@github.com>
Message-ID: <_eP7uCnY-ZlzK3aCMJNWEQ0m9UP3pGkCR-L0ReZIrdo=.8f369ddf-0b68-4cc5-98d1-4e474bf7ae6c@github.com>

On Thu, 21 Jan 2021 01:34:19 GMT, Corey Ashford <github.com+51754783+CoreyAshford at openjdk.org> 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
>
> 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.

If predicate is added, adlc fails with an error message: "Syntax Error: :ADLC does not support instruction chain rules with predicates"  I think addL_reg_imm34 allows predicate because it is not called from other rules.  Is it better to leave some comments?  (BTW, immI32 is only for POWER10 or higher.  POWER9 version uses immI16 or immI16hi.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/2095

From ogatak at openjdk.java.net  Tue Jan 26 19:20:47 2021
From: ogatak at openjdk.java.net (Kazunori Ogata)
Date: Tue, 26 Jan 2021 19:20:47 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10
In-Reply-To: <AtBNdURD637gt2Uq0UtN6SGzcslSsWs7ZLC4TrOTXPQ=.65482e3d-1db6-4772-bfd2-771ec0fbbdf6@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <AtBNdURD637gt2Uq0UtN6SGzcslSsWs7ZLC4TrOTXPQ=.65482e3d-1db6-4772-bfd2-771ec0fbbdf6@github.com>
Message-ID: <sSDP07j2elqVDT0qGYi5ZHF0L1fZ6pQu43ozzP_TdE8=.d5f3030a-c8cc-4097-822f-99f71012eb58@github.com>

On Thu, 21 Jan 2021 01:19:02 GMT, Corey Ashford <github.com+51754783+CoreyAshford at openjdk.org> 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
>
> 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.

It is just intended to show a usage of the second argument of is_paddi(const int* p, bool is_pli = false).  Is it unnecessary, i.e., self-evident?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2095

From ogatak at openjdk.java.net  Tue Jan 26 19:38:58 2021
From: ogatak at openjdk.java.net (Kazunori Ogata)
Date: Tue, 26 Jan 2021 19:38:58 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10 [v2]
In-Reply-To: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
Message-ID: <xTMynZAcYrAqDeYgUP3nj4oZGiJcfS5a5FIIzh8pLfo=.aa6837b8-46bb-4b8c-884a-a30bf600e9d5@github.com>

> 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

Kazunori Ogata has updated the pull request incrementally with one additional commit since the last revision:

  Update based on review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2095/files
  - new: https://git.openjdk.java.net/jdk/pull/2095/files/05b92eaf..9a7ef64e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2095&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2095&range=00-01

  Stats: 16 lines in 4 files changed: 0 ins; 5 del; 11 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 ogatak at openjdk.java.net  Tue Jan 26 19:38:59 2021
From: ogatak at openjdk.java.net (Kazunori Ogata)
Date: Tue, 26 Jan 2021 19:38:59 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10 [v2]
In-Reply-To: <AtBNdURD637gt2Uq0UtN6SGzcslSsWs7ZLC4TrOTXPQ=.65482e3d-1db6-4772-bfd2-771ec0fbbdf6@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <AtBNdURD637gt2Uq0UtN6SGzcslSsWs7ZLC4TrOTXPQ=.65482e3d-1db6-4772-bfd2-771ec0fbbdf6@github.com>
Message-ID: <A8yyytoty1VxWefpKkSgMJAMz22QL0RvkZo7GimGYS4=.85e8aef1-e02e-4cf8-b32b-3b0c45dc80ee@github.com>

On Thu, 21 Jan 2021 01:38:17 GMT, Corey Ashford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> Kazunori Ogata has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update based on review comments
>
> 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.

It is intended to show an example of an efficient set of macros/functions for a prefixed instruction. Since a non-prefixed (32-bit) instruction is more efficient if the argument fits within the operand fields because of smaller I-cache usage and no need for the padding nop, it is convenient to have a macro/function that select better format. I intended to show an example of recommended set of useful macros/functions when adding support for a prefixed instruction. I'm planning to use this function in my next patch. Is it better to move this to the next patch?

> 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.

Same reason as the next comment (paddi_or_addi), but necessity of this one may be weaker.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2095

From ogatak at openjdk.java.net  Tue Jan 26 19:45:44 2021
From: ogatak at openjdk.java.net (Kazunori Ogata)
Date: Tue, 26 Jan 2021 19:45:44 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10 [v2]
In-Reply-To: <AtBNdURD637gt2Uq0UtN6SGzcslSsWs7ZLC4TrOTXPQ=.65482e3d-1db6-4772-bfd2-771ec0fbbdf6@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <AtBNdURD637gt2Uq0UtN6SGzcslSsWs7ZLC4TrOTXPQ=.65482e3d-1db6-4772-bfd2-771ec0fbbdf6@github.com>
Message-ID: <Ep9bxWtLFScgDNsJRs_7OwgZaJb4N5eUbimSz90HdHY=.7bb40733-1fcd-4fa2-bb76-eb53684bc6a1@github.com>

On Thu, 21 Jan 2021 01:53:02 GMT, Corey Ashford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> Kazunori Ogata has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update based on review comments
>
> This looks good overall.  I'm looking forward to being able to utilize this capability.

@CoreyAshford Thank you very much for your review.  I updated my patch based on your comment.  For some comments that I left unchanged, I replied to each of them.  Please give me your thought.

For merge conflict, I verified the conflict is only the copyright years.  I'll fix it when real changes are reviewed because pulling the latest master to resolve conflict makes this patch difficult to review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2095

From phh at openjdk.java.net  Tue Jan 26 20:55:39 2021
From: phh at openjdk.java.net (Paul Hohensee)
Date: Tue, 26 Jan 2021 20:55:39 GMT
Subject: RFR: 8260334: Remove deprecated sv_for_node_id() from Compile
In-Reply-To: <EWFHsSIkXX2nq_tCkLQS1ZRRCarg_Y-naRLEFAmnuk4=.2abb307a-ba4b-4107-8b09-156133a54aa9@github.com>
References: <EWFHsSIkXX2nq_tCkLQS1ZRRCarg_Y-naRLEFAmnuk4=.2abb307a-ba4b-4107-8b09-156133a54aa9@github.com>
Message-ID: <zo3weO5j9OtnOpQEE86pXkyQWtbCzTrkt3T9eByWxp4=.9175e1f8-7f8a-4335-97d1-3eaa27f0737c@github.com>

On Sun, 24 Jan 2021 19:18:58 GMT, Xin Liu <xliu at openjdk.org> 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 phh (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2211

From xliu at openjdk.java.net  Tue Jan 26 20:55:40 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 26 Jan 2021 20:55:40 GMT
Subject: Integrated: 8260334: Remove deprecated sv_for_node_id() from Compile
In-Reply-To: <EWFHsSIkXX2nq_tCkLQS1ZRRCarg_Y-naRLEFAmnuk4=.2abb307a-ba4b-4107-8b09-156133a54aa9@github.com>
References: <EWFHsSIkXX2nq_tCkLQS1ZRRCarg_Y-naRLEFAmnuk4=.2abb307a-ba4b-4107-8b09-156133a54aa9@github.com>
Message-ID: <VRdFSLQn98FIrPlic7mnuHWKd-Fb9sKX1RmJrVjC7JI=.45e49f82-36df-48b1-a4b1-ed7f8c3e23c1@github.com>

On Sun, 24 Jan 2021 19:18:58 GMT, Xin Liu <xliu at openjdk.org> 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.

This pull request has now been integrated.

Changeset: 19b6f61b
Author:    Xin Liu <xliu at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/19b6f61b
Stats:     8 lines in 2 files changed: 1 ins; 3 del; 4 mod

8260334: Remove deprecated sv_for_node_id() from Compile

Reviewed-by: neliasso, chagedorn, thartmann, phh

-------------

PR: https://git.openjdk.java.net/jdk/pull/2211

From xliu at openjdk.java.net  Tue Jan 26 21:05:40 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 26 Jan 2021 21:05:40 GMT
Subject: RFR: 8260334: Remove deprecated sv_for_node_id() from Compile
In-Reply-To: <zo3weO5j9OtnOpQEE86pXkyQWtbCzTrkt3T9eByWxp4=.9175e1f8-7f8a-4335-97d1-3eaa27f0737c@github.com>
References: <EWFHsSIkXX2nq_tCkLQS1ZRRCarg_Y-naRLEFAmnuk4=.2abb307a-ba4b-4107-8b09-156133a54aa9@github.com>
 <zo3weO5j9OtnOpQEE86pXkyQWtbCzTrkt3T9eByWxp4=.9175e1f8-7f8a-4335-97d1-3eaa27f0737c@github.com>
Message-ID: <HumFG2KBJ0wJbCphvAtFN-ev4ykZthgJIGpU7rbwQlk=.14c48255-21f5-47be-b157-0d311cfe226f@github.com>

On Tue, 26 Jan 2021 20:51:29 GMT, Paul Hohensee <phh at openjdk.org> 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 phh (Reviewer).

Thanks to all reviewers and the sponsor.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2211

From jiefu at openjdk.java.net  Tue Jan 26 23:47:44 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 26 Jan 2021 23:47:44 GMT
Subject: [jdk16] RFR: 8260339: JVM crashes when executing
 PhaseIdealLoop::match_fill_loop
In-Reply-To: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
References: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
Message-ID: <SqYCbdxw6j7gCBTYvJWy3RNba5cWgdR3MnR2Pm2N_kE=.6e4bd956-d26a-4536-89a6-bbeb07a88a3a@github.com>

On Tue, 26 Jan 2021 02:01:00 GMT, Wang Huang <whuang at openjdk.org> wrote:

> The reason is :
> 
>   BasicType t = store->as_Mem()->memory_type();
>   const char* fill_name;
>   if (msg == NULL &&
>       StubRoutines::select_fill_function(t, false, fill_name) == NULL) {
>     msg = "unsupported store";
>     msg_node = store;
>   }
> 
> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here.
> 
> I add a new case here to avoid mistake:
>   case T_NARROWOOP:
>   case T_NARROWKLASS:
>   case T_ADDRESS:
> +  case T_VOID:
>     // Currently unsupported
>     return NULL;

> Hi @Wanghuang-Huawei , I'm still not clear how to reproduce the bug.
> 

Ah, I missed the attachment in the JBS.
Thumbs-up @Wanghuang-Huawei .

-------------

PR: https://git.openjdk.java.net/jdk16/pull/132

From jwilhelm at openjdk.java.net  Wed Jan 27 01:19:58 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 27 Jan 2021 01:19:58 GMT
Subject: RFR: Merge jdk16
Message-ID: <GSPUA2N53fMF_fUDUasyeFNuatRGdQAbWQy9a8ekHg0=.1430a351-c678-4e2f-9539-a5e07d8f27f4@github.com>

Forwardport JDK 16 -> JDK 17

-------------

Commit messages:
 - Merge
 - 8259025: Record compact constructor using Objects.requireNonNull
 - 8259276: C2: Empty expression stack when reexecuting tableswitch/lookupswitch instructions after deoptimization
 - 8260284: C2: assert(_base == Int) failed: Not an Int

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2248&range=00.0
 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2248&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/2248/files
  Stats: 114 lines in 4 files changed: 107 ins; 3 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2248.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2248/head:pull/2248

PR: https://git.openjdk.java.net/jdk/pull/2248

From thartmann at openjdk.java.net  Wed Jan 27 07:23:39 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 27 Jan 2021 07:23:39 GMT
Subject: RFR: 8260407: cmp != __null && cmp->Opcode() == Op_CmpL failure
 with -XX:StressLongCountedLoop=200000000 in lucene
In-Reply-To: <Ud0obOyQpdKh2yyyWnQJVNQMiJu2qgTW3RE9G8bR8lI=.f839f2db-0778-4ccf-b607-7ded9d655655@github.com>
References: <Ud0obOyQpdKh2yyyWnQJVNQMiJu2qgTW3RE9G8bR8lI=.f839f2db-0778-4ccf-b607-7ded9d655655@github.com>
Message-ID: <1QX1mX7KTZOBaVL1U-H5YqRY-CHlO7Mo6RW2hKicvAQ=.12ef4f78-e40c-4116-9a35-0060419f701d@github.com>

On Tue, 26 Jan 2021 15:14:27 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Long counted loops are transformed in 3 steps:
> 
> 1- LongCountedLoopNode/LongCountedLoopEndNode are created (similar to
> int counted loops)
> 
> 2- a loop nest is built from the
> LongCountedLoopNode/LongCountedLoopEndNode with an inner loop with a
> int iv
> 
> 3- the inner loop is transformed to a CountedLoop
> 
> Between 1- and 2-, the LongCountedLoopEndNode is transformed by split
> if because a dominated if uses the same condition. Fix simplys applies
> existing check for CountedLoopEndNode to LongCountedLoopEndNode.

Looks good to me.

test/hotspot/jtreg/compiler/longcountedloops/TestLongCountedLoopSplitIf.java line 2:

> 1: /*
> 2:  * Copyright (c) 2020, Red Hat, Inc. All rights reserved.

Copyright should be 2021.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2240

From chagedorn at openjdk.java.net  Wed Jan 27 07:28:39 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 27 Jan 2021 07:28:39 GMT
Subject: RFR: 8257498: Remove useless skeleton predicates [v6]
In-Reply-To: <57hgBgvjq3HuXyIpCDtmE_9JA_DkELqDdSFanVddk1k=.1a330884-cc32-4826-8905-ffdba9c60357@github.com>
References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com>
 <LZ3ADMv86S4qX-DQGOvvC6DgPsDlUrbfDtymusWDH_o=.73c74709-4988-4db7-add0-159ac99469e5@github.com>
 <57hgBgvjq3HuXyIpCDtmE_9JA_DkELqDdSFanVddk1k=.1a330884-cc32-4826-8905-ffdba9c60357@github.com>
Message-ID: <HRYJ0m2m0bRwoykbULthRYWYpOjXCigUk9IlLZb1eMU=.33ac37ed-84b5-4568-af31-2f06bc9f2a6d@github.com>

On Mon, 25 Jan 2021 10:54:57 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix consistency
>
> Marked as reviewed by thartmann (Reviewer).

Thanks Roland and Tobias for your reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2075

From thartmann at openjdk.java.net  Wed Jan 27 07:42:41 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 27 Jan 2021 07:42:41 GMT
Subject: RFR: 8258894: C2: Forbid GCM to move stores into loops [v2]
In-Reply-To: <Cc3p7ckhtKan6TnZ_fDBjjsLFVPgunetcYTY1-hpEXY=.be60b63c-134c-4875-8af0-6a35e033690c@github.com>
References: <VMq5l7qqmyryiukK2Ug23hAxDyQTbACrZpV06SbGzPE=.d9198af8-dec4-4b81-b483-ccc6937733f8@github.com>
 <QZR3Mai4qMA-6Sq3IRcl3yB0NrpWHtitL-LKj-ggSMY=.a798cbd5-dba8-4a31-b1df-33916b3b5117@github.com>
 <Cc3p7ckhtKan6TnZ_fDBjjsLFVPgunetcYTY1-hpEXY=.be60b63c-134c-4875-8af0-6a35e033690c@github.com>
Message-ID: <ON_hsgBVUyzRrjbsChRlIPSTf64IQuXm46aNXLmbUB4=.6b71c379-1077-45d0-a3be-294fad11e04a@github.com>

On Tue, 26 Jan 2021 17:42:17 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use NOT_DEBUG_RETURN in PhaseCFG verification functions
>>   
>>   Move is_memory_writer() test into PhaseCFG::verify_memory_writer_placement(),
>>   mark the function as NOT_DEBUG_RETURN, and make it independent of the PRODUCT
>>   flag. Apply the same refactoring to PhaseCFG::verify(), for consistency.
>>   Simplify callers of both functions accordingly.
>
> Nice.

Thanks for the clarifications!

> Yes, but triggering failures would require JDK-8257146, which is blocked by this issue, to be integrated. I propose to add StressGCM to the tests later in JDK-8257146. Does that make sense?

Yes, that makes sense.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2140

From thartmann at openjdk.java.net  Wed Jan 27 07:56:39 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 27 Jan 2021 07:56:39 GMT
Subject: RFR: 8258894: C2: Forbid GCM to move stores into loops [v2]
In-Reply-To: <QZR3Mai4qMA-6Sq3IRcl3yB0NrpWHtitL-LKj-ggSMY=.a798cbd5-dba8-4a31-b1df-33916b3b5117@github.com>
References: <VMq5l7qqmyryiukK2Ug23hAxDyQTbACrZpV06SbGzPE=.d9198af8-dec4-4b81-b483-ccc6937733f8@github.com>
 <QZR3Mai4qMA-6Sq3IRcl3yB0NrpWHtitL-LKj-ggSMY=.a798cbd5-dba8-4a31-b1df-33916b3b5117@github.com>
Message-ID: <9kFOeiXVarMDbTUHQ3QXzQeUYefEVpTEFByWVqZ-lvE=.c9b05066-6bac-4822-bebc-dc59c8c7ec04@github.com>

On Tue, 26 Jan 2021 12:32:55 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> 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).
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use NOT_DEBUG_RETURN in PhaseCFG verification functions
>   
>   Move is_memory_writer() test into PhaseCFG::verify_memory_writer_placement(),
>   mark the function as NOT_DEBUG_RETURN, and make it independent of the PRODUCT
>   flag. Apply the same refactoring to PhaseCFG::verify(), for consistency.
>   Simplify callers of both functions accordingly.

Marked as reviewed by thartmann (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2140

From thartmann at openjdk.java.net  Wed Jan 27 08:02:51 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 27 Jan 2021 08:02:51 GMT
Subject: [jdk16] RFR: 8260370: C2: LoopLimit node is not eliminated
In-Reply-To: <XIr8Dm4Gof2VYPtirKtd3RXdtOLbAHO5NrJ21-woU6I=.622646d9-ee51-417c-b340-ce04511542ab@github.com>
References: <XIr8Dm4Gof2VYPtirKtd3RXdtOLbAHO5NrJ21-woU6I=.622646d9-ee51-417c-b340-ce04511542ab@github.com>
Message-ID: <LsthchqjSmdZwfDq172WfGHWHv9mkr6Sqxi3RUZj2tQ=.d01b5167-803a-48ce-a492-00497493fb5a@github.com>

On Tue, 26 Jan 2021 16:54:48 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> As part of JDK-8255000 `C->major_progress` check was replaced with an explicit phase check (`post_loop_opts_phase()`).
> But `LoopLimit` was not covered and still relied on `C->major_progress()`. It exposed a problem: sometimes IGVN sets `major_progress` (e.g., see `LoopNode::Ideal()`) and it blocks `LoopLimit` node elimination if the node is processed later (`LoopLimitNode::Ideal()` is misled that loop opts phase is not over).         
> 
> The fix migrates `LoopLimitNode::Ideal()` to  `post_loop_opts_phase()`. 
> 
> Also, post-loop opts IGVN pass conservatively clears `major_progress()` just in case.  
>    
> Testing:
> - [x] failing test
> - [x] hs-tier1 - hs-tier4

Looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/134

From roland at openjdk.java.net  Wed Jan 27 08:07:04 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 27 Jan 2021 08:07:04 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v3]
In-Reply-To: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
Message-ID: <N4znCSiBMzQSv2T9Nn42nKEmmfVw59SZoc6fZVq7lgw=.1c87d509-70f1-4ddb-a1aa-eda427d8e259@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 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 seven additional commits since the last revision:

 - convert all tests
 - Merge branch 'master' into JDK-8260296
 - use CoreUtils
 - whitespaces
 - SA fixes
 - VM fix
 - test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2195/files
  - new: https://git.openjdk.java.net/jdk/pull/2195/files/8221f04b..d1e9381c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2195&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2195&range=01-02

  Stats: 25854 lines in 528 files changed: 6537 ins; 15888 del; 3429 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 rcastanedalo at openjdk.java.net  Wed Jan 27 08:08:39 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 27 Jan 2021 08:08:39 GMT
Subject: RFR: 8258894: C2: Forbid GCM to move stores into loops [v2]
In-Reply-To: <9kFOeiXVarMDbTUHQ3QXzQeUYefEVpTEFByWVqZ-lvE=.c9b05066-6bac-4822-bebc-dc59c8c7ec04@github.com>
References: <VMq5l7qqmyryiukK2Ug23hAxDyQTbACrZpV06SbGzPE=.d9198af8-dec4-4b81-b483-ccc6937733f8@github.com>
 <QZR3Mai4qMA-6Sq3IRcl3yB0NrpWHtitL-LKj-ggSMY=.a798cbd5-dba8-4a31-b1df-33916b3b5117@github.com>
 <9kFOeiXVarMDbTUHQ3QXzQeUYefEVpTEFByWVqZ-lvE=.c9b05066-6bac-4822-bebc-dc59c8c7ec04@github.com>
Message-ID: <26d7dmCCsh-MgY9rygK3_Fltr3bHqDEtxAVw1g41rW0=.6a0aa55a-2408-491a-b63a-722541ae6bd9@github.com>

On Wed, 27 Jan 2021 07:54:00 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use NOT_DEBUG_RETURN in PhaseCFG verification functions
>>   
>>   Move is_memory_writer() test into PhaseCFG::verify_memory_writer_placement(),
>>   mark the function as NOT_DEBUG_RETURN, and make it independent of the PRODUCT
>>   flag. Apply the same refactoring to PhaseCFG::verify(), for consistency.
>>   Simplify callers of both functions accordingly.
>
> Marked as reviewed by thartmann (Reviewer).

Thanks for reviewing, Tobias and Vladimir!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2140

From roland at openjdk.java.net  Wed Jan 27 08:07:06 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 27 Jan 2021 08:07:06 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v2]
In-Reply-To: <a8145fRfX7g7-42bjfGpjOuxTAHFO2vIIBTN6dOrlvs=.8d481f21-cc2a-4f0c-a2de-36ed477a1a4a@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <16SQMU3YXDN1LM9OnuT9_3kim-JBltWEoT63tQNPWgI=.c14df656-06dc-4d00-80e3-2df5acaaf58a@github.com>
 <a8145fRfX7g7-42bjfGpjOuxTAHFO2vIIBTN6dOrlvs=.8d481f21-cc2a-4f0c-a2de-36ed477a1a4a@github.com>
Message-ID: <Nl8c-3si1MxS0o-8RK08r6zqUqBu3Wws2hCZy-VNbP4=.0e3dcd42-0e24-4d97-ab56-96ae9aad3f97@github.com>

On Mon, 25 Jan 2021 19:43:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use CoreUtils
>
> test/lib/jdk/test/lib/util/CoreUtils.java line 193:
> 
>> 191:     public static String getCoreFileLocation(String crashOutputString) throws IOException {
>> 192:         return getCoreFileLocation(crashOutputString, -1);
>> 193:     }
> 
> In order to be consistent, it seems that all users of `getCoreFileLocation()` should now be passing in the pid and we should get rid of this version that doesn't require it. That means they also all need to be converted to use `ProcessTools.executeProcessPreservePID()`.

I pushed a new change that updates all tests.

> test/lib/jdk/test/lib/util/CoreUtils.java line 176:
> 
>> 174:                                 Asserts.assertGT(coreFile.length(), 0L, "Unexpected core size");
>> 175:                                 System.out.println("coredumpctl succeeded");
>> 176:                                 return core;
> 
> At the start of the outermost if/else block, there is a comment that says "See if we can figure out the likely reason the core file was not found". However, now we are doing further attempts to find the core file. At the very least the comment should be updated. Maybe add something like "Recover from failure if possible."

ok.

> test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java line 182:
> 
>> 180:         if (needCoreDump) {
>> 181:             try {
>> 182:                 String coreFileLocation = CoreUtils.getCoreFileLocation(crashOutputString);
> 
> Don't you need to pass in `pid` here?

right.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2195

From cjplummer at openjdk.java.net  Wed Jan 27 08:19:45 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 27 Jan 2021 08:19:45 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v3]
In-Reply-To: <N4znCSiBMzQSv2T9Nn42nKEmmfVw59SZoc6fZVq7lgw=.1c87d509-70f1-4ddb-a1aa-eda427d8e259@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <N4znCSiBMzQSv2T9Nn42nKEmmfVw59SZoc6fZVq7lgw=.1c87d509-70f1-4ddb-a1aa-eda427d8e259@github.com>
Message-ID: <1HcUcC5ld4jp2Yk4QXbLKCkCFmFf6PbkSRd83Mf9XkU=.1c9fef10-2867-4315-907f-f36b0688b044@github.com>

On Wed, 27 Jan 2021 08:07:04 GMT, Roland Westrelin <roland at openjdk.org> 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.
>
> 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 seven additional commits since the last revision:
> 
>  - convert all tests
>  - Merge branch 'master' into JDK-8260296
>  - use CoreUtils
>  - whitespaces
>  - SA fixes
>  - VM fix
>  - test

Marked as reviewed by cjplummer (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2195

From cjplummer at openjdk.java.net  Wed Jan 27 08:19:48 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 27 Jan 2021 08:19:48 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v3]
In-Reply-To: <1HcUcC5ld4jp2Yk4QXbLKCkCFmFf6PbkSRd83Mf9XkU=.1c9fef10-2867-4315-907f-f36b0688b044@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <N4znCSiBMzQSv2T9Nn42nKEmmfVw59SZoc6fZVq7lgw=.1c87d509-70f1-4ddb-a1aa-eda427d8e259@github.com>
 <1HcUcC5ld4jp2Yk4QXbLKCkCFmFf6PbkSRd83Mf9XkU=.1c9fef10-2867-4315-907f-f36b0688b044@github.com>
Message-ID: <PoJ_TvrBaGd2jbnQRcWyaS2_oLtHW5XJIlZ-6Z7a2Gg=.6e7b923f-b873-4d60-9720-da62b190972c@github.com>

On Wed, 27 Jan 2021 08:14:43 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> 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 seven additional commits since the last revision:
>> 
>>  - convert all tests
>>  - Merge branch 'master' into JDK-8260296
>>  - use CoreUtils
>>  - whitespaces
>>  - SA fixes
>>  - VM fix
>>  - test
>
> Marked as reviewed by cjplummer (Reviewer).

I forgot to mention that almost all the files need copyright updates, but otherwise approved.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2195

From roland at openjdk.java.net  Wed Jan 27 08:19:51 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 27 Jan 2021 08:19:51 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v3]
In-Reply-To: <tEV1-slB54oXmA3j4rn-zhpMhMblOcOUCZWgNEXSga0=.b04faa82-06ed-4d3c-917f-626de33536f1@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <tEV1-slB54oXmA3j4rn-zhpMhMblOcOUCZWgNEXSga0=.b04faa82-06ed-4d3c-917f-626de33536f1@github.com>
Message-ID: <bRsGbmTgAVs1Sk0l1ivyQLJv5lJTEht3ZzLzK2xNxKg=.5d8743aa-59cf-4c47-859f-6e3e378fccd1@github.com>

On Fri, 22 Jan 2021 17:44:34 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> 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 seven additional commits since the last revision:
>> 
>>  - convert all tests
>>  - Merge branch 'master' into JDK-8260296
>>  - use CoreUtils
>>  - whitespaces
>>  - SA fixes
>>  - VM fix
>>  - test
>
> Looks good to me.

@vnkozlov @plummercj Thanks for the reviews
@iignatev Do you want to review this change?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2195

From roland at openjdk.java.net  Wed Jan 27 08:36:11 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 27 Jan 2021 08:36:11 GMT
Subject: RFR: 8259609: C2: optimize long range checks in long counted
 loops [v4]
In-Reply-To: <J0Kj7AiqCi5l8cNV1YRmcPu005hmLgeCbBCurQ2hwHc=.aaec0d99-c0f0-4b6a-b492-d08c07b46806@github.com>
References: <J0Kj7AiqCi5l8cNV1YRmcPu005hmLgeCbBCurQ2hwHc=.aaec0d99-c0f0-4b6a-b492-d08c07b46806@github.com>
Message-ID: <SXAvq1BxF-hO_8cR_Xo8wrkwgC6gnETzEmnl-bcYW1U=.dbf6034c-e3a7-47ea-9e38-3446eb40b1a8@github.com>

> 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 ten additional commits since the last revision:

 - Tobias' comments
 - Merge branch 'master' into JDK-8259609
 - min_jint overflow fix
 - Revert "assert(static_cast<T1>(result) == thing) fix"
   
   This reverts commit e234477df097475d503ea6f94ab6a258132d165e.
 - Merge branch 'master' into JDK-8259609
 - assert(static_cast<T1>(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/afdbdea6..c308ee2e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2045&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2045&range=02-03

  Stats: 25857 lines in 524 files changed: 6535 ins; 15889 del; 3433 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 27 08:36:11 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 27 Jan 2021 08:36:11 GMT
Subject: RFR: 8259609: C2: optimize long range checks in long counted
 loops [v3]
In-Reply-To: <r3bRcbUoILjstUn96_s76Sk7aUa8KtOcG5NqS2oUPQc=.bc2edfa0-d3e3-4015-9441-02fb72e024c4@github.com>
References: <J0Kj7AiqCi5l8cNV1YRmcPu005hmLgeCbBCurQ2hwHc=.aaec0d99-c0f0-4b6a-b492-d08c07b46806@github.com>
 <iFQyPXcZCNA6TDoZUxHgLNy1t3pBuqcrONWmLkZnuw4=.c4cc12d2-a337-49d2-99ee-f567fd2295b2@github.com>
 <r3bRcbUoILjstUn96_s76Sk7aUa8KtOcG5NqS2oUPQc=.bc2edfa0-d3e3-4015-9441-02fb72e024c4@github.com>
Message-ID: <PCbmTFPyAeI7nSOM_CTrLz_6CoL9S42R0G_qxHqhSiQ=.e8f8017a-824a-4e5f-8129-ab118e1cbaa1@github.com>

On Mon, 25 Jan 2021 10:07:20 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - min_jint overflow fix
>>  - Revert "assert(static_cast<T1>(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.

@TobiHartmann thanks for the comments. I pushed a change that should address them.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2045

From whuang at openjdk.java.net  Wed Jan 27 09:05:46 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Wed, 27 Jan 2021 09:05:46 GMT
Subject: [jdk16] RFR: 8260339: JVM crashes when executing
 PhaseIdealLoop::match_fill_loop
In-Reply-To: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
References: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
Message-ID: <TvxNATFV9R2HAfAOcAdSiJMT65-L7bycFBeb8CBHXpw=.37cbeab0-cbb1-4bd2-a888-e21cffce2bdf@github.com>

On Tue, 26 Jan 2021 02:01:00 GMT, Wang Huang <whuang at openjdk.org> wrote:

> The reason is :
> 
>   BasicType t = store->as_Mem()->memory_type();
>   const char* fill_name;
>   if (msg == NULL &&
>       StubRoutines::select_fill_function(t, false, fill_name) == NULL) {
>     msg = "unsupported store";
>     msg_node = store;
>   }
> 
> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here.
> 
> I add a new case here to avoid mistake:
>   case T_NARROWOOP:
>   case T_NARROWKLASS:
>   case T_ADDRESS:
> +  case T_VOID:
>     // Currently unsupported
>     return NULL;

> Hi @Wanghuang-Huawei,
> 
> given JDK16 is RDP2 and your patch changes the shared code, you are to integrate an automated jtreg test together with the fix. I've taken `TestLoopStoreVector.java` from 8260339 and added the minimal required jtreg test description, and double-checked that the test fails on linux-aarch64 w/o the fix and passes w/ it. you can take the jtreg-ified test from my [pull/132](https://github.com/iignatev/jdk16/tree/pull/132) branch (you will need to replace `$copyright-header` w/ the appropriate line), feel free to use it as-is or modify.
> 
> Thanks,
> -- Igor

Thank you very much. I will push a new commit which contains jtreg test.

-------------

PR: https://git.openjdk.java.net/jdk16/pull/132

From whuang at openjdk.java.net  Wed Jan 27 09:27:04 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Wed, 27 Jan 2021 09:27:04 GMT
Subject: [jdk16] RFR: 8260339: JVM crashes when executing
 PhaseIdealLoop::match_fill_loop [v4]
In-Reply-To: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
References: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
Message-ID: <rf72ctBXb95gIHLNKMLC5HP29itFVroOql3optIv-sQ=.d1c7313a-4aa9-45bc-8ed7-30582fcb7950@github.com>

> The reason is :
> 
>   BasicType t = store->as_Mem()->memory_type();
>   const char* fill_name;
>   if (msg == NULL &&
>       StubRoutines::select_fill_function(t, false, fill_name) == NULL) {
>     msg = "unsupported store";
>     msg_node = store;
>   }
> 
> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here.
> 
> I add a new case here to avoid mistake:
>   case T_NARROWOOP:
>   case T_NARROWKLASS:
>   case T_ADDRESS:
> +  case T_VOID:
>     // Currently unsupported
>     return NULL;

Wang Huang has updated the pull request incrementally with one additional commit since the last revision:

  add jtreg test case

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/132/files
  - new: https://git.openjdk.java.net/jdk16/pull/132/files/ee3797d9..7ec5e23b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=02-03

  Stats: 80 lines in 1 file changed: 80 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/132.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/132/head:pull/132

PR: https://git.openjdk.java.net/jdk16/pull/132

From whuang at openjdk.java.net  Wed Jan 27 09:34:03 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Wed, 27 Jan 2021 09:34:03 GMT
Subject: [jdk16] RFR: 8260339: JVM crashes when executing
 PhaseIdealLoop::match_fill_loop [v5]
In-Reply-To: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
References: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
Message-ID: <IqzR4-31mn5ihtKVvHM5hkWPKuSVea86Wi8iNFdBiQs=.a114f488-b3e3-414a-bf86-8b71b4a4a220@github.com>

> The reason is :
> 
>   BasicType t = store->as_Mem()->memory_type();
>   const char* fill_name;
>   if (msg == NULL &&
>       StubRoutines::select_fill_function(t, false, fill_name) == NULL) {
>     msg = "unsupported store";
>     msg_node = store;
>   }
> 
> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here.
> 
> I add a new case here to avoid mistake:
>   case T_NARROWOOP:
>   case T_NARROWKLASS:
>   case T_ADDRESS:
> +  case T_VOID:
>     // Currently unsupported
>     return NULL;

Wang Huang has updated the pull request incrementally with one additional commit since the last revision:

  fix code style

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/132/files
  - new: https://git.openjdk.java.net/jdk16/pull/132/files/7ec5e23b..6efc7cee

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=03-04

  Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/132.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/132/head:pull/132

PR: https://git.openjdk.java.net/jdk16/pull/132

From whuang at openjdk.java.net  Wed Jan 27 09:37:08 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Wed, 27 Jan 2021 09:37:08 GMT
Subject: [jdk16] RFR: 8260339: JVM crashes when executing
 PhaseIdealLoop::match_fill_loop [v6]
In-Reply-To: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
References: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
Message-ID: <htlFtc-9PUq_ZCmcZwrV4ugOpIMgEl_6l80FQ41Qoik=.d3c2f0ed-a85b-4eec-8346-97f69c629c9d@github.com>

> The reason is :
> 
>   BasicType t = store->as_Mem()->memory_type();
>   const char* fill_name;
>   if (msg == NULL &&
>       StubRoutines::select_fill_function(t, false, fill_name) == NULL) {
>     msg = "unsupported store";
>     msg_node = store;
>   }
> 
> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here.
> 
> I add a new case here to avoid mistake:
>   case T_NARROWOOP:
>   case T_NARROWKLASS:
>   case T_ADDRESS:
> +  case T_VOID:
>     // Currently unsupported
>     return NULL;

Wang Huang has updated the pull request incrementally with one additional commit since the last revision:

  fix trailing whitespace

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/132/files
  - new: https://git.openjdk.java.net/jdk16/pull/132/files/6efc7cee..b9f1a249

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/132.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/132/head:pull/132

PR: https://git.openjdk.java.net/jdk16/pull/132

From neliasso at openjdk.java.net  Wed Jan 27 10:25:45 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 27 Jan 2021 10:25:45 GMT
Subject: [jdk16] RFR: 8260339: JVM crashes when executing
 PhaseIdealLoop::match_fill_loop
In-Reply-To: <TvxNATFV9R2HAfAOcAdSiJMT65-L7bycFBeb8CBHXpw=.37cbeab0-cbb1-4bd2-a888-e21cffce2bdf@github.com>
References: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
 <TvxNATFV9R2HAfAOcAdSiJMT65-L7bycFBeb8CBHXpw=.37cbeab0-cbb1-4bd2-a888-e21cffce2bdf@github.com>
Message-ID: <XDLXDh0RvFI_EP460LvuV671sb6KKTPKulEKNV_SQ94=.ad73a379-b7e0-4187-95fd-e6f2b1700ab3@github.com>

On Wed, 27 Jan 2021 09:02:26 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> The reason is :
>> 
>>   BasicType t = store->as_Mem()->memory_type();
>>   const char* fill_name;
>>   if (msg == NULL &&
>>       StubRoutines::select_fill_function(t, false, fill_name) == NULL) {
>>     msg = "unsupported store";
>>     msg_node = store;
>>   }
>> 
>> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here.
>> 
>> I add a new case here to avoid mistake:
>>   case T_NARROWOOP:
>>   case T_NARROWKLASS:
>>   case T_ADDRESS:
>> +  case T_VOID:
>>     // Currently unsupported
>>     return NULL;
>
>> Hi @Wanghuang-Huawei,
>> 
>> given JDK16 is RDP2 and your patch changes the shared code, you are to integrate an automated jtreg test together with the fix. I've taken `TestLoopStoreVector.java` from 8260339 and added the minimal required jtreg test description, and double-checked that the test fails on linux-aarch64 w/o the fix and passes w/ it. you can take the jtreg-ified test from my [pull/132](https://github.com/iignatev/jdk16/tree/pull/132) branch (you will need to replace `$copyright-header` w/ the appropriate line), feel free to use it as-is or modify.
>> 
>> Thanks,
>> -- Igor
> 
> Thank you very much. I will push a new commit which contains jtreg test.

@Wanghuang-Huawei Have you been able to reproduce this on any other platform that linux-aarch64? I'm having trouble reproducing this on x64.

-------------

PR: https://git.openjdk.java.net/jdk16/pull/132

From vlivanov at openjdk.java.net  Wed Jan 27 10:33:42 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 27 Jan 2021 10:33:42 GMT
Subject: [jdk16] Integrated: 8260370: C2: LoopLimit node is not eliminated
In-Reply-To: <XIr8Dm4Gof2VYPtirKtd3RXdtOLbAHO5NrJ21-woU6I=.622646d9-ee51-417c-b340-ce04511542ab@github.com>
References: <XIr8Dm4Gof2VYPtirKtd3RXdtOLbAHO5NrJ21-woU6I=.622646d9-ee51-417c-b340-ce04511542ab@github.com>
Message-ID: <N2gWGoqTq2sZhEC_Ge9a-Y-Rk2HnTJW292lN20RSeEo=.e2598f08-1741-4f06-8ece-698f8673bf21@github.com>

On Tue, 26 Jan 2021 16:54:48 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> As part of JDK-8255000 `C->major_progress` check was replaced with an explicit phase check (`post_loop_opts_phase()`).
> But `LoopLimit` was not covered and still relied on `C->major_progress()`. It exposed a problem: sometimes IGVN sets `major_progress` (e.g., see `LoopNode::Ideal()`) and it blocks `LoopLimit` node elimination if the node is processed later (`LoopLimitNode::Ideal()` is misled that loop opts phase is not over).         
> 
> The fix migrates `LoopLimitNode::Ideal()` to  `post_loop_opts_phase()`. 
> 
> Also, post-loop opts IGVN pass conservatively clears `major_progress()` just in case.  
>    
> Testing:
> - [x] failing test
> - [x] hs-tier1 - hs-tier4

This pull request has now been integrated.

Changeset: e28e1111
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/e28e1111
Stats:     9 lines in 2 files changed: 8 ins; 0 del; 1 mod

8260370: C2: LoopLimit node is not eliminated

Reviewed-by: kvn, thartmann

-------------

PR: https://git.openjdk.java.net/jdk16/pull/134

From jiefu at openjdk.java.net  Wed Jan 27 10:41:41 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 27 Jan 2021 10:41:41 GMT
Subject: [jdk16] RFR: 8260339: JVM crashes when executing
 PhaseIdealLoop::match_fill_loop
In-Reply-To: <TvxNATFV9R2HAfAOcAdSiJMT65-L7bycFBeb8CBHXpw=.37cbeab0-cbb1-4bd2-a888-e21cffce2bdf@github.com>
References: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
 <TvxNATFV9R2HAfAOcAdSiJMT65-L7bycFBeb8CBHXpw=.37cbeab0-cbb1-4bd2-a888-e21cffce2bdf@github.com>
Message-ID: <aBi1y1O44zCvL7eAzCPC0uIKql4fP17u4B0dmOH6uYE=.c337e569-d099-477e-b0c5-1d3884b72a81@github.com>

On Wed, 27 Jan 2021 09:02:26 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> The reason is :
>> 
>>   BasicType t = store->as_Mem()->memory_type();
>>   const char* fill_name;
>>   if (msg == NULL &&
>>       StubRoutines::select_fill_function(t, false, fill_name) == NULL) {
>>     msg = "unsupported store";
>>     msg_node = store;
>>   }
>> 
>> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here.
>> 
>> I add a new case here to avoid mistake:
>>   case T_NARROWOOP:
>>   case T_NARROWKLASS:
>>   case T_ADDRESS:
>> +  case T_VOID:
>>     // Currently unsupported
>>     return NULL;
>
>> Hi @Wanghuang-Huawei,
>> 
>> given JDK16 is RDP2 and your patch changes the shared code, you are to integrate an automated jtreg test together with the fix. I've taken `TestLoopStoreVector.java` from 8260339 and added the minimal required jtreg test description, and double-checked that the test fails on linux-aarch64 w/o the fix and passes w/ it. you can take the jtreg-ified test from my [pull/132](https://github.com/iignatev/jdk16/tree/pull/132) branch (you will need to replace `$copyright-header` w/ the appropriate line), feel free to use it as-is or modify.
>> 
>> Thanks,
>> -- Igor
> 
> Thank you very much. I will push a new commit which contains jtreg test.

> @Wanghuang-Huawei Have you been able to reproduce this on any other platform that linux-aarch64? I'm having trouble reproducing this on x64.

I tried the reproducer on the JBS just now and couldn't reproduce it on x64 either.

-------------

PR: https://git.openjdk.java.net/jdk16/pull/132

From njian at openjdk.java.net  Wed Jan 27 10:41:42 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Wed, 27 Jan 2021 10:41:42 GMT
Subject: [jdk16] RFR: 8260339: JVM crashes when executing
 PhaseIdealLoop::match_fill_loop
In-Reply-To: <TvxNATFV9R2HAfAOcAdSiJMT65-L7bycFBeb8CBHXpw=.37cbeab0-cbb1-4bd2-a888-e21cffce2bdf@github.com>
References: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
 <TvxNATFV9R2HAfAOcAdSiJMT65-L7bycFBeb8CBHXpw=.37cbeab0-cbb1-4bd2-a888-e21cffce2bdf@github.com>
Message-ID: <dJFSuD_5vLPii8B4RweesvD5eFzICui_FO8a1u37CM0=.58ce0cb2-73a9-4682-ac91-2bbf98472bc1@github.com>

On Wed, 27 Jan 2021 09:02:26 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> The reason is :
>> 
>>   BasicType t = store->as_Mem()->memory_type();
>>   const char* fill_name;
>>   if (msg == NULL &&
>>       StubRoutines::select_fill_function(t, false, fill_name) == NULL) {
>>     msg = "unsupported store";
>>     msg_node = store;
>>   }
>> 
>> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here.
>> 
>> I add a new case here to avoid mistake:
>>   case T_NARROWOOP:
>>   case T_NARROWKLASS:
>>   case T_ADDRESS:
>> +  case T_VOID:
>>     // Currently unsupported
>>     return NULL;
>
>> Hi @Wanghuang-Huawei,
>> 
>> given JDK16 is RDP2 and your patch changes the shared code, you are to integrate an automated jtreg test together with the fix. I've taken `TestLoopStoreVector.java` from 8260339 and added the minimal required jtreg test description, and double-checked that the test fails on linux-aarch64 w/o the fix and passes w/ it. you can take the jtreg-ified test from my [pull/132](https://github.com/iignatev/jdk16/tree/pull/132) branch (you will need to replace `$copyright-header` w/ the appropriate line), feel free to use it as-is or modify.
>> 
>> Thanks,
>> -- Igor
> 
> Thank you very much. I will push a new commit which contains jtreg test.

> @Wanghuang-Huawei Have you been able to reproduce this on any other platform that linux-aarch64? I'm having trouble reproducing this on x64.

I think x64 has disabled OptimizeFill by default. I can reproduce this with -XX:+OptimizeFill.

-------------

PR: https://git.openjdk.java.net/jdk16/pull/132

From linuxhippy at gmail.com  Wed Jan 27 10:53:58 2021
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Wed, 27 Jan 2021 11:53:58 +0100
Subject: Frequent c1 compiler errors running IntelliJ with Openjdk 15
 (JavaCallWrapper::JavaCallWrapper - failed: cannot make java calls from the
 native compiler)
Message-ID: <CAFvQSYThOqet7TK56B=qwFqEy=bbQjb3asEm0UwEd_Gsfdn2xA@mail.gmail.com>

Hi,

Since I started using IntelliJ for working on the java2d opengl backend I
get internal errors in C1, in the method JavaCallWrapper::JavaCallWrapper:
https://pastebin.com/rbNLeAvL
I observed those crashes with both - fedora bundled openjdk as well as with
a build of adoptopenjdk:

Fedora-33:
  openjdk version "15.0.1" 2020-10-20
  OpenJDK Runtime Environment 20.9 (build 15.0.1+9)
AdoptOpenJDK:
  openjdk version "15.0.2" 2021-01-19
  OpenJDK Runtime Environment AdoptOpenJDK (build 15.0.2+7)

The crash log looks quite equal each time (log attached).

I wonder, is this a known problem - is should I report it?

Thanks, Clemens

# Internal Error (javaCalls.cpp:60), pid=35643, tid=35656
# guarantee(thread->can_call_java()) failed: cannot make java calls from
the native compiler
#

Current CompileTask:
C1: 485187 64127       3
com.intellij.codeInspection.sameParameterValue.SameParameterValueInspection$LocalSameParameterValueInspection$1::visitMethod
(362 bytes)

Stack: [0x00007fe2fc0fb000,0x00007fe2fc1fc000],  sp=0x00007fe2fc1f8fc0,
 free space=1015k
Native frames: (J=compiled Java code, A=aot compiled Java code,
j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x7ded64]  JavaCallWrapper::JavaCallWrapper(methodHandle
const&, Handle, JavaValue*, Thread*)+0x1c4
V  [libjvm.so+0x7e2253]  JavaCalls::call_helper(JavaValue*, methodHandle
const&, JavaCallArguments*, Thread*)+0x183
V  [libjvm.so+0x7e066c]  JavaCalls::call_special(JavaValue*, Handle,
Klass*, Symbol*, Symbol*, Handle, Handle, Thread*)+0x1cc
V  [libjvm.so+0xdfe55d]
 SystemDictionary::validate_protection_domain(InstanceKlass*, Handle,
Handle, Thread*)+0x20d
V  [libjvm.so+0xe0113c]
 SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle,
Thread*)+0xb1c
V  [libjvm.so+0xe012ea]
 SystemDictionary::resolve_instance_class_or_null_helper(Symbol*, Handle,
Handle, Thread*)+0x2a
V  [libjvm.so+0xe026ce]  SystemDictionary::resolve_or_fail(Symbol*, Handle,
Handle, bool, Thread*)+0x2e
V  [libjvm.so+0x598baf]  ConstantPool::klass_at_impl(constantPoolHandle
const&, int, bool, Thread*)+0xdf
V  [libjvm.so+0x7bf7e0]  ConstantPool::klass_at(int, Thread*)+0x60
V  [libjvm.so+0x7b9d17]  InstanceKlass::has_nest_member(InstanceKlass*,
Thread*) const+0x397
V  [libjvm.so+0x7bbbbe]  InstanceKlass::nest_host(Thread*) [clone
.part.349]+0x3ae
V  [libjvm.so+0x7bbd1c]
 InstanceKlass::has_nestmate_access_to(InstanceKlass*, Thread*)+0x4c
V  [libjvm.so+0xc5b707]  Reflection::verify_member_access(Klass const*,
Klass const*, Klass const*, AccessFlags, bool, bool, Thread*)+0x207
V  [libjvm.so+0xa17b21]  LinkResolver::check_method_accessability(Klass*,
Klass*, Klass*, methodHandle const&, Thread*)+0x61
V  [libjvm.so+0xa18776]  LinkResolver::resolve_method(LinkInfo const&,
Bytecodes::Code, Thread*)+0x3e6
V  [libjvm.so+0xa1b947]
 LinkResolver::linktime_resolve_virtual_method(LinkInfo const&,
Thread*)+0x27
V  [libjvm.so+0xa1bbb2]
 LinkResolver::linktime_resolve_virtual_method_or_null(LinkInfo const&)+0x32
V  [libjvm.so+0x4d137c]  ciEnv::get_method_by_index_impl(constantPoolHandle
const&, int, Bytecodes::Code, ciInstanceKlass*)+0x3ec
V  [libjvm.so+0x4d1910]  ciEnv::get_method_by_index(constantPoolHandle
const&, int, Bytecodes::Code, ciInstanceKlass*)+0x310
V  [libjvm.so+0x4f58ee]  ciBytecodeStream::get_method(bool&,
ciSignature**)+0x11e
V  [libjvm.so+0x407323]  GraphBuilder::invoke(Bytecodes::Code)+0x33
V  [libjvm.so+0x409667]
 GraphBuilder::iterate_bytecodes_for_block(int)+0x10b7
V  [libjvm.so+0x40b0d4]  GraphBuilder::iterate_all_blocks(bool)+0x174
V  [libjvm.so+0x40cf30]  GraphBuilder::GraphBuilder(Compilation*,
IRScope*)+0x440
V  [libjvm.so+0x410a72]  IRScope::IRScope(Compilation*, IRScope*, int,
ciMethod*, int, bool)+0x1d2
V  [libjvm.so+0x4116b6]  IR::IR(Compilation*, ciMethod*, int)+0xa6
V  [libjvm.so+0x3f1586]  Compilation::build_hir() [clone .part.95]+0x166
V  [libjvm.so+0x3f1dd3]  Compilation::compile_java_method()+0x3a3
V  [libjvm.so+0x3f1f6f]  Compilation::compile_method()+0x12f
V  [libjvm.so+0x3f23cc]  Compilation::Compilation(AbstractCompiler*,
ciEnv*, ciMethod*, int, BufferBlob*, DirectiveSet*)+0x22c
V  [libjvm.so+0x3f2cae]  Compiler::compile_method(ciEnv*, ciMethod*, int,
DirectiveSet*)+0xae
V  [libjvm.so+0x5720cc]
 CompileBroker::invoke_compiler_on_method(CompileTask*)+0xeec
V  [libjvm.so+0x572eb8]  CompileBroker::compiler_thread_loop()+0x5b8
V  [libjvm.so+0xe50f8a]  JavaThread::thread_main_inner()+0x1da
V  [libjvm.so+0xe55baf]  Thread::call_run()+0xff
V  [libjvm.so+0xbc77e7]  thread_native_entry(Thread*)+0xe7

From neliasso at openjdk.java.net  Wed Jan 27 11:13:42 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 27 Jan 2021 11:13:42 GMT
Subject: [jdk16] RFR: 8260339: JVM crashes when executing
 PhaseIdealLoop::match_fill_loop
In-Reply-To: <dJFSuD_5vLPii8B4RweesvD5eFzICui_FO8a1u37CM0=.58ce0cb2-73a9-4682-ac91-2bbf98472bc1@github.com>
References: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
 <TvxNATFV9R2HAfAOcAdSiJMT65-L7bycFBeb8CBHXpw=.37cbeab0-cbb1-4bd2-a888-e21cffce2bdf@github.com>
 <dJFSuD_5vLPii8B4RweesvD5eFzICui_FO8a1u37CM0=.58ce0cb2-73a9-4682-ac91-2bbf98472bc1@github.com>
Message-ID: <XAlign_bkEddFEWaiaUrVGkAK_IF1o3vJnnvj2Z6FPw=.6dc069e7-2040-4a58-b4dd-7b5aa0cb1cc3@github.com>

On Wed, 27 Jan 2021 10:39:24 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

>>> Hi @Wanghuang-Huawei,
>>> 
>>> given JDK16 is RDP2 and your patch changes the shared code, you are to integrate an automated jtreg test together with the fix. I've taken `TestLoopStoreVector.java` from 8260339 and added the minimal required jtreg test description, and double-checked that the test fails on linux-aarch64 w/o the fix and passes w/ it. you can take the jtreg-ified test from my [pull/132](https://github.com/iignatev/jdk16/tree/pull/132) branch (you will need to replace `$copyright-header` w/ the appropriate line), feel free to use it as-is or modify.
>>> 
>>> Thanks,
>>> -- Igor
>> 
>> Thank you very much. I will push a new commit which contains jtreg test.
>
>> @Wanghuang-Huawei Have you been able to reproduce this on any other platform that linux-aarch64? I'm having trouble reproducing this on x64.
> 
> I think x64 has disabled OptimizeFill by default. I can reproduce this with -XX:+OptimizeFill.

Please add  -XX:+OptimizeFill to the regression test

-------------

PR: https://git.openjdk.java.net/jdk16/pull/132

From vladimir.x.ivanov at oracle.com  Wed Jan 27 11:46:36 2021
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 27 Jan 2021 14:46:36 +0300
Subject: Frequent c1 compiler errors running IntelliJ with Openjdk 15
 (JavaCallWrapper::JavaCallWrapper - failed: cannot make java calls from the
 native compiler)
In-Reply-To: <CAFvQSYThOqet7TK56B=qwFqEy=bbQjb3asEm0UwEd_Gsfdn2xA@mail.gmail.com>
References: <CAFvQSYThOqet7TK56B=qwFqEy=bbQjb3asEm0UwEd_Gsfdn2xA@mail.gmail.com>
Message-ID: <1632ce78-f490-d586-fe47-c254561e6cd8@oracle.com>

(CCing hotspot-runtime-dev since it is related to nestmates support.)

Hi Clemens,

It does look very similar to JDK-8217765 [1], but the bug was fixed long 
time ago.

Please, file new bug.

Best regards,
Vladimir Ivanov

[1] https://bugs.openjdk.java.net/browse/JDK-8217765

On 27.01.2021 13:53, Clemens Eisserer wrote:
> Hi,
> 
> Since I started using IntelliJ for working on the java2d opengl backend I
> get internal errors in C1, in the method JavaCallWrapper::JavaCallWrapper:
> https://pastebin.com/rbNLeAvL
> I observed those crashes with both - fedora bundled openjdk as well as with
> a build of adoptopenjdk:
> 
> Fedora-33:
>    openjdk version "15.0.1" 2020-10-20
>    OpenJDK Runtime Environment 20.9 (build 15.0.1+9)
> AdoptOpenJDK:
>    openjdk version "15.0.2" 2021-01-19
>    OpenJDK Runtime Environment AdoptOpenJDK (build 15.0.2+7)
> 
> The crash log looks quite equal each time (log attached).
> 
> I wonder, is this a known problem - is should I report it?
> 
> Thanks, Clemens
> 
> # Internal Error (javaCalls.cpp:60), pid=35643, tid=35656
> # guarantee(thread->can_call_java()) failed: cannot make java calls from
> the native compiler
> #
> 
> Current CompileTask:
> C1: 485187 64127       3
> com.intellij.codeInspection.sameParameterValue.SameParameterValueInspection$LocalSameParameterValueInspection$1::visitMethod
> (362 bytes)
> 
> Stack: [0x00007fe2fc0fb000,0x00007fe2fc1fc000],  sp=0x00007fe2fc1f8fc0,
>   free space=1015k
> Native frames: (J=compiled Java code, A=aot compiled Java code,
> j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x7ded64]  JavaCallWrapper::JavaCallWrapper(methodHandle
> const&, Handle, JavaValue*, Thread*)+0x1c4
> V  [libjvm.so+0x7e2253]  JavaCalls::call_helper(JavaValue*, methodHandle
> const&, JavaCallArguments*, Thread*)+0x183
> V  [libjvm.so+0x7e066c]  JavaCalls::call_special(JavaValue*, Handle,
> Klass*, Symbol*, Symbol*, Handle, Handle, Thread*)+0x1cc
> V  [libjvm.so+0xdfe55d]
>   SystemDictionary::validate_protection_domain(InstanceKlass*, Handle,
> Handle, Thread*)+0x20d
> V  [libjvm.so+0xe0113c]
>   SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle,
> Thread*)+0xb1c
> V  [libjvm.so+0xe012ea]
>   SystemDictionary::resolve_instance_class_or_null_helper(Symbol*, Handle,
> Handle, Thread*)+0x2a
> V  [libjvm.so+0xe026ce]  SystemDictionary::resolve_or_fail(Symbol*, Handle,
> Handle, bool, Thread*)+0x2e
> V  [libjvm.so+0x598baf]  ConstantPool::klass_at_impl(constantPoolHandle
> const&, int, bool, Thread*)+0xdf
> V  [libjvm.so+0x7bf7e0]  ConstantPool::klass_at(int, Thread*)+0x60
> V  [libjvm.so+0x7b9d17]  InstanceKlass::has_nest_member(InstanceKlass*,
> Thread*) const+0x397
> V  [libjvm.so+0x7bbbbe]  InstanceKlass::nest_host(Thread*) [clone
> .part.349]+0x3ae
> V  [libjvm.so+0x7bbd1c]
>   InstanceKlass::has_nestmate_access_to(InstanceKlass*, Thread*)+0x4c
> V  [libjvm.so+0xc5b707]  Reflection::verify_member_access(Klass const*,
> Klass const*, Klass const*, AccessFlags, bool, bool, Thread*)+0x207
> V  [libjvm.so+0xa17b21]  LinkResolver::check_method_accessability(Klass*,
> Klass*, Klass*, methodHandle const&, Thread*)+0x61
> V  [libjvm.so+0xa18776]  LinkResolver::resolve_method(LinkInfo const&,
> Bytecodes::Code, Thread*)+0x3e6
> V  [libjvm.so+0xa1b947]
>   LinkResolver::linktime_resolve_virtual_method(LinkInfo const&,
> Thread*)+0x27
> V  [libjvm.so+0xa1bbb2]
>   LinkResolver::linktime_resolve_virtual_method_or_null(LinkInfo const&)+0x32
> V  [libjvm.so+0x4d137c]  ciEnv::get_method_by_index_impl(constantPoolHandle
> const&, int, Bytecodes::Code, ciInstanceKlass*)+0x3ec
> V  [libjvm.so+0x4d1910]  ciEnv::get_method_by_index(constantPoolHandle
> const&, int, Bytecodes::Code, ciInstanceKlass*)+0x310
> V  [libjvm.so+0x4f58ee]  ciBytecodeStream::get_method(bool&,
> ciSignature**)+0x11e
> V  [libjvm.so+0x407323]  GraphBuilder::invoke(Bytecodes::Code)+0x33
> V  [libjvm.so+0x409667]
>   GraphBuilder::iterate_bytecodes_for_block(int)+0x10b7
> V  [libjvm.so+0x40b0d4]  GraphBuilder::iterate_all_blocks(bool)+0x174
> V  [libjvm.so+0x40cf30]  GraphBuilder::GraphBuilder(Compilation*,
> IRScope*)+0x440
> V  [libjvm.so+0x410a72]  IRScope::IRScope(Compilation*, IRScope*, int,
> ciMethod*, int, bool)+0x1d2
> V  [libjvm.so+0x4116b6]  IR::IR(Compilation*, ciMethod*, int)+0xa6
> V  [libjvm.so+0x3f1586]  Compilation::build_hir() [clone .part.95]+0x166
> V  [libjvm.so+0x3f1dd3]  Compilation::compile_java_method()+0x3a3
> V  [libjvm.so+0x3f1f6f]  Compilation::compile_method()+0x12f
> V  [libjvm.so+0x3f23cc]  Compilation::Compilation(AbstractCompiler*,
> ciEnv*, ciMethod*, int, BufferBlob*, DirectiveSet*)+0x22c
> V  [libjvm.so+0x3f2cae]  Compiler::compile_method(ciEnv*, ciMethod*, int,
> DirectiveSet*)+0xae
> V  [libjvm.so+0x5720cc]
>   CompileBroker::invoke_compiler_on_method(CompileTask*)+0xeec
> V  [libjvm.so+0x572eb8]  CompileBroker::compiler_thread_loop()+0x5b8
> V  [libjvm.so+0xe50f8a]  JavaThread::thread_main_inner()+0x1da
> V  [libjvm.so+0xe55baf]  Thread::call_run()+0xff
> V  [libjvm.so+0xbc77e7]  thread_native_entry(Thread*)+0xe7
> 

From jiefu at openjdk.java.net  Wed Jan 27 11:56:47 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 27 Jan 2021 11:56:47 GMT
Subject: RFR: 8260501: [Vector API] Improve register usage for shift
 operations on x86
Message-ID: <eiKG7lnaASe7574tjTNKvcokiwA1mkp_c8rD6VK2iPI=.12a4a3c1-970f-4ce2-9d6c-1a0057a2f207@github.com>

Hi all,

I found the register usage is less optimized for some shift operations.
For example, vshiftL_imm [1]/vshiftI_imm require dst != src.
But it's actually fine for the register allocator to assign dst == src.

Also, vshiftL [2]/vshiftI/vshiftS require dst != src.
But it's actually required for UseAVX==0 only.
For the most common cases (UseAVX > 0), it's fine to assign dst == src.

The fix splits vshiftS/vshiftI/vshiftL into UseAVX > 0 and UseAVX == 0 cases.
And just removes the unreasonable requirement for vshiftI_imm and vshiftL_imm. 

Testing:
  - jdk/incubator/vector/ on x64 with UseAVX=3/2/1/0, no regression

Thanks.
Best regards,
Jie

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L6058
[2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L6037

-------------

Commit messages:
 - 8260501: [Vector API] Improve register usage for shift operations on x86

Changes: https://git.openjdk.java.net/jdk/pull/2257/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2257&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260501
  Stats: 86 lines in 1 file changed: 46 ins; 22 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2257.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2257/head:pull/2257

PR: https://git.openjdk.java.net/jdk/pull/2257

From aleksei.voitylov at bell-sw.com  Wed Jan 27 12:05:13 2021
From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov)
Date: Wed, 27 Jan 2021 15:05:13 +0300
Subject: Frequent c1 compiler errors running IntelliJ with Openjdk 15
 (JavaCallWrapper::JavaCallWrapper - failed: cannot make java calls from the
 native compiler)
In-Reply-To: <1632ce78-f490-d586-fe47-c254561e6cd8@oracle.com>
References: <CAFvQSYThOqet7TK56B=qwFqEy=bbQjb3asEm0UwEd_Gsfdn2xA@mail.gmail.com>
 <1632ce78-f490-d586-fe47-c254561e6cd8@oracle.com>
Message-ID: <a8870fa2-47ca-ce16-fda3-376aa15c9052@bell-sw.com>

Clemens, which version of IntelliJ are you on? I'm asking because
another manifestation of this issue was fixed in JBR-1884.

That said, I don't believe we have ruled out all possibilities for the
cause of these crashes with JDK-8217765. I plan to submit an issue with
another attempt to fix this on the jni.cpp side, but your stack seems to
show yet another problem.

-Aleksei

On 27/01/2021 14:46, Vladimir Ivanov wrote:
> (CCing hotspot-runtime-dev since it is related to nestmates support.)
>
> Hi Clemens,
>
> It does look very similar to JDK-8217765 [1], but the bug was fixed
> long time ago.
>
> Please, file new bug.
>
> Best regards,
> Vladimir Ivanov
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8217765
>
> On 27.01.2021 13:53, Clemens Eisserer wrote:
>> Hi,
>>
>> Since I started using IntelliJ for working on the java2d opengl
>> backend I
>> get internal errors in C1, in the method
>> JavaCallWrapper::JavaCallWrapper:
>> https://pastebin.com/rbNLeAvL
>> I observed those crashes with both - fedora bundled openjdk as well
>> as with
>> a build of adoptopenjdk:
>>
>> Fedora-33:
>> ?? openjdk version "15.0.1" 2020-10-20
>> ?? OpenJDK Runtime Environment 20.9 (build 15.0.1+9)
>> AdoptOpenJDK:
>> ?? openjdk version "15.0.2" 2021-01-19
>> ?? OpenJDK Runtime Environment AdoptOpenJDK (build 15.0.2+7)
>>
>> The crash log looks quite equal each time (log attached).
>>
>> I wonder, is this a known problem - is should I report it?
>>
>> Thanks, Clemens
>>
>> # Internal Error (javaCalls.cpp:60), pid=35643, tid=35656
>> # guarantee(thread->can_call_java()) failed: cannot make java calls from
>> the native compiler
>> #
>>
>> Current CompileTask:
>> C1: 485187 64127?????? 3
>> com.intellij.codeInspection.sameParameterValue.SameParameterValueInspection$LocalSameParameterValueInspection$1::visitMethod
>>
>> (362 bytes)
>>
>> Stack: [0x00007fe2fc0fb000,0x00007fe2fc1fc000],? sp=0x00007fe2fc1f8fc0,
>> ? free space=1015k
>> Native frames: (J=compiled Java code, A=aot compiled Java code,
>> j=interpreted, Vv=VM code, C=native code)
>> V? [libjvm.so+0x7ded64]? JavaCallWrapper::JavaCallWrapper(methodHandle
>> const&, Handle, JavaValue*, Thread*)+0x1c4
>> V? [libjvm.so+0x7e2253]? JavaCalls::call_helper(JavaValue*, methodHandle
>> const&, JavaCallArguments*, Thread*)+0x183
>> V? [libjvm.so+0x7e066c]? JavaCalls::call_special(JavaValue*, Handle,
>> Klass*, Symbol*, Symbol*, Handle, Handle, Thread*)+0x1cc
>> V? [libjvm.so+0xdfe55d]
>> ? SystemDictionary::validate_protection_domain(InstanceKlass*, Handle,
>> Handle, Thread*)+0x20d
>> V? [libjvm.so+0xe0113c]
>> ? SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle,
>> Handle,
>> Thread*)+0xb1c
>> V? [libjvm.so+0xe012ea]
>> ? SystemDictionary::resolve_instance_class_or_null_helper(Symbol*,
>> Handle,
>> Handle, Thread*)+0x2a
>> V? [libjvm.so+0xe026ce]? SystemDictionary::resolve_or_fail(Symbol*,
>> Handle,
>> Handle, bool, Thread*)+0x2e
>> V? [libjvm.so+0x598baf]? ConstantPool::klass_at_impl(constantPoolHandle
>> const&, int, bool, Thread*)+0xdf
>> V? [libjvm.so+0x7bf7e0]? ConstantPool::klass_at(int, Thread*)+0x60
>> V? [libjvm.so+0x7b9d17]? InstanceKlass::has_nest_member(InstanceKlass*,
>> Thread*) const+0x397
>> V? [libjvm.so+0x7bbbbe]? InstanceKlass::nest_host(Thread*) [clone
>> .part.349]+0x3ae
>> V? [libjvm.so+0x7bbd1c]
>> ? InstanceKlass::has_nestmate_access_to(InstanceKlass*, Thread*)+0x4c
>> V? [libjvm.so+0xc5b707]? Reflection::verify_member_access(Klass const*,
>> Klass const*, Klass const*, AccessFlags, bool, bool, Thread*)+0x207
>> V? [libjvm.so+0xa17b21]?
>> LinkResolver::check_method_accessability(Klass*,
>> Klass*, Klass*, methodHandle const&, Thread*)+0x61
>> V? [libjvm.so+0xa18776]? LinkResolver::resolve_method(LinkInfo const&,
>> Bytecodes::Code, Thread*)+0x3e6
>> V? [libjvm.so+0xa1b947]
>> ? LinkResolver::linktime_resolve_virtual_method(LinkInfo const&,
>> Thread*)+0x27
>> V? [libjvm.so+0xa1bbb2]
>> ? LinkResolver::linktime_resolve_virtual_method_or_null(LinkInfo
>> const&)+0x32
>> V? [libjvm.so+0x4d137c]?
>> ciEnv::get_method_by_index_impl(constantPoolHandle
>> const&, int, Bytecodes::Code, ciInstanceKlass*)+0x3ec
>> V? [libjvm.so+0x4d1910]? ciEnv::get_method_by_index(constantPoolHandle
>> const&, int, Bytecodes::Code, ciInstanceKlass*)+0x310
>> V? [libjvm.so+0x4f58ee]? ciBytecodeStream::get_method(bool&,
>> ciSignature**)+0x11e
>> V? [libjvm.so+0x407323]? GraphBuilder::invoke(Bytecodes::Code)+0x33
>> V? [libjvm.so+0x409667]
>> ? GraphBuilder::iterate_bytecodes_for_block(int)+0x10b7
>> V? [libjvm.so+0x40b0d4]? GraphBuilder::iterate_all_blocks(bool)+0x174
>> V? [libjvm.so+0x40cf30]? GraphBuilder::GraphBuilder(Compilation*,
>> IRScope*)+0x440
>> V? [libjvm.so+0x410a72]? IRScope::IRScope(Compilation*, IRScope*, int,
>> ciMethod*, int, bool)+0x1d2
>> V? [libjvm.so+0x4116b6]? IR::IR(Compilation*, ciMethod*, int)+0xa6
>> V? [libjvm.so+0x3f1586]? Compilation::build_hir() [clone .part.95]+0x166
>> V? [libjvm.so+0x3f1dd3]? Compilation::compile_java_method()+0x3a3
>> V? [libjvm.so+0x3f1f6f]? Compilation::compile_method()+0x12f
>> V? [libjvm.so+0x3f23cc]? Compilation::Compilation(AbstractCompiler*,
>> ciEnv*, ciMethod*, int, BufferBlob*, DirectiveSet*)+0x22c
>> V? [libjvm.so+0x3f2cae]? Compiler::compile_method(ciEnv*, ciMethod*,
>> int,
>> DirectiveSet*)+0xae
>> V? [libjvm.so+0x5720cc]
>> ? CompileBroker::invoke_compiler_on_method(CompileTask*)+0xeec
>> V? [libjvm.so+0x572eb8]? CompileBroker::compiler_thread_loop()+0x5b8
>> V? [libjvm.so+0xe50f8a]? JavaThread::thread_main_inner()+0x1da
>> V? [libjvm.so+0xe55baf]? Thread::call_run()+0xff
>> V? [libjvm.so+0xbc77e7]? thread_native_entry(Thread*)+0xe7
>>


From mdoerr at openjdk.java.net  Wed Jan 27 12:17:49 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 27 Jan 2021 12:17:49 GMT
Subject: RFR: 8260502: [s390] NativeMovRegMem::verify() fails because it's too
 strict
Message-ID: <B-kpkKfkuSOmBHpe6qjjZ_xowa1MHzqzK2zuWDIus0c=.b550a29c-7a78-402c-adbb-d071dbadf6d6@github.com>

"fatal error: this is not a `NativeMovRegMem' site" was observed while testing the debug build without CompressedOops.
NativeMovRegMem::verify() tries to verify instructions beyond the load_const at a place at which we don't have valid instructions. See bug for details.
I suggest to remove the wrong part of the verification.

-------------

Commit messages:
 - 8260502: [s390] NativeMovRegMem::verify() fails because it's too strict

Changes: https://git.openjdk.java.net/jdk/pull/2258/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2258&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260502
  Stats: 27 lines in 1 file changed: 0 ins; 27 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2258.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2258/head:pull/2258

PR: https://git.openjdk.java.net/jdk/pull/2258

From linuxhippy at gmail.com  Wed Jan 27 12:40:42 2021
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Wed, 27 Jan 2021 13:40:42 +0100
Subject: Frequent c1 compiler errors running IntelliJ with Openjdk 15
 (JavaCallWrapper::JavaCallWrapper - failed: cannot make java calls from the
 native compiler)
In-Reply-To: <a8870fa2-47ca-ce16-fda3-376aa15c9052@bell-sw.com>
References: <CAFvQSYThOqet7TK56B=qwFqEy=bbQjb3asEm0UwEd_Gsfdn2xA@mail.gmail.com>
 <1632ce78-f490-d586-fe47-c254561e6cd8@oracle.com>
 <a8870fa2-47ca-ce16-fda3-376aa15c9052@bell-sw.com>
Message-ID: <CAFvQSYSeCUKbLi2Qk7A=ySHDe0aEFdP+pLHBx-qYoofzLgBDPA@mail.gmail.com>

Hi Aleksei,

I am using ...

IntelliJ IDEA 2020.3.1 (Ultimate Edition)
Build #IU-203.6682.168, built on December 29, 2020
Runtime version: 15.0.2+7 amd64
VM: OpenJDK 64-Bit Server VM by AdoptOpenJDK
Linux 5.10.9-201.fc33.x86_64
GC: G1 Young Generation, G1 Old Generation
Memory: 4096M
Cores: 6
Non-Bundled Plugins: com.jetbrains.ChooseRuntime,
com.redhat.devtools.intellij.quarkus, org.jetbrains.kotlin,
com.intellij.plugins.html.instantEditing, org.asciidoctor.intellij.asciidoc
Current Desktop: KDE

Best regards, Clemens

Am Mi., 27. Jan. 2021 um 13:05 Uhr schrieb Aleksei Voitylov <
aleksei.voitylov at bell-sw.com>:

> Clemens, which version of IntelliJ are you on? I'm asking because
> another manifestation of this issue was fixed in JBR-1884.
>
> That said, I don't believe we have ruled out all possibilities for the
> cause of these crashes with JDK-8217765. I plan to submit an issue with
> another attempt to fix this on the jni.cpp side, but your stack seems to
> show yet another problem.
>
> -Aleksei
>
> On 27/01/2021 14:46, Vladimir Ivanov wrote:
> > (CCing hotspot-runtime-dev since it is related to nestmates support.)
> >
> > Hi Clemens,
> >
> > It does look very similar to JDK-8217765 [1], but the bug was fixed
> > long time ago.
> >
> > Please, file new bug.
> >
> > Best regards,
> > Vladimir Ivanov
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8217765
> >
> > On 27.01.2021 13:53, Clemens Eisserer wrote:
> >> Hi,
> >>
> >> Since I started using IntelliJ for working on the java2d opengl
> >> backend I
> >> get internal errors in C1, in the method
> >> JavaCallWrapper::JavaCallWrapper:
> >> https://pastebin.com/rbNLeAvL
> >> I observed those crashes with both - fedora bundled openjdk as well
> >> as with
> >> a build of adoptopenjdk:
> >>
> >> Fedora-33:
> >>    openjdk version "15.0.1" 2020-10-20
> >>    OpenJDK Runtime Environment 20.9 (build 15.0.1+9)
> >> AdoptOpenJDK:
> >>    openjdk version "15.0.2" 2021-01-19
> >>    OpenJDK Runtime Environment AdoptOpenJDK (build 15.0.2+7)
> >>
> >> The crash log looks quite equal each time (log attached).
> >>
> >> I wonder, is this a known problem - is should I report it?
> >>
> >> Thanks, Clemens
> >>
> >> # Internal Error (javaCalls.cpp:60), pid=35643, tid=35656
> >> # guarantee(thread->can_call_java()) failed: cannot make java calls from
> >> the native compiler
> >> #
> >>
> >> Current CompileTask:
> >> C1: 485187 64127       3
> >>
> com.intellij.codeInspection.sameParameterValue.SameParameterValueInspection$LocalSameParameterValueInspection$1::visitMethod
> >>
> >> (362 bytes)
> >>
> >> Stack: [0x00007fe2fc0fb000,0x00007fe2fc1fc000],  sp=0x00007fe2fc1f8fc0,
> >>   free space=1015k
> >> Native frames: (J=compiled Java code, A=aot compiled Java code,
> >> j=interpreted, Vv=VM code, C=native code)
> >> V  [libjvm.so+0x7ded64]  JavaCallWrapper::JavaCallWrapper(methodHandle
> >> const&, Handle, JavaValue*, Thread*)+0x1c4
> >> V  [libjvm.so+0x7e2253]  JavaCalls::call_helper(JavaValue*, methodHandle
> >> const&, JavaCallArguments*, Thread*)+0x183
> >> V  [libjvm.so+0x7e066c]  JavaCalls::call_special(JavaValue*, Handle,
> >> Klass*, Symbol*, Symbol*, Handle, Handle, Thread*)+0x1cc
> >> V  [libjvm.so+0xdfe55d]
> >>   SystemDictionary::validate_protection_domain(InstanceKlass*, Handle,
> >> Handle, Thread*)+0x20d
> >> V  [libjvm.so+0xe0113c]
> >>   SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle,
> >> Handle,
> >> Thread*)+0xb1c
> >> V  [libjvm.so+0xe012ea]
> >>   SystemDictionary::resolve_instance_class_or_null_helper(Symbol*,
> >> Handle,
> >> Handle, Thread*)+0x2a
> >> V  [libjvm.so+0xe026ce]  SystemDictionary::resolve_or_fail(Symbol*,
> >> Handle,
> >> Handle, bool, Thread*)+0x2e
> >> V  [libjvm.so+0x598baf]  ConstantPool::klass_at_impl(constantPoolHandle
> >> const&, int, bool, Thread*)+0xdf
> >> V  [libjvm.so+0x7bf7e0]  ConstantPool::klass_at(int, Thread*)+0x60
> >> V  [libjvm.so+0x7b9d17]  InstanceKlass::has_nest_member(InstanceKlass*,
> >> Thread*) const+0x397
> >> V  [libjvm.so+0x7bbbbe]  InstanceKlass::nest_host(Thread*) [clone
> >> .part.349]+0x3ae
> >> V  [libjvm.so+0x7bbd1c]
> >>   InstanceKlass::has_nestmate_access_to(InstanceKlass*, Thread*)+0x4c
> >> V  [libjvm.so+0xc5b707]  Reflection::verify_member_access(Klass const*,
> >> Klass const*, Klass const*, AccessFlags, bool, bool, Thread*)+0x207
> >> V  [libjvm.so+0xa17b21]
> >> LinkResolver::check_method_accessability(Klass*,
> >> Klass*, Klass*, methodHandle const&, Thread*)+0x61
> >> V  [libjvm.so+0xa18776]  LinkResolver::resolve_method(LinkInfo const&,
> >> Bytecodes::Code, Thread*)+0x3e6
> >> V  [libjvm.so+0xa1b947]
> >>   LinkResolver::linktime_resolve_virtual_method(LinkInfo const&,
> >> Thread*)+0x27
> >> V  [libjvm.so+0xa1bbb2]
> >>   LinkResolver::linktime_resolve_virtual_method_or_null(LinkInfo
> >> const&)+0x32
> >> V  [libjvm.so+0x4d137c]
> >> ciEnv::get_method_by_index_impl(constantPoolHandle
> >> const&, int, Bytecodes::Code, ciInstanceKlass*)+0x3ec
> >> V  [libjvm.so+0x4d1910]  ciEnv::get_method_by_index(constantPoolHandle
> >> const&, int, Bytecodes::Code, ciInstanceKlass*)+0x310
> >> V  [libjvm.so+0x4f58ee]  ciBytecodeStream::get_method(bool&,
> >> ciSignature**)+0x11e
> >> V  [libjvm.so+0x407323]  GraphBuilder::invoke(Bytecodes::Code)+0x33
> >> V  [libjvm.so+0x409667]
> >>   GraphBuilder::iterate_bytecodes_for_block(int)+0x10b7
> >> V  [libjvm.so+0x40b0d4]  GraphBuilder::iterate_all_blocks(bool)+0x174
> >> V  [libjvm.so+0x40cf30]  GraphBuilder::GraphBuilder(Compilation*,
> >> IRScope*)+0x440
> >> V  [libjvm.so+0x410a72]  IRScope::IRScope(Compilation*, IRScope*, int,
> >> ciMethod*, int, bool)+0x1d2
> >> V  [libjvm.so+0x4116b6]  IR::IR(Compilation*, ciMethod*, int)+0xa6
> >> V  [libjvm.so+0x3f1586]  Compilation::build_hir() [clone .part.95]+0x166
> >> V  [libjvm.so+0x3f1dd3]  Compilation::compile_java_method()+0x3a3
> >> V  [libjvm.so+0x3f1f6f]  Compilation::compile_method()+0x12f
> >> V  [libjvm.so+0x3f23cc]  Compilation::Compilation(AbstractCompiler*,
> >> ciEnv*, ciMethod*, int, BufferBlob*, DirectiveSet*)+0x22c
> >> V  [libjvm.so+0x3f2cae]  Compiler::compile_method(ciEnv*, ciMethod*,
> >> int,
> >> DirectiveSet*)+0xae
> >> V  [libjvm.so+0x5720cc]
> >>   CompileBroker::invoke_compiler_on_method(CompileTask*)+0xeec
> >> V  [libjvm.so+0x572eb8]  CompileBroker::compiler_thread_loop()+0x5b8
> >> V  [libjvm.so+0xe50f8a]  JavaThread::thread_main_inner()+0x1da
> >> V  [libjvm.so+0xe55baf]  Thread::call_run()+0xff
> >> V  [libjvm.so+0xbc77e7]  thread_native_entry(Thread*)+0xe7
> >>
>
>

From redestad at openjdk.java.net  Wed Jan 27 12:50:46 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 27 Jan 2021 12:50:46 GMT
Subject: RFR: 8256368: Avoid repeated upcalls into Java to re-resolve
 MH/VH linkers/invokers
In-Reply-To: <zH3ZulR1jnw9irhlguFfnp3syF06R15RY1Y5fjuGLCQ=.a20df501-c0cb-42e2-a0f2-815340c70f96@github.com>
References: <QQXG49x-8brTFEmUPZGm6jZ_ZrUCOGxtW5yrdnoziBo=.c932a6bd-8f92-4e8d-8cb4-9cc996ba9548@github.com>
 <zH3ZulR1jnw9irhlguFfnp3syF06R15RY1Y5fjuGLCQ=.a20df501-c0cb-42e2-a0f2-815340c70f96@github.com>
Message-ID: <ZT48equY0GCvWefLjMiQCQs5WT0gSgUh2D2638rIisA=.1471917a-23f5-44f8-9434-9e8328c673c8@github.com>

On Fri, 27 Nov 2020 19:02:04 GMT, Coleen Phillimore <coleenp at openjdk.org> 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
>
> src/hotspot/share/interpreter/linkResolver.cpp line 1705:
> 
>> 1703:   int cache_index = ConstantPool::decode_cpcache_index(index, true);
>> 1704:   ConstantPoolCacheEntry* cpce = pool->cache()->entry_at(cache_index);
>> 1705:   if (!cpce->is_f1_null()) {
> 
> If f1 is non-null any racing resolution is complete.  Can you double check if that's also the case for indy_resolution_failed?

My reading is that a non-null f1 means any resolution races is complete and writes to indy_resolution_failed (part of flags) is done before writing f1, see comments in and logic in  [ConstantPoolCacheEntry::set_method_handle_common](https://github.com/openjdk/jdk/blob/7ed591cc9a1c46f7c0b10a4c4ad3c181333bf5b6/src/hotspot/share/oops/cpCache.cpp#L364). It thus seem consistent and correct to resolve successfully here, no?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1453

From rcastanedalo at openjdk.java.net  Wed Jan 27 14:25:42 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 27 Jan 2021 14:25:42 GMT
Subject: RFR: 8258894: C2: Forbid GCM to move stores into loops [v2]
In-Reply-To: <26d7dmCCsh-MgY9rygK3_Fltr3bHqDEtxAVw1g41rW0=.6a0aa55a-2408-491a-b63a-722541ae6bd9@github.com>
References: <VMq5l7qqmyryiukK2Ug23hAxDyQTbACrZpV06SbGzPE=.d9198af8-dec4-4b81-b483-ccc6937733f8@github.com>
 <QZR3Mai4qMA-6Sq3IRcl3yB0NrpWHtitL-LKj-ggSMY=.a798cbd5-dba8-4a31-b1df-33916b3b5117@github.com>
 <9kFOeiXVarMDbTUHQ3QXzQeUYefEVpTEFByWVqZ-lvE=.c9b05066-6bac-4822-bebc-dc59c8c7ec04@github.com>
 <26d7dmCCsh-MgY9rygK3_Fltr3bHqDEtxAVw1g41rW0=.6a0aa55a-2408-491a-b63a-722541ae6bd9@github.com>
Message-ID: <fyxODYevFMQLbvfLRD7BKeyB9Bpp_-YKeDglIngxfYY=.e91cc4d1-1dfc-44de-9ddf-5d62f8348352@github.com>

On Wed, 27 Jan 2021 08:06:03 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Marked as reviewed by thartmann (Reviewer).
>
> Thanks for reviewing, Tobias and Vladimir!

Please sponsor.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2140

From rcastanedalo at openjdk.java.net  Wed Jan 27 15:11:42 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 27 Jan 2021 15:11:42 GMT
Subject: Integrated: 8258894: C2: Forbid GCM to move stores into loops
In-Reply-To: <VMq5l7qqmyryiukK2Ug23hAxDyQTbACrZpV06SbGzPE=.d9198af8-dec4-4b81-b483-ccc6937733f8@github.com>
References: <VMq5l7qqmyryiukK2Ug23hAxDyQTbACrZpV06SbGzPE=.d9198af8-dec4-4b81-b483-ccc6937733f8@github.com>
Message-ID: <_KZv_a4QnqGzSLgS3goxOslffNsOr0hxJ_EvUpsjQCA=.9908d131-a84e-40e7-b57c-9bc8757dfc2d@github.com>

On Tue, 19 Jan 2021 08:32:42 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> 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).

This pull request has now been integrated.

Changeset: f353fcf2
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f353fcf2
Stats:     238 lines in 7 files changed: 192 ins; 5 del; 41 mod

8258894: C2: Forbid GCM to move stores into 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.

Reviewed-by: thartmann, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/2140

From lucy at openjdk.java.net  Wed Jan 27 16:18:41 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Wed, 27 Jan 2021 16:18:41 GMT
Subject: RFR: 8260502: [s390] NativeMovRegMem::verify() fails because it's
 too strict
In-Reply-To: <B-kpkKfkuSOmBHpe6qjjZ_xowa1MHzqzK2zuWDIus0c=.b550a29c-7a78-402c-adbb-d071dbadf6d6@github.com>
References: <B-kpkKfkuSOmBHpe6qjjZ_xowa1MHzqzK2zuWDIus0c=.b550a29c-7a78-402c-adbb-d071dbadf6d6@github.com>
Message-ID: <mFmb58ijIdpKhnEHnkrEYQJwpzHE_lnyXDw__BmiQsk=.caba9056-ab2f-4728-8365-87b7bbf926f6@github.com>

On Wed, 27 Jan 2021 12:13:27 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> "fatal error: this is not a `NativeMovRegMem' site" was observed while testing the debug build without CompressedOops.
> NativeMovRegMem::verify() tries to verify instructions beyond the load_const at a place at which we don't have valid instructions. See bug for details.
> I suggest to remove the wrong part of the verification.

Looks good to me.
Thanks for finding and fixing.

-------------

Marked as reviewed by lucy (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2258

From iveresov at openjdk.java.net  Wed Jan 27 16:46:47 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Wed, 27 Jan 2021 16:46:47 GMT
Subject: RFR: 8251462: Remove legacy compilation policy [v5]
In-Reply-To: <IliBxirjkus6BbQX4Fu4SjKre08650J8Ro6PYaH4Gj8=.d28798dc-bed3-422f-a21f-3746a1f173e2@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <j6u8qjorR4y5p5sbClq6u_0aIL0ws8fKrx2QkZSPAE0=.bf1ed84c-ef3c-4223-886c-2d281ae32784@github.com>
 <Qu3sFmKcKyyY6bWJ-hcUKa9cfx_tNv5I2d1YO8pC98Q=.c672461f-2b2d-4362-a870-a861910f2b72@github.com>
 <IliBxirjkus6BbQX4Fu4SjKre08650J8Ro6PYaH4Gj8=.d28798dc-bed3-422f-a21f-3746a1f173e2@github.com>
Message-ID: <YDACkCpp7KInVe_5lU-KgujJHS-v-2fMcYeM4Wdnf0Y=.c7528306-a96d-4109-8b3f-5a54a6b609fc@github.com>

On Mon, 25 Jan 2021 18:13:20 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Looks better now. I would like to see result of performance testing before approving.
>
> I asked Eric to run the benchmarks. The results should be ready on Wednesday.

The benchmarking is done. No regressions. There are mild improvements in startup benchmarks on the order of 1-5% (I suspect because of the compilation policy devirtualization).

@dholmes-ora, do still plan to look at this? It's been a few weeks, I'd like to push this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1985

From shade at openjdk.java.net  Wed Jan 27 17:02:50 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 27 Jan 2021 17:02:50 GMT
Subject: RFR: 8251462: Remove legacy compilation policy [v5]
In-Reply-To: <YDACkCpp7KInVe_5lU-KgujJHS-v-2fMcYeM4Wdnf0Y=.c7528306-a96d-4109-8b3f-5a54a6b609fc@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <j6u8qjorR4y5p5sbClq6u_0aIL0ws8fKrx2QkZSPAE0=.bf1ed84c-ef3c-4223-886c-2d281ae32784@github.com>
 <Qu3sFmKcKyyY6bWJ-hcUKa9cfx_tNv5I2d1YO8pC98Q=.c672461f-2b2d-4362-a870-a861910f2b72@github.com>
 <IliBxirjkus6BbQX4Fu4SjKre08650J8Ro6PYaH4Gj8=.d28798dc-bed3-422f-a21f-3746a1f173e2@github.com>
 <YDACkCpp7KInVe_5lU-KgujJHS-v-2fMcYeM4Wdnf0Y=.c7528306-a96d-4109-8b3f-5a54a6b609fc@github.com>
Message-ID: <ZmRD1xo8T58X8pZ1wuvKvJyi4wswk9rE8ygfuFfmAUo=.10ac70bf-00f9-49e6-b188-4a6e8748ef31@github.com>

On Wed, 27 Jan 2021 16:43:28 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> I asked Eric to run the benchmarks. The results should be ready on Wednesday.
>
> The benchmarking is done. No regressions. There are mild improvements in startup benchmarks on the order of 1-5% (I suspect because of the compilation policy devirtualization).
> 
> @dholmes-ora, do still plan to look at this? It's been a few weeks, I'd like to push this.

Please update from current master to get x86_32 built and tested in GH Actions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1985

From kvn at openjdk.java.net  Wed Jan 27 17:09:48 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 27 Jan 2021 17:09:48 GMT
Subject: RFR: 8251462: Remove legacy compilation policy [v5]
In-Reply-To: <j6u8qjorR4y5p5sbClq6u_0aIL0ws8fKrx2QkZSPAE0=.bf1ed84c-ef3c-4223-886c-2d281ae32784@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <j6u8qjorR4y5p5sbClq6u_0aIL0ws8fKrx2QkZSPAE0=.bf1ed84c-ef3c-4223-886c-2d281ae32784@github.com>
Message-ID: <kSQEjXshwl36vMc0GuNrhpdJ8ihxNnU2pdKx05WNQqM=.e9aa1b1e-2efb-45e6-9e3a-288a3e8ad80a@github.com>

On Sun, 24 Jan 2021 03:53:00 GMT, Igor Veresov <iveresov at openjdk.org> 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:
> 
>   Address Vladimir's review comments

I approve it based on performance results.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1985

From github.com+51754783+coreyashford at openjdk.java.net  Wed Jan 27 17:21:42 2021
From: github.com+51754783+coreyashford at openjdk.java.net (Corey Ashford)
Date: Wed, 27 Jan 2021 17:21:42 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10 [v2]
In-Reply-To: <WkG8POXO8k_j81QNw3YnpQoFphd19RjEbLEv70L7ipw=.17a355a7-1e46-4bbc-ad0c-8b0d9d8a6a55@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <AtBNdURD637gt2Uq0UtN6SGzcslSsWs7ZLC4TrOTXPQ=.65482e3d-1db6-4772-bfd2-771ec0fbbdf6@github.com>
 <WkG8POXO8k_j81QNw3YnpQoFphd19RjEbLEv70L7ipw=.17a355a7-1e46-4bbc-ad0c-8b0d9d8a6a55@github.com>
Message-ID: <PpInreZkFNbfTwB16sPiWZWKVvKMSziItU7ZEHNIh7A=.dea74217-bd1e-46da-94c9-443971aaf169@github.com>

On Tue, 26 Jan 2021 18:55:13 GMT, Kazunori Ogata <ogatak at openjdk.org> wrote:

>> 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.
>
> I'll leave it since other comments that refer to a specific ISA implementation use Power X. (I changed POWER10 to Power 10, though.)

ok, sounds good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2095

From iveresov at openjdk.java.net  Wed Jan 27 17:25:58 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Wed, 27 Jan 2021 17:25:58 GMT
Subject: RFR: 8251462: Remove legacy compilation policy [v6]
In-Reply-To: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
Message-ID: <B1_fjlXpnfPV5j95-BnObHNV4RG984ixhfrryVkumMI=.f578de2c-4dd0-4786-a60a-ee9386f3b2af@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 with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Address Vladimir's review comments
 - Check legacy flags validity before deriving flag values for emulation mode.
 - Fix another s390 compilation failure
 - Fix s390 build
 - 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=05
  Stats: 5318 lines in 98 files changed: 1519 ins; 2994 del; 805 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 github.com+51754783+coreyashford at openjdk.java.net  Wed Jan 27 17:26:46 2021
From: github.com+51754783+coreyashford at openjdk.java.net (Corey Ashford)
Date: Wed, 27 Jan 2021 17:26:46 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10 [v2]
In-Reply-To: <sSDP07j2elqVDT0qGYi5ZHF0L1fZ6pQu43ozzP_TdE8=.d5f3030a-c8cc-4097-822f-99f71012eb58@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <AtBNdURD637gt2Uq0UtN6SGzcslSsWs7ZLC4TrOTXPQ=.65482e3d-1db6-4772-bfd2-771ec0fbbdf6@github.com>
 <sSDP07j2elqVDT0qGYi5ZHF0L1fZ6pQu43ozzP_TdE8=.d5f3030a-c8cc-4097-822f-99f71012eb58@github.com>
Message-ID: <QwZJ8uu8nQeCIxfKQAGzNlafEVnZSE1yfw08csZNHUI=.e13726aa-50b8-4f9d-90a5-26f5fdd34910@github.com>

On Tue, 26 Jan 2021 19:18:18 GMT, Kazunori Ogata <ogatak at openjdk.org> wrote:

>> 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.
>
> It is just intended to show a usage of the second argument of is_paddi(const int* p, bool is_pli = false).  Is it unnecessary, i.e., self-evident?

In past open source projects I have worked on, functions that essentially are unreachable in the final product cannot be tested, so there's no way to know if they work as intended. For that reason, only code that is used and/or can be tested in the final product (e.g. via an externally-visible API) would be accepted in a commit.

I don't know if the OpenJDK project follows that rule or not.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2095

From kvn at openjdk.java.net  Wed Jan 27 17:26:50 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 27 Jan 2021 17:26:50 GMT
Subject: [jdk16] RFR: 8260339: JVM crashes when executing
 PhaseIdealLoop::match_fill_loop
In-Reply-To: <XAlign_bkEddFEWaiaUrVGkAK_IF1o3vJnnvj2Z6FPw=.6dc069e7-2040-4a58-b4dd-7b5aa0cb1cc3@github.com>
References: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
 <TvxNATFV9R2HAfAOcAdSiJMT65-L7bycFBeb8CBHXpw=.37cbeab0-cbb1-4bd2-a888-e21cffce2bdf@github.com>
 <dJFSuD_5vLPii8B4RweesvD5eFzICui_FO8a1u37CM0=.58ce0cb2-73a9-4682-ac91-2bbf98472bc1@github.com>
 <XAlign_bkEddFEWaiaUrVGkAK_IF1o3vJnnvj2Z6FPw=.6dc069e7-2040-4a58-b4dd-7b5aa0cb1cc3@github.com>
Message-ID: <pMScn8tESFf_TrJxrgPhmxEJaWIk0SGR_tus3f1NSrU=.77f92464-35c8-4a5c-a550-c59cd0c08a53@github.com>

On Wed, 27 Jan 2021 11:10:59 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>>> @Wanghuang-Huawei Have you been able to reproduce this on any other platform that linux-aarch64? I'm having trouble reproducing this on x64.
>> 
>> I think x64 has disabled OptimizeFill by default. I can reproduce this with -XX:+OptimizeFill.
>
> Please add  -XX:+OptimizeFill to the regression test

Yes, OptimizeFill  is off after 8247307 changes in JDK 16. Add it to @run command (it is C2 flag so you need `Ignore*` flag):
* @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -XX:+OptimizeFill

-------------

PR: https://git.openjdk.java.net/jdk16/pull/132

From github.com+51754783+coreyashford at openjdk.java.net  Wed Jan 27 17:50:42 2021
From: github.com+51754783+coreyashford at openjdk.java.net (Corey Ashford)
Date: Wed, 27 Jan 2021 17:50:42 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10 [v2]
In-Reply-To: <_eP7uCnY-ZlzK3aCMJNWEQ0m9UP3pGkCR-L0ReZIrdo=.8f369ddf-0b68-4cc5-98d1-4e474bf7ae6c@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <AtBNdURD637gt2Uq0UtN6SGzcslSsWs7ZLC4TrOTXPQ=.65482e3d-1db6-4772-bfd2-771ec0fbbdf6@github.com>
 <_eP7uCnY-ZlzK3aCMJNWEQ0m9UP3pGkCR-L0ReZIrdo=.8f369ddf-0b68-4cc5-98d1-4e474bf7ae6c@github.com>
Message-ID: <nh8KRw9bTrlpfQHNg5KZRIEAEaXAo3RZcd26NTMYGq4=.07a6884e-b850-4c72-9b6d-21bd37a5052c@github.com>

On Tue, 26 Jan 2021 19:14:45 GMT, Kazunori Ogata <ogatak at openjdk.org> wrote:

>> 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.
>
> If predicate is added, adlc fails with an error message: "Syntax Error: :ADLC does not support instruction chain rules with predicates"  I think addL_reg_imm34 allows predicate because it is not called from other rules.  Is it better to leave some comments?  (BTW, immI32 is only for POWER10 or higher.  POWER9 version uses immI16 or immI16hi.)

Hmm, I'm confused.  I don't see any other reference to loadConL34 in ppc.ad.

>> 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.
>
> Same reason as the next comment (paddi_or_addi), but necessity of this one may be weaker.

Ok.  See my other comments about unused/untestable code.

>> 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.
>
> It is intended to show an example of an efficient set of macros/functions for a prefixed instruction. Since a non-prefixed (32-bit) instruction is more efficient if the argument fits within the operand fields because of smaller I-cache usage and no need for the padding nop, it is convenient to have a macro/function that select better format. I intended to show an example of recommended set of useful macros/functions when adding support for a prefixed instruction. I'm planning to use this function in my next patch. Is it better to move this to the next patch?

It would be my preference to post code up only when it's actually used.  When you get around to using it, there's a possibility you will want to modify it a bit, add a comment, etc.   So that can be done all in one commit, instead of split across two.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2095

From github.com+51754783+coreyashford at openjdk.java.net  Wed Jan 27 17:53:42 2021
From: github.com+51754783+coreyashford at openjdk.java.net (Corey Ashford)
Date: Wed, 27 Jan 2021 17:53:42 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10 [v2]
In-Reply-To: <cLMlamzeU3HzSZVUMSgz0AkOIryBxRfUChh-WxX-g6M=.9358d16c-1645-4cca-8ac6-fe860cee0eba@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <AtBNdURD637gt2Uq0UtN6SGzcslSsWs7ZLC4TrOTXPQ=.65482e3d-1db6-4772-bfd2-771ec0fbbdf6@github.com>
 <cLMlamzeU3HzSZVUMSgz0AkOIryBxRfUChh-WxX-g6M=.9358d16c-1645-4cca-8ac6-fe860cee0eba@github.com>
Message-ID: <MzaJSTGiqCkZINAqOWRnig7-kUCmxBLGNU_CjvqTiBY=.60911a12-97ef-4068-81e8-c7ec83d21a06@github.com>

On Tue, 26 Jan 2021 19:07:40 GMT, Kazunori Ogata <ogatak at openjdk.org> wrote:

>> src/hotspot/cpu/ppc/assembler_ppc.hpp line 1533:
>> 
>>> 1531:      int32_t* p_inst = (int32_t*)p;
>>> 1532: 
>>> 1533:      if (is_aligned(reinterpret_cast<uintptr_t>(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)?
>
> "is_<instr>()" are the functions for testing instructions in the generated code and they are usually called in "assert()" or complex combination of if statements.  So if this function returns false when p points at nop, the assertions or the if-conditions need to handle the nop case and the code will become difficult to read.  Since the padding nop is a non-common case, I'd like to hide the existence of nop in this function.

Ok, got it.  Thanks for the explanation.  Maybe an extra comment in the code saying essentially what you said here would be appropriate?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2095

From jwilhelm at openjdk.java.net  Wed Jan 27 20:59:44 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 27 Jan 2021 20:59:44 GMT
Subject: Integrated: Merge jdk16
In-Reply-To: <GSPUA2N53fMF_fUDUasyeFNuatRGdQAbWQy9a8ekHg0=.1430a351-c678-4e2f-9539-a5e07d8f27f4@github.com>
References: <GSPUA2N53fMF_fUDUasyeFNuatRGdQAbWQy9a8ekHg0=.1430a351-c678-4e2f-9539-a5e07d8f27f4@github.com>
Message-ID: <DtX91AXFVR38DjfnFjg7gml-ltFDGSn89kLGKLBEC8I=.c3a41293-02b7-46db-9b3f-8167f8b7d214@github.com>

On Wed, 27 Jan 2021 01:13:51 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: c52212b1
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c52212b1
Stats:     114 lines in 4 files changed: 107 ins; 3 del; 4 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/2248

From kvn at openjdk.java.net  Wed Jan 27 21:13:00 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 27 Jan 2021 21:13:00 GMT
Subject: [jdk16] RFR: 8253353: Crash in C2: guarantee(n != NULL) failed: No
 Node
Message-ID: <gvNpYhQInkonT7X4UvX8_vivCQj_zJqRXOiQEIWw7oE=.6c4b5369-f999-4c7a-a525-e65301d940f5@github.com>

Nesting loops for this case reaches 400+. But the type of IdeaLoopTree::_nest field is uint8 (the maximum value allowed is 255). The test passed with the following fix proposed by @RealFYang:

- uint8_t _nest; // Nesting depth 
+ uint16_t _nest; // Nesting depth

New regression test is added.
Passed hs-tier1 - 3 testing.

-------------

Commit messages:
 - 8253353: Crash in C2: guarantee(n != NULL) failed: No Node

Changes: https://git.openjdk.java.net/jdk16/pull/135/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=135&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253353
  Stats: 1987 lines in 4 files changed: 1986 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/135/head:pull/135

PR: https://git.openjdk.java.net/jdk16/pull/135

From vlivanov at openjdk.java.net  Wed Jan 27 21:17:42 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 27 Jan 2021 21:17:42 GMT
Subject: [jdk16] RFR: 8253353: Crash in C2: guarantee(n != NULL) failed:
 No Node
In-Reply-To: <gvNpYhQInkonT7X4UvX8_vivCQj_zJqRXOiQEIWw7oE=.6c4b5369-f999-4c7a-a525-e65301d940f5@github.com>
References: <gvNpYhQInkonT7X4UvX8_vivCQj_zJqRXOiQEIWw7oE=.6c4b5369-f999-4c7a-a525-e65301d940f5@github.com>
Message-ID: <VXsTch41DUANQY4LRcORqeKoK46-WJkUIheZeFuMfS0=.115c7eaa-69e6-481d-9c9c-f01ccadd718c@github.com>

On Wed, 27 Jan 2021 21:03:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Nesting loops for this case reaches 400+. But the type of IdeaLoopTree::_nest field is uint8 (the maximum value allowed is 255). The test passed with the following fix proposed by @RealFYang:
> 
> - uint8_t _nest; // Nesting depth 
> + uint16_t _nest; // Nesting depth
> 
> New regression test is added.
> Passed hs-tier1 - 3 testing.

Looks good.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/135

From vlivanov at openjdk.java.net  Wed Jan 27 21:45:39 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 27 Jan 2021 21:45:39 GMT
Subject: RFR: 8260501: [Vector API] Improve register usage for shift
 operations on x86
In-Reply-To: <eiKG7lnaASe7574tjTNKvcokiwA1mkp_c8rD6VK2iPI=.12a4a3c1-970f-4ce2-9d6c-1a0057a2f207@github.com>
References: <eiKG7lnaASe7574tjTNKvcokiwA1mkp_c8rD6VK2iPI=.12a4a3c1-970f-4ce2-9d6c-1a0057a2f207@github.com>
Message-ID: <gh80Y779wLM-B1tEPn_dSg0HLeWcWUhNxANmjKKEuL4=.a8a5fbdc-5a9f-4e58-bb13-7423e7d88850@github.com>

On Wed, 27 Jan 2021 11:52:54 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> I found the register usage is less optimized for some shift operations.
> For example, vshiftL_imm [1]/vshiftI_imm require dst != src.
> But it's actually fine for the register allocator to assign dst == src.
> 
> Also, vshiftL [2]/vshiftI/vshiftS require dst != src.
> But it's actually required for UseAVX==0 only.
> For the most common cases (UseAVX > 0), it's fine to assign dst == src.
> 
> The fix splits vshiftS/vshiftI/vshiftL into UseAVX > 0 and UseAVX == 0 cases.
> And just removes the unreasonable requirement for vshiftI_imm and vshiftL_imm. 
> 
> Testing:
>   - jdk/incubator/vector/ on x64 with UseAVX=3/2/1/0, no regression
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L6058
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L6037

IIRC AD instructions for variable shifts were deliberately merged to reduce static footprint of the JVM on x86 (JVM library size). IMO it's preferable to leave them as they are.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2257

From neliasso at openjdk.java.net  Wed Jan 27 22:02:40 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 27 Jan 2021 22:02:40 GMT
Subject: [jdk16] RFR: 8253353: Crash in C2: guarantee(n != NULL) failed:
 No Node
In-Reply-To: <gvNpYhQInkonT7X4UvX8_vivCQj_zJqRXOiQEIWw7oE=.6c4b5369-f999-4c7a-a525-e65301d940f5@github.com>
References: <gvNpYhQInkonT7X4UvX8_vivCQj_zJqRXOiQEIWw7oE=.6c4b5369-f999-4c7a-a525-e65301d940f5@github.com>
Message-ID: <HEtY99TEo769cAcVvpAsOd0SA3Swdv3C6KS4cDsBYaE=.8f5ba55f-7ae3-443a-92d7-0a4e32179084@github.com>

On Wed, 27 Jan 2021 21:03:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Nesting loops for this case reaches 400+. But the type of IdeaLoopTree::_nest field is uint8 (the maximum value allowed is 255). The test passed with the following fix proposed by @RealFYang:
> 
> - uint8_t _nest; // Nesting depth 
> + uint16_t _nest; // Nesting depth
> 
> I think increase size to `unsigned short` (16 bits) is enough for this value. We will bailout C2 compilation due to big IR graph (MaxNodeLimit = 80000) before we can construct MAX_USHORT (65535)  nested loops. And I added asserts to catch such case if it happens.
> 
> New regression test is added.
> Passed hs-tier1 - 3 testing.

Looks good.

-------------

Marked as reviewed by neliasso (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/135

From kvn at openjdk.java.net  Wed Jan 27 23:29:41 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 27 Jan 2021 23:29:41 GMT
Subject: RFR: 8260407: cmp != __null && cmp->Opcode() == Op_CmpL failure
 with -XX:StressLongCountedLoop=200000000 in lucene
In-Reply-To: <Ud0obOyQpdKh2yyyWnQJVNQMiJu2qgTW3RE9G8bR8lI=.f839f2db-0778-4ccf-b607-7ded9d655655@github.com>
References: <Ud0obOyQpdKh2yyyWnQJVNQMiJu2qgTW3RE9G8bR8lI=.f839f2db-0778-4ccf-b607-7ded9d655655@github.com>
Message-ID: <63YqhotF6CyDKIeSBa5GXZCQFbwPBfObM0bvO6iUfXk=.5e349494-7933-47bf-ac4f-72c50af16c46@github.com>

On Tue, 26 Jan 2021 15:14:27 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Long counted loops are transformed in 3 steps:
> 
> 1- LongCountedLoopNode/LongCountedLoopEndNode are created (similar to
> int counted loops)
> 
> 2- a loop nest is built from the
> LongCountedLoopNode/LongCountedLoopEndNode with an inner loop with a
> int iv
> 
> 3- the inner loop is transformed to a CountedLoop
> 
> Between 1- and 2-, the LongCountedLoopEndNode is transformed by split
> if because a dominated if uses the same condition. Fix simplys applies
> existing check for CountedLoopEndNode to LongCountedLoopEndNode.

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2240

From github.com+25214855+casparcwang at openjdk.java.net  Thu Jan 28 00:51:49 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Thu, 28 Jan 2021 00:51:49 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled
Message-ID: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>

https://bugs.openjdk.java.net/browse/JDK-8260473

Function "PhaseVector::expand_vunbox_node" creates a LoadNode, but forgets to make the LoadNode to pass gc barriers.


Testing: all Vector API related tests have passed.

-------------

Commit messages:
 - 8260473: [vector] ZGC: VectorReshape test produces incorrect results with ZGC enabled

Changes: https://git.openjdk.java.net/jdk/pull/2253/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2253&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260473
  Stats: 12 lines in 1 file changed: 3 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2253.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2253/head:pull/2253

PR: https://git.openjdk.java.net/jdk/pull/2253

From whuang at openjdk.java.net  Thu Jan 28 01:34:12 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Thu, 28 Jan 2021 01:34:12 GMT
Subject: [jdk16] RFR: 8260339: JVM crashes when executing
 PhaseIdealLoop::match_fill_loop [v7]
In-Reply-To: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
References: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
Message-ID: <9vpuiDLlNDANMFx3E5bOfyjPsKMQD4yRmV7WcE6JVTI=.acf2c8e9-45a5-4096-a83c-92d7ff856aa5@github.com>

> The reason is :
> 
>   BasicType t = store->as_Mem()->memory_type();
>   const char* fill_name;
>   if (msg == NULL &&
>       StubRoutines::select_fill_function(t, false, fill_name) == NULL) {
>     msg = "unsupported store";
>     msg_node = store;
>   }
> 
> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here.
> 
> I add a new case here to avoid mistake:
>   case T_NARROWOOP:
>   case T_NARROWKLASS:
>   case T_ADDRESS:
> +  case T_VOID:
>     // Currently unsupported
>     return NULL;

Wang Huang has updated the pull request incrementally with one additional commit since the last revision:

  add -XX:+OptimizeFill

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/132/files
  - new: https://git.openjdk.java.net/jdk16/pull/132/files/b9f1a249..cf54002d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/132.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/132/head:pull/132

PR: https://git.openjdk.java.net/jdk16/pull/132

From dongbo at openjdk.java.net  Thu Jan 28 01:41:48 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Thu, 28 Jan 2021 01:41:48 GMT
Subject: RFR: 8258953: AArch64: move NEON instructions to aarch64_neon.ad
Message-ID: <XGTLq2Pqnu1FU70iDyaAaSQkEYH4rtKbj_wqJHRWv7s=.dbfd57ad-5d5d-4b90-b5fb-e3da2acc5df6@github.com>

As discussed in [1], all NEON instructions should be moved from `aarch64.ad` to `aarch64_neon.ad`.

In the first commit [2] of this PR, the NEON instructions are deleted from `aarch64.ad` and appended to `aarch64_neon.ad`.
I compared the generated code in `aarch64_neon.ad` with original code in `aarch64.ad`, no suspicious differences found.
The last two commits just simply move code around in `aarch64_neon.ad` to put related instructions together, i.e. `LoadStore` [3], `Reduction` [4].

This also supports vector length 4 for `vsraa8B_imm` and `vsrla8B_imm`, vector length 2 for `vsraa4S_imm` and `vsrla4S_imm`, fixes few typos, e.g. `vor8B`, `vsrla4S_imm`.

[1] https://github.com/openjdk/jdk/pull/1215#issuecomment-728186803
[2] https://github.com/dgbo/jdk/commit/40cbe99e647cdf93712edf8f77ab3b5b30ea0a95
[3] https://github.com/dgbo/jdk/commit/695fb8f8ef009b733a8f804e791347f4bfe2572e
[4] https://github.com/dgbo/jdk/commit/e0c38aa9aaa6af9925a3821328384b1e2b2c2070

-------------

Commit messages:
 - put all VReduction together
 - put all VLoadStore together
 - 8258953: AArch64: move NEON instructions to aarch64_neon.ad

Changes: https://git.openjdk.java.net/jdk/pull/2273/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2273&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258953
  Stats: 5703 lines in 3 files changed: 3241 ins; 2442 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2273.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2273/head:pull/2273

PR: https://git.openjdk.java.net/jdk/pull/2273

From github.com+10482586+therealeliu at openjdk.java.net  Thu Jan 28 01:50:39 2021
From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu)
Date: Thu, 28 Jan 2021 01:50:39 GMT
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value
In-Reply-To: <8bFPyc33jjtDCZ3teQf14B6SmFJ1ifdD3DGp2ClHIk4=.4b861d50-8333-4fe9-b9d7-d28599e91831@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <8bFPyc33jjtDCZ3teQf14B6SmFJ1ifdD3DGp2ClHIk4=.4b861d50-8333-4fe9-b9d7-d28599e91831@github.com>
Message-ID: <61lv2ty2HbKLSeNr7AXPM_ShDHfUf9ScdLQZDxh-tF4=.d1155fc9-e7fe-47ec-b84a-31764b33cc2e@github.com>

On Mon, 4 Jan 2021 01:58:38 GMT, Eric Liu <github.com+10482586+theRealELiu at openjdk.org> 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?

Ping

-------------

PR: https://git.openjdk.java.net/jdk/pull/1858

From kvn at openjdk.java.net  Thu Jan 28 01:59:47 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 28 Jan 2021 01:59:47 GMT
Subject: [jdk16] RFR: 8260339: JVM crashes when executing
 PhaseIdealLoop::match_fill_loop [v7]
In-Reply-To: <9vpuiDLlNDANMFx3E5bOfyjPsKMQD4yRmV7WcE6JVTI=.acf2c8e9-45a5-4096-a83c-92d7ff856aa5@github.com>
References: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
 <9vpuiDLlNDANMFx3E5bOfyjPsKMQD4yRmV7WcE6JVTI=.acf2c8e9-45a5-4096-a83c-92d7ff856aa5@github.com>
Message-ID: <AkcdEtGkLd05nXA4-pM0LNiyNd8Ne-cNN0-qYUiGukY=.a3a6787c-4358-4d46-ab13-56bf2aa2159f@github.com>

On Thu, 28 Jan 2021 01:34:12 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> The reason is :
>> 
>>   BasicType t = store->as_Mem()->memory_type();
>>   const char* fill_name;
>>   if (msg == NULL &&
>>       StubRoutines::select_fill_function(t, false, fill_name) == NULL) {
>>     msg = "unsupported store";
>>     msg_node = store;
>>   }
>> 
>> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here.
>> 
>> I add a new case here to avoid mistake:
>>   case T_NARROWOOP:
>>   case T_NARROWKLASS:
>>   case T_ADDRESS:
>> +  case T_VOID:
>>     // Currently unsupported
>>     return NULL;
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add -XX:+OptimizeFill

test/hotspot/jtreg/compiler/vectorapi/TestLoopStoreVector.java line 35:

> 33:  * @modules jdk.incubator.vector
> 34:  *
> 35:  * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -XX:+OptimizeFill

You forgot test name

-------------

PR: https://git.openjdk.java.net/jdk16/pull/132

From azeemj at openjdk.java.net  Thu Jan 28 02:01:39 2021
From: azeemj at openjdk.java.net (Azeem Jiva)
Date: Thu, 28 Jan 2021 02:01:39 GMT
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value
In-Reply-To: <61lv2ty2HbKLSeNr7AXPM_ShDHfUf9ScdLQZDxh-tF4=.d1155fc9-e7fe-47ec-b84a-31764b33cc2e@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <8bFPyc33jjtDCZ3teQf14B6SmFJ1ifdD3DGp2ClHIk4=.4b861d50-8333-4fe9-b9d7-d28599e91831@github.com>
 <61lv2ty2HbKLSeNr7AXPM_ShDHfUf9ScdLQZDxh-tF4=.d1155fc9-e7fe-47ec-b84a-31764b33cc2e@github.com>
Message-ID: <6NOQ2e_ISepbYq22u1EUy7F5OIVArfQUugnlPjBW7HY=.b0b934ee-bf7b-4ef2-8887-d369251582e6@github.com>

On Thu, 28 Jan 2021 01:47:32 GMT, Eric Liu <github.com+10482586+theRealELiu at openjdk.org> wrote:

>> Could anyone help to take a look at this PR?
>
> Ping

What impact does this have on runtime?  There are also Tier1 failures in x86, which you'll need to investigate

-------------

PR: https://git.openjdk.java.net/jdk/pull/1858

From jiefu at openjdk.java.net  Thu Jan 28 02:09:58 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 28 Jan 2021 02:09:58 GMT
Subject: RFR: 8260501: [Vector API] Improve register usage for shift
 operations on x86 [v2]
In-Reply-To: <eiKG7lnaASe7574tjTNKvcokiwA1mkp_c8rD6VK2iPI=.12a4a3c1-970f-4ce2-9d6c-1a0057a2f207@github.com>
References: <eiKG7lnaASe7574tjTNKvcokiwA1mkp_c8rD6VK2iPI=.12a4a3c1-970f-4ce2-9d6c-1a0057a2f207@github.com>
Message-ID: <KlokyrB2xpITspayhUgkmckPj8cB1M-jpkWfv1PSuAo=.ef99265d-0dc4-4dbe-b037-79dcaad77307@github.com>

> Hi all,
> 
> I found the register usage is less optimized for some shift operations.
> For example, vshiftL_imm [1]/vshiftI_imm require dst != src.
> But it's actually fine for the register allocator to assign dst == src.
> 
> Also, vshiftL [2]/vshiftI/vshiftS require dst != src.
> But it's actually required for UseAVX==0 only.
> For the most common cases (UseAVX > 0), it's fine to assign dst == src.
> 
> The fix splits vshiftS/vshiftI/vshiftL into UseAVX > 0 and UseAVX == 0 cases.
> And just removes the unreasonable requirement for vshiftI_imm and vshiftL_imm. 
> 
> Testing:
>   - jdk/incubator/vector/ on x64 with UseAVX=3/2/1/0, no regression
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L6058
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L6037

Jie Fu has updated the pull request incrementally with two additional commits since the last revision:

 - Recuce the binary size
 - Revert changes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2257/files
  - new: https://git.openjdk.java.net/jdk/pull/2257/files/b528758e..fb207730

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2257&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2257&range=00-01

  Stats: 84 lines in 1 file changed: 20 ins; 46 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2257.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2257/head:pull/2257

PR: https://git.openjdk.java.net/jdk/pull/2257

From jiefu at openjdk.java.net  Thu Jan 28 02:14:39 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 28 Jan 2021 02:14:39 GMT
Subject: RFR: 8260501: [Vector API] Improve register usage for shift
 operations on x86
In-Reply-To: <gh80Y779wLM-B1tEPn_dSg0HLeWcWUhNxANmjKKEuL4=.a8a5fbdc-5a9f-4e58-bb13-7423e7d88850@github.com>
References: <eiKG7lnaASe7574tjTNKvcokiwA1mkp_c8rD6VK2iPI=.12a4a3c1-970f-4ce2-9d6c-1a0057a2f207@github.com>
 <gh80Y779wLM-B1tEPn_dSg0HLeWcWUhNxANmjKKEuL4=.a8a5fbdc-5a9f-4e58-bb13-7423e7d88850@github.com>
Message-ID: <A9xpsMoqqN9mSeuulPjPt_FUjPDIe7HZLsvRVIdOakw=.58fee2cc-07ec-4125-baef-872cd8e26b88@github.com>

On Wed, 27 Jan 2021 21:43:08 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> IIRC AD instructions for variable shifts were deliberately merged to reduce static footprint of the JVM on x86 (JVM library size). IMO it's preferable to leave them as they are.

Hi @iwanowww  ,

I didn't know that variable shifts were deliberately merged to reduce the size of libjvm.so.
Thanks for your clarification.

With the original patch, the size of libjvm.so on Linux/x64 will be increased by ~0.085%.

However, vshiftL_imm and vshiftI_imm can still be optimized without increasing the binary size.
And the size of libjvm.so will be further decreased by ~0.003% with the updated patch on Linux/x64.
So are you OK with it?

Thanks.
Best regards,
Jie

-------------

PR: https://git.openjdk.java.net/jdk/pull/2257

From github.com+10482586+therealeliu at openjdk.java.net  Thu Jan 28 02:20:41 2021
From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu)
Date: Thu, 28 Jan 2021 02:20:41 GMT
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value
In-Reply-To: <6NOQ2e_ISepbYq22u1EUy7F5OIVArfQUugnlPjBW7HY=.b0b934ee-bf7b-4ef2-8887-d369251582e6@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <8bFPyc33jjtDCZ3teQf14B6SmFJ1ifdD3DGp2ClHIk4=.4b861d50-8333-4fe9-b9d7-d28599e91831@github.com>
 <61lv2ty2HbKLSeNr7AXPM_ShDHfUf9ScdLQZDxh-tF4=.d1155fc9-e7fe-47ec-b84a-31764b33cc2e@github.com>
 <6NOQ2e_ISepbYq22u1EUy7F5OIVArfQUugnlPjBW7HY=.b0b934ee-bf7b-4ef2-8887-d369251582e6@github.com>
Message-ID: <Cba9nuZg_0pzKraAsDuOoC6Mo8LF1ljpGbXqxUVikDI=.ad71a55b-121a-4811-928a-28ebf1c6674d@github.com>

On Thu, 28 Jan 2021 01:58:33 GMT, Azeem Jiva <azeemj at openjdk.org> wrote:

>> Ping
>
> What impact does this have on runtime?  There are also Tier1 failures in x86, which you'll need to investigate

I suppose this failure was not caused by my patch, and it has been fixed by https://github.com/openjdk/jdk/commit/1594372c.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1858

From whuang at openjdk.java.net  Thu Jan 28 02:24:06 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Thu, 28 Jan 2021 02:24:06 GMT
Subject: [jdk16] RFR: 8260339: JVM crashes when executing
 PhaseIdealLoop::match_fill_loop [v8]
In-Reply-To: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
References: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
Message-ID: <Xo-s3cuHGgLKABu_zZQo5rmJu4eSP3yjbAJ29DgMSSA=.f8c3965c-daa0-477e-bbd5-5b80ab53fbac@github.com>

> The reason is :
> 
>   BasicType t = store->as_Mem()->memory_type();
>   const char* fill_name;
>   if (msg == NULL &&
>       StubRoutines::select_fill_function(t, false, fill_name) == NULL) {
>     msg = "unsupported store";
>     msg_node = store;
>   }
> 
> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here.
> 
> I add a new case here to avoid mistake:
>   case T_NARROWOOP:
>   case T_NARROWKLASS:
>   case T_ADDRESS:
> +  case T_VOID:
>     // Currently unsupported
>     return NULL;

Wang Huang has updated the pull request incrementally with one additional commit since the last revision:

  add missing summary and test name

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/132/files
  - new: https://git.openjdk.java.net/jdk16/pull/132/files/cf54002d..8e1c90d6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=06-07

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/132.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/132/head:pull/132

PR: https://git.openjdk.java.net/jdk16/pull/132

From kvn at openjdk.java.net  Thu Jan 28 02:41:42 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 28 Jan 2021 02:41:42 GMT
Subject: [jdk16] RFR: 8260339: JVM crashes when executing
 PhaseIdealLoop::match_fill_loop [v8]
In-Reply-To: <Xo-s3cuHGgLKABu_zZQo5rmJu4eSP3yjbAJ29DgMSSA=.f8c3965c-daa0-477e-bbd5-5b80ab53fbac@github.com>
References: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
 <Xo-s3cuHGgLKABu_zZQo5rmJu4eSP3yjbAJ29DgMSSA=.f8c3965c-daa0-477e-bbd5-5b80ab53fbac@github.com>
Message-ID: <pk1P6oJLXJbASSbJxf4zodifqmm-Qcb0lu-dY2fPfo4=.123f911d-0900-46e8-8905-039ed4d3f01e@github.com>

On Thu, 28 Jan 2021 02:24:06 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> The reason is :
>> 
>>   BasicType t = store->as_Mem()->memory_type();
>>   const char* fill_name;
>>   if (msg == NULL &&
>>       StubRoutines::select_fill_function(t, false, fill_name) == NULL) {
>>     msg = "unsupported store";
>>     msg_node = store;
>>   }
>> 
>> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here.
>> 
>> I add a new case here to avoid mistake:
>>   case T_NARROWOOP:
>>   case T_NARROWKLASS:
>>   case T_ADDRESS:
>> +  case T_VOID:
>>     // Currently unsupported
>>     return NULL;
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing summary and test name

Good.
Wait an other day for other people to look.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/132

From iignatyev at openjdk.java.net  Thu Jan 28 02:48:46 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 28 Jan 2021 02:48:46 GMT
Subject: [jdk16] RFR: 8260339: JVM crashes when executing
 PhaseIdealLoop::match_fill_loop [v8]
In-Reply-To: <Xo-s3cuHGgLKABu_zZQo5rmJu4eSP3yjbAJ29DgMSSA=.f8c3965c-daa0-477e-bbd5-5b80ab53fbac@github.com>
References: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
 <Xo-s3cuHGgLKABu_zZQo5rmJu4eSP3yjbAJ29DgMSSA=.f8c3965c-daa0-477e-bbd5-5b80ab53fbac@github.com>
Message-ID: <Dz83Z0WcI9ocP0PKf7fqAmh07fMW0kAFmZjl77UKZR4=.406faae0-9df2-4528-8584-c56afb817f48@github.com>

On Thu, 28 Jan 2021 02:24:06 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> The reason is :
>> 
>>   BasicType t = store->as_Mem()->memory_type();
>>   const char* fill_name;
>>   if (msg == NULL &&
>>       StubRoutines::select_fill_function(t, false, fill_name) == NULL) {
>>     msg = "unsupported store";
>>     msg_node = store;
>>   }
>> 
>> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here.
>> 
>> I add a new case here to avoid mistake:
>>   case T_NARROWOOP:
>>   case T_NARROWKLASS:
>>   case T_ADDRESS:
>> +  case T_VOID:
>>     // Currently unsupported
>>     return NULL;
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing summary and test name

LGTM

-------------

Marked as reviewed by iignatyev (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/132

From jwilhelm at openjdk.java.net  Thu Jan 28 02:52:02 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 28 Jan 2021 02:52:02 GMT
Subject: RFR: Merge jdk16
Message-ID: <5DNFrX1dKv2xwzps11B_CoGrsxousiY7k8-QRv3oQZ8=.fb8a9773-b3d9-4637-9151-5120de901431@github.com>

Forwardport JDK 16 -> JDK 17

-------------

Commit messages:
 - Merge
 - 8260370: C2: LoopLimit node is not eliminated

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2276&range=00.0
 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2276&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/2276/files
  Stats: 9 lines in 2 files changed: 8 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2276.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2276/head:pull/2276

PR: https://git.openjdk.java.net/jdk/pull/2276

From jwilhelm at openjdk.java.net  Thu Jan 28 03:41:40 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 28 Jan 2021 03:41:40 GMT
Subject: Integrated: Merge jdk16
In-Reply-To: <5DNFrX1dKv2xwzps11B_CoGrsxousiY7k8-QRv3oQZ8=.fb8a9773-b3d9-4637-9151-5120de901431@github.com>
References: <5DNFrX1dKv2xwzps11B_CoGrsxousiY7k8-QRv3oQZ8=.fb8a9773-b3d9-4637-9151-5120de901431@github.com>
Message-ID: <oSWJBtPbDiz6IENZhouUW9wgPijFo2Atdm5TxggMUHE=.63b44684-f083-4474-a581-e914ac9ad3a9@github.com>

On Thu, 28 Jan 2021 02:47:00 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: 62ffe75b
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/62ffe75b
Stats:     9 lines in 2 files changed: 8 ins; 0 del; 1 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/2276

From david.holmes at oracle.com  Thu Jan 28 04:44:13 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 28 Jan 2021 14:44:13 +1000
Subject: RFR: 8251462: Remove legacy compilation policy [v5]
In-Reply-To: <YDACkCpp7KInVe_5lU-KgujJHS-v-2fMcYeM4Wdnf0Y=.c7528306-a96d-4109-8b3f-5a54a6b609fc@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
 <j6u8qjorR4y5p5sbClq6u_0aIL0ws8fKrx2QkZSPAE0=.bf1ed84c-ef3c-4223-886c-2d281ae32784@github.com>
 <Qu3sFmKcKyyY6bWJ-hcUKa9cfx_tNv5I2d1YO8pC98Q=.c672461f-2b2d-4362-a870-a861910f2b72@github.com>
 <IliBxirjkus6BbQX4Fu4SjKre08650J8Ro6PYaH4Gj8=.d28798dc-bed3-422f-a21f-3746a1f173e2@github.com>
 <YDACkCpp7KInVe_5lU-KgujJHS-v-2fMcYeM4Wdnf0Y=.c7528306-a96d-4109-8b3f-5a54a6b609fc@github.com>
Message-ID: <7a846651-9ffe-eacd-af93-91f2e545b059@oracle.com>

Hi Igor,

On 28/01/2021 2:46 am, Igor Veresov wrote:
> On Mon, 25 Jan 2021 18:13:20 GMT, Igor Veresov <iveresov at openjdk.org> wrote:
> 
>>> Looks better now. I would like to see result of performance testing before approving.
>>
>> I asked Eric to run the benchmarks. The results should be ready on Wednesday.
> 
> The benchmarking is done. No regressions. There are mild improvements in startup benchmarks on the order of 1-5% (I suspect because of the compilation policy devirtualization).
> 
> @dholmes-ora, do still plan to look at this? It's been a few weeks, I'd like to push this.

No I only perused this and made a couple of comments, now addressed.

I'll leave a full review to others.

Thanks,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/1985
> 

From neliasso at openjdk.java.net  Thu Jan 28 08:10:40 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Thu, 28 Jan 2021 08:10:40 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled
In-Reply-To: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
Message-ID: <ZsrnJkRnQpKZ7ThiMFyBTlITgtEmS9we8pPKa3W5X2I=.a8ad7411-b377-4998-8a02-59a850ffba39@github.com>

On Wed, 27 Jan 2021 10:05:56 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8260473
> 
> Function "PhaseVector::expand_vunbox_node" creates a LoadNode, but forgets to make the LoadNode to pass gc barriers.
> 
> 
> Testing: all Vector API related tests have passed.

The patch looks good.

Please turn the reproducer into a regression test for this bug. Contact me if you need any help with that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From vlivanov at openjdk.java.net  Thu Jan 28 08:24:46 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 28 Jan 2021 08:24:46 GMT
Subject: RFR: 8260501: [Vector API] Improve register usage for shift
 operations on x86 [v2]
In-Reply-To: <KlokyrB2xpITspayhUgkmckPj8cB1M-jpkWfv1PSuAo=.ef99265d-0dc4-4dbe-b037-79dcaad77307@github.com>
References: <eiKG7lnaASe7574tjTNKvcokiwA1mkp_c8rD6VK2iPI=.12a4a3c1-970f-4ce2-9d6c-1a0057a2f207@github.com>
 <KlokyrB2xpITspayhUgkmckPj8cB1M-jpkWfv1PSuAo=.ef99265d-0dc4-4dbe-b037-79dcaad77307@github.com>
Message-ID: <aHHe9Uaj_hPhDP0cz39kq5lygJ-QIHh7lCrsQjktdrc=.2bd1e238-9a42-4907-ba9d-717d2fe0d0fe@github.com>

On Thu, 28 Jan 2021 02:09:58 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> I found the register usage is less optimized for some shift operations.
>> For example, vshiftL_imm [1]/vshiftI_imm require dst != src.
>> But it's actually fine for the register allocator to assign dst == src.
>> 
>> Also, vshiftL [2]/vshiftI/vshiftS require dst != src.
>> But it's actually required for UseAVX==0 only.
>> For the most common cases (UseAVX > 0), it's fine to assign dst == src.
>> 
>> The fix splits vshiftS/vshiftI/vshiftL into UseAVX > 0 and UseAVX == 0 cases.
>> And just removes the unreasonable requirement for vshiftI_imm and vshiftL_imm. 
>> 
>> Testing:
>>   - jdk/incubator/vector/ on x64 with UseAVX=3/2/1/0, no regression
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L6058
>> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L6037
>
> Jie Fu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Recuce the binary size
>  - Revert changes

Looks good.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2257

From vlivanov at openjdk.java.net  Thu Jan 28 08:24:47 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 28 Jan 2021 08:24:47 GMT
Subject: RFR: 8260501: [Vector API] Improve register usage for shift
 operations on x86
In-Reply-To: <A9xpsMoqqN9mSeuulPjPt_FUjPDIe7HZLsvRVIdOakw=.58fee2cc-07ec-4125-baef-872cd8e26b88@github.com>
References: <eiKG7lnaASe7574tjTNKvcokiwA1mkp_c8rD6VK2iPI=.12a4a3c1-970f-4ce2-9d6c-1a0057a2f207@github.com>
 <gh80Y779wLM-B1tEPn_dSg0HLeWcWUhNxANmjKKEuL4=.a8a5fbdc-5a9f-4e58-bb13-7423e7d88850@github.com>
 <A9xpsMoqqN9mSeuulPjPt_FUjPDIe7HZLsvRVIdOakw=.58fee2cc-07ec-4125-baef-872cd8e26b88@github.com>
Message-ID: <synzYPdlvPtGClJi1e7VTb6l5p853NmhBic3X3sut2Q=.de9d9f49-c4a5-4adf-909b-ee9450e310a9@github.com>

On Thu, 28 Jan 2021 02:11:53 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> With the original patch, the size of libjvm.so on Linux/x64 will be increased by ~0.085%.

Just wanted to point out that it was a deliberate compromise. Small things quickly add up and there was a noticeable static footprint increase from Vector API support due to numerous new AD instructions added. (There's still room for improvement, but the refactorings targeted at reducing the overall number of AD instructions allowed to keep it under control.)

There were other cases where generated code quality could worsen a bit and I don't want to see subsequent patches to revert those changes unless there are compelling code quality improvements.  

> However, vshiftL_imm and vshiftI_imm can still be optimized without increasing the binary size.
> And the size of libjvm.so will be further decreased by ~0.003% with the updated patch on Linux/x64.
> So are you OK with it?

Yes, I do. And normally I don't have concerns about footprint increase from adding individual AD instructions. It's specific to vectorization support that stretches C2 in unusual ways on x86.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2257

From jiefu at openjdk.java.net  Thu Jan 28 08:43:41 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 28 Jan 2021 08:43:41 GMT
Subject: RFR: 8260501: [Vector API] Improve register usage for shift
 operations on x86 [v2]
In-Reply-To: <aHHe9Uaj_hPhDP0cz39kq5lygJ-QIHh7lCrsQjktdrc=.2bd1e238-9a42-4907-ba9d-717d2fe0d0fe@github.com>
References: <eiKG7lnaASe7574tjTNKvcokiwA1mkp_c8rD6VK2iPI=.12a4a3c1-970f-4ce2-9d6c-1a0057a2f207@github.com>
 <KlokyrB2xpITspayhUgkmckPj8cB1M-jpkWfv1PSuAo=.ef99265d-0dc4-4dbe-b037-79dcaad77307@github.com>
 <aHHe9Uaj_hPhDP0cz39kq5lygJ-QIHh7lCrsQjktdrc=.2bd1e238-9a42-4907-ba9d-717d2fe0d0fe@github.com>
Message-ID: <jU7X79A3Mx2cSYbicRVnNBt_niegcZnk6lzYfiaC4Oc=.c9922ca9-c904-4546-9edc-f44e81461ab8@github.com>

On Thu, 28 Jan 2021 08:21:34 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jie Fu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Recuce the binary size
>>  - Revert changes
>
> Looks good.

> > With the original patch, the size of libjvm.so on Linux/x64 will be increased by ~0.085%.
> 
> Just wanted to point out that it was a deliberate compromise. Small things quickly add up and there was a noticeable static footprint increase from Vector API support due to numerous new AD instructions added. (There's still room for improvement, but the refactorings targeted at reducing the overall number of AD instructions allowed to keep it under control.)
> 
> There were other cases where generated code quality could worsen a bit and I don't want to see subsequent patches to revert those changes unless there are compelling code quality improvements.
> 
> > However, vshiftL_imm and vshiftI_imm can still be optimized without increasing the binary size.
> > And the size of libjvm.so will be further decreased by ~0.003% with the updated patch on Linux/x64.
> > So are you OK with it?
> 
> Yes, I do. And normally I don't have concerns about footprint increase from adding individual AD instructions. It's specific to vectorization support that stretches C2 in unusual ways on x86.

Got it and I totally agree with you @iwanowww .
Thanks for your review and comments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2257

From vlivanov at openjdk.java.net  Thu Jan 28 09:04:42 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 28 Jan 2021 09:04:42 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled
In-Reply-To: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
Message-ID: <4GliJeBE2JZSVgnDH5pAMIADyJdgA0YGEcCv6j9GdWY=.5d156f50-6ea9-470a-ad0a-db9056507108@github.com>

On Wed, 27 Jan 2021 10:05:56 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8260473
> 
> Function "PhaseVector::expand_vunbox_node" creates a LoadNode, but forgets to make the LoadNode to pass gc barriers.
> 
> 
> Testing: all Vector API related tests have passed.

What about migrating it to `GraphKit::access_load_at` instead?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From aph at redhat.com  Thu Jan 28 09:30:03 2021
From: aph at redhat.com (Andrew Haley)
Date: Thu, 28 Jan 2021 09:30:03 +0000
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value
In-Reply-To: <61lv2ty2HbKLSeNr7AXPM_ShDHfUf9ScdLQZDxh-tF4=.d1155fc9-e7fe-47ec-b84a-31764b33cc2e@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <8bFPyc33jjtDCZ3teQf14B6SmFJ1ifdD3DGp2ClHIk4=.4b861d50-8333-4fe9-b9d7-d28599e91831@github.com>
 <61lv2ty2HbKLSeNr7AXPM_ShDHfUf9ScdLQZDxh-tF4=.d1155fc9-e7fe-47ec-b84a-31764b33cc2e@github.com>
Message-ID: <f8b965ae-1b83-62a1-5c8d-7642f7e6c8a1@redhat.com>

On 1/28/21 1:50 AM, Eric Liu wrote:
> 
> Ping
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/1858

I'm reviewing it now.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From thartmann at openjdk.java.net  Thu Jan 28 09:46:47 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 28 Jan 2021 09:46:47 GMT
Subject: RFR: 8260577: Unused code in AbstractCompiler after Shark compiler
 removal
Message-ID: <CPa6az52TajrWcI_bwAFHcRRS-4srQNbc0EjakDpgHY=.33ad0d64-904d-455f-913d-51a4fd405bc3@github.com>

After removal of the Shark compiler with [JDK-8171853](https://bugs.openjdk.java.net/browse/JDK-8171853) in JDK 10, some methods in AbstractCompiler are unused.

Thanks,
Tobias

-------------

Commit messages:
 - 8260577: Unused code in AbstractCompiler after Shark compiler removal

Changes: https://git.openjdk.java.net/jdk/pull/2281/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2281&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260577
  Stats: 19 lines in 4 files changed: 0 ins; 16 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2281.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2281/head:pull/2281

PR: https://git.openjdk.java.net/jdk/pull/2281

From shade at openjdk.java.net  Thu Jan 28 09:53:43 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 28 Jan 2021 09:53:43 GMT
Subject: RFR: 8260577: Unused code in AbstractCompiler after Shark
 compiler removal
In-Reply-To: <CPa6az52TajrWcI_bwAFHcRRS-4srQNbc0EjakDpgHY=.33ad0d64-904d-455f-913d-51a4fd405bc3@github.com>
References: <CPa6az52TajrWcI_bwAFHcRRS-4srQNbc0EjakDpgHY=.33ad0d64-904d-455f-913d-51a4fd405bc3@github.com>
Message-ID: <y3AtX-oy5jhs5CrnLKnijb_J_mJR9PgzCwBFgiOZ5XE=.e23d6bd5-2c61-498b-88b6-aa0a2e750e29@github.com>

On Thu, 28 Jan 2021 09:41:48 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> After removal of the Shark compiler with [JDK-8171853](https://bugs.openjdk.java.net/browse/JDK-8171853) in JDK 10, some methods in AbstractCompiler are unused.
> 
> Thanks,
> Tobias

Looks fine. I do wonder if `CICompileOSR` and `CICompileNatives` were also for Shark, and maybe the flags and their relevant blocks could be eliminated as well.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2281

From thartmann at openjdk.java.net  Thu Jan 28 10:11:02 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 28 Jan 2021 10:11:02 GMT
Subject: RFR: 8260577: Unused code in AbstractCompiler after Shark
 compiler removal [v2]
In-Reply-To: <CPa6az52TajrWcI_bwAFHcRRS-4srQNbc0EjakDpgHY=.33ad0d64-904d-455f-913d-51a4fd405bc3@github.com>
References: <CPa6az52TajrWcI_bwAFHcRRS-4srQNbc0EjakDpgHY=.33ad0d64-904d-455f-913d-51a4fd405bc3@github.com>
Message-ID: <xLblrvZXfn89JYOukmOhzuxirNfnCxpunzZsME_XlGY=.d17dfd3c-3843-4aba-ba83-57de45a12455@github.com>

> After removal of the Shark compiler with [JDK-8171853](https://bugs.openjdk.java.net/browse/JDK-8171853) in JDK 10, some methods in AbstractCompiler are unused.
> 
> Thanks,
> Tobias

Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:

  Removed CICompileNatives and CICompileOSR

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2281/files
  - new: https://git.openjdk.java.net/jdk/pull/2281/files/c0096ea8..a95c3586

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2281&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2281&range=00-01

  Stats: 36 lines in 14 files changed: 0 ins; 33 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2281.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2281/head:pull/2281

PR: https://git.openjdk.java.net/jdk/pull/2281

From thartmann at openjdk.java.net  Thu Jan 28 10:11:03 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 28 Jan 2021 10:11:03 GMT
Subject: RFR: 8260577: Unused code in AbstractCompiler after Shark
 compiler removal [v2]
In-Reply-To: <y3AtX-oy5jhs5CrnLKnijb_J_mJR9PgzCwBFgiOZ5XE=.e23d6bd5-2c61-498b-88b6-aa0a2e750e29@github.com>
References: <CPa6az52TajrWcI_bwAFHcRRS-4srQNbc0EjakDpgHY=.33ad0d64-904d-455f-913d-51a4fd405bc3@github.com>
 <y3AtX-oy5jhs5CrnLKnijb_J_mJR9PgzCwBFgiOZ5XE=.e23d6bd5-2c61-498b-88b6-aa0a2e750e29@github.com>
Message-ID: <1cAYgcWPd4vrHs1qhmsaZQTDVILxie_MDIEjgwumuAY=.d0e1a835-28e2-4ea2-aca1-0eaa0a0ca410@github.com>

On Thu, 28 Jan 2021 09:51:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed CICompileNatives and CICompileOSR
>
> Looks fine. I do wonder if `CICompileOSR` and `CICompileNatives` were also for Shark, and maybe the flags and their relevant blocks could be eliminated as well.

Thanks for looking at this Aleksey.

> Looks fine. I do wonder if CICompileOSR and CICompileNatives were also for Shark, and maybe the flags and their relevant blocks could be eliminated as well.

Good point, I think these can go as well. I'll update the PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2281

From rrich at openjdk.java.net  Thu Jan 28 10:12:41 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Thu, 28 Jan 2021 10:12:41 GMT
Subject: RFR: 8260502: [s390] NativeMovRegMem::verify() fails because it's
 too strict
In-Reply-To: <B-kpkKfkuSOmBHpe6qjjZ_xowa1MHzqzK2zuWDIus0c=.b550a29c-7a78-402c-adbb-d071dbadf6d6@github.com>
References: <B-kpkKfkuSOmBHpe6qjjZ_xowa1MHzqzK2zuWDIus0c=.b550a29c-7a78-402c-adbb-d071dbadf6d6@github.com>
Message-ID: <_CAsjmb4zetDJd3-TpdeA-TWmb_j_UGqSBejhQ2IgBk=.8e48778a-fef3-41d1-b14e-2479a65b514e@github.com>

On Wed, 27 Jan 2021 12:13:27 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> "fatal error: this is not a `NativeMovRegMem' site" was observed while testing the debug build without CompressedOops.
> NativeMovRegMem::verify() tries to verify instructions beyond the load_const at a place at which we don't have valid instructions. See bug for details.
> I suggest to remove the wrong part of the verification.

The fix looks good to me.

The comment before the declaration of NativeMovRegMem seems to be wrong. I'd suggest to change it like this:

s/optional, load only/optional, store only/

// The instruction sequence looks like this:
//   iihf        %r1,$bits1              ; load offset for mem access
//   iilf        %r1,$bits2
//   [compress oop]                      ; optional, store only
//   load/store  %r2,0(%r1,%r2)          ; memory access

I noticed that on x86 encoding/decoding the T_OBJECT field value in reg2mem/mem2reg is done before/after the code that is to be patched. Changing the s390/PPC versions to do the same may have solved JDK-8233081 as well. This wouldn't have increased the complexity of the already extremely complex C1 patching mechanics. But it is like it is.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2258

From shade at openjdk.java.net  Thu Jan 28 10:21:43 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 28 Jan 2021 10:21:43 GMT
Subject: RFR: 8260577: Unused code in AbstractCompiler after Shark
 compiler removal [v2]
In-Reply-To: <xLblrvZXfn89JYOukmOhzuxirNfnCxpunzZsME_XlGY=.d17dfd3c-3843-4aba-ba83-57de45a12455@github.com>
References: <CPa6az52TajrWcI_bwAFHcRRS-4srQNbc0EjakDpgHY=.33ad0d64-904d-455f-913d-51a4fd405bc3@github.com>
 <xLblrvZXfn89JYOukmOhzuxirNfnCxpunzZsME_XlGY=.d17dfd3c-3843-4aba-ba83-57de45a12455@github.com>
Message-ID: <pbTzGKL_DwVLBmMJgFS2swo-mi2LB42SMsQXfTDvjGU=.b6d1b180-5e0e-4bfa-a574-54d0985c64da@github.com>

On Thu, 28 Jan 2021 10:11:02 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> After removal of the Shark compiler with [JDK-8171853](https://bugs.openjdk.java.net/browse/JDK-8171853) in JDK 10, some methods in AbstractCompiler are unused.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed CICompileNatives and CICompileOSR

This looks fine, thanks.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2281

From shade at openjdk.java.net  Thu Jan 28 10:22:52 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 28 Jan 2021 10:22:52 GMT
Subject: RFR: 8260579: PPC64 and S390 builds failures after JDK-8260467
Message-ID: <F3adcqs1QBysPMsU6G9EQ49fOBXGg4Al5lEUZ5_fpqM=.7b34f2d3-9e1c-4081-bbf3-4a4b7ad5f6a2@github.com>

Creating support/modules_libs/java.base/server/libjvm.so from 889 file(s)


   83 | InstanceKlass** klass_addr = VMClassses::klass_addr_at(klass_id);
      | ^~~~~~~~~~

   84 | Klass* klass = VMClassses::klass_at(klass_id);
      | ^~~~~~~~~~
This is an obvious typo in "VMClassses", it should actually be "vmClasses".

This readily manifests in current GH Action runs. It would have been caught by #2246 PR, if GHA were enabled, @iklam.

Additional testing:
 - [x] Linux s390x hotspot cross-compile
 - [x] Linux ppc64le hotspot cross-compile

-------------

Commit messages:
 - 8260579: PPC64 and S390 builds failures after JDK-8260467

Changes: https://git.openjdk.java.net/jdk/pull/2282/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2282&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260579
  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2282.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2282/head:pull/2282

PR: https://git.openjdk.java.net/jdk/pull/2282

From mdoerr at openjdk.java.net  Thu Jan 28 10:28:01 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 28 Jan 2021 10:28:01 GMT
Subject: RFR: 8260502: [s390] NativeMovRegMem::verify() fails because it's
 too strict [v2]
In-Reply-To: <B-kpkKfkuSOmBHpe6qjjZ_xowa1MHzqzK2zuWDIus0c=.b550a29c-7a78-402c-adbb-d071dbadf6d6@github.com>
References: <B-kpkKfkuSOmBHpe6qjjZ_xowa1MHzqzK2zuWDIus0c=.b550a29c-7a78-402c-adbb-d071dbadf6d6@github.com>
Message-ID: <VmyF0gPTWfnz3KF-_Tvm-VFq9Jh1UzLv4QNYLSY6AHU=.594dd004-5cfe-41bb-bd1c-e86bdb8629e6@github.com>

> "fatal error: this is not a `NativeMovRegMem' site" was observed while testing the debug build without CompressedOops.
> NativeMovRegMem::verify() tries to verify instructions beyond the load_const at a place at which we don't have valid instructions. See bug for details.
> I suggest to remove the wrong part of the verification.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Fix comment for NativeMovRegMem

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2258/files
  - new: https://git.openjdk.java.net/jdk/pull/2258/files/54fa039c..f178b208

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2258&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2258&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2258.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2258/head:pull/2258

PR: https://git.openjdk.java.net/jdk/pull/2258

From mdoerr at openjdk.java.net  Thu Jan 28 10:28:02 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 28 Jan 2021 10:28:02 GMT
Subject: RFR: 8260502: [s390] NativeMovRegMem::verify() fails because it's
 too strict [v2]
In-Reply-To: <_CAsjmb4zetDJd3-TpdeA-TWmb_j_UGqSBejhQ2IgBk=.8e48778a-fef3-41d1-b14e-2479a65b514e@github.com>
References: <B-kpkKfkuSOmBHpe6qjjZ_xowa1MHzqzK2zuWDIus0c=.b550a29c-7a78-402c-adbb-d071dbadf6d6@github.com>
 <_CAsjmb4zetDJd3-TpdeA-TWmb_j_UGqSBejhQ2IgBk=.8e48778a-fef3-41d1-b14e-2479a65b514e@github.com>
Message-ID: <mYKJ9FnumMhmleuyTjmjcvt3mQcxL7y00DBWuHtgEQo=.25a2d6df-57a0-4931-9aaf-f32cfa8bba3a@github.com>

On Thu, 28 Jan 2021 10:09:57 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment for NativeMovRegMem
>
> The fix looks good to me.
> 
> The comment before the declaration of NativeMovRegMem seems to be wrong. I'd suggest to change it like this:
> 
> s/optional, load only/optional, store only/
> 
> // The instruction sequence looks like this:
> //   iihf        %r1,$bits1              ; load offset for mem access
> //   iilf        %r1,$bits2
> //   [compress oop]                      ; optional, store only
> //   load/store  %r2,0(%r1,%r2)          ; memory access
> 
> I noticed that on x86 encoding/decoding the T_OBJECT field value in reg2mem/mem2reg is done before/after the code that is to be patched. Changing the s390/PPC versions to do the same may have solved JDK-8233081 as well. This wouldn't have increased the complexity of the already extremely complex C1 patching mechanics. But it is like it is.

Thanks for the reviews! I've fixed the comment as suggested. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2258

From aph at redhat.com  Thu Jan 28 10:29:15 2021
From: aph at redhat.com (Andrew Haley)
Date: Thu, 28 Jan 2021 10:29:15 +0000
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value
In-Reply-To: <f8b965ae-1b83-62a1-5c8d-7642f7e6c8a1@redhat.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <8bFPyc33jjtDCZ3teQf14B6SmFJ1ifdD3DGp2ClHIk4=.4b861d50-8333-4fe9-b9d7-d28599e91831@github.com>
 <61lv2ty2HbKLSeNr7AXPM_ShDHfUf9ScdLQZDxh-tF4=.d1155fc9-e7fe-47ec-b84a-31764b33cc2e@github.com>
 <f8b965ae-1b83-62a1-5c8d-7642f7e6c8a1@redhat.com>
Message-ID: <601ea8e0-f775-f328-4206-56abb09ceef4@redhat.com>

On 1/28/21 9:30 AM, Andrew Haley wrote:
> On 1/28/21 1:50 AM, Eric Liu wrote:
>>
>> Ping
>>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/1858
> 
> I'm reviewing it now.

Looks basically OK, but was tough to review because of the flags and
comments cleanup that made the diff hard to read.

An oddity. For rotations we have:

  match(Set dst (AndI src1 (XorI(RotateRight src2 src3) src4)));

but for all other shifts we have:

  match(Set dst (AndL src1 (XorL(RShiftL src2 src3) src4)));

That is to say, the other shifts have a type suffix. This doesn't look
right. Do you know what is going on?

Otherwise, this looks OK.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From chagedorn at openjdk.java.net  Thu Jan 28 10:35:42 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 28 Jan 2021 10:35:42 GMT
Subject: RFR: 8260577: Unused code in AbstractCompiler after Shark
 compiler removal [v2]
In-Reply-To: <xLblrvZXfn89JYOukmOhzuxirNfnCxpunzZsME_XlGY=.d17dfd3c-3843-4aba-ba83-57de45a12455@github.com>
References: <CPa6az52TajrWcI_bwAFHcRRS-4srQNbc0EjakDpgHY=.33ad0d64-904d-455f-913d-51a4fd405bc3@github.com>
 <xLblrvZXfn89JYOukmOhzuxirNfnCxpunzZsME_XlGY=.d17dfd3c-3843-4aba-ba83-57de45a12455@github.com>
Message-ID: <sDUG4Xdl7cdnLg4WgEU7dS-fL4Cv6D9ZcaJJ71ZEVlA=.6cfc7aab-8bc1-48d2-809d-d5ef9d6e9780@github.com>

On Thu, 28 Jan 2021 10:11:02 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> After removal of the Shark compiler with [JDK-8171853](https://bugs.openjdk.java.net/browse/JDK-8171853) in JDK 10, some methods in AbstractCompiler are unused.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed CICompileNatives and CICompileOSR

Looks good!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2281

From njian at openjdk.java.net  Thu Jan 28 10:40:46 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Thu, 28 Jan 2021 10:40:46 GMT
Subject: RFR: 8258953: AArch64: move NEON instructions to aarch64_neon.ad
In-Reply-To: <XGTLq2Pqnu1FU70iDyaAaSQkEYH4rtKbj_wqJHRWv7s=.dbfd57ad-5d5d-4b90-b5fb-e3da2acc5df6@github.com>
References: <XGTLq2Pqnu1FU70iDyaAaSQkEYH4rtKbj_wqJHRWv7s=.dbfd57ad-5d5d-4b90-b5fb-e3da2acc5df6@github.com>
Message-ID: <MfYLgDMBJtH0UqijF2WEWSJ6odtcEa65J28e83IH5wU=.cd4cd6ce-546b-4c6b-b078-001b5b9e94ea@github.com>

On Thu, 28 Jan 2021 01:37:33 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> As discussed in [1], all NEON instructions should be moved from `aarch64.ad` to `aarch64_neon.ad`.
> 
> In the first commit [2] of this PR, the NEON instructions are deleted from `aarch64.ad` and appended to `aarch64_neon.ad`.
> I compared the generated code in `aarch64_neon.ad` with original code in `aarch64.ad`, no suspicious differences found.
> The last two commits just simply move code around in `aarch64_neon.ad` to put related instructions together, i.e. `LoadStore` [3], `Reduction` [4].
> 
> This also supports vector length 4 for `vsraa8B_imm` and `vsrla8B_imm`, vector length 2 for `vsraa4S_imm` and `vsrla4S_imm`, fixes few typos, e.g. `vor8B`, `vsrla4S_imm`.
> 
> [1] https://github.com/openjdk/jdk/pull/1215#issuecomment-728186803
> [2] https://github.com/dgbo/jdk/commit/40cbe99e647cdf93712edf8f77ab3b5b30ea0a95
> [3] https://github.com/dgbo/jdk/commit/695fb8f8ef009b733a8f804e791347f4bfe2572e
> [4] https://github.com/dgbo/jdk/commit/e0c38aa9aaa6af9925a3821328384b1e2b2c2070

I managed to sort all the instructs and compare them with and without the patch. They are general the same except for some trailing whitespaces and typos you mentioned.

src/hotspot/cpu/aarch64/aarch64_neon.ad line 776:

> 774:            as_FloatRegister($vsrc$$reg), 0, 1);
> 775:     __ fadds(as_FloatRegister($dst$$reg),
> 776:              as_FloatRegister($dst$$reg), as_FloatRegister($tmp$$reg)); 

Remove trailing whitespace.

src/hotspot/cpu/aarch64/aarch64_neon.ad line 880:

> 878:            as_FloatRegister($vsrc$$reg), 0, 1);
> 879:     __ faddd(as_FloatRegister($dst$$reg),
> 880:              as_FloatRegister($dst$$reg), as_FloatRegister($tmp$$reg)); 

Trailing whitespace.

src/hotspot/cpu/aarch64/aarch64_neon.ad line 800:

> 798:            as_FloatRegister($vsrc$$reg), 0, 1);
> 799:     __ fadds(as_FloatRegister($dst$$reg),
> 800:              as_FloatRegister($dst$$reg), as_FloatRegister($tmp$$reg)); 

trailing whitespace

src/hotspot/cpu/aarch64/aarch64_neon.ad line 4936:

> 4934:   format %{ "fsqrt  $dst, $src\t# vector (2D)" %}
> 4935:   ins_encode %{
> 4936:     __ fsqrt(as_FloatRegister($dst$$reg), __ T2D, 

trailing whitespace

src/hotspot/cpu/aarch64/aarch64_neon.ad line 900:

> 898:            as_FloatRegister($vsrc$$reg), 0, 1);
> 899:     __ fmuld(as_FloatRegister($dst$$reg),
> 900:              as_FloatRegister($dst$$reg), as_FloatRegister($tmp$$reg)); 

trailing whitespace?

src/hotspot/cpu/aarch64/aarch64_neon.ad line 5022:

> 5020:   match(Set dst (OrV src1 src2));
> 5021:   ins_cost(INSN_COST);
> 5022:   format %{ "orr  $dst,$src1,$src2\t# vector (8B)" %}

Good catch for this typo!

src/hotspot/cpu/aarch64/aarch64_neon.ad line 5937:

> 5935:              as_FloatRegister($src$$reg));
> 5936:     } else {
> 5937:       __ usra(as_FloatRegister($dst$$reg), __ T4H,

I see you have fixed this typo, from ushr to usra. I presume original version generates wrong code and produces wrong results for specific case? If so, do you think it deserves a separate fix, e.g. for jdk16?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2273

From thartmann at openjdk.java.net  Thu Jan 28 10:41:42 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 28 Jan 2021 10:41:42 GMT
Subject: RFR: 8260577: Unused code in AbstractCompiler after Shark
 compiler removal [v2]
In-Reply-To: <sDUG4Xdl7cdnLg4WgEU7dS-fL4Cv6D9ZcaJJ71ZEVlA=.6cfc7aab-8bc1-48d2-809d-d5ef9d6e9780@github.com>
References: <CPa6az52TajrWcI_bwAFHcRRS-4srQNbc0EjakDpgHY=.33ad0d64-904d-455f-913d-51a4fd405bc3@github.com>
 <xLblrvZXfn89JYOukmOhzuxirNfnCxpunzZsME_XlGY=.d17dfd3c-3843-4aba-ba83-57de45a12455@github.com>
 <sDUG4Xdl7cdnLg4WgEU7dS-fL4Cv6D9ZcaJJ71ZEVlA=.6cfc7aab-8bc1-48d2-809d-d5ef9d6e9780@github.com>
Message-ID: <Vm_Db1JzQ08Xdf-5Zqc8u4CxeNPsdxt1MVvhrEWlEJI=.06b4ceed-7935-4a19-991a-c3c29b8921ed@github.com>

On Thu, 28 Jan 2021 10:33:18 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed CICompileNatives and CICompileOSR
>
> Looks good!

Thanks for the reviews, Aleksey and Christian.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2281

From rrich at openjdk.java.net  Thu Jan 28 10:43:40 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Thu, 28 Jan 2021 10:43:40 GMT
Subject: RFR: 8260502: [s390] NativeMovRegMem::verify() fails because it's
 too strict [v2]
In-Reply-To: <VmyF0gPTWfnz3KF-_Tvm-VFq9Jh1UzLv4QNYLSY6AHU=.594dd004-5cfe-41bb-bd1c-e86bdb8629e6@github.com>
References: <B-kpkKfkuSOmBHpe6qjjZ_xowa1MHzqzK2zuWDIus0c=.b550a29c-7a78-402c-adbb-d071dbadf6d6@github.com>
 <VmyF0gPTWfnz3KF-_Tvm-VFq9Jh1UzLv4QNYLSY6AHU=.594dd004-5cfe-41bb-bd1c-e86bdb8629e6@github.com>
Message-ID: <Co24p81oXmy2hY9OzcfFIzb86XN1TFoAaTxtVkCXf58=.82160c45-dd8b-472d-a76f-8190826f402c@github.com>

On Thu, 28 Jan 2021 10:28:01 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> "fatal error: this is not a `NativeMovRegMem' site" was observed while testing the debug build without CompressedOops.
>> NativeMovRegMem::verify() tries to verify instructions beyond the load_const at a place at which we don't have valid instructions. See bug for details.
>> I suggest to remove the wrong part of the verification.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment for NativeMovRegMem

LGTM, Thanks.

-------------

Marked as reviewed by rrich (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2258

From aph at redhat.com  Thu Jan 28 11:15:46 2021
From: aph at redhat.com (Andrew Haley)
Date: Thu, 28 Jan 2021 11:15:46 +0000
Subject: RFR: 8258953: AArch64: move NEON instructions to aarch64_neon.ad
In-Reply-To: <XGTLq2Pqnu1FU70iDyaAaSQkEYH4rtKbj_wqJHRWv7s=.dbfd57ad-5d5d-4b90-b5fb-e3da2acc5df6@github.com>
References: <XGTLq2Pqnu1FU70iDyaAaSQkEYH4rtKbj_wqJHRWv7s=.dbfd57ad-5d5d-4b90-b5fb-e3da2acc5df6@github.com>
Message-ID: <0802d608-e672-7f9c-db91-ff032fb37f10@redhat.com>

On 1/28/21 1:41 AM, Dong Bo wrote:
> The last two commits just simply move code around in `aarch64_neon.ad` to put related instructions together, i.e. `LoadStore` [3], `Reduction` [4].

I might even do these as separate changes.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From neliasso at openjdk.java.net  Thu Jan 28 11:16:42 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Thu, 28 Jan 2021 11:16:42 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled
In-Reply-To: <4GliJeBE2JZSVgnDH5pAMIADyJdgA0YGEcCv6j9GdWY=.5d156f50-6ea9-470a-ad0a-db9056507108@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <4GliJeBE2JZSVgnDH5pAMIADyJdgA0YGEcCv6j9GdWY=.5d156f50-6ea9-470a-ad0a-db9056507108@github.com>
Message-ID: <0CCcwl_AOsuDgmWZTBrWEAe9pqKDshyQeItgEiCEiZs=.6cd6be67-0951-4373-9546-fb496f48a41b@github.com>

On Thu, 28 Jan 2021 09:02:22 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8260473
>> 
>> Function "PhaseVector::expand_vunbox_node" creates a LoadNode, but forgets to make the LoadNode to pass gc barriers.
>> 
>> 
>> Testing: all Vector API related tests have passed.
>
> What about migrating it to `GraphKit::access_load_at` instead?

@iwanowww GraphKit::access_load_at is for parse time only. C2OptAccess must be used here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From neliasso at openjdk.java.net  Thu Jan 28 11:38:47 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Thu, 28 Jan 2021 11:38:47 GMT
Subject: [jdk16] RFR: 8260339: JVM crashes when executing
 PhaseIdealLoop::match_fill_loop [v8]
In-Reply-To: <Xo-s3cuHGgLKABu_zZQo5rmJu4eSP3yjbAJ29DgMSSA=.f8c3965c-daa0-477e-bbd5-5b80ab53fbac@github.com>
References: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
 <Xo-s3cuHGgLKABu_zZQo5rmJu4eSP3yjbAJ29DgMSSA=.f8c3965c-daa0-477e-bbd5-5b80ab53fbac@github.com>
Message-ID: <iJXafbdlMTe3y6tmtrfli1hxoMUBAV_LEIk-5xBqWOc=.c3fbab6e-b4ab-4d3f-b31f-e75d0004db40@github.com>

On Thu, 28 Jan 2021 02:24:06 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> The reason is :
>> 
>>   BasicType t = store->as_Mem()->memory_type();
>>   const char* fill_name;
>>   if (msg == NULL &&
>>       StubRoutines::select_fill_function(t, false, fill_name) == NULL) {
>>     msg = "unsupported store";
>>     msg_node = store;
>>   }
>> 
>> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here.
>> 
>> I add a new case here to avoid mistake:
>>   case T_NARROWOOP:
>>   case T_NARROWKLASS:
>>   case T_ADDRESS:
>> +  case T_VOID:
>>     // Currently unsupported
>>     return NULL;
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing summary and test name

Looks good.

-------------

Marked as reviewed by neliasso (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/132

From neliasso at openjdk.java.net  Thu Jan 28 11:38:48 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Thu, 28 Jan 2021 11:38:48 GMT
Subject: [jdk16] RFR: 8260339: JVM crashes when executing
 PhaseIdealLoop::match_fill_loop [v8]
In-Reply-To: <iJXafbdlMTe3y6tmtrfli1hxoMUBAV_LEIk-5xBqWOc=.c3fbab6e-b4ab-4d3f-b31f-e75d0004db40@github.com>
References: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
 <Xo-s3cuHGgLKABu_zZQo5rmJu4eSP3yjbAJ29DgMSSA=.f8c3965c-daa0-477e-bbd5-5b80ab53fbac@github.com>
 <iJXafbdlMTe3y6tmtrfli1hxoMUBAV_LEIk-5xBqWOc=.c3fbab6e-b4ab-4d3f-b31f-e75d0004db40@github.com>
Message-ID: <wl0Rpfdf_FU7wO500J_C0KWqziO-HF6UmUHeJsNIP1Y=.6c6787e3-87ff-4f8b-80af-6189d15b8cac@github.com>

On Thu, 28 Jan 2021 11:33:36 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add missing summary and test name
>
> Looks good.

I will sponsor this change when 24 hours have passed since the last update.

-------------

PR: https://git.openjdk.java.net/jdk16/pull/132

From mdoerr at openjdk.java.net  Thu Jan 28 11:42:38 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 28 Jan 2021 11:42:38 GMT
Subject: Integrated: 8260502: [s390] NativeMovRegMem::verify() fails because
 it's too strict
In-Reply-To: <B-kpkKfkuSOmBHpe6qjjZ_xowa1MHzqzK2zuWDIus0c=.b550a29c-7a78-402c-adbb-d071dbadf6d6@github.com>
References: <B-kpkKfkuSOmBHpe6qjjZ_xowa1MHzqzK2zuWDIus0c=.b550a29c-7a78-402c-adbb-d071dbadf6d6@github.com>
Message-ID: <4ovEIgor5NwaGsjjfN3S88zEjsuf7P6HIySw6F_bjvE=.7dd95c58-4222-4bb0-b4c9-fd7640f6f285@github.com>

On Wed, 27 Jan 2021 12:13:27 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> "fatal error: this is not a `NativeMovRegMem' site" was observed while testing the debug build without CompressedOops.
> NativeMovRegMem::verify() tries to verify instructions beyond the load_const at a place at which we don't have valid instructions. See bug for details.
> I suggest to remove the wrong part of the verification.

This pull request has now been integrated.

Changeset: 87522573
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/87522573
Stats:     28 lines in 2 files changed: 0 ins; 27 del; 1 mod

8260502: [s390] NativeMovRegMem::verify() fails because it's too strict

Reviewed-by: lucy, rrich

-------------

PR: https://git.openjdk.java.net/jdk/pull/2258

From mdoerr at openjdk.java.net  Thu Jan 28 11:50:40 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 28 Jan 2021 11:50:40 GMT
Subject: RFR: 8260579: PPC64 and S390 builds failures after JDK-8260467
In-Reply-To: <F3adcqs1QBysPMsU6G9EQ49fOBXGg4Al5lEUZ5_fpqM=.7b34f2d3-9e1c-4081-bbf3-4a4b7ad5f6a2@github.com>
References: <F3adcqs1QBysPMsU6G9EQ49fOBXGg4Al5lEUZ5_fpqM=.7b34f2d3-9e1c-4081-bbf3-4a4b7ad5f6a2@github.com>
Message-ID: <7gOpcMBp6bJciOpld5R4IomhzpCFPimocHl0rh2EQWk=.da90ebac-845b-460a-a933-508884a150e4@github.com>

On Thu, 28 Jan 2021 10:17:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Creating support/modules_libs/java.base/server/libjvm.so from 889 file(s)
> 
> 
>    83 | InstanceKlass** klass_addr = VMClassses::klass_addr_at(klass_id);
>       | ^~~~~~~~~~
> 
>    84 | Klass* klass = VMClassses::klass_at(klass_id);
>       | ^~~~~~~~~~
> This is an obvious typo in "VMClassses", it should actually be "vmClasses".
> 
> This readily manifests in current GH Action runs. It would have been caught by #2246 PR, if GHA were enabled, @iklam.
> 
> Additional testing:
>  - [x] Linux s390x hotspot cross-compile
>  - [x] Linux ppc64le hotspot cross-compile

Looks good and trivial. Thank you for fixing!

-------------

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2282

From shade at openjdk.java.net  Thu Jan 28 12:04:39 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 28 Jan 2021 12:04:39 GMT
Subject: RFR: 8260579: PPC64 and S390 builds failures after JDK-8260467
In-Reply-To: <7gOpcMBp6bJciOpld5R4IomhzpCFPimocHl0rh2EQWk=.da90ebac-845b-460a-a933-508884a150e4@github.com>
References: <F3adcqs1QBysPMsU6G9EQ49fOBXGg4Al5lEUZ5_fpqM=.7b34f2d3-9e1c-4081-bbf3-4a4b7ad5f6a2@github.com>
 <7gOpcMBp6bJciOpld5R4IomhzpCFPimocHl0rh2EQWk=.da90ebac-845b-460a-a933-508884a150e4@github.com>
Message-ID: <IU0VvZMJN18oRY6mpKmLm_rECSPQ2dkG3yrM56hPpK4=.14bc8cf0-3202-4b98-99c2-9bb3126561c2@github.com>

On Thu, 28 Jan 2021 11:48:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Creating support/modules_libs/java.base/server/libjvm.so from 889 file(s)
>> 
>> 
>>    83 | InstanceKlass** klass_addr = VMClassses::klass_addr_at(klass_id);
>>       | ^~~~~~~~~~
>> 
>>    84 | Klass* klass = VMClassses::klass_at(klass_id);
>>       | ^~~~~~~~~~
>> This is an obvious typo in "VMClassses", it should actually be "vmClasses".
>> 
>> This readily manifests in current GH Action runs. It would have been caught by #2246 PR, if GHA were enabled, @iklam.
>> 
>> Additional testing:
>>  - [x] Linux s390x hotspot cross-compile
>>  - [x] Linux ppc64le hotspot cross-compile
>
> Looks good and trivial. Thank you for fixing!

PPC64 and S390 builds are green in GH Actions now, integrating.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2282

From shade at openjdk.java.net  Thu Jan 28 12:04:40 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 28 Jan 2021 12:04:40 GMT
Subject: Integrated: 8260579: PPC64 and S390 builds failures after JDK-8260467
In-Reply-To: <F3adcqs1QBysPMsU6G9EQ49fOBXGg4Al5lEUZ5_fpqM=.7b34f2d3-9e1c-4081-bbf3-4a4b7ad5f6a2@github.com>
References: <F3adcqs1QBysPMsU6G9EQ49fOBXGg4Al5lEUZ5_fpqM=.7b34f2d3-9e1c-4081-bbf3-4a4b7ad5f6a2@github.com>
Message-ID: <wG6_N_73FNAxzE4G_VVUZ0CToqgEmt01XnSz_ZXBpcs=.fcaf718b-7b69-4642-a090-e739a6c26b36@github.com>

On Thu, 28 Jan 2021 10:17:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Creating support/modules_libs/java.base/server/libjvm.so from 889 file(s)
> 
> 
>    83 | InstanceKlass** klass_addr = VMClassses::klass_addr_at(klass_id);
>       | ^~~~~~~~~~
> 
>    84 | Klass* klass = VMClassses::klass_at(klass_id);
>       | ^~~~~~~~~~
> This is an obvious typo in "VMClassses", it should actually be "vmClasses".
> 
> This readily manifests in current GH Action runs. It would have been caught by #2246 PR, if GHA were enabled, @iklam.
> 
> Additional testing:
>  - [x] Linux s390x hotspot cross-compile
>  - [x] Linux ppc64le hotspot cross-compile

This pull request has now been integrated.

Changeset: a68c6c2a
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a68c6c2a
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8260579: PPC64 and S390 builds failures after JDK-8260467

Reviewed-by: mdoerr

-------------

PR: https://git.openjdk.java.net/jdk/pull/2282

From dongbo at openjdk.java.net  Thu Jan 28 12:12:45 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Thu, 28 Jan 2021 12:12:45 GMT
Subject: RFR: 8258953: AArch64: move NEON instructions to aarch64_neon.ad
In-Reply-To: <MfYLgDMBJtH0UqijF2WEWSJ6odtcEa65J28e83IH5wU=.cd4cd6ce-546b-4c6b-b078-001b5b9e94ea@github.com>
References: <XGTLq2Pqnu1FU70iDyaAaSQkEYH4rtKbj_wqJHRWv7s=.dbfd57ad-5d5d-4b90-b5fb-e3da2acc5df6@github.com>
 <MfYLgDMBJtH0UqijF2WEWSJ6odtcEa65J28e83IH5wU=.cd4cd6ce-546b-4c6b-b078-001b5b9e94ea@github.com>
Message-ID: <lbQOLnB1EvIN27mCZWlifjwnE9kdN5IJSz74O1ibTZI=.9e94cfda-09a4-4ed3-add0-25f3ef0896fb@github.com>

On Thu, 28 Jan 2021 10:37:47 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

>> As discussed in [1], all NEON instructions should be moved from `aarch64.ad` to `aarch64_neon.ad`.
>> 
>> In the first commit [2] of this PR, the NEON instructions are deleted from `aarch64.ad` and appended to `aarch64_neon.ad`.
>> I compared the generated code in `aarch64_neon.ad` with original code in `aarch64.ad`, no suspicious differences found.
>> The last two commits just simply move code around in `aarch64_neon.ad` to put related instructions together, i.e. `LoadStore` [3], `Reduction` [4].
>> 
>> This also supports vector length 4 for `vsraa8B_imm` and `vsrla8B_imm`, vector length 2 for `vsraa4S_imm` and `vsrla4S_imm`, fixes few typos, e.g. `vor8B`, `vsrla4S_imm`.
>> 
>> [1] https://github.com/openjdk/jdk/pull/1215#issuecomment-728186803
>> [2] https://github.com/dgbo/jdk/commit/40cbe99e647cdf93712edf8f77ab3b5b30ea0a95
>> [3] https://github.com/dgbo/jdk/commit/695fb8f8ef009b733a8f804e791347f4bfe2572e
>> [4] https://github.com/dgbo/jdk/commit/e0c38aa9aaa6af9925a3821328384b1e2b2c2070
>
> I managed to sort all the instructs and compare them with and without the patch. They are general the same except for some trailing whitespaces and typos you mentioned.

> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [hotspot-dev](mailto:hotspot-dev at openjdk.java.net):_
> 
> On 1/28/21 10:40 AM, Ningsheng Jian wrote:
> 
> > I see you have fixed this typo, from ushr to usra. I presume original version generates wrong code and produces wrong results for specific case? If so, do you think it deserves a separate fix, e.g. for jdk16?
> 
> It does. This patch should change nothing at all, except moving
> text from A to B.
> 
> --
> Andrew Haley (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

@nsjian @theRealAph Thank you for the comments. I'll raise a seperate PR to fix this right now.

BTW, since Andrew says we should change nothing at all in this move, do you think we should also do the things below in separtate PRs?
1. fix the typo of `vor8B`.
2. supporting vector length 4 for `vsraa8B_imm` and `vsrla8B_imm`, vector length 2 for `vsraa4S_imm` and `vsrla4S_imm`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2273

From github.com+25214855+casparcwang at openjdk.java.net  Thu Jan 28 12:19:07 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Thu, 28 Jan 2021 12:19:07 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v2]
In-Reply-To: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
Message-ID: <OpyYSSPOTMkAvQlTeYSIIOdu2LIG9gMm9z0akDo3d94=.61b8c03a-355f-4f0d-b625-1edcaefc7c33@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8260473
> 
> Function "PhaseVector::expand_vunbox_node" creates a LoadNode, but forgets to make the LoadNode to pass gc barriers.
> 
> 
> Testing: all Vector API related tests have passed.

?? has updated the pull request incrementally with one additional commit since the last revision:

  Add the regression test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2253/files
  - new: https://git.openjdk.java.net/jdk/pull/2253/files/5859bbbc..fbaddfb7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2253&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2253&range=00-01

  Stats: 132 lines in 1 file changed: 132 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2253.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2253/head:pull/2253

PR: https://git.openjdk.java.net/jdk/pull/2253

From github.com+25214855+casparcwang at openjdk.java.net  Thu Jan 28 12:21:58 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Thu, 28 Jan 2021 12:21:58 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v3]
In-Reply-To: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
Message-ID: <sGywYZy9AvtMNgbl-_T0biN0wsJVINr2WqsZ_p1wikw=.5ce1e28e-9bc5-42e4-aa5d-128dd6127b3e@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8260473
> 
> Function "PhaseVector::expand_vunbox_node" creates a LoadNode, but forgets to make the LoadNode to pass gc barriers.
> 
> 
> Testing: all Vector API related tests have passed.

?? has updated the pull request incrementally with one additional commit since the last revision:

  rm trailing whitespace

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2253/files
  - new: https://git.openjdk.java.net/jdk/pull/2253/files/fbaddfb7..b1db113f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2253&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2253&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2253.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2253/head:pull/2253

PR: https://git.openjdk.java.net/jdk/pull/2253

From github.com+25214855+casparcwang at openjdk.java.net  Thu Jan 28 12:25:39 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Thu, 28 Jan 2021 12:25:39 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v3]
In-Reply-To: <0CCcwl_AOsuDgmWZTBrWEAe9pqKDshyQeItgEiCEiZs=.6cd6be67-0951-4373-9546-fb496f48a41b@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <4GliJeBE2JZSVgnDH5pAMIADyJdgA0YGEcCv6j9GdWY=.5d156f50-6ea9-470a-ad0a-db9056507108@github.com>
 <0CCcwl_AOsuDgmWZTBrWEAe9pqKDshyQeItgEiCEiZs=.6cd6be67-0951-4373-9546-fb496f48a41b@github.com>
Message-ID: <1_hVbQCFz5VshMGIRCNKt8BZpxiuGfptHD7_dTZ5z9M=.44499d58-f526-4d3a-bad2-72be3063dc68@github.com>

On Thu, 28 Jan 2021 11:13:37 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> What about migrating it to `GraphKit::access_load_at` instead?
>
> @iwanowww GraphKit::access_load_at is for parse time only. C2OptAccess must be used here.

The test is part of test/jdk/jdk/incubator/vector/VectorReshapeTests.java.
And run the original big test with zgc didn't reproduce the failure, so just add a new small test.

The small test is provided by Stuart Monteith in the JBS. Thanks for providing the test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From roland at openjdk.java.net  Thu Jan 28 12:31:07 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 28 Jan 2021 12:31:07 GMT
Subject: RFR: 8260407: cmp != __null && cmp->Opcode() == Op_CmpL failure
 with -XX:StressLongCountedLoop=200000000 in lucene [v2]
In-Reply-To: <Ud0obOyQpdKh2yyyWnQJVNQMiJu2qgTW3RE9G8bR8lI=.f839f2db-0778-4ccf-b607-7ded9d655655@github.com>
References: <Ud0obOyQpdKh2yyyWnQJVNQMiJu2qgTW3RE9G8bR8lI=.f839f2db-0778-4ccf-b607-7ded9d655655@github.com>
Message-ID: <IGymofe4I_Betpz_P6ojIoHWTZ4VOQv9G6Ron8WrmOc=.6e1a8476-8a18-417d-bb87-45fb0a6f351b@github.com>

> Long counted loops are transformed in 3 steps:
> 
> 1- LongCountedLoopNode/LongCountedLoopEndNode are created (similar to
> int counted loops)
> 
> 2- a loop nest is built from the
> LongCountedLoopNode/LongCountedLoopEndNode with an inner loop with a
> int iv
> 
> 3- the inner loop is transformed to a CountedLoop
> 
> Between 1- and 2-, the LongCountedLoopEndNode is transformed by split
> if because a dominated if uses the same condition. Fix simplys applies
> existing check for CountedLoopEndNode to LongCountedLoopEndNode.

Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:

  copyright

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2240/files
  - new: https://git.openjdk.java.net/jdk/pull/2240/files/8b3312aa..d1f32df7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2240&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2240&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2240.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2240/head:pull/2240

PR: https://git.openjdk.java.net/jdk/pull/2240

From roland at openjdk.java.net  Thu Jan 28 12:31:07 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 28 Jan 2021 12:31:07 GMT
Subject: RFR: 8260407: cmp != __null && cmp->Opcode() == Op_CmpL failure
 with -XX:StressLongCountedLoop=200000000 in lucene [v2]
In-Reply-To: <1QX1mX7KTZOBaVL1U-H5YqRY-CHlO7Mo6RW2hKicvAQ=.12ef4f78-e40c-4116-9a35-0060419f701d@github.com>
References: <Ud0obOyQpdKh2yyyWnQJVNQMiJu2qgTW3RE9G8bR8lI=.f839f2db-0778-4ccf-b607-7ded9d655655@github.com>
 <1QX1mX7KTZOBaVL1U-H5YqRY-CHlO7Mo6RW2hKicvAQ=.12ef4f78-e40c-4116-9a35-0060419f701d@github.com>
Message-ID: <B8flI0Rnmf33XjEQIOje-9CsW7SOjhPDr7UkjXskA-U=.3c57595b-9d0f-4dfe-bb08-4f5718434c23@github.com>

On Wed, 27 Jan 2021 07:20:28 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright
>
> Looks good to me.

@TobiHartmann @vnkozlov Thanks for the reviews (I fixed the copyright)

-------------

PR: https://git.openjdk.java.net/jdk/pull/2240

From roland at openjdk.java.net  Thu Jan 28 12:31:10 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 28 Jan 2021 12:31:10 GMT
Subject: Integrated: 8260407: cmp != __null && cmp->Opcode() == Op_CmpL
 failure with -XX:StressLongCountedLoop=200000000 in lucene
In-Reply-To: <Ud0obOyQpdKh2yyyWnQJVNQMiJu2qgTW3RE9G8bR8lI=.f839f2db-0778-4ccf-b607-7ded9d655655@github.com>
References: <Ud0obOyQpdKh2yyyWnQJVNQMiJu2qgTW3RE9G8bR8lI=.f839f2db-0778-4ccf-b607-7ded9d655655@github.com>
Message-ID: <hxGagS-UgiQt8H-jaTC-6o12quAFE00AfBvgiB2aMzg=.23854170-0d52-48df-9311-287d68edb226@github.com>

On Tue, 26 Jan 2021 15:14:27 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Long counted loops are transformed in 3 steps:
> 
> 1- LongCountedLoopNode/LongCountedLoopEndNode are created (similar to
> int counted loops)
> 
> 2- a loop nest is built from the
> LongCountedLoopNode/LongCountedLoopEndNode with an inner loop with a
> int iv
> 
> 3- the inner loop is transformed to a CountedLoop
> 
> Between 1- and 2-, the LongCountedLoopEndNode is transformed by split
> if because a dominated if uses the same condition. Fix simplys applies
> existing check for CountedLoopEndNode to LongCountedLoopEndNode.

This pull request has now been integrated.

Changeset: 11d6467c
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/11d6467c
Stats:     73 lines in 2 files changed: 72 ins; 0 del; 1 mod

8260407: cmp != __null && cmp->Opcode() == Op_CmpL failure with -XX:StressLongCountedLoop=200000000 in lucene

Reviewed-by: thartmann, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/2240

From jiefu at openjdk.java.net  Thu Jan 28 12:40:39 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 28 Jan 2021 12:40:39 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v3]
In-Reply-To: <1_hVbQCFz5VshMGIRCNKt8BZpxiuGfptHD7_dTZ5z9M=.44499d58-f526-4d3a-bad2-72be3063dc68@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <4GliJeBE2JZSVgnDH5pAMIADyJdgA0YGEcCv6j9GdWY=.5d156f50-6ea9-470a-ad0a-db9056507108@github.com>
 <0CCcwl_AOsuDgmWZTBrWEAe9pqKDshyQeItgEiCEiZs=.6cd6be67-0951-4373-9546-fb496f48a41b@github.com>
 <1_hVbQCFz5VshMGIRCNKt8BZpxiuGfptHD7_dTZ5z9M=.44499d58-f526-4d3a-bad2-72be3063dc68@github.com>
Message-ID: <JiQEFdh2zVScfxDVw_N3r08g-ZPHFwlx2vJdStHKHLg=.f0677414-164a-4bca-8b79-05897fbfc40f@github.com>

On Thu, 28 Jan 2021 12:22:35 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

>> @iwanowww GraphKit::access_load_at is for parse time only. C2OptAccess must be used here.
>
> The test is part of test/jdk/jdk/incubator/vector/VectorReshapeTests.java.
> And run the original big test with zgc didn't reproduce the failure, so just add a new small test.
> 
> The small test is provided by Stuart Monteith in the JBS. Thanks for providing the test.

I suggest adding the test under test/hotspot/jtreg/compiler/vectorapi.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From jiefu at openjdk.java.net  Thu Jan 28 12:47:40 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 28 Jan 2021 12:47:40 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v3]
In-Reply-To: <JiQEFdh2zVScfxDVw_N3r08g-ZPHFwlx2vJdStHKHLg=.f0677414-164a-4bca-8b79-05897fbfc40f@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <4GliJeBE2JZSVgnDH5pAMIADyJdgA0YGEcCv6j9GdWY=.5d156f50-6ea9-470a-ad0a-db9056507108@github.com>
 <0CCcwl_AOsuDgmWZTBrWEAe9pqKDshyQeItgEiCEiZs=.6cd6be67-0951-4373-9546-fb496f48a41b@github.com>
 <1_hVbQCFz5VshMGIRCNKt8BZpxiuGfptHD7_dTZ5z9M=.44499d58-f526-4d3a-bad2-72be3063dc68@github.com>
 <JiQEFdh2zVScfxDVw_N3r08g-ZPHFwlx2vJdStHKHLg=.f0677414-164a-4bca-8b79-05897fbfc40f@github.com>
Message-ID: <9t9pW4ro734dO5B6Rv_mv8MqoOq9Yr-XlAojRItL7M0=.1fbab424-d892-4e17-9d26-0383780a73ba@github.com>

On Thu, 28 Jan 2021 12:38:11 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> The test is part of test/jdk/jdk/incubator/vector/VectorReshapeTests.java.
>> And run the original big test with zgc didn't reproduce the failure, so just add a new small test.
>> 
>> The small test is provided by Stuart Monteith in the JBS. Thanks for providing the test.
>
> I suggest adding the test under test/hotspot/jtreg/compiler/vectorapi.
> Thanks.

Since 32-bit VM doesn't support ZGC, the test should only for 64-bit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From vlivanov at openjdk.java.net  Thu Jan 28 12:47:43 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 28 Jan 2021 12:47:43 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v3]
In-Reply-To: <4GliJeBE2JZSVgnDH5pAMIADyJdgA0YGEcCv6j9GdWY=.5d156f50-6ea9-470a-ad0a-db9056507108@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <4GliJeBE2JZSVgnDH5pAMIADyJdgA0YGEcCv6j9GdWY=.5d156f50-6ea9-470a-ad0a-db9056507108@github.com>
Message-ID: <op_Mr8BB_Y0MYYkEpQYL1RxyxialuEa1bz1RbfKoaNM=.a3f2d113-917a-4b3f-bb50-a8330bf4b682@github.com>

On Thu, 28 Jan 2021 09:02:22 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> ?? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rm trailing whitespace
>
> What about migrating it to `GraphKit::access_load_at` instead?

> @iwanowww GraphKit::access_load_at is for parse time only. C2OptAccess must be used here.

I see. That's unfortunate.

Actually, `PhaseVector::optimize_vector_boxes()` sets `C->inlining_incrementally() == true` and it enables the code to use `GraphKit` and, moreover,  perform late inlining of vector reboxing operations. But I haven't thought through all the implications yet.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From github.com+25214855+casparcwang at openjdk.java.net  Thu Jan 28 12:53:03 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Thu, 28 Jan 2021 12:53:03 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v4]
In-Reply-To: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
Message-ID: <rdtmz-1qWqPh036NjaVt6BXeVZdHuIJOFCpnVIkoI4I=.e503ab3b-5259-40f6-b056-976d0efa5ae5@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8260473
> 
> Function "PhaseVector::expand_vunbox_node" creates a LoadNode, but forgets to make the LoadNode to pass gc barriers.
> 
> 
> Testing: all Vector API related tests have passed.

?? has updated the pull request incrementally with one additional commit since the last revision:

  Change the directory & fix the include order

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2253/files
  - new: https://git.openjdk.java.net/jdk/pull/2253/files/b1db113f..d52fd4c4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2253&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2253&range=02-03

  Stats: 2 lines in 2 files changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2253.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2253/head:pull/2253

PR: https://git.openjdk.java.net/jdk/pull/2253

From github.com+25214855+casparcwang at openjdk.java.net  Thu Jan 28 13:04:39 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Thu, 28 Jan 2021 13:04:39 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v4]
In-Reply-To: <op_Mr8BB_Y0MYYkEpQYL1RxyxialuEa1bz1RbfKoaNM=.a3f2d113-917a-4b3f-bb50-a8330bf4b682@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <4GliJeBE2JZSVgnDH5pAMIADyJdgA0YGEcCv6j9GdWY=.5d156f50-6ea9-470a-ad0a-db9056507108@github.com>
 <op_Mr8BB_Y0MYYkEpQYL1RxyxialuEa1bz1RbfKoaNM=.a3f2d113-917a-4b3f-bb50-a8330bf4b682@github.com>
Message-ID: <8CdueoVmisyBg7xQko_cVOVPJDw5qhAOVGL2lyRDn54=.6f498c27-cced-460a-9198-514c5f8cd605@github.com>

On Thu, 28 Jan 2021 12:45:39 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> > @iwanowww GraphKit::access_load_at is for parse time only. C2OptAccess must be used here.
> 
> I see. That's unfortunate.
> 
> Actually, `PhaseVector::optimize_vector_boxes()` sets `C->inlining_incrementally() == true` and it enables the code to use `GraphKit` and, moreover, perform late inlining of vector reboxing operations. But I haven't thought through all the implications yet.

`ArrayCopyNode::load` performs the same work as it does here in `PhaseVector::optimize_vector_boxes `.
Is there a need to provide a similar function in PhaseVector or GraphKit?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From eosterlund at openjdk.java.net  Thu Jan 28 13:12:42 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 28 Jan 2021 13:12:42 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v4]
In-Reply-To: <8CdueoVmisyBg7xQko_cVOVPJDw5qhAOVGL2lyRDn54=.6f498c27-cced-460a-9198-514c5f8cd605@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <4GliJeBE2JZSVgnDH5pAMIADyJdgA0YGEcCv6j9GdWY=.5d156f50-6ea9-470a-ad0a-db9056507108@github.com>
 <op_Mr8BB_Y0MYYkEpQYL1RxyxialuEa1bz1RbfKoaNM=.a3f2d113-917a-4b3f-bb50-a8330bf4b682@github.com>
 <8CdueoVmisyBg7xQko_cVOVPJDw5qhAOVGL2lyRDn54=.6f498c27-cced-460a-9198-514c5f8cd605@github.com>
Message-ID: <VUOVO7L38_q9DrqIsMd2d8OPkUsLd4j_9lqtNIPh4cE=.59ec5a74-9c62-4ab0-99f3-d5a3e1b44271@github.com>

On Thu, 28 Jan 2021 13:01:36 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

>>> @iwanowww GraphKit::access_load_at is for parse time only. C2OptAccess must be used here.
>> 
>> I see. That's unfortunate.
>> 
>> Actually, `PhaseVector::optimize_vector_boxes()` sets `C->inlining_incrementally() == true` and it enables the code to use `GraphKit` and, moreover,  perform late inlining of vector reboxing operations. But I haven't thought through all the implications yet.
>
>> > @iwanowww GraphKit::access_load_at is for parse time only. C2OptAccess must be used here.
>> 
>> I see. That's unfortunate.
>> 
>> Actually, `PhaseVector::optimize_vector_boxes()` sets `C->inlining_incrementally() == true` and it enables the code to use `GraphKit` and, moreover, perform late inlining of vector reboxing operations. But I haven't thought through all the implications yet.
> 
> `ArrayCopyNode::load` performs the same work as it does here in `PhaseVector::optimize_vector_boxes `.
> Is there a need to provide a similar function in PhaseVector or GraphKit?

Worth mentioning is that we have optimization-time loads and stores in the arraycopy/clone code. When that was added, it was the only place where we had such accesses, so a little load/store wrapper utility was written in the arraycopy code. But perhaps now that there is more than one place, that utility belongs in a more central place, so the boilerplate can be reduced. I'm okay with doing that in a follow-up RFE though, as it is a refactoring only, and getting the actual bug fix in soon is is of value.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From github.com+10482586+therealeliu at openjdk.java.net  Thu Jan 28 13:32:46 2021
From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu)
Date: Thu, 28 Jan 2021 13:32:46 GMT
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value
In-Reply-To: <Cba9nuZg_0pzKraAsDuOoC6Mo8LF1ljpGbXqxUVikDI=.ad71a55b-121a-4811-928a-28ebf1c6674d@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <8bFPyc33jjtDCZ3teQf14B6SmFJ1ifdD3DGp2ClHIk4=.4b861d50-8333-4fe9-b9d7-d28599e91831@github.com>
 <61lv2ty2HbKLSeNr7AXPM_ShDHfUf9ScdLQZDxh-tF4=.d1155fc9-e7fe-47ec-b84a-31764b33cc2e@github.com>
 <6NOQ2e_ISepbYq22u1EUy7F5OIVArfQUugnlPjBW7HY=.b0b934ee-bf7b-4ef2-8887-d369251582e6@github.com>
 <Cba9nuZg_0pzKraAsDuOoC6Mo8LF1ljpGbXqxUVikDI=.ad71a55b-121a-4811-928a-28ebf1c6674d@github.com>
Message-ID: <pXh18Rv51L46wztRftQto-iWQIyHvOdvFcPSFj4rWRo=.9b7882e2-368a-47b6-94ec-9df00f968bcb@github.com>

On Thu, 28 Jan 2021 02:17:47 GMT, Eric Liu <github.com+10482586+theRealELiu at openjdk.org> wrote:

>> What impact does this have on runtime?  There are also Tier1 failures in x86, which you'll need to investigate
>
> I suppose this failure was not caused by my patch, and it has been fixed by https://github.com/openjdk/jdk/commit/1594372c.

Thanks for your kindly review.

> An oddity. For rotations we have:
>
> match(Set dst (AndI src1 (XorI(RotateRight src2 src3) src4)));
>
> but for all other shifts we have:
>
> match(Set dst (AndL src1 (XorL(RShiftL src2 src3) src4)));
>
> That is to say, the other shifts have a type suffix. This doesn't look
> right. Do you know what is going on?

For rotation node, they have an extra field to identify the type, maybe this could save some code size...   And I didn't use 'predicate' to check that because middle-end could guarantee Xor's input type was correct.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1858

From azeemj at openjdk.java.net  Thu Jan 28 13:37:45 2021
From: azeemj at openjdk.java.net (Azeem Jiva)
Date: Thu, 28 Jan 2021 13:37:45 GMT
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value
In-Reply-To: <Cba9nuZg_0pzKraAsDuOoC6Mo8LF1ljpGbXqxUVikDI=.ad71a55b-121a-4811-928a-28ebf1c6674d@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <8bFPyc33jjtDCZ3teQf14B6SmFJ1ifdD3DGp2ClHIk4=.4b861d50-8333-4fe9-b9d7-d28599e91831@github.com>
 <61lv2ty2HbKLSeNr7AXPM_ShDHfUf9ScdLQZDxh-tF4=.d1155fc9-e7fe-47ec-b84a-31764b33cc2e@github.com>
 <6NOQ2e_ISepbYq22u1EUy7F5OIVArfQUugnlPjBW7HY=.b0b934ee-bf7b-4ef2-8887-d369251582e6@github.com>
 <Cba9nuZg_0pzKraAsDuOoC6Mo8LF1ljpGbXqxUVikDI=.ad71a55b-121a-4811-928a-28ebf1c6674d@github.com>
Message-ID: <HE7Un2556ZGfbsbU2Q_0Ijl3q6UC3Ker8uegxFDwPKc=.15e74dec-c279-4e60-88d9-2806fd56017f@github.com>

On Thu, 28 Jan 2021 02:17:47 GMT, Eric Liu <github.com+10482586+theRealELiu at openjdk.org> wrote:

> I suppose this failure was not caused by my patch, and it has been fixed by https://github.com/openjdk/jdk/commit/1594372c.

Benchmark results?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1858

From aph at openjdk.java.net  Thu Jan 28 14:29:42 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 28 Jan 2021 14:29:42 GMT
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value
In-Reply-To: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
Message-ID: <WDQ0yZR8gbP6aLt1qOEIMsSOrwiSMdS4V8l4pi4RBmc=.b201fce0-ed3e-4319-b96b-9651bd4ecdd7@github.com>

On Mon, 21 Dec 2020 10:10:10 GMT, Eric Liu <github.com+10482586+theRealELiu at openjdk.org> 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

All that remains to do is the benchmarks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1858

From aph at openjdk.java.net  Thu Jan 28 14:29:43 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 28 Jan 2021 14:29:43 GMT
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value
In-Reply-To: <pXh18Rv51L46wztRftQto-iWQIyHvOdvFcPSFj4rWRo=.9b7882e2-368a-47b6-94ec-9df00f968bcb@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <8bFPyc33jjtDCZ3teQf14B6SmFJ1ifdD3DGp2ClHIk4=.4b861d50-8333-4fe9-b9d7-d28599e91831@github.com>
 <61lv2ty2HbKLSeNr7AXPM_ShDHfUf9ScdLQZDxh-tF4=.d1155fc9-e7fe-47ec-b84a-31764b33cc2e@github.com>
 <6NOQ2e_ISepbYq22u1EUy7F5OIVArfQUugnlPjBW7HY=.b0b934ee-bf7b-4ef2-8887-d369251582e6@github.com>
 <Cba9nuZg_0pzKraAsDuOoC6Mo8LF1ljpGbXqxUVikDI=.ad71a55b-121a-4811-928a-28ebf1c6674d@github.com>
 <pXh18Rv51L46wztRftQto-iWQIyHvOdvFcPSFj4rWRo=.9b7882e2-368a-47b6-94ec-9df00f968bcb@github.com>
Message-ID: <18f2lDyH7lfB15_aJV2Ed2RIAK8Nu5_cjAMaOiRCqPQ=.262de405-fae5-42af-9efb-60a696851aa0@github.com>

On Thu, 28 Jan 2021 13:29:59 GMT, Eric Liu <github.com+10482586+theRealELiu at openjdk.org> wrote:

> > An oddity. For rotations we have:
> > ``` match(Set dst (AndI src1 (XorI(RotateRight src2 src3) src4))); ```
> > but for all other shifts we have:
> > ``` match(Set dst (AndL src1 (XorL(RShiftL src2 src3) src4))); ```
> > That is to say, the other shifts have a type suffix. This doesn't look
> > right. Do you know what is going on?
> 
> For rotation node, they have an extra field to identify the type, maybe this could save some code size... And I didn't use 'predicate' to check that because middle-end could guarantee Xor's input type was correct.

Ok, I see. That's very ugly, but it's not your fault.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1858

From pliden at openjdk.java.net  Thu Jan 28 14:50:47 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Thu, 28 Jan 2021 14:50:47 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v4]
In-Reply-To: <rdtmz-1qWqPh036NjaVt6BXeVZdHuIJOFCpnVIkoI4I=.e503ab3b-5259-40f6-b056-976d0efa5ae5@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <rdtmz-1qWqPh036NjaVt6BXeVZdHuIJOFCpnVIkoI4I=.e503ab3b-5259-40f6-b056-976d0efa5ae5@github.com>
Message-ID: <iIYn7GIJbme9tCGYr7b4fkiTiyq_UFOFj8TF8DKLDWE=.7705d465-d22f-4bee-ba6a-a36b4a69da2f@github.com>

On Thu, 28 Jan 2021 12:53:03 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8260473
>> 
>> Function "PhaseVector::expand_vunbox_node" creates a LoadNode, but forgets to make the LoadNode to pass gc barriers.
>> 
>> 
>> Testing: all Vector API related tests have passed.
>
> ?? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change the directory & fix the include order

test/hotspot/jtreg/compiler/vectorapi/VectorReshapeTest.java line 38:

> 36:  * @test
> 37:  * @bug 8260473
> 38:  * @modules jdk.incubator.vector

This test should have a `@requires vm.gc.Z` tag. That will make sure it's only executed on platforms where ZGC is supported (and that ZGC is included in the build).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From kvn at openjdk.java.net  Thu Jan 28 16:19:51 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 28 Jan 2021 16:19:51 GMT
Subject: [jdk16] Integrated: 8253353: Crash in C2: guarantee(n != NULL)
 failed: No Node
In-Reply-To: <gvNpYhQInkonT7X4UvX8_vivCQj_zJqRXOiQEIWw7oE=.6c4b5369-f999-4c7a-a525-e65301d940f5@github.com>
References: <gvNpYhQInkonT7X4UvX8_vivCQj_zJqRXOiQEIWw7oE=.6c4b5369-f999-4c7a-a525-e65301d940f5@github.com>
Message-ID: <BTEvn18STQmMxqZd0nlgszt4WquIIy5F3R4U4Kxb67M=.593874a3-d5d6-4b8e-a57b-076fea1b7494@github.com>

On Wed, 27 Jan 2021 21:03:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Nesting loops for this case reaches 400+. But the type of IdeaLoopTree::_nest field is uint8 (the maximum value allowed is 255). The test passed with the following fix proposed by @RealFYang:
> 
> - uint8_t _nest; // Nesting depth 
> + uint16_t _nest; // Nesting depth
> 
> I think increase size to `unsigned short` (16 bits) is enough for this value. We will bailout C2 compilation due to big IR graph (MaxNodeLimit = 80000) before we can construct MAX_USHORT (65535)  nested loops. And I added asserts to catch such case if it happens.
> 
> New regression test is added.
> Passed hs-tier1 - 3 testing.

This pull request has now been integrated.

Changeset: 1926765f
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/1926765f
Stats:     1987 lines in 4 files changed: 1986 ins; 0 del; 1 mod

8253353: Crash in C2: guarantee(n != NULL) failed: No Node

Co-authored-by: Fei Yang <fyang at openjdk.org>
Reviewed-by: vlivanov, neliasso

-------------

PR: https://git.openjdk.java.net/jdk16/pull/135

From kvn at openjdk.java.net  Thu Jan 28 16:33:40 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 28 Jan 2021 16:33:40 GMT
Subject: RFR: 8260501: [Vector API] Improve register usage for shift
 operations on x86 [v2]
In-Reply-To: <KlokyrB2xpITspayhUgkmckPj8cB1M-jpkWfv1PSuAo=.ef99265d-0dc4-4dbe-b037-79dcaad77307@github.com>
References: <eiKG7lnaASe7574tjTNKvcokiwA1mkp_c8rD6VK2iPI=.12a4a3c1-970f-4ce2-9d6c-1a0057a2f207@github.com>
 <KlokyrB2xpITspayhUgkmckPj8cB1M-jpkWfv1PSuAo=.ef99265d-0dc4-4dbe-b037-79dcaad77307@github.com>
Message-ID: <mnBR-fYOjbg0Sjd-8OdFnhYVCFuOvY-lXx59m6Ho2F0=.e434f482-5c1b-4b07-add7-755b0b9799f8@github.com>

On Thu, 28 Jan 2021 02:09:58 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> I found the register usage is less optimized for some shift operations.
>> For example, vshiftL_imm [1]/vshiftI_imm require dst != src.
>> But it's actually fine for the register allocator to assign dst == src.
>> 
>> Also, vshiftL [2]/vshiftI/vshiftS require dst != src.
>> But it's actually required for UseAVX==0 only.
>> For the most common cases (UseAVX > 0), it's fine to assign dst == src.
>> 
>> The fix splits vshiftS/vshiftI/vshiftL into UseAVX > 0 and UseAVX == 0 cases.
>> And just removes the unreasonable requirement for vshiftI_imm and vshiftL_imm. 
>> 
>> Testing:
>>   - jdk/incubator/vector/ on x64 with UseAVX=3/2/1/0, no regression
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L6058
>> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L6037
>
> Jie Fu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Recuce the binary size
>  - Revert changes

Looks fine to me.
@iwanowww please submit mach5 testing for this change before integration.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2257

From kvn at openjdk.java.net  Thu Jan 28 16:47:44 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 28 Jan 2021 16:47:44 GMT
Subject: RFR: 8260577: Unused code in AbstractCompiler after Shark
 compiler removal [v2]
In-Reply-To: <xLblrvZXfn89JYOukmOhzuxirNfnCxpunzZsME_XlGY=.d17dfd3c-3843-4aba-ba83-57de45a12455@github.com>
References: <CPa6az52TajrWcI_bwAFHcRRS-4srQNbc0EjakDpgHY=.33ad0d64-904d-455f-913d-51a4fd405bc3@github.com>
 <xLblrvZXfn89JYOukmOhzuxirNfnCxpunzZsME_XlGY=.d17dfd3c-3843-4aba-ba83-57de45a12455@github.com>
Message-ID: <Uj71c8_CR5FDGozMsJfUGw4luDjJOvXDiOc4BO7hmok=.24b8ce8d-5770-48b8-b667-6b5b24a84252@github.com>

On Thu, 28 Jan 2021 10:11:02 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> After removal of the Shark compiler with [JDK-8171853](https://bugs.openjdk.java.net/browse/JDK-8171853) in JDK 10, some methods in AbstractCompiler are unused.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed CICompileNatives and CICompileOSR

Both flags are not related to Shark. I use `CICompileOSR=false` very frequently during debugging to avoid C2 OSR compilations:
http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/062bd42c5e2b/src/share/vm/runtime/globals.hpp#l2403

Revert CICompileOSR back to platform independent and keep both flags.
I agree with removal of functions which always return `true`.

-------------

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2281

From xliu at openjdk.java.net  Thu Jan 28 17:52:57 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 28 Jan 2021 17:52:57 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v3]
In-Reply-To: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
Message-ID: <hDl459V0NTbM2qbDkzZZOchRyqet3eLIQzgWfTWDho0=.56773b72-1a67-42d0-9d42-4ed1eee0bf76@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 incrementally with one additional commit since the last revision:

  8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
  
  fix merge conflict.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2178/files
  - new: https://git.openjdk.java.net/jdk/pull/2178/files/7ed1ac83..8381ad3a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2178&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2178&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 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 smonteith at openjdk.java.net  Thu Jan 28 17:59:44 2021
From: smonteith at openjdk.java.net (Stuart Monteith)
Date: Thu, 28 Jan 2021 17:59:44 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v4]
In-Reply-To: <rdtmz-1qWqPh036NjaVt6BXeVZdHuIJOFCpnVIkoI4I=.e503ab3b-5259-40f6-b056-976d0efa5ae5@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <rdtmz-1qWqPh036NjaVt6BXeVZdHuIJOFCpnVIkoI4I=.e503ab3b-5259-40f6-b056-976d0efa5ae5@github.com>
Message-ID: <zBnzf7Me1OV3TVIDvrbNQrr-pxgFSeRcTASH6wNCXGs=.81d032d4-2503-47b1-8c48-651ecf35f7fa@github.com>

On Thu, 28 Jan 2021 12:53:03 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8260473
>> 
>> Function "PhaseVector::expand_vunbox_node" creates a LoadNode, but forgets to make the LoadNode to pass gc barriers.
>> 
>> 
>> Testing: all Vector API related tests have passed.
>
> ?? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change the directory & fix the include order

Looks good, but needs some editing.

test/hotspot/jtreg/compiler/vectorapi/VectorReshapeTest.java line 86:

> 84:         System.out.println("output: "+Arrays.toString(output));
> 85:         // Assert.assertEquals(expected, output);
> 86:         assert(expected.equals(output)); // SRDM

"SRDM" are my initials. You can remove this line and replace it with the uncommented line above.
I was structuring this to work outwith the jtreg framework.

test/hotspot/jtreg/compiler/vectorapi/VectorReshapeTest.java line 44:

> 42:  */
> 43: 
> 44: public class VectorReshapeTest {

This simply has this name as it is a cut-down version of test/jdk/jdk/incubator/vector/VectorReshapeTests.java
The problem was originally intermittent, but was narrowed somewhat down to what we have here. Perhaps this could be renamed?

test/hotspot/jtreg/compiler/vectorapi/VectorReshapeTest.java line 40:

> 38:  * @modules jdk.incubator.vector
> 39:  * @modules java.base/jdk.internal.vm.annotation
> 40:  * @run main/othervm -XX:CompileCommand=compileonly,jdk/incubator/vector/ByteVector.fromByteBuffer

-XX:CompileCommand=compileonly,jdk/incubator/vector/ByteVector.fromByteBuffer restricts the compilation to a single method for diagnostic purposes. The test runs much quicker without it, and still reproduces the issue.

test/hotspot/jtreg/compiler/vectorapi/VectorReshapeTest.java line 45:

> 43: 
> 44: public class VectorReshapeTest {
> 45:     static final int INVOC_COUNT = Integer.getInteger("jdk.incubator.vector.test.loop-iterations", 100);

The name "jdk.incubator.vector.test.loop-iterations" should probably be "jtreg.compiler.vectorapi.vectorreshapetest.loop-iterations".
In addition, it should be reset to "1000" to ensure the test is compiled and executed with a chance of GCing to occur.

-------------

Changes requested by smonteith (Author).

PR: https://git.openjdk.java.net/jdk/pull/2253

From xliu at openjdk.java.net  Thu Jan 28 18:06:42 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 28 Jan 2021 18:06:42 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set
In-Reply-To: <1lfc5MjMIFUx-Q19CkfKJvP4yYoM6B5APuRsvevpuk8=.3ba9c333-74b6-4ba4-bb3c-66c4583701fb@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
 <1lfc5MjMIFUx-Q19CkfKJvP4yYoM6B5APuRsvevpuk8=.3ba9c333-74b6-4ba4-bb3c-66c4583701fb@github.com>
Message-ID: <yiZVqonBxaefuevXsp6kflksoEkCBmSPOTyvL9jfDMA=.ea90d033-9471-48e9-b9c1-ff0a91b29861@github.com>

On Mon, 25 Jan 2021 09:25:22 GMT, Nils Eliasson <neliasso at openjdk.org> 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.

@neliasso  Thanks for reviewing this. 
Exactly.  The first reason is I am not familiar with oops/ codebase.  I guess some clients expect to see multiple lines. The second reason is that there are [many places](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/klass.cpp#L783). I am not sure I can clean them up completely.  

That's why I modify outputStream and give it a 'suppress_cr' mode.  May I ask hotspot-dev's advice?  /cc hotspot-dev

-------------

PR: https://git.openjdk.java.net/jdk/pull/2178

From kvn at openjdk.java.net  Thu Jan 28 18:58:48 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 28 Jan 2021 18:58:48 GMT
Subject: RFR: 8259584: SuperWord::fix_commutative_inputs checks in_bb(fin1)
 instead of in_bb(fin2)
Message-ID: <B5pCG3ww_WmUYcyh07r4nBGHlytgbNk4LbMPZ9nwFUg=.ad2fecf0-b012-4294-9373-4019ea0bf04d@github.com>

Fix typo. Note, this change does not affect product because this code is not executed after JDK-8251994 fix: 
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/superword.cpp#L519

-------------

Commit messages:
 - 8259584: SuperWord::fix_commutative_inputs checks in_bb(fin1) instead of in_bb(fin2)

Changes: https://git.openjdk.java.net/jdk/pull/2299/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2299&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259584
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2299.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2299/head:pull/2299

PR: https://git.openjdk.java.net/jdk/pull/2299

From shade at openjdk.java.net  Thu Jan 28 19:05:45 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 28 Jan 2021 19:05:45 GMT
Subject: RFR: 8259584: SuperWord::fix_commutative_inputs checks
 in_bb(fin1) instead of in_bb(fin2)
In-Reply-To: <B5pCG3ww_WmUYcyh07r4nBGHlytgbNk4LbMPZ9nwFUg=.ad2fecf0-b012-4294-9373-4019ea0bf04d@github.com>
References: <B5pCG3ww_WmUYcyh07r4nBGHlytgbNk4LbMPZ9nwFUg=.ad2fecf0-b012-4294-9373-4019ea0bf04d@github.com>
Message-ID: <fh3bHWXalTkVAqKRLWpY9EYYABLzll0b-MdcQAqZ-eM=.e2db554b-b78e-4ff0-9d27-58aaa3cc3a01@github.com>

On Thu, 28 Jan 2021 18:54:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Fix typo. Note, this change does not affect product because this code is not executed after JDK-8251994 fix: 
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/superword.cpp#L519

Looks fine to me, thanks.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2299

From redestad at openjdk.java.net  Thu Jan 28 19:26:47 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 28 Jan 2021 19:26:47 GMT
Subject: RFR: 8260605: Various java.lang.invoke cleanups
Message-ID: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>

- Remove unused code
- Inline and simplify the bootstrap method invocation code (remove pointless reboxing checks etc)
- Apply pattern matching to make some code more readable

-------------

Commit messages:
 - Avoid unnecessary reboxing checks, inline and simplify class/mt invokes
 - j.l.invoke cleanups

Changes: https://git.openjdk.java.net/jdk/pull/2300/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2300&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260605
  Stats: 269 lines in 14 files changed: 11 ins; 161 del; 97 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2300.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2300/head:pull/2300

PR: https://git.openjdk.java.net/jdk/pull/2300

From redestad at openjdk.java.net  Thu Jan 28 19:33:55 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 28 Jan 2021 19:33:55 GMT
Subject: RFR: 8260605: Various java.lang.invoke cleanups [v2]
In-Reply-To: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
References: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
Message-ID: <yeXcSnRpX3O3WYi7oIZ3Oh7icii6w5_49NNKUxivhks=.489b41c8-a282-4de1-96d8-8fecf762a7f0@github.com>

> - Remove unused code
> - Inline and simplify the bootstrap method invocation code (remove pointless reboxing checks etc)
> - Apply pattern matching to make some code more readable

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Missing outstanding changes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2300/files
  - new: https://git.openjdk.java.net/jdk/pull/2300/files/dc8b586d..68d3475a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2300&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2300&range=00-01

  Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2300.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2300/head:pull/2300

PR: https://git.openjdk.java.net/jdk/pull/2300

From iveresov at openjdk.java.net  Thu Jan 28 20:53:49 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Thu, 28 Jan 2021 20:53:49 GMT
Subject: Integrated: 8251462: Simplify compilation policy
In-Reply-To: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
References: <vgt4m4iOfKwGkExAroxDeZe3Fhjm6Wro-IadV1Ov1Lk=.2deeff66-5626-47e5-b15c-6f9c915613bf@github.com>
Message-ID: <yJErRCc6RGwYmNieAYmR3vPJn440_kpQ8z6xk3iK6wA=.ec6721d5-16c3-47c4-8572-cd6ca28e44b2@github.com>

On Thu, 7 Jan 2021 18:43:51 GMT, Igor Veresov <iveresov at openjdk.org> 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!

This pull request has now been integrated.

Changeset: 15196325
Author:    Igor Veresov <iveresov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/15196325
Stats:     5314 lines in 98 files changed: 1519 ins; 2994 del; 801 mod

8251462: Simplify compilation policy

Reviewed-by: cjplummer, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/1985

From vlivanov at openjdk.java.net  Thu Jan 28 21:39:43 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 28 Jan 2021 21:39:43 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v4]
In-Reply-To: <zBnzf7Me1OV3TVIDvrbNQrr-pxgFSeRcTASH6wNCXGs=.81d032d4-2503-47b1-8c48-651ecf35f7fa@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <rdtmz-1qWqPh036NjaVt6BXeVZdHuIJOFCpnVIkoI4I=.e503ab3b-5259-40f6-b056-976d0efa5ae5@github.com>
 <zBnzf7Me1OV3TVIDvrbNQrr-pxgFSeRcTASH6wNCXGs=.81d032d4-2503-47b1-8c48-651ecf35f7fa@github.com>
Message-ID: <iYbXJvVqZy-ZetNKrrbPTT0jLTCrj_DEjBKPv8ckHVs=.b2263634-62a4-40a4-9ab8-248e3081dbb4@github.com>

On Thu, 28 Jan 2021 17:56:39 GMT, Stuart Monteith <smonteith at openjdk.org> wrote:

>> ?? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change the directory & fix the include order
>
> Looks good, but needs some editing.

> ArrayCopyNode::load performs the same work as it does here in PhaseVector::optimize_vector_boxes .
> Is there a need to provide a similar function in PhaseVector or GraphKit?

My point is since PhaseVector effectively enters the parsing phase (by signaling about the possibility of post-parse inlining), technically I don't see why `GraphKit::access_load_at` won't work. But I need to spend more time looking into the details.

So far, I took a look at the review thread of 8212243 (which introduced `ArrayCopyNode::load`) and found the following discussion between Roland and Erik:
https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-October/030971.html
> ... Also it beats  me that this is strictly speaking a load barrier for loads performed in 
> arraycopy. Would it be possible to use something like access_load_at  instead? ...
...
GraphKit is a parse time only thing. So the existing gc interface
doesn't offer any way to add barriers once parsing is over. This code
runs after parsing in optimization phases.
...

Considering `PhaseVector::optimize_vector_boxes()` already has access to a usable `GraphKit` instance, it is possible that `GraphKit::access_load_at` will "just work".

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From iignatyev at openjdk.java.net  Thu Jan 28 21:51:58 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 28 Jan 2021 21:51:58 GMT
Subject: [jdk16] RFR: 8260608: add a regression test for 8260370
Message-ID: <ywgI8GORhLGXvT5pXu0J_bWB6UiT6y3-uAsLJT7qd04=.2a384e08-ec9f-4ddf-a659-736e8bbcc6be@github.com>

Hi all,

could you please review this small and trivial patch that adds a regression test for [8260370](https://bugs.openjdk.java.net/browse/JDK-8260370) ?

Thanks,
-- Igor

-------------

Commit messages:
 - 8260608: add a regression test for 8260370

Changes: https://git.openjdk.java.net/jdk16/pull/137/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=137&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260608
  Stats: 72 lines in 1 file changed: 72 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/137.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/137/head:pull/137

PR: https://git.openjdk.java.net/jdk16/pull/137

From kvn at openjdk.java.net  Thu Jan 28 22:09:51 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 28 Jan 2021 22:09:51 GMT
Subject: [jdk16] RFR: 8260608: add a regression test for 8260370
In-Reply-To: <ywgI8GORhLGXvT5pXu0J_bWB6UiT6y3-uAsLJT7qd04=.2a384e08-ec9f-4ddf-a659-736e8bbcc6be@github.com>
References: <ywgI8GORhLGXvT5pXu0J_bWB6UiT6y3-uAsLJT7qd04=.2a384e08-ec9f-4ddf-a659-736e8bbcc6be@github.com>
Message-ID: <XrmSFzXfzGoqNSbvjhVrAeAbXhRjSw83twRQedRFy4o=.4e5991a7-9c61-4220-b3f6-8073d5042048@github.com>

On Thu, 28 Jan 2021 21:46:54 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds a regression test for [8260370](https://bugs.openjdk.java.net/browse/JDK-8260370) ?
> 
> Thanks,
> -- Igor

test/hotspot/jtreg/compiler/loopopts/TestLoopLimitNodeElimination.java line 42:

> 40:     long b[] = new long[a];
> 41: 
> 42:     void c(String[] d) {

Please, don't use single latter for constants and method names. It is better to not use them for anything - all names should be meaningful.

Also you need to change RFE to Bug. the process only allows test bugs:
http://openjdk.java.net/jeps/3#rdp-2
`RDP2: P1?P5 doc/test bugs`

-------------

PR: https://git.openjdk.java.net/jdk16/pull/137

From iignatyev at openjdk.java.net  Thu Jan 28 22:13:47 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 28 Jan 2021 22:13:47 GMT
Subject: [jdk16] RFR: 8260608: add a regression test for 8260370
In-Reply-To: <XrmSFzXfzGoqNSbvjhVrAeAbXhRjSw83twRQedRFy4o=.4e5991a7-9c61-4220-b3f6-8073d5042048@github.com>
References: <ywgI8GORhLGXvT5pXu0J_bWB6UiT6y3-uAsLJT7qd04=.2a384e08-ec9f-4ddf-a659-736e8bbcc6be@github.com>
 <XrmSFzXfzGoqNSbvjhVrAeAbXhRjSw83twRQedRFy4o=.4e5991a7-9c61-4220-b3f6-8073d5042048@github.com>
Message-ID: <L4Xj54k0ktrqNHvvZdPhvHnqhDndVyXn32nNk9lKbBU=.534a7a9f-d960-42ea-aa44-0abd5fd64562@github.com>

On Thu, 28 Jan 2021 22:06:30 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this small and trivial patch that adds a regression test for [8260370](https://bugs.openjdk.java.net/browse/JDK-8260370) ?
>> 
>> Thanks,
>> -- Igor
>
> test/hotspot/jtreg/compiler/loopopts/TestLoopLimitNodeElimination.java line 42:
> 
>> 40:     long b[] = new long[a];
>> 41: 
>> 42:     void c(String[] d) {
> 
> Please, don't use single latter for constants and method names. It is better to not use them for anything - all names should be meaningful.
> 
> Also you need to change RFE to Bug. the process only allows test bugs:
> http://openjdk.java.net/jeps/3#rdp-2
> `RDP2: P1?P5 doc/test bugs`

Vladimir, there is nothing meaningful about these constants, methods, variables ? the whole test is randomly generated.

-------------

PR: https://git.openjdk.java.net/jdk16/pull/137

From jiefu at openjdk.java.net  Thu Jan 28 22:59:40 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 28 Jan 2021 22:59:40 GMT
Subject: RFR: 8260501: [Vector API] Improve register usage for shift
 operations on x86 [v2]
In-Reply-To: <mnBR-fYOjbg0Sjd-8OdFnhYVCFuOvY-lXx59m6Ho2F0=.e434f482-5c1b-4b07-add7-755b0b9799f8@github.com>
References: <eiKG7lnaASe7574tjTNKvcokiwA1mkp_c8rD6VK2iPI=.12a4a3c1-970f-4ce2-9d6c-1a0057a2f207@github.com>
 <KlokyrB2xpITspayhUgkmckPj8cB1M-jpkWfv1PSuAo=.ef99265d-0dc4-4dbe-b037-79dcaad77307@github.com>
 <mnBR-fYOjbg0Sjd-8OdFnhYVCFuOvY-lXx59m6Ho2F0=.e434f482-5c1b-4b07-add7-755b0b9799f8@github.com>
Message-ID: <9DkaMJLyY1JEVVs7D1KfIjVQaIGyW-esEISk4zIPNs8=.3395e43c-28e0-47bf-910b-4cb4fff78e9e@github.com>

On Thu, 28 Jan 2021 16:30:40 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Looks fine to me.
> @iwanowww please submit mach5 testing for this change before integration.

Thanks @vnkozlov for your review.

@iwanowww , please let me know if it's OK on mach5.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2257

From kvn at openjdk.java.net  Thu Jan 28 23:04:46 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 28 Jan 2021 23:04:46 GMT
Subject: [jdk16] RFR: 8260608: add a regression test for 8260370
In-Reply-To: <L4Xj54k0ktrqNHvvZdPhvHnqhDndVyXn32nNk9lKbBU=.534a7a9f-d960-42ea-aa44-0abd5fd64562@github.com>
References: <ywgI8GORhLGXvT5pXu0J_bWB6UiT6y3-uAsLJT7qd04=.2a384e08-ec9f-4ddf-a659-736e8bbcc6be@github.com>
 <XrmSFzXfzGoqNSbvjhVrAeAbXhRjSw83twRQedRFy4o=.4e5991a7-9c61-4220-b3f6-8073d5042048@github.com>
 <L4Xj54k0ktrqNHvvZdPhvHnqhDndVyXn32nNk9lKbBU=.534a7a9f-d960-42ea-aa44-0abd5fd64562@github.com>
Message-ID: <18ES9SshsIpwH4D-M1y3jgomZZ7RAm3U4lBgNJJgGJc=.48574e33-5995-4dcf-9775-3257881a9d1d@github.com>

On Thu, 28 Jan 2021 22:11:02 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/loopopts/TestLoopLimitNodeElimination.java line 42:
>> 
>>> 40:     long b[] = new long[a];
>>> 41: 
>>> 42:     void c(String[] d) {
>> 
>> Please, don't use single latter for constants and method names. It is better to not use them for anything - all names should be meaningful.
>> 
>> Also you need to change RFE to Bug. the process only allows test bugs:
>> http://openjdk.java.net/jeps/3#rdp-2
>> `RDP2: P1?P5 doc/test bugs`
>
> Vladimir, there is nothing meaningful about these constants, methods, variables ? the whole test is randomly generated.

Got it. But even then, you can at least rename 'c()' to 'test()' and 'a' to 'N'. And add comment that it is randomly generated to avoid complains later.

-------------

PR: https://git.openjdk.java.net/jdk16/pull/137

From github.com+25214855+casparcwang at openjdk.java.net  Fri Jan 29 02:19:07 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Fri, 29 Jan 2021 02:19:07 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v4]
In-Reply-To: <iIYn7GIJbme9tCGYr7b4fkiTiyq_UFOFj8TF8DKLDWE=.7705d465-d22f-4bee-ba6a-a36b4a69da2f@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <rdtmz-1qWqPh036NjaVt6BXeVZdHuIJOFCpnVIkoI4I=.e503ab3b-5259-40f6-b056-976d0efa5ae5@github.com>
 <iIYn7GIJbme9tCGYr7b4fkiTiyq_UFOFj8TF8DKLDWE=.7705d465-d22f-4bee-ba6a-a36b4a69da2f@github.com>
Message-ID: <2lCFUfFm21gM4ut27Uz_mYoh7GqajJFaDub5w2Y9WXo=.58895381-1f9c-4122-be83-36d3a2c3ffa3@github.com>

On Thu, 28 Jan 2021 14:47:50 GMT, Per Liden <pliden at openjdk.org> wrote:

>> ?? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change the directory & fix the include order
>
> test/hotspot/jtreg/compiler/vectorapi/VectorReshapeTest.java line 38:
> 
>> 36:  * @test
>> 37:  * @bug 8260473
>> 38:  * @modules jdk.incubator.vector
> 
> This test should have a `@requires vm.gc.Z` tag. That will make sure it's only executed on platforms where ZGC is supported (and that ZGC is included in the build).

done

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From github.com+25214855+casparcwang at openjdk.java.net  Fri Jan 29 02:19:06 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Fri, 29 Jan 2021 02:19:06 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v5]
In-Reply-To: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
Message-ID: <gK1Fp1gNb_e38sXPXLNnyT210FlZy8CAU2yjkuJuQTg=.7f24be14-4893-469d-945c-27ab97e9ed6f@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8260473
> 
> Function "PhaseVector::expand_vunbox_node" creates a LoadNode, but forgets to make the LoadNode to pass gc barriers.
> 
> 
> Testing: all Vector API related tests have passed.

?? has updated the pull request incrementally with one additional commit since the last revision:

  Several modification:
  
  1, require Z gc
  2, Use testng Assert
  3, Rename the test
  4, get the right INVOC_COUNT

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2253/files
  - new: https://git.openjdk.java.net/jdk/pull/2253/files/d52fd4c4..da06b0aa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2253&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2253&range=03-04

  Stats: 293 lines in 2 files changed: 162 ins; 131 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2253.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2253/head:pull/2253

PR: https://git.openjdk.java.net/jdk/pull/2253

From github.com+25214855+casparcwang at openjdk.java.net  Fri Jan 29 02:19:09 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Fri, 29 Jan 2021 02:19:09 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v4]
In-Reply-To: <zBnzf7Me1OV3TVIDvrbNQrr-pxgFSeRcTASH6wNCXGs=.81d032d4-2503-47b1-8c48-651ecf35f7fa@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <rdtmz-1qWqPh036NjaVt6BXeVZdHuIJOFCpnVIkoI4I=.e503ab3b-5259-40f6-b056-976d0efa5ae5@github.com>
 <zBnzf7Me1OV3TVIDvrbNQrr-pxgFSeRcTASH6wNCXGs=.81d032d4-2503-47b1-8c48-651ecf35f7fa@github.com>
Message-ID: <Me-fcQw-HzYI6OAi7MOMigwKTzn603WYm6yeVetz9Wc=.c6e9a6d5-9f13-4010-a037-124dda6bf530@github.com>

On Thu, 28 Jan 2021 17:09:16 GMT, Stuart Monteith <smonteith at openjdk.org> wrote:

>> ?? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change the directory & fix the include order
>
> test/hotspot/jtreg/compiler/vectorapi/VectorReshapeTest.java line 86:
> 
>> 84:         System.out.println("output: "+Arrays.toString(output));
>> 85:         // Assert.assertEquals(expected, output);
>> 86:         assert(expected.equals(output)); // SRDM
> 
> "SRDM" are my initials. You can remove this line and replace it with the uncommented line above.
> I was structuring this to work outwith the jtreg framework.

done

> test/hotspot/jtreg/compiler/vectorapi/VectorReshapeTest.java line 44:
> 
>> 42:  */
>> 43: 
>> 44: public class VectorReshapeTest {
> 
> This simply has this name as it is a cut-down version of test/jdk/jdk/incubator/vector/VectorReshapeTests.java
> The problem was originally intermittent, but was narrowed somewhat down to what we have here. Perhaps this could be renamed?

The test has changed to VectorRebracket128Test.java

> test/hotspot/jtreg/compiler/vectorapi/VectorReshapeTest.java line 40:
> 
>> 38:  * @modules jdk.incubator.vector
>> 39:  * @modules java.base/jdk.internal.vm.annotation
>> 40:  * @run main/othervm -XX:CompileCommand=compileonly,jdk/incubator/vector/ByteVector.fromByteBuffer
> 
> -XX:CompileCommand=compileonly,jdk/incubator/vector/ByteVector.fromByteBuffer restricts the compilation to a single method for diagnostic purposes. The test runs much quicker without it, and still reproduces the issue.

The test is changed to 'testng' mode, remove option compileonly will make the test pass the assert in jtreg test framework. But add the option will make it fail the assert.  So the option is left unchanged.

> test/hotspot/jtreg/compiler/vectorapi/VectorReshapeTest.java line 45:
> 
>> 43: 
>> 44: public class VectorReshapeTest {
>> 45:     static final int INVOC_COUNT = Integer.getInteger("jdk.incubator.vector.test.loop-iterations", 100);
> 
> The name "jdk.incubator.vector.test.loop-iterations" should probably be "jtreg.compiler.vectorapi.vectorreshapetest.loop-iterations".
> In addition, it should be reset to "1000" to ensure the test is compiled and executed with a chance of GCing to occur.

done

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From github.com+25214855+casparcwang at openjdk.java.net  Fri Jan 29 02:27:01 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Fri, 29 Jan 2021 02:27:01 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v6]
In-Reply-To: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
Message-ID: <5j0GBfBaAXcZboEk5DKBBIsbV2U77X7zQSxjwhmLp7c=.b6ee34c1-15f7-4034-b796-ead45f91f230@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8260473
> 
> Function "PhaseVector::expand_vunbox_node" creates a LoadNode, but forgets to make the LoadNode to pass gc barriers.
> 
> 
> Testing: all Vector API related tests have passed.

?? has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundent empty line & import force inline

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2253/files
  - new: https://git.openjdk.java.net/jdk/pull/2253/files/da06b0aa..db0e596d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2253&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2253&range=04-05

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2253.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2253/head:pull/2253

PR: https://git.openjdk.java.net/jdk/pull/2253

From iignatyev at openjdk.java.net  Fri Jan 29 03:12:03 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 29 Jan 2021 03:12:03 GMT
Subject: [jdk16] RFR: 8260608: add a regression test for 8260370 [v2]
In-Reply-To: <ywgI8GORhLGXvT5pXu0J_bWB6UiT6y3-uAsLJT7qd04=.2a384e08-ec9f-4ddf-a659-736e8bbcc6be@github.com>
References: <ywgI8GORhLGXvT5pXu0J_bWB6UiT6y3-uAsLJT7qd04=.2a384e08-ec9f-4ddf-a659-736e8bbcc6be@github.com>
Message-ID: <MSc4e99z-_AjKsgzE9cX0XC68xHdp5DpiUDCM7P6SMI=.5f5f2cd5-894b-450f-a454-9c4f5a770818@github.com>

> Hi all,
> 
> could you please review this small and trivial patch that adds a regression test for [8260370](https://bugs.openjdk.java.net/browse/JDK-8260370) ?
> 
> Thanks,
> -- Igor

Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:

  refactored the test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/137/files
  - new: https://git.openjdk.java.net/jdk16/pull/137/files/5293f0e0..58b19fd7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=137&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=137&range=00-01

  Stats: 26 lines in 1 file changed: 4 ins; 1 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/137.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/137/head:pull/137

PR: https://git.openjdk.java.net/jdk16/pull/137

From xgong at openjdk.java.net  Fri Jan 29 03:43:41 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 29 Jan 2021 03:43:41 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v2]
In-Reply-To: <OpyYSSPOTMkAvQlTeYSIIOdu2LIG9gMm9z0akDo3d94=.61b8c03a-355f-4f0d-b625-1edcaefc7c33@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <OpyYSSPOTMkAvQlTeYSIIOdu2LIG9gMm9z0akDo3d94=.61b8c03a-355f-4f0d-b625-1edcaefc7c33@github.com>
Message-ID: <GBNu61Wf0eNcbofkfLTZUrmcgxxp35rDancHzSp_feU=.707cd2a5-d3bb-4fc1-98f8-f8192306497d@github.com>

On Thu, 28 Jan 2021 12:19:07 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8260473
>> 
>> Function "PhaseVector::expand_vunbox_node" creates a LoadNode, but forgets to make the LoadNode to pass gc barriers.
>> 
>> 
>> Testing: all Vector API related tests have passed.
>
> ?? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add the regression test

test/jdk/jdk/incubator/vector/VectorReshapeTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved.

The Copyright should be " Copyright (c) 2021," since it's a new file added in 2021.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From kvn at openjdk.java.net  Fri Jan 29 03:49:46 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 29 Jan 2021 03:49:46 GMT
Subject: [jdk16] RFR: 8260608: add a regression test for 8260370 [v2]
In-Reply-To: <MSc4e99z-_AjKsgzE9cX0XC68xHdp5DpiUDCM7P6SMI=.5f5f2cd5-894b-450f-a454-9c4f5a770818@github.com>
References: <ywgI8GORhLGXvT5pXu0J_bWB6UiT6y3-uAsLJT7qd04=.2a384e08-ec9f-4ddf-a659-736e8bbcc6be@github.com>
 <MSc4e99z-_AjKsgzE9cX0XC68xHdp5DpiUDCM7P6SMI=.5f5f2cd5-894b-450f-a454-9c4f5a770818@github.com>
Message-ID: <xCmfdHacsxPhuFBIOqOsCVRn4ti0XbPrXlMpzmX2-1c=.595ee9d3-3d17-4e2a-8c3e-c2bdb37667d8@github.com>

On Fri, 29 Jan 2021 03:12:03 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this small and trivial patch that adds a regression test for [8260370](https://bugs.openjdk.java.net/browse/JDK-8260370) ?
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactored the test

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/137

From github.com+25214855+casparcwang at openjdk.java.net  Fri Jan 29 04:05:42 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Fri, 29 Jan 2021 04:05:42 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v4]
In-Reply-To: <iYbXJvVqZy-ZetNKrrbPTT0jLTCrj_DEjBKPv8ckHVs=.b2263634-62a4-40a4-9ab8-248e3081dbb4@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <rdtmz-1qWqPh036NjaVt6BXeVZdHuIJOFCpnVIkoI4I=.e503ab3b-5259-40f6-b056-976d0efa5ae5@github.com>
 <zBnzf7Me1OV3TVIDvrbNQrr-pxgFSeRcTASH6wNCXGs=.81d032d4-2503-47b1-8c48-651ecf35f7fa@github.com>
 <iYbXJvVqZy-ZetNKrrbPTT0jLTCrj_DEjBKPv8ckHVs=.b2263634-62a4-40a4-9ab8-248e3081dbb4@github.com>
Message-ID: <Sm5e0TdFCKQztHlJGCs6Tsxc5AEpv711D_XBy_iLDs4=.940eabf1-69e9-4c67-a758-55f564f102dd@github.com>

On Thu, 28 Jan 2021 21:36:39 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> > ArrayCopyNode::load performs the same work as it does here in PhaseVector::optimize_vector_boxes .
> > Is there a need to provide a similar function in PhaseVector or GraphKit?
> 
> My point is since PhaseVector effectively enters the parsing phase (by signaling about the possibility of post-parse inlining), technically I don't see why `GraphKit::access_load_at` won't work. But I need to spend more time looking into the details.
> 
> So far, I took a look at the review thread of 8212243 (which introduced `ArrayCopyNode::load`) and found the following discussion between Roland and Erik:
> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-October/030971.html
> 
> ```
> > ... Also it beats  me that this is strictly speaking a load barrier for loads performed in 
> > arraycopy. Would it be possible to use something like access_load_at  instead? ...
> ...
> GraphKit is a parse time only thing. So the existing gc interface
> doesn't offer any way to add barriers once parsing is over. This code
> runs after parsing in optimization phases.
> ...
> ```
> 
> Considering `PhaseVector::optimize_vector_boxes()` already has access to a usable `GraphKit` instance, it is possible that `GraphKit::access_load_at` will "just work".

`kit.access_load_at` can be called here and make the test pass, but will lead to another test(test/hotspot/jtreg/compiler/vectorapi/VectorReinterpretTest.java) fail, I'm trying to find out why.

diff --git a/src/hotspot/share/opto/vector.cpp b/src/hotspot/share/opto/vector.cpp
index 671083e..69c00c5 100644
--- a/src/hotspot/share/opto/vector.cpp
+++ b/src/hotspot/share/opto/vector.cpp
@@ -414,17 +414,12 @@ void PhaseVector::expand_vunbox_node(VectorUnboxNode* vec_unbox) {
 
     Node* mem = vec_unbox->mem();
     Node* ctrl = vec_unbox->in(0);
-    Node* vec_field_ld;
-    {
-      DecoratorSet decorators = C2_READ_ACCESS | C2_CONTROL_DEPENDENT_LOAD | IN_HEAP;
-      C2AccessValuePtr addr(vec_adr, vec_adr->bottom_type()->is_ptr());
-      MergeMemNode* local_mem = MergeMemNode::make(mem);
-      gvn.record_for_igvn(local_mem);
-      BarrierSetC2* bs = BarrierSet::barrier_set()->barrier_set_c2();
-      C2OptAccess access(gvn, ctrl, local_mem, decorators, T_OBJECT, obj, addr);
-      const Type* type = TypeOopPtr::make_from_klass(field->type()->as_klass());
-      vec_field_ld = bs->load_at(access, type);
-    }
+    Node* vec_field_ld = kit.access_load_at(obj,
+                                            vec_adr,
+                                            vec_adr->bottom_type()->is_ptr(),
+                                            TypeOopPtr::make_from_klass(field->type()->as_klass()),
+                                            T_OBJECT,
+                                            C2_READ_ACCESS | C2_CONTROL_DEPENDENT_LOAD | IN_HEAP);
 
     // For proper aliasing, attach concrete payload type.
     ciKlass* payload_klass = ciTypeArrayKlass::make(bt);

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From iignatyev at openjdk.java.net  Fri Jan 29 04:09:51 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 29 Jan 2021 04:09:51 GMT
Subject: [jdk16] RFR: 8260608: add a regression test for 8260370 [v2]
In-Reply-To: <xCmfdHacsxPhuFBIOqOsCVRn4ti0XbPrXlMpzmX2-1c=.595ee9d3-3d17-4e2a-8c3e-c2bdb37667d8@github.com>
References: <ywgI8GORhLGXvT5pXu0J_bWB6UiT6y3-uAsLJT7qd04=.2a384e08-ec9f-4ddf-a659-736e8bbcc6be@github.com>
 <MSc4e99z-_AjKsgzE9cX0XC68xHdp5DpiUDCM7P6SMI=.5f5f2cd5-894b-450f-a454-9c4f5a770818@github.com>
 <xCmfdHacsxPhuFBIOqOsCVRn4ti0XbPrXlMpzmX2-1c=.595ee9d3-3d17-4e2a-8c3e-c2bdb37667d8@github.com>
Message-ID: <ra4XtAndF65NlkUhF9UMilWCJAks1CkqecLBFIiFzDo=.44f73920-50c9-42c7-920a-6c3e7757a46a@github.com>

On Fri, 29 Jan 2021 03:47:25 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refactored the test
>
> Good.

thanks, Vladimir.

-------------

PR: https://git.openjdk.java.net/jdk16/pull/137

From iignatyev at openjdk.java.net  Fri Jan 29 04:09:54 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 29 Jan 2021 04:09:54 GMT
Subject: [jdk16] Integrated: 8260608: add a regression test for 8260370
In-Reply-To: <ywgI8GORhLGXvT5pXu0J_bWB6UiT6y3-uAsLJT7qd04=.2a384e08-ec9f-4ddf-a659-736e8bbcc6be@github.com>
References: <ywgI8GORhLGXvT5pXu0J_bWB6UiT6y3-uAsLJT7qd04=.2a384e08-ec9f-4ddf-a659-736e8bbcc6be@github.com>
Message-ID: <jAUdOfjNKIM-dK86HZW1be2lkhJSGl3Hw0CVamWYuk8=.fe3b1b04-6f81-42ed-916a-b551f7caa518@github.com>

On Thu, 28 Jan 2021 21:46:54 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds a regression test for [8260370](https://bugs.openjdk.java.net/browse/JDK-8260370) ?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 8ffdbceb
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/8ffdbceb
Stats:     75 lines in 1 file changed: 75 ins; 0 del; 0 mod

8260608: add a regression test for 8260370

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk16/pull/137

From github.com+25214855+casparcwang at openjdk.java.net  Fri Jan 29 04:14:03 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Fri, 29 Jan 2021 04:14:03 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v7]
In-Reply-To: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
Message-ID: <mPKKzESQWrPm8Sn-2K_QJibH4_59x5k5c550SMh0sws=.0ed12218-71b3-49e8-a879-6d58f12046d3@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8260473
> 
> Function "PhaseVector::expand_vunbox_node" creates a LoadNode, but forgets to make the LoadNode to pass gc barriers.
> 
> 
> Testing: all Vector API related tests have passed.

?? has updated the pull request incrementally with one additional commit since the last revision:

  Fix the copyright date

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2253/files
  - new: https://git.openjdk.java.net/jdk/pull/2253/files/db0e596d..33039344

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2253&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2253&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2253.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2253/head:pull/2253

PR: https://git.openjdk.java.net/jdk/pull/2253

From github.com+25214855+casparcwang at openjdk.java.net  Fri Jan 29 04:14:04 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Fri, 29 Jan 2021 04:14:04 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v2]
In-Reply-To: <GBNu61Wf0eNcbofkfLTZUrmcgxxp35rDancHzSp_feU=.707cd2a5-d3bb-4fc1-98f8-f8192306497d@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <OpyYSSPOTMkAvQlTeYSIIOdu2LIG9gMm9z0akDo3d94=.61b8c03a-355f-4f0d-b625-1edcaefc7c33@github.com>
 <GBNu61Wf0eNcbofkfLTZUrmcgxxp35rDancHzSp_feU=.707cd2a5-d3bb-4fc1-98f8-f8192306497d@github.com>
Message-ID: <4LoMwq9yY7iVtvAEGd3f-gdXt2buzKF2WpyY6YWUGBE=.665be558-2df1-422c-b9a1-ae4f0677f92f@github.com>

On Fri, 29 Jan 2021 03:40:22 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> The Copyright should be " Copyright (c) 2021," since it's a new file added in 2021.

done

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From github.com+25214855+casparcwang at openjdk.java.net  Fri Jan 29 06:51:43 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Fri, 29 Jan 2021 06:51:43 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v4]
In-Reply-To: <Sm5e0TdFCKQztHlJGCs6Tsxc5AEpv711D_XBy_iLDs4=.940eabf1-69e9-4c67-a758-55f564f102dd@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <rdtmz-1qWqPh036NjaVt6BXeVZdHuIJOFCpnVIkoI4I=.e503ab3b-5259-40f6-b056-976d0efa5ae5@github.com>
 <zBnzf7Me1OV3TVIDvrbNQrr-pxgFSeRcTASH6wNCXGs=.81d032d4-2503-47b1-8c48-651ecf35f7fa@github.com>
 <iYbXJvVqZy-ZetNKrrbPTT0jLTCrj_DEjBKPv8ckHVs=.b2263634-62a4-40a4-9ab8-248e3081dbb4@github.com>
 <Sm5e0TdFCKQztHlJGCs6Tsxc5AEpv711D_XBy_iLDs4=.940eabf1-69e9-4c67-a758-55f564f102dd@github.com>
Message-ID: <j3eZ95EoTA292mgew_cghhGuaFTfJW0J5Fon27G2ibQ=.fa233153-a19e-4b28-869a-2299786178eb@github.com>

On Fri, 29 Jan 2021 04:02:34 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

> > ArrayCopyNode::load performs the same work as it does here in PhaseVector::optimize_vector_boxes .
> > Is there a need to provide a similar function in PhaseVector or GraphKit?
> 
> My point is since PhaseVector effectively enters the parsing phase (by signaling about the possibility of post-parse inlining), technically I don't see why `GraphKit::access_load_at` won't work. But I need to spend more time looking into the details.
> 
> So far, I took a look at the review thread of 8212243 (which introduced `ArrayCopyNode::load`) and found the following discussion between Roland and Erik:
> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-October/030971.html
> 
> ```
> > ... Also it beats  me that this is strictly speaking a load barrier for loads performed in 
> > arraycopy. Would it be possible to use something like access_load_at  instead? ...
> ...
> GraphKit is a parse time only thing. So the existing gc interface
> doesn't offer any way to add barriers once parsing is over. This code
> runs after parsing in optimization phases.
> ...
> ```
> 
> Considering `PhaseVector::optimize_vector_boxes()` already has access to a usable `GraphKit` instance, it is possible that `GraphKit::access_load_at` will "just work".

As far as I can see, during the parse phase, GraphKit contains the jvm state info which can be used to get the control and memory for creating new nodes. But during optimization, the jvm state info may be missing like the situation in `PhaseVector::optimize_vector_boxes` or Macro Expansion. So it should use C2OptAccess to create the Load Node directly by providing control and memory nodes.

I think a similar api like `GraphKit::access_load_at ` should be provided for usage during optimization stages,  but where should the API be placed? GraphKit or PhaseIterGVN or somewhere else?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From thartmann at openjdk.java.net  Fri Jan 29 07:30:00 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 29 Jan 2021 07:30:00 GMT
Subject: RFR: 8260577: Unused code in AbstractCompiler after Shark
 compiler removal [v3]
In-Reply-To: <CPa6az52TajrWcI_bwAFHcRRS-4srQNbc0EjakDpgHY=.33ad0d64-904d-455f-913d-51a4fd405bc3@github.com>
References: <CPa6az52TajrWcI_bwAFHcRRS-4srQNbc0EjakDpgHY=.33ad0d64-904d-455f-913d-51a4fd405bc3@github.com>
Message-ID: <s7UfO16vOyl_f08N2yiUwQ31eNj3l3TAAzcI1q_WXAg=.143764f1-8273-4c38-8b76-5e8bf9445c0a@github.com>

> After removal of the Shark compiler with [JDK-8171853](https://bugs.openjdk.java.net/browse/JDK-8171853) in JDK 10, some methods in AbstractCompiler are unused.
> 
> Thanks,
> Tobias

Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Removed CICompileNatives and CICompileOSR"
  
  This reverts commit a95c358687495ee1ed701cd10d48a3a9c6a45f26.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2281/files
  - new: https://git.openjdk.java.net/jdk/pull/2281/files/a95c3586..42c487e1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2281&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2281&range=01-02

  Stats: 36 lines in 14 files changed: 33 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2281.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2281/head:pull/2281

PR: https://git.openjdk.java.net/jdk/pull/2281

From thartmann at openjdk.java.net  Fri Jan 29 07:30:01 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 29 Jan 2021 07:30:01 GMT
Subject: RFR: 8260577: Unused code in AbstractCompiler after Shark
 compiler removal [v2]
In-Reply-To: <Uj71c8_CR5FDGozMsJfUGw4luDjJOvXDiOc4BO7hmok=.24b8ce8d-5770-48b8-b667-6b5b24a84252@github.com>
References: <CPa6az52TajrWcI_bwAFHcRRS-4srQNbc0EjakDpgHY=.33ad0d64-904d-455f-913d-51a4fd405bc3@github.com>
 <xLblrvZXfn89JYOukmOhzuxirNfnCxpunzZsME_XlGY=.d17dfd3c-3843-4aba-ba83-57de45a12455@github.com>
 <Uj71c8_CR5FDGozMsJfUGw4luDjJOvXDiOc4BO7hmok=.24b8ce8d-5770-48b8-b667-6b5b24a84252@github.com>
Message-ID: <bOd9wI25JnERq07fnxoht8SrMnkdYSTafj3gJjrx8gA=.141580d7-0373-4816-a1ff-82d49f8aea05@github.com>

On Thu, 28 Jan 2021 16:44:28 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I use CICompileOSR=false very frequently during debugging to avoid C2 OSR compilations

Okay but it also disables C1 OSR compilations, right? I've never used that flag and thought it's semantically equivalent to `UseOnStackReplacement`. I'll revert the latest changes then.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2281

From whuang at openjdk.java.net  Fri Jan 29 08:10:51 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Fri, 29 Jan 2021 08:10:51 GMT
Subject: [jdk16] Integrated: 8260339: JVM crashes when executing
 PhaseIdealLoop::match_fill_loop
In-Reply-To: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
References: <YpzzQs3oxGZYXBtVzmye3pIbUsE-_ate-QLyNjxwVUc=.a53704e9-5475-4459-aab1-9e7063742f94@github.com>
Message-ID: <iBFW5AEaucGfGitIUDUPJrBD1Tv-mZR-K2DtSSMctw0=.b4fd947f-5760-4f34-ac01-38be8e1e861d@github.com>

On Tue, 26 Jan 2021 02:01:00 GMT, Wang Huang <whuang at openjdk.org> wrote:

> The reason is :
> 
>   BasicType t = store->as_Mem()->memory_type();
>   const char* fill_name;
>   if (msg == NULL &&
>       StubRoutines::select_fill_function(t, false, fill_name) == NULL) {
>     msg = "unsupported store";
>     msg_node = store;
>   }
> 
> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here.
> 
> I add a new case here to avoid mistake:
>   case T_NARROWOOP:
>   case T_NARROWKLASS:
>   case T_ADDRESS:
> +  case T_VOID:
>     // Currently unsupported
>     return NULL;

This pull request has now been integrated.

Changeset: a117e115
Author:    Wang Huang <whuang at openjdk.org>
Committer: Nils Eliasson <neliasso at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/a117e115
Stats:     82 lines in 2 files changed: 82 ins; 0 del; 0 mod

8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop

Co-authored-by: He Xuejin <hexuejin2 at huawei.com>
Reviewed-by: neliasso, kvn, iignatyev

-------------

PR: https://git.openjdk.java.net/jdk16/pull/132

From eosterlund at openjdk.java.net  Fri Jan 29 08:26:42 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 29 Jan 2021 08:26:42 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v4]
In-Reply-To: <j3eZ95EoTA292mgew_cghhGuaFTfJW0J5Fon27G2ibQ=.fa233153-a19e-4b28-869a-2299786178eb@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <rdtmz-1qWqPh036NjaVt6BXeVZdHuIJOFCpnVIkoI4I=.e503ab3b-5259-40f6-b056-976d0efa5ae5@github.com>
 <zBnzf7Me1OV3TVIDvrbNQrr-pxgFSeRcTASH6wNCXGs=.81d032d4-2503-47b1-8c48-651ecf35f7fa@github.com>
 <iYbXJvVqZy-ZetNKrrbPTT0jLTCrj_DEjBKPv8ckHVs=.b2263634-62a4-40a4-9ab8-248e3081dbb4@github.com>
 <Sm5e0TdFCKQztHlJGCs6Tsxc5AEpv711D_XBy_iLDs4=.940eabf1-69e9-4c67-a758-55f564f102dd@github.com>
 <j3eZ95EoTA292mgew_cghhGuaFTfJW0J5Fon27G2ibQ=.fa233153-a19e-4b28-869a-2299786178eb@github.com>
Message-ID: <6nZPJh_IZbeLrS2D1lrwq7NIIry0zGQ8EzAXD6fkSrE=.4b476693-5877-434e-9e97-b26f73870e33@github.com>

On Fri, 29 Jan 2021 06:48:36 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

> Considering `PhaseVector::optimize_vector_boxes()` already has access to a usable `GraphKit` instance, it is possible that `GraphKit::access_load_at` will "just work".

The main thing to make sure you get right, is the aliasing. I'm not sure that will work right after parsing, the way it works now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From github.com+10482586+therealeliu at openjdk.java.net  Fri Jan 29 08:35:40 2021
From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu)
Date: Fri, 29 Jan 2021 08:35:40 GMT
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value
In-Reply-To: <WDQ0yZR8gbP6aLt1qOEIMsSOrwiSMdS4V8l4pi4RBmc=.b201fce0-ed3e-4319-b96b-9651bd4ecdd7@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <WDQ0yZR8gbP6aLt1qOEIMsSOrwiSMdS4V8l4pi4RBmc=.b201fce0-ed3e-4319-b96b-9651bd4ecdd7@github.com>
Message-ID: <KxrCbTo3Or4kTUEau7IYHc0FUkI2Sa6a8hPzk8mjLME=.00f5dd6f-ed0d-4298-80d6-baeae8b66490@github.com>

On Thu, 28 Jan 2021 14:26:32 GMT, Andrew Haley <aph at openjdk.org> 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
>
> All that remains to do is the benchmarks.

I benchmarked on 7 platforms with jmh test[1], most of them were hard to see any performance changes. On one platform the performance become bad, and seems a little unstable.

Before:
Benchmark                Mode  Cnt    Score   Error  Units
Rotation.addRotateRight  avgt   15  270.080 ? 0.630  ns/op
Rotation.andRotateRight  avgt   15  269.000 ? 0.226  ns/op
Rotation.bicRotateRight  avgt   15  269.269 ? 0.769  ns/op
Rotation.eonRotateRight  avgt   15  269.456 ? 0.056  ns/op
Rotation.ornRotateRight  avgt   15  269.681 ? 1.028  ns/op
Rotation.xorRotateRight  avgt   15  270.953 ? 2.764  ns/op
After:
Benchmark                Mode  Cnt    Score    Error  Units
Rotation.addRotateRight  avgt   15  399.995 ? 10.702  ns/op
Rotation.andRotateRight  avgt   15  399.517 ?  7.933  ns/op
Rotation.bicRotateRight  avgt   15  396.602 ?  2.038  ns/op
Rotation.eonRotateRight  avgt   15  401.978 ? 17.371  ns/op
Rotation.ornRotateRight  avgt   15  431.052 ? 73.711  ns/op
Rotation.xorRotateRight  avgt   15  410.447 ? 42.929  ns/op
------------------
[1] http://cr.openjdk.java.net/~xgong/rfr/8256438/Rotation.java

-------------

PR: https://git.openjdk.java.net/jdk/pull/1858

From aph at redhat.com  Fri Jan 29 10:11:41 2021
From: aph at redhat.com (Andrew Haley)
Date: Fri, 29 Jan 2021 10:11:41 +0000
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value
In-Reply-To: <KxrCbTo3Or4kTUEau7IYHc0FUkI2Sa6a8hPzk8mjLME=.00f5dd6f-ed0d-4298-80d6-baeae8b66490@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <WDQ0yZR8gbP6aLt1qOEIMsSOrwiSMdS4V8l4pi4RBmc=.b201fce0-ed3e-4319-b96b-9651bd4ecdd7@github.com>
 <KxrCbTo3Or4kTUEau7IYHc0FUkI2Sa6a8hPzk8mjLME=.00f5dd6f-ed0d-4298-80d6-baeae8b66490@github.com>
Message-ID: <813ca59c-59a8-7fca-7566-0472017681ab@redhat.com>

On 1/29/21 8:35 AM, Eric Liu wrote:
> I benchmarked on 7 platforms with jmh test[1], most of them were hard to see any performance changes. On one platform the performance become bad, and seems a little unstable.

Wow. I'll have to look at this.

In theory we prefer combined instructions because it should reduce code
size. However, we can't escape the possibility that on some implementations
combined instructions might cause pipeline stalls.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From duke at openjdk.java.net  Fri Jan 29 14:11:46 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 29 Jan 2021 14:11:46 GMT
Subject: Withdrawn: 8238812: assert(false) failed: bad AD file
In-Reply-To: <1EX-Ex8dvIp6djNy9GKWdGjhwDEDj4yrlh0Dr8dleMs=.043075af-3e8e-49d5-8dad-acde01a18bc6@github.com>
References: <1EX-Ex8dvIp6djNy9GKWdGjhwDEDj4yrlh0Dr8dleMs=.043075af-3e8e-49d5-8dad-acde01a18bc6@github.com>
Message-ID: <9YfxofWqylrffF6Jk3XCANM4pRUn_hsYDDyCyjfwqYc=.6c00423f-31ae-4668-8d8d-5520ccdb926b@github.com>

On Wed, 2 Dec 2020 14:29:35 GMT, Rahul Raghavan <rraghavan at openjdk.org> wrote:

> Request help to review this 8238812 fix.
> 
> <JBS> https://bugs.openjdk.java.net/browse/JDK-8238812
> 
> Found the root cause of the problem as that the following type 
> two If checks are not folded into one for the sample test:
> 
>  170 ConI === 0 [[ 171 ]] #int:31
>  171 CmpI === _ 144 170 [[ 172 179 ]]
>  172 Bool === _ 171 [[ 173 ]] [ne]
> 
>  173 If === 158 172 [[ 176 177 ]]
>  176 IfFalse === 173 [[ 168 ]] #0
>  177 IfTrue === 173 [[ 180 ]] #1
>  179 Bool === _ 171 [[ 180 ]] [lt]
> 
>  180 If === 177 179 [[ 181 182 ]]
>  181 IfTrue === 180 [[ 168 ]] #1
>  182 IfFalse === 180 [[ 218 ]] #0
> 
> Where 144 is the value and the ifs check for:
> value != 31
> value < 31
> 
> Now if we reach 182 IfFalse, the following holds:
>    value != 31 && !(value < 31)
> => value != 31 && value >= 31
> => value > 31
> 
> But the type of value (144) becomes #int:16..31 :
>  140 ConI === 0 [[ 141 ]] #int:2
>  135 Phi === 534 481 528 [[ ... ]] #int:1..4 #tripcount
>  141 LShiftI === _ 135 140 [[ 142 ]] #int:4..16
>  143 ConI === 0 [[ 144 ]] #int:11
>  142 AddI === _ 141 135 [[ 144 500 485 ]] #int:5..20
>  144 AddI === _ 142 143 [[ ... ]] #int:16..31
> 
> And that means that value > 31 is always false and should be folded.
> The root cause of the bug is that this does not happen.
> Understood that the fix by Tobias for JDK-8236721 should optimize exactly above type cases
> https://hg.openjdk.java.net/jdk/jdk/rev/9c53fdf6ba63
> 
> Found the IfNode::fold_compares optmization (and 8236721 related changes by Tobias)
> is not called for 180-If, after the type of 144-AddI is set to #int:16..31.
> because the _worklist is not correctly updated!
> 
> Proposed changes helped to add the required If node to _worklist (after the correct type setting of related value)
> and with this change no failure due to existing fold_compares optimization happening later on.
> Sample test passed and found no issues with various tier testing.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1563

From rcastanedalo at openjdk.java.net  Fri Jan 29 14:11:52 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 29 Jan 2021 14:11:52 GMT
Subject: RFR: 8260581: IGV: enhance node search
Message-ID: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>

Apply several enhancements to the quick node search functionality: 

- Allow users to search by node id or name by default, instead of name only.
- Show partial matches when searching for a specific property (e.g. so that searching "type=con" lists all "control"-type nodes).
- Avoid showing the "All _N_ matching nodes" entry if there is a single match, or the user is searching a numeric value.
- Rank matches so that full matches are listed first, followed by matches at the beginning of the partially matched value, followed by the rest of matches in increasing size of the partially matched value. For example, searching "5" on a set of nodes with labels {"5 AddI", "25 AddL", "253 AddL", "554 MulI"} should list the matches as follows:
    1. **5** AddI
    2. **5**54 MulI
    3. 2**5** AddL
    4. 2**5**3 AddL

As an illustration of some of these enhancements, this screenshot shows the behavior of the quick node search functionality before the changes:

![search-before](https://user-images.githubusercontent.com/8792647/106283438-374ba500-6242-11eb-8ef4-d18117eabcbb.png)

and after:

![search-after](https://user-images.githubusercontent.com/8792647/106282880-7e856600-6241-11eb-8cb5-48fae5582cc2.png)


Tested manually on small and large (~10000 nodes) graphs. Thanks to Christian Hagedorn for feedback on several iterations of the enhancements.

As part of the review, please evaluate not just the code changes but also the usability.

-------------

Commit messages:
 - Avoid registering search results needlessly
 - Revert "Make it possible to disable 'Recent Searches'"
 - Make it possible to disable 'Recent Searches'
 - Rank quick search results
 - Show 'All N matching nodes' entry only if relevant
 - List suggestions for partial property matches as well
 - Update copyright headers
 - 8260581: IGV: search on node labels by default instead of name only

Changes: https://git.openjdk.java.net/jdk/pull/2285/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2285&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260581
  Stats: 79 lines in 3 files changed: 55 ins; 5 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2285.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2285/head:pull/2285

PR: https://git.openjdk.java.net/jdk/pull/2285

From rcastanedalo at openjdk.java.net  Fri Jan 29 14:11:52 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 29 Jan 2021 14:11:52 GMT
Subject: RFR: 8260581: IGV: enhance node search
In-Reply-To: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>
References: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>
Message-ID: <3-6WXHFVDEcEAeOq6bHUVJ_1bSJHxLQnLOCyUzlo3Kg=.eb3809b2-b85c-4fa9-8de8-edab0f145a07@github.com>

On Thu, 28 Jan 2021 11:07:38 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> Apply several enhancements to the quick node search functionality: 
> 
> - Allow users to search by node id or name by default, instead of name only.
> - Show partial matches when searching for a specific property (e.g. so that searching "type=con" lists all "control"-type nodes).
> - Avoid showing the "All _N_ matching nodes" entry if there is a single match, or the user is searching a numeric value.
> - Rank matches so that full matches are listed first, followed by matches at the beginning of the partially matched value, followed by the rest of matches in increasing size of the partially matched value. For example, searching "5" on a set of nodes with labels {"5 AddI", "25 AddL", "253 AddL", "554 MulI"} should list the matches as follows:
>     1. **5** AddI
>     2. **5**54 MulI
>     3. 2**5** AddL
>     4. 2**5**3 AddL
> 
> As an illustration of some of these enhancements, this screenshot shows the behavior of the quick node search functionality before the changes:
> 
> ![search-before](https://user-images.githubusercontent.com/8792647/106283438-374ba500-6242-11eb-8ef4-d18117eabcbb.png)
> 
> and after:
> 
> ![search-after](https://user-images.githubusercontent.com/8792647/106282880-7e856600-6241-11eb-8cb5-48fae5582cc2.png)
> 
> 
> Tested manually on small and large (~10000 nodes) graphs. Thanks to Christian Hagedorn for feedback on several iterations of the enhancements.
> 
> As part of the review, please evaluate not just the code changes but also the usability.

Change the default quick search property to "label", to allow users to search by
node id or name by default, instead of name only. Re-compute the "label"
property every time node labels are updated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2285

From rcastanedalo at openjdk.java.net  Fri Jan 29 14:11:52 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 29 Jan 2021 14:11:52 GMT
Subject: RFR: 8260581: IGV: enhance node search
In-Reply-To: <3-6WXHFVDEcEAeOq6bHUVJ_1bSJHxLQnLOCyUzlo3Kg=.eb3809b2-b85c-4fa9-8de8-edab0f145a07@github.com>
References: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>
 <3-6WXHFVDEcEAeOq6bHUVJ_1bSJHxLQnLOCyUzlo3Kg=.eb3809b2-b85c-4fa9-8de8-edab0f145a07@github.com>
Message-ID: <0aZ3vBgDD6iJ67Nk0RFtAju0y3DsXiNnW_JWJUvUr4c=.5ec9aacb-998f-4c4d-b36e-930a840a1c3a@github.com>

On Thu, 28 Jan 2021 11:10:36 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Apply several enhancements to the quick node search functionality: 
>> 
>> - Allow users to search by node id or name by default, instead of name only.
>> - Show partial matches when searching for a specific property (e.g. so that searching "type=con" lists all "control"-type nodes).
>> - Avoid showing the "All _N_ matching nodes" entry if there is a single match, or the user is searching a numeric value.
>> - Rank matches so that full matches are listed first, followed by matches at the beginning of the partially matched value, followed by the rest of matches in increasing size of the partially matched value. For example, searching "5" on a set of nodes with labels {"5 AddI", "25 AddL", "253 AddL", "554 MulI"} should list the matches as follows:
>>     1. **5** AddI
>>     2. **5**54 MulI
>>     3. 2**5** AddL
>>     4. 2**5**3 AddL
>> 
>> As an illustration of some of these enhancements, this screenshot shows the behavior of the quick node search functionality before the changes:
>> 
>> ![search-before](https://user-images.githubusercontent.com/8792647/106283438-374ba500-6242-11eb-8ef4-d18117eabcbb.png)
>> 
>> and after:
>> 
>> ![search-after](https://user-images.githubusercontent.com/8792647/106282880-7e856600-6241-11eb-8cb5-48fae5582cc2.png)
>> 
>> 
>> Tested manually on small and large (~10000 nodes) graphs. Thanks to Christian Hagedorn for feedback on several iterations of the enhancements.
>> 
>> As part of the review, please evaluate not just the code changes but also the usability.
>
> Change the default quick search property to "label", to allow users to search by
> node id or name by default, instead of name only. Re-compute the "label"
> property every time node labels are updated.

Allow users to search by node id or name by default, show partial matches when
searching for a specific property, show 'All N matching nodes' entry only if
relevant, and rank results by level of matching.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2285

From duke at openjdk.java.net  Fri Jan 29 14:13:43 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 29 Jan 2021 14:13:43 GMT
Subject: Withdrawn: 8252237: C2: Call to compute_separating_interferences has
 wrong argument order
In-Reply-To: <07qmIQCCJgfxcJpqCqVJ-X2uBFaN7k5FXhvgypIUCEk=.689dba23-ffda-4893-ae0e-60ff05b78f17@github.com>
References: <07qmIQCCJgfxcJpqCqVJ-X2uBFaN7k5FXhvgypIUCEk=.689dba23-ffda-4893-ae0e-60ff05b78f17@github.com>
Message-ID: <pKuOolIXnjHGrIqhYuBfZL9SVeIAt1PfKLgC5t40Q4Q=.952b354e-11c5-43c3-be89-6dc5799c8d20@github.com>

On Tue, 1 Dec 2020 07:35:33 GMT, Rahul Raghavan <rraghavan at openjdk.org> wrote:

> **# [.../src/hotspot/share/opto/coalesce.hpp] -**
> **112** uint compute_separating_interferences(Node *dst_copy, Node *src_copy, Block *b, uint bindex, RegMask &rm, **uint rm_size, uint reg_degree,** uint lr1, uint lr2);
> 
> 
> **# [.../src/hotspot/share/opto/coalesce.cpp] -**
> ..........
> **538** uint PhaseConservativeCoalesce::compute_separating_interferences(Node *dst_copy, Node *src_copy, Block *b, uint bindex, RegMask &rm, **uint reg_degree, uint rm_size,** uint lr1, uint lr2 ) {
> .................
> **747** reg_degree = compute_separating_interferences(dst_copy, src_copy, b, bindex, rm, **rm_size, reg_degree,** lr1, lr2 );
> 
> 
> **# So fixing the argument order - [.../src/hotspot/share/opto/coalesce.cpp]**
> -uint PhaseConservativeCoalesce::compute_separating_interferences(Node *dst_copy, Node *src_copy, Block *b, uint bindex, RegMask &rm, **uint reg_degree, uint rm_size,** uint lr1, uint lr2 ) {
> +uint PhaseConservativeCoalesce::compute_separating_interferences(Node *dst_copy, Node *src_copy, Block *b, uint bindex, RegMask &rm, **uint rm_size, uint reg_degree,** uint lr1, uint lr2 ) {

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1533

From rcastanedalo at openjdk.java.net  Fri Jan 29 14:14:59 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 29 Jan 2021 14:14:59 GMT
Subject: RFR: 8260581: IGV: enhance node search [v2]
In-Reply-To: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>
References: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>
Message-ID: <1OvXkUZq1-wp42Ik4uO1Po77am92EVM99S9JWB4mf4I=.32748364-a89f-4002-b7a7-378ca2623422@github.com>

> Apply several enhancements to the quick node search functionality: 
> 
> - Allow users to search by node id or name by default, instead of name only.
> - Show partial matches when searching for a specific property (e.g. so that searching "type=con" lists all "control"-type nodes).
> - Avoid showing the "All _N_ matching nodes" entry if there is a single match, or the user is searching a numeric value.
> - Rank matches so that full matches are listed first, followed by matches at the beginning of the partially matched value, followed by the rest of matches in increasing size of the partially matched value. For example, searching "5" on a set of nodes with labels {"5 AddI", "25 AddL", "253 AddL", "554 MulI"} should list the matches as follows:
>     1. **5** AddI
>     2. **5**54 MulI
>     3. 2**5** AddL
>     4. 2**5**3 AddL
> 
> As an illustration of some of these enhancements, this screenshot shows the behavior of the quick node search functionality before the changes:
> 
> ![search-before](https://user-images.githubusercontent.com/8792647/106283438-374ba500-6242-11eb-8ef4-d18117eabcbb.png)
> 
> and after:
> 
> ![search-after](https://user-images.githubusercontent.com/8792647/106282880-7e856600-6241-11eb-8cb5-48fae5582cc2.png)
> 
> 
> Tested manually on small and large (~10000 nodes) graphs. Thanks to Christian Hagedorn for feedback on several iterations of the enhancements.
> 
> As part of the review, please evaluate not just the code changes but also the usability.

Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:

  Remove debug print

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2285/files
  - new: https://git.openjdk.java.net/jdk/pull/2285/files/41eeadc5..73d0ed02

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2285&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2285&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2285.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2285/head:pull/2285

PR: https://git.openjdk.java.net/jdk/pull/2285

From thartmann at openjdk.java.net  Fri Jan 29 14:40:51 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 29 Jan 2021 14:40:51 GMT
Subject: RFR: 8260420: C2 compilation fails with assert(found_sfpt) failed: no
 node in loop that's not input to safepoint
Message-ID: <JeYENql3vZ7iilXYXlwo4PPfj0-7Egz35hwCmZhGMKE=.6f5ab863-9d1b-4b1a-a1a6-6adeb8bb2b86@github.com>

Loop strip mining verification fails because a `LoadNode` with no safepoint use ends up in the `OuterStripMinedLoop`. The root cause is very similar to [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607): A `LoadNode` with two uses (a field store and a return, see `test2`) is cloned by `PhaseIdealLoop::split_if_with_blocks_post()` for each use, to allow it to flow out of the loop. Both clones end up in the `OuterStripMinedLoop`, the clone for the field store because the store has a safepoint use and the clone for the return because `late_load_ctrl` is too conservative by taking all initial uses into account.

Now the load without a safepoint use is always detected by loop strip mining verification but without verification (for example, in a product build), we still hit several different issues depending on the exact use of the load (compare `test2/3/4`). The main issue is that loads without a safepoint use are not correctly wired when creating pre/main/post loops. Christian described this well in his RFR for [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607): https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-August/039638.html

Therefore, relaxing loop strip mining verification is not an option.

The problem with the fix for [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607) is that it relies on IGVN being executed before pre/main/post loops are created, merging the two clones such that the remaining one has a safepoint use and is therefore correctly handled. However, this is not guaranteed. In fact, if `major_progress` is not set, pre/main/post loops could be created in the same round of loop opts without IGVN in-between (`IdealLoopTree::iteration_split` is executed right after `PhaseIdealLoop::split_if_with_blocks`).

I think we have the following options:
1) Bail out if the loop is strip mined. I think that would be too conservative.

2) Simply set `major_progress` when pinning a `LoadNode` to the `OuterStripMinedLoop` to make sure IGVN is executed and duplicate `LoadNodes` are merged. That seems quite invasive though.

3) Allow the cloned load without a safepoint use (and therefore no usages in the `OuterStripMinedLoop`) to completely flow out of the loop. Currently, this is blocked by `late_load_ctrl` being computed on the initial `LoadNode` instead of the clone and therefore also taking into account the store that is referenced by the safepoint. We could simply re-compute the late ctrl for the cloned load, allowing it to flow out of the `OuterStripMinedLoop`. However, that only works if there is no anti-dependency in the `OuterStripMinedLoop`.

4) Detect duplicate loads in the `OuterStripMinedLoop` on creation in `PhaseIdealLoop::split_if_with_blocks` and merge them right away.

I've decided to go with a combination of 3) and 4). If there is not anti-dependency, 3) will ensure that the load is moved out of the `OuterStripMinedLoop`. If there is an anti-dependency, 4) will ensure that still no duplicate loads are created.

I've also reverted the fix for JDK-8249607 which is no longer required.

As Roland and Christian already noticed, there are various other issues with that code that hopefully will be addressed at some point by [JDK-8252372](https://bugs.openjdk.java.net/browse/JDK-8252372).

Thanks,
Tobias

-------------

Commit messages:
 - 8260420: C2 compilation fails with assert(found_sfpt) failed: no node in loop that's not input to safepoint

Changes: https://git.openjdk.java.net/jdk/pull/2315/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2315&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260420
  Stats: 94 lines in 2 files changed: 77 ins; 1 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2315.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2315/head:pull/2315

PR: https://git.openjdk.java.net/jdk/pull/2315

From thartmann at openjdk.java.net  Fri Jan 29 14:59:14 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 29 Jan 2021 14:59:14 GMT
Subject: RFR: 8260420: C2 compilation fails with assert(found_sfpt)
 failed: no node in loop that's not input to safepoint [v2]
In-Reply-To: <JeYENql3vZ7iilXYXlwo4PPfj0-7Egz35hwCmZhGMKE=.6f5ab863-9d1b-4b1a-a1a6-6adeb8bb2b86@github.com>
References: <JeYENql3vZ7iilXYXlwo4PPfj0-7Egz35hwCmZhGMKE=.6f5ab863-9d1b-4b1a-a1a6-6adeb8bb2b86@github.com>
Message-ID: <ssckgvy5QHhClePOXmNCSk41EaeYbmZgAMIxlVFOys4=.b5245a3b-c332-4f84-9384-ec2e23d06369@github.com>

> Loop strip mining verification fails because a `LoadNode` with no safepoint use ends up in the `OuterStripMinedLoop`. The root cause is very similar to [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607): A `LoadNode` with two uses (a field store and a return, see `test2`) is cloned by `PhaseIdealLoop::split_if_with_blocks_post()` for each use, to allow it to flow out of the loop. Both clones end up in the `OuterStripMinedLoop`, the clone for the field store because the store has a safepoint use and the clone for the return because `late_load_ctrl` is too conservative by taking all initial uses into account.
> 
> Now the load without a safepoint use is always detected by loop strip mining verification but without verification (for example, in a product build), we still hit several different issues depending on the exact use of the load (compare `test2/3/4`). The main issue is that loads without a safepoint use are not correctly wired when creating pre/main/post loops. Christian described this well in his RFR for [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607): https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-August/039638.html
> 
> Therefore, relaxing loop strip mining verification is not an option.
> 
> The problem with the fix for [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607) is that it relies on IGVN being executed before pre/main/post loops are created, merging the two clones such that the remaining one has a safepoint use and is therefore correctly handled. However, this is not guaranteed. In fact, if `major_progress` is not set, pre/main/post loops could be created in the same round of loop opts without IGVN in-between (`IdealLoopTree::iteration_split` is executed right after `PhaseIdealLoop::split_if_with_blocks`).
> 
> I think we have the following options:
> 1) Bail out if the loop is strip mined. I think that would be too conservative.
> 
> 2) Simply set `major_progress` when pinning a `LoadNode` to the `OuterStripMinedLoop` to make sure IGVN is executed and duplicate `LoadNodes` are merged. That seems quite invasive though.
> 
> 3) Allow the cloned load without a safepoint use (and therefore no usages in the `OuterStripMinedLoop`) to completely flow out of the loop. Currently, this is blocked by `late_load_ctrl` being computed on the initial `LoadNode` instead of the clone and therefore also taking into account the store that is referenced by the safepoint. We could simply re-compute the late ctrl for the cloned load, allowing it to flow out of the `OuterStripMinedLoop`. However, that only works if there is no anti-dependency in the `OuterStripMinedLoop`.
> 
> 4) Detect duplicate loads in the `OuterStripMinedLoop` on creation in `PhaseIdealLoop::split_if_with_blocks` and merge them right away.
> 
> I've decided to go with 4) and also reverted the fix for JDK-8249607 which is no longer required.
> 
> As Roland and Christian already noticed, there are various other issues with that code that hopefully will be addressed at some point by [JDK-8252372](https://bugs.openjdk.java.net/browse/JDK-8252372).
> 
> Thanks,
> Tobias

Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:

  Remove late ctrl update

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2315/files
  - new: https://git.openjdk.java.net/jdk/pull/2315/files/b18fb7f1..fd70aef2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2315&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2315&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2315.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2315/head:pull/2315

PR: https://git.openjdk.java.net/jdk/pull/2315

From chagedorn at openjdk.java.net  Fri Jan 29 15:24:44 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Fri, 29 Jan 2021 15:24:44 GMT
Subject: RFR: 8260581: IGV: enhance node search [v2]
In-Reply-To: <1OvXkUZq1-wp42Ik4uO1Po77am92EVM99S9JWB4mf4I=.32748364-a89f-4002-b7a7-378ca2623422@github.com>
References: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>
 <1OvXkUZq1-wp42Ik4uO1Po77am92EVM99S9JWB4mf4I=.32748364-a89f-4002-b7a7-378ca2623422@github.com>
Message-ID: <Bi-IBOh27-CpVV2BhAnfs7tRDTaVRIlPwfEBsf28-yo=.2852a85a-970d-4426-a6fe-75db4cde79e8@github.com>

On Fri, 29 Jan 2021 14:14:59 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Apply several enhancements to the quick node search functionality: 
>> 
>> - Allow users to search by node id or name by default, instead of name only.
>> - Show partial matches when searching for a specific property (e.g. so that searching "type=con" lists all "control"-type nodes).
>> - Avoid showing the "All _N_ matching nodes" entry if there is a single match, or the user is searching a numeric value.
>> - Rank matches so that full matches are listed first, followed by matches at the beginning of the partially matched value, followed by the rest of matches in increasing size of the partially matched value. For example, searching "5" on a set of nodes with labels {"5 AddI", "25 AddL", "253 AddL", "554 MulI"} should list the matches as follows:
>>     1. **5** AddI
>>     2. **5**54 MulI
>>     3. 2**5** AddL
>>     4. 2**5**3 AddL
>> 
>> As an illustration of some of these enhancements, this screenshot shows the behavior of the quick node search functionality before the changes:
>> 
>> ![search-before](https://user-images.githubusercontent.com/8792647/106283438-374ba500-6242-11eb-8ef4-d18117eabcbb.png)
>> 
>> and after:
>> 
>> ![search-after](https://user-images.githubusercontent.com/8792647/106282880-7e856600-6241-11eb-8cb5-48fae5582cc2.png)
>> 
>> 
>> Tested manually on small and large (~10000 nodes) graphs. Thanks to Christian Hagedorn for feedback on several iterations of the enhancements.
>> 
>> As part of the review, please evaluate not just the code changes but also the usability.
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove debug print

Otherwise, it looks good to me.

I applied your patch and tested the new features in the IGV. They work as expected. Good to see the search being improved!

src/utils/IdealGraphVisualizer/View/src/com/sun/hotspot/igv/view/NodeQuickSearch.java line 140:

> 138:                                  (InputNode a, InputNode b) ->
> 139:                                  Integer.valueOf(rankMatch(rawValue, a.getProperties().get(name)))
> 140:                                  .compareTo(rankMatch(rawValue, b.getProperties().get(name))));

You can use `Integer.compare()` which directly takes two `ints` instead of `compareTo()`.

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2285

From vlivanov at openjdk.java.net  Fri Jan 29 15:38:44 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 29 Jan 2021 15:38:44 GMT
Subject: RFR: 8260581: IGV: enhance node search [v2]
In-Reply-To: <1OvXkUZq1-wp42Ik4uO1Po77am92EVM99S9JWB4mf4I=.32748364-a89f-4002-b7a7-378ca2623422@github.com>
References: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>
 <1OvXkUZq1-wp42Ik4uO1Po77am92EVM99S9JWB4mf4I=.32748364-a89f-4002-b7a7-378ca2623422@github.com>
Message-ID: <XLrxv_fFDXIdNYi_35tIT5UhbbIayuY9mYDPVfGjOvU=.3066e6fc-b523-4368-8e09-2977c5b90c34@github.com>

On Fri, 29 Jan 2021 14:14:59 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Apply several enhancements to the quick node search functionality: 
>> 
>> - Allow users to search by node id or name by default, instead of name only.
>> - Show partial matches when searching for a specific property (e.g. so that searching "type=con" lists all "control"-type nodes).
>> - Avoid showing the "All _N_ matching nodes" entry if there is a single match, or the user is searching a numeric value.
>> - Rank matches so that full matches are listed first, followed by matches at the beginning of the partially matched value, followed by the rest of matches in increasing size of the partially matched value. For example, searching "5" on a set of nodes with labels {"5 AddI", "25 AddL", "253 AddL", "554 MulI"} should list the matches as follows:
>>     1. **5** AddI
>>     2. **5**54 MulI
>>     3. 2**5** AddL
>>     4. 2**5**3 AddL
>> 
>> As an illustration of some of these enhancements, this screenshot shows the behavior of the quick node search functionality before the changes:
>> 
>> ![search-before](https://user-images.githubusercontent.com/8792647/106283438-374ba500-6242-11eb-8ef4-d18117eabcbb.png)
>> 
>> and after:
>> 
>> ![search-after](https://user-images.githubusercontent.com/8792647/106282880-7e856600-6241-11eb-8cb5-48fae5582cc2.png)
>> 
>> 
>> Tested manually on small and large (~10000 nodes) graphs. Thanks to Christian Hagedorn for feedback on several iterations of the enhancements.
>> 
>> As part of the review, please evaluate not just the code changes but also the usability.
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove debug print

Awesome! Finally!

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2285

From kvn at openjdk.java.net  Fri Jan 29 16:18:41 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 29 Jan 2021 16:18:41 GMT
Subject: Integrated: 8259584: SuperWord::fix_commutative_inputs checks
 in_bb(fin1) instead of in_bb(fin2)
In-Reply-To: <B5pCG3ww_WmUYcyh07r4nBGHlytgbNk4LbMPZ9nwFUg=.ad2fecf0-b012-4294-9373-4019ea0bf04d@github.com>
References: <B5pCG3ww_WmUYcyh07r4nBGHlytgbNk4LbMPZ9nwFUg=.ad2fecf0-b012-4294-9373-4019ea0bf04d@github.com>
Message-ID: <aqmE63Q7eaNdDxu_2N0hH5VysUm9CyQnQ35b1BukUGo=.9659381e-dc07-49ec-bcf1-f45474b9f673@github.com>

On Thu, 28 Jan 2021 18:54:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Fix typo. Note, this change does not affect product because this code is not executed after JDK-8251994 fix: 
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/superword.cpp#L519

This pull request has now been integrated.

Changeset: 6415d3b8
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6415d3b8
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8259584: SuperWord::fix_commutative_inputs checks in_bb(fin1) instead of in_bb(fin2)

Reviewed-by: shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/2299

From aph at redhat.com  Fri Jan 29 16:29:53 2021
From: aph at redhat.com (Andrew Haley)
Date: Fri, 29 Jan 2021 16:29:53 +0000
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value
In-Reply-To: <813ca59c-59a8-7fca-7566-0472017681ab@redhat.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <WDQ0yZR8gbP6aLt1qOEIMsSOrwiSMdS4V8l4pi4RBmc=.b201fce0-ed3e-4319-b96b-9651bd4ecdd7@github.com>
 <KxrCbTo3Or4kTUEau7IYHc0FUkI2Sa6a8hPzk8mjLME=.00f5dd6f-ed0d-4298-80d6-baeae8b66490@github.com>
 <813ca59c-59a8-7fca-7566-0472017681ab@redhat.com>
Message-ID: <0f770a11-e235-d2ab-e927-8f192e80638b@redhat.com>

On 29/01/2021 10:11, Andrew Haley wrote:
> On 1/29/21 8:35 AM, Eric Liu wrote:
>> I benchmarked on 7 platforms with jmh test[1], most of them were hard to see any performance changes. On one platform the performance become bad, and seems a little unstable.

Your benchmark did not work for me. It did not generate the correct
instructions.

Please try with this or similar:

    @Benchmark
    public void xorRotateRight(MyState s, Blackhole blackhole) {
        int x = s.xi;
        int y = s.yi;
        for (int i = 0; i < COUNT; i++) {
            y = x ^ ((y >>> 5) | (y << -5));
            x = y ^ ((x >>> 5) | (x << -5));
        }
        blackhole.consume(x);
    }

I get:

Benchmark                             Mode  Cnt     Score    Error  Units
Rotation.xorRotateRight   (before)    avgt    3  6142.575 ? 15.940  ns/op
Rotation.xorRotateRight   (after)     avgt    3  4081.587 ? 33.904  ns/op

Please integrate the corrected benchmark into your patch.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From neliasso at openjdk.java.net  Fri Jan 29 16:34:40 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 29 Jan 2021 16:34:40 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v4]
In-Reply-To: <6nZPJh_IZbeLrS2D1lrwq7NIIry0zGQ8EzAXD6fkSrE=.4b476693-5877-434e-9e97-b26f73870e33@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <rdtmz-1qWqPh036NjaVt6BXeVZdHuIJOFCpnVIkoI4I=.e503ab3b-5259-40f6-b056-976d0efa5ae5@github.com>
 <zBnzf7Me1OV3TVIDvrbNQrr-pxgFSeRcTASH6wNCXGs=.81d032d4-2503-47b1-8c48-651ecf35f7fa@github.com>
 <iYbXJvVqZy-ZetNKrrbPTT0jLTCrj_DEjBKPv8ckHVs=.b2263634-62a4-40a4-9ab8-248e3081dbb4@github.com>
 <Sm5e0TdFCKQztHlJGCs6Tsxc5AEpv711D_XBy_iLDs4=.940eabf1-69e9-4c67-a758-55f564f102dd@github.com>
 <j3eZ95EoTA292mgew_cghhGuaFTfJW0J5Fon27G2ibQ=.fa233153-a19e-4b28-869a-2299786178eb@github.com>
 <6nZPJh_IZbeLrS2D1lrwq7NIIry0zGQ8EzAXD6fkSrE=.4b476693-5877-434e-9e97-b26f73870e33@github.com>
Message-ID: <A6jtvTa_8BpHED_dbtsQZk3gdUNAMPw2QSTtVG5Tzxo=.6ed5dbc6-a786-4753-b217-3f762917f34a@github.com>

On Fri, 29 Jan 2021 08:24:13 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>>> > ArrayCopyNode::load performs the same work as it does here in PhaseVector::optimize_vector_boxes .
>>> > Is there a need to provide a similar function in PhaseVector or GraphKit?
>>> 
>>> My point is since PhaseVector effectively enters the parsing phase (by signaling about the possibility of post-parse inlining), technically I don't see why `GraphKit::access_load_at` won't work. But I need to spend more time looking into the details.
>>> 
>>> So far, I took a look at the review thread of 8212243 (which introduced `ArrayCopyNode::load`) and found the following discussion between Roland and Erik:
>>> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-October/030971.html
>>> 
>>> ```
>>> > ... Also it beats  me that this is strictly speaking a load barrier for loads performed in 
>>> > arraycopy. Would it be possible to use something like access_load_at  instead? ...
>>> ...
>>> GraphKit is a parse time only thing. So the existing gc interface
>>> doesn't offer any way to add barriers once parsing is over. This code
>>> runs after parsing in optimization phases.
>>> ...
>>> ```
>>> 
>>> Considering `PhaseVector::optimize_vector_boxes()` already has access to a usable `GraphKit` instance, it is possible that `GraphKit::access_load_at` will "just work".
>> 
>> As far as I can see, during the parse phase, GraphKit contains the jvm state info which can be used to get the control and memory for creating new nodes. But during optimization, the jvm state info may be missing like the situation in `PhaseVector::optimize_vector_boxes` or Macro Expansion. So it should use C2OptAccess to create the Load Node directly by providing control and memory nodes.
>> 
>> I think a similar api like `GraphKit::access_load_at ` should be provided for usage during optimization stages,  but where should the API be placed? GraphKit or PhaseIterGVN or somewhere else?
>
>> Considering `PhaseVector::optimize_vector_boxes()` already has access to a usable `GraphKit` instance, it is possible that `GraphKit::access_load_at` will "just work".
> 
> The main thing to make sure you get right, is the aliasing. I'm not sure that will work right after parsing, the way it works now.

I suggest you keep this CR as it is since 16 is in rampdown and we need to get approval and push it before Feb 4th (and we do want some margin). 

Open an enhancement on 17 to fix the api.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From neliasso at openjdk.java.net  Fri Jan 29 16:38:41 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 29 Jan 2021 16:38:41 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v7]
In-Reply-To: <mPKKzESQWrPm8Sn-2K_QJibH4_59x5k5c550SMh0sws=.0ed12218-71b3-49e8-a879-6d58f12046d3@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <mPKKzESQWrPm8Sn-2K_QJibH4_59x5k5c550SMh0sws=.0ed12218-71b3-49e8-a879-6d58f12046d3@github.com>
Message-ID: <3qxMI_2q1rdcDoLFZ5Qil__d_shHCQaAkVU39VAGPdU=.9fbb67fa-a195-49d6-aa20-5991f34b61d0@github.com>

On Fri, 29 Jan 2021 04:14:03 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8260473
>> 
>> Function "PhaseVector::expand_vunbox_node" creates a LoadNode, but forgets to make the LoadNode to pass gc barriers.
>> 
>> 
>> Testing: all Vector API related tests have passed.
>
> ?? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the copyright date

src/hotspot/share/opto/vector.cpp line 419:

> 417:     Node* vec_field_ld;
> 418:     {
> 419:       DecoratorSet decorators = C2_READ_ACCESS | C2_CONTROL_DEPENDENT_LOAD | IN_HEAP;

C2_READ_ACCESS will be set by "bs->load_at" so you can skip that. 
MO_UNORDERED is missing. That corresponds to "MemNode::unordered" in the original code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From vlivanov at openjdk.java.net  Fri Jan 29 16:46:41 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 29 Jan 2021 16:46:41 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v4]
In-Reply-To: <A6jtvTa_8BpHED_dbtsQZk3gdUNAMPw2QSTtVG5Tzxo=.6ed5dbc6-a786-4753-b217-3f762917f34a@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <rdtmz-1qWqPh036NjaVt6BXeVZdHuIJOFCpnVIkoI4I=.e503ab3b-5259-40f6-b056-976d0efa5ae5@github.com>
 <zBnzf7Me1OV3TVIDvrbNQrr-pxgFSeRcTASH6wNCXGs=.81d032d4-2503-47b1-8c48-651ecf35f7fa@github.com>
 <iYbXJvVqZy-ZetNKrrbPTT0jLTCrj_DEjBKPv8ckHVs=.b2263634-62a4-40a4-9ab8-248e3081dbb4@github.com>
 <Sm5e0TdFCKQztHlJGCs6Tsxc5AEpv711D_XBy_iLDs4=.940eabf1-69e9-4c67-a758-55f564f102dd@github.com>
 <j3eZ95EoTA292mgew_cghhGuaFTfJW0J5Fon27G2ibQ=.fa233153-a19e-4b28-869a-2299786178eb@github.com>
 <6nZPJh_IZbeLrS2D1lrwq7NIIry0zGQ8EzAXD6fkSrE=.4b476693-5877-434e-9e97-b26f73870e33@github.com>
 <A6jtvTa_8BpHED_dbtsQZk3gdUNAMPw2QSTtVG5Tzxo=.6ed5dbc6-a786-4753-b217-3f762917f34a@github.com>
Message-ID: <HlJ7HD6M8hxuxNESS13iBnk8-r5MTRfVNk_oYvzckB8=.a309986a-f7bd-4ec8-a0b7-80ef136bfd01@github.com>

On Fri, 29 Jan 2021 16:31:47 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> I suggest you keep this CR as it is since 16 is in rampdown and we need to get approval and push it before Feb 4th (and we do want some margin).

I agree. @casparcwang, please, file an RFE.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From vlivanov at openjdk.java.net  Fri Jan 29 16:46:43 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 29 Jan 2021 16:46:43 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v7]
In-Reply-To: <3qxMI_2q1rdcDoLFZ5Qil__d_shHCQaAkVU39VAGPdU=.9fbb67fa-a195-49d6-aa20-5991f34b61d0@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <mPKKzESQWrPm8Sn-2K_QJibH4_59x5k5c550SMh0sws=.0ed12218-71b3-49e8-a879-6d58f12046d3@github.com>
 <3qxMI_2q1rdcDoLFZ5Qil__d_shHCQaAkVU39VAGPdU=.9fbb67fa-a195-49d6-aa20-5991f34b61d0@github.com>
Message-ID: <x9QwadDTw4Wq1Xqx4aVDx7lDeha1WA-6hiFd9UoFaMU=.370c7738-f3ac-4be1-89cf-16f3310c7dab@github.com>

On Fri, 29 Jan 2021 16:35:39 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> ?? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix the copyright date
>
> src/hotspot/share/opto/vector.cpp line 419:
> 
>> 417:     Node* vec_field_ld;
>> 418:     {
>> 419:       DecoratorSet decorators = C2_READ_ACCESS | C2_CONTROL_DEPENDENT_LOAD | IN_HEAP;
> 
> C2_READ_ACCESS will be set by "bs->load_at" so you can skip that. 
> MO_UNORDERED is missing. That corresponds to "MemNode::unordered" in the original code.

`C2_CONTROL_DEPENDENT_LOAD` is also redundant (though original code does that): it's just a plain load from a final instance field).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From vlivanov at openjdk.java.net  Fri Jan 29 16:50:40 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 29 Jan 2021 16:50:40 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v4]
In-Reply-To: <j3eZ95EoTA292mgew_cghhGuaFTfJW0J5Fon27G2ibQ=.fa233153-a19e-4b28-869a-2299786178eb@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <rdtmz-1qWqPh036NjaVt6BXeVZdHuIJOFCpnVIkoI4I=.e503ab3b-5259-40f6-b056-976d0efa5ae5@github.com>
 <zBnzf7Me1OV3TVIDvrbNQrr-pxgFSeRcTASH6wNCXGs=.81d032d4-2503-47b1-8c48-651ecf35f7fa@github.com>
 <iYbXJvVqZy-ZetNKrrbPTT0jLTCrj_DEjBKPv8ckHVs=.b2263634-62a4-40a4-9ab8-248e3081dbb4@github.com>
 <Sm5e0TdFCKQztHlJGCs6Tsxc5AEpv711D_XBy_iLDs4=.940eabf1-69e9-4c67-a758-55f564f102dd@github.com>
 <j3eZ95EoTA292mgew_cghhGuaFTfJW0J5Fon27G2ibQ=.fa233153-a19e-4b28-869a-2299786178eb@github.com>
Message-ID: <aEy95Uxy52lpFSDzmlCE9nilQ-S0G_W40FLOe-Z4THA=.16c0bb89-412c-43d6-a241-6125698d453a@github.com>

On Fri, 29 Jan 2021 06:48:36 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

> As far as I can see, during the parse phase, GraphKit contains the jvm state info which can be used to get the control and memory for creating new nodes. But during optimization, the jvm state info may be missing like the situation in PhaseVector::optimize_vector_boxes or Macro Expansion.

JVM state is irrelevant here (otherwise, `VectorUnbox` node would have captured relevant info during construction). What is actually missing is `GraphKit` instance lacks info about control and memory. You need to explicitly set it using `GraphKit::set_control()` and `GraphKit::set_all_memory()`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From duke at openjdk.java.net  Fri Jan 29 17:08:41 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 29 Jan 2021 17:08:41 GMT
Subject: Withdrawn: 8058176: [mlvm] tests should tolerate exceptions caused by
 code cache exhaustion
In-Reply-To: <4vwa6sZ_fIeHJfHaDYeNWmB0x1Ou23_BR8_kgWo_o-M=.d4ef61b1-0ae8-4fff-bb3a-5432cdb4164a@github.com>
References: <4vwa6sZ_fIeHJfHaDYeNWmB0x1Ou23_BR8_kgWo_o-M=.d4ef61b1-0ae8-4fff-bb3a-5432cdb4164a@github.com>
Message-ID: <fQgF5Oi4MOYSSeTlrS5m7yKidAUtx0ctRuv93KoNqJ4=.c3cec464-90dc-4709-b74a-8f28128e3640@github.com>

On Fri, 4 Dec 2020 13:47:27 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

> 1. Normalise meth/stress/compiler/i2c_c2i/Test.java to use MultiThreadedTest framework;
> 2. Adjust MultiThreadedTest in order to accomodate the i2c_c2i test (add prepareThread method and logic);
> 3. Add ThrowableTolerance and DefaultThrowableTolerance as ways to control what Throwables are accepted;
> 4. Adjust MultiThreadedTest to catch Throwables and check if they are accepted;
> 5. Adjust individual tests to catch possible Throwables and check if they are accepted;
> 6. Un-problemlist the failing tests.
> 
> Testing: vmTestBase/vm/mlvm/meth/stress and vmTestBase/vm/mlvm/func tests run on macos-linux-windows in x64-debug configurations.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1622

From neliasso at openjdk.java.net  Fri Jan 29 17:14:44 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 29 Jan 2021 17:14:44 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v4]
In-Reply-To: <aEy95Uxy52lpFSDzmlCE9nilQ-S0G_W40FLOe-Z4THA=.16c0bb89-412c-43d6-a241-6125698d453a@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <rdtmz-1qWqPh036NjaVt6BXeVZdHuIJOFCpnVIkoI4I=.e503ab3b-5259-40f6-b056-976d0efa5ae5@github.com>
 <zBnzf7Me1OV3TVIDvrbNQrr-pxgFSeRcTASH6wNCXGs=.81d032d4-2503-47b1-8c48-651ecf35f7fa@github.com>
 <iYbXJvVqZy-ZetNKrrbPTT0jLTCrj_DEjBKPv8ckHVs=.b2263634-62a4-40a4-9ab8-248e3081dbb4@github.com>
 <Sm5e0TdFCKQztHlJGCs6Tsxc5AEpv711D_XBy_iLDs4=.940eabf1-69e9-4c67-a758-55f564f102dd@github.com>
 <j3eZ95EoTA292mgew_cghhGuaFTfJW0J5Fon27G2ibQ=.fa233153-a19e-4b28-869a-2299786178eb@github.com>
 <aEy95Uxy52lpFSDzmlCE9nilQ-S0G_W40FLOe-Z4THA=.16c0bb89-412c-43d6-a241-6125698d453a@github.com>
Message-ID: <_4PyarggOjbeRGvLGk2nFhLcuCMJCilw5kOaj0C3c4Y=.8f0e5910-1c43-43e7-ac56-edbf87d3bf09@github.com>

On Fri, 29 Jan 2021 16:47:53 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>>> > ArrayCopyNode::load performs the same work as it does here in PhaseVector::optimize_vector_boxes .
>>> > Is there a need to provide a similar function in PhaseVector or GraphKit?
>>> 
>>> My point is since PhaseVector effectively enters the parsing phase (by signaling about the possibility of post-parse inlining), technically I don't see why `GraphKit::access_load_at` won't work. But I need to spend more time looking into the details.
>>> 
>>> So far, I took a look at the review thread of 8212243 (which introduced `ArrayCopyNode::load`) and found the following discussion between Roland and Erik:
>>> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-October/030971.html
>>> 
>>> ```
>>> > ... Also it beats  me that this is strictly speaking a load barrier for loads performed in 
>>> > arraycopy. Would it be possible to use something like access_load_at  instead? ...
>>> ...
>>> GraphKit is a parse time only thing. So the existing gc interface
>>> doesn't offer any way to add barriers once parsing is over. This code
>>> runs after parsing in optimization phases.
>>> ...
>>> ```
>>> 
>>> Considering `PhaseVector::optimize_vector_boxes()` already has access to a usable `GraphKit` instance, it is possible that `GraphKit::access_load_at` will "just work".
>> 
>> As far as I can see, during the parse phase, GraphKit contains the jvm state info which can be used to get the control and memory for creating new nodes. But during optimization, the jvm state info may be missing like the situation in `PhaseVector::optimize_vector_boxes` or Macro Expansion. So it should use C2OptAccess to create the Load Node directly by providing control and memory nodes.
>> 
>> I think a similar api like `GraphKit::access_load_at ` should be provided for usage during optimization stages,  but where should the API be placed? GraphKit or PhaseIterGVN or somewhere else?
>
>> As far as I can see, during the parse phase, GraphKit contains the jvm state info which can be used to get the control and memory for creating new nodes. But during optimization, the jvm state info may be missing like the situation in PhaseVector::optimize_vector_boxes or Macro Expansion.
> 
> JVM state is irrelevant here (otherwise, `VectorUnbox` node would have captured relevant info during construction). What is actually missing is `GraphKit` instance lacks info about control and memory. You need to explicitly set it using `GraphKit::set_control()` and `GraphKit::set_all_memory()`.

We need this patch to be based on the JDK 16 repository.

I will help out with the fix-request and sponsor-ship.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From kvn at openjdk.java.net  Fri Jan 29 17:28:44 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 29 Jan 2021 17:28:44 GMT
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers
In-Reply-To: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
Message-ID: <GF0g94F7kCr5d37eOYL1d_ELxEnUb9Os_iWXCvtGrxs=.83af2b2b-7fd0-43ee-83e6-006fe9597f53@github.com>

On Thu, 28 Jan 2021 13:01:07 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> This is a typo introduced by JDK-8255949.
> Compiler will generate `ushr` for shifting right and accumulating four short integers.
> It produces wrong results for specific case. The instruction should be `usra`.

Someone familiar with Aarch64 assembler have to review this before it is approved for JDK 16.

-------------

PR: https://git.openjdk.java.net/jdk16/pull/136

From kvn at openjdk.java.net  Fri Jan 29 17:45:54 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 29 Jan 2021 17:45:54 GMT
Subject: RFR: 8259398: Super word not applied to a loop with
 byteArrayViewVarHandle
Message-ID: <I0ExHviPyb7ZzxqBZh6lkvpUtl35ghRzDdI1Oq57RYA=.4bfd8809-78be-49a0-b7bb-03ff9d60f3fa@github.com>

Address expressing in this case has CastII which is not range check related.
I think it is safe to skip any CastII nodes (similar to ConvI2L nodes) when parsing address for vectors - vectors will be constructed only if the same loop's variable and invariant are used for all memory operations regardless casts. Also vectors address depends on loop's variable so they will not be moved outside loop.
In 32-bit VM there is no ConvI2L nodes so I moved CastII checks from under ConvI2L check.

New regression case added to TestBufferVectorization.java test.

Testing hs-tier1-7, RenaissanceStressTest. Run all vectorizing tests locally to make sure no regression.

-------------

Commit messages:
 - 8259398: Super word not applied to a loop with byteArrayViewVarHandle

Changes: https://git.openjdk.java.net/jdk/pull/2317/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2317&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259398
  Stats: 57 lines in 2 files changed: 41 ins; 6 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2317.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2317/head:pull/2317

PR: https://git.openjdk.java.net/jdk/pull/2317

From vlivanov at openjdk.java.net  Fri Jan 29 17:51:39 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 29 Jan 2021 17:51:39 GMT
Subject: RFR: 8259398: Super word not applied to a loop with
 byteArrayViewVarHandle
In-Reply-To: <I0ExHviPyb7ZzxqBZh6lkvpUtl35ghRzDdI1Oq57RYA=.4bfd8809-78be-49a0-b7bb-03ff9d60f3fa@github.com>
References: <I0ExHviPyb7ZzxqBZh6lkvpUtl35ghRzDdI1Oq57RYA=.4bfd8809-78be-49a0-b7bb-03ff9d60f3fa@github.com>
Message-ID: <WCLmYErpy5sV6XDqyfzKYnIgyjkdZ7jMwQ5zlW1RN1Q=.e4940b59-cf9e-4485-a507-28252be8a0f8@github.com>

On Fri, 29 Jan 2021 17:40:39 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Address expressing in this case has CastII which is not range check related.
> I think it is safe to skip any CastII nodes (similar to ConvI2L nodes) when parsing address for vectors - vectors will be constructed only if the same loop's variable and invariant are used for all memory operations regardless casts. Also vectors address depends on loop's variable so they will not be moved outside loop.
> In 32-bit VM there is no ConvI2L nodes so I moved CastII checks from under ConvI2L check.
> 
> New regression case added to TestBufferVectorization.java test.
> 
> Testing hs-tier1-7, RenaissanceStressTest. Run all vectorizing tests locally to make sure no regression.

Looks good.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2317

From iveresov at openjdk.java.net  Fri Jan 29 18:24:42 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Fri, 29 Jan 2021 18:24:42 GMT
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers
In-Reply-To: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
Message-ID: <gxJht5koARX2TQtpnNQ3paw6PCrplMTZyKyqbm7e6B4=.77876e61-7000-4065-8e44-26516e1d6851@github.com>

On Thu, 28 Jan 2021 13:01:07 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> This is a typo introduced by JDK-8255949.
> Compiler will generate `ushr` for shifting right and accumulating four short integers.
> It produces wrong results for specific case. The instruction should be `usra`.

Marked as reviewed by iveresov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk16/pull/136

From kvn at openjdk.java.net  Fri Jan 29 19:26:41 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 29 Jan 2021 19:26:41 GMT
Subject: RFR: 8259398: Super word not applied to a loop with
 byteArrayViewVarHandle
In-Reply-To: <WCLmYErpy5sV6XDqyfzKYnIgyjkdZ7jMwQ5zlW1RN1Q=.e4940b59-cf9e-4485-a507-28252be8a0f8@github.com>
References: <I0ExHviPyb7ZzxqBZh6lkvpUtl35ghRzDdI1Oq57RYA=.4bfd8809-78be-49a0-b7bb-03ff9d60f3fa@github.com>
 <WCLmYErpy5sV6XDqyfzKYnIgyjkdZ7jMwQ5zlW1RN1Q=.e4940b59-cf9e-4485-a507-28252be8a0f8@github.com>
Message-ID: <X0xraSu-auMN6O8eyyP6gopMObhJ8pYT0DB0tEMHxaU=.133e9f66-fe0e-46cb-977a-af68ca3cb881@github.com>

On Fri, 29 Jan 2021 17:48:59 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Address expressing in this case has CastII which is not range check related.
>> I think it is safe to skip any CastII nodes (similar to ConvI2L nodes) when parsing address for vectors - vectors will be constructed only if the same loop's variable and invariant are used for all memory operations regardless casts. Also vectors address depends on loop's variable so they will not be moved outside loop.
>> In 32-bit VM there is no ConvI2L nodes so I moved CastII checks from under ConvI2L check.
>> 
>> New regression case added to TestBufferVectorization.java test.
>> 
>> Testing hs-tier1-7, RenaissanceStressTest. Run all vectorizing tests locally to make sure no regression.
>
> Looks good.

Thank you @iwanowww

-------------

PR: https://git.openjdk.java.net/jdk/pull/2317

From kvn at openjdk.java.net  Fri Jan 29 19:30:44 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 29 Jan 2021 19:30:44 GMT
Subject: RFR: 8260420: C2 compilation fails with assert(found_sfpt)
 failed: no node in loop that's not input to safepoint [v2]
In-Reply-To: <ssckgvy5QHhClePOXmNCSk41EaeYbmZgAMIxlVFOys4=.b5245a3b-c332-4f84-9384-ec2e23d06369@github.com>
References: <JeYENql3vZ7iilXYXlwo4PPfj0-7Egz35hwCmZhGMKE=.6f5ab863-9d1b-4b1a-a1a6-6adeb8bb2b86@github.com>
 <ssckgvy5QHhClePOXmNCSk41EaeYbmZgAMIxlVFOys4=.b5245a3b-c332-4f84-9384-ec2e23d06369@github.com>
Message-ID: <B8t5ruExmEo4411CcQk_ayBlPGCGZt7d59faCYc_ZQo=.baac30f3-a5b8-4195-969b-542216a3dd75@github.com>

On Fri, 29 Jan 2021 14:59:14 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Loop strip mining verification fails because a `LoadNode` with no safepoint use ends up in the `OuterStripMinedLoop`. The root cause is very similar to [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607): A `LoadNode` with two uses (a field store and a return, see `test2`) is cloned by `PhaseIdealLoop::split_if_with_blocks_post()` for each use, to allow it to flow out of the loop. Both clones end up in the `OuterStripMinedLoop`, the clone for the field store because the store has a safepoint use and the clone for the return because `late_load_ctrl` is too conservative by taking all initial uses into account.
>> 
>> Now the load without a safepoint use is always detected by loop strip mining verification but without verification (for example, in a product build), we still hit several different issues depending on the exact use of the load (compare `test2/3/4`). The main issue is that loads without a safepoint use are not correctly wired when creating pre/main/post loops. Christian described this well in his RFR for [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607): https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-August/039638.html
>> 
>> Therefore, relaxing loop strip mining verification is not an option.
>> 
>> The problem with the fix for [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607) is that it relies on IGVN being executed before pre/main/post loops are created, merging the two clones such that the remaining one has a safepoint use and is therefore correctly handled. However, this is not guaranteed. In fact, if `major_progress` is not set, pre/main/post loops could be created in the same round of loop opts without IGVN in-between (`IdealLoopTree::iteration_split` is executed right after `PhaseIdealLoop::split_if_with_blocks`).
>> 
>> I think we have the following options:
>> 1) Bail out if the loop is strip mined. I think that would be too conservative.
>> 
>> 2) Simply set `major_progress` when pinning a `LoadNode` to the `OuterStripMinedLoop` to make sure IGVN is executed and duplicate `LoadNodes` are merged. That seems quite invasive though.
>> 
>> 3) Allow the cloned load without a safepoint use (and therefore no usages in the `OuterStripMinedLoop`) to completely flow out of the loop. Currently, this is blocked by `late_load_ctrl` being computed on the initial `LoadNode` instead of the clone and therefore also taking into account the store that is referenced by the safepoint. We could simply re-compute the late ctrl for the cloned load, allowing it to flow out of the `OuterStripMinedLoop`. However, that only works if there is no anti-dependency in the `OuterStripMinedLoop`.
>> 
>> 4) Detect duplicate loads in the `OuterStripMinedLoop` on creation in `PhaseIdealLoop::split_if_with_blocks` and merge them right away.
>> 
>> I've decided to go with 4) and also reverted the fix for JDK-8249607 which is no longer required.
>> 
>> As Roland and Christian already noticed, there are various other issues with that code that hopefully will be addressed at some point by [JDK-8252372](https://bugs.openjdk.java.net/browse/JDK-8252372).
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove late ctrl update

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2315

From kvn at openjdk.java.net  Fri Jan 29 19:31:46 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 29 Jan 2021 19:31:46 GMT
Subject: RFR: 8260577: Unused code in AbstractCompiler after Shark
 compiler removal [v3]
In-Reply-To: <s7UfO16vOyl_f08N2yiUwQ31eNj3l3TAAzcI1q_WXAg=.143764f1-8273-4c38-8b76-5e8bf9445c0a@github.com>
References: <CPa6az52TajrWcI_bwAFHcRRS-4srQNbc0EjakDpgHY=.33ad0d64-904d-455f-913d-51a4fd405bc3@github.com>
 <s7UfO16vOyl_f08N2yiUwQ31eNj3l3TAAzcI1q_WXAg=.143764f1-8273-4c38-8b76-5e8bf9445c0a@github.com>
Message-ID: <6Dzr-rCwYfZsFCZGf-JhNzlDqyqtQWRziOKTtvFbqNY=.ea8aeb54-eb1c-49e8-b3ed-bfb4d3fb047f@github.com>

On Fri, 29 Jan 2021 07:30:00 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> After removal of the Shark compiler with [JDK-8171853](https://bugs.openjdk.java.net/browse/JDK-8171853) in JDK 10, some methods in AbstractCompiler are unused.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Removed CICompileNatives and CICompileOSR"
>   
>   This reverts commit a95c358687495ee1ed701cd10d48a3a9c6a45f26.

Looks good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2281

From dlong at openjdk.java.net  Fri Jan 29 20:11:42 2021
From: dlong at openjdk.java.net (Dean Long)
Date: Fri, 29 Jan 2021 20:11:42 GMT
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers
In-Reply-To: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
Message-ID: <gkYDr4l-AQBjXzC3Te7uQhPj9obSHmknNeZm-8BRKfk=.4df1dab4-cc3a-45f3-a4d9-160e72088553@github.com>

On Thu, 28 Jan 2021 13:01:07 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> This is a typo introduced by JDK-8255949.
> Compiler will generate `ushr` for shifting right and accumulating four short integers.
> It produces wrong results for specific case. The instruction should be `usra`.

Marked as reviewed by dlong (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk16/pull/136

From dlong at openjdk.java.net  Fri Jan 29 20:26:48 2021
From: dlong at openjdk.java.net (Dean Long)
Date: Fri, 29 Jan 2021 20:26:48 GMT
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers
In-Reply-To: <gkYDr4l-AQBjXzC3Te7uQhPj9obSHmknNeZm-8BRKfk=.4df1dab4-cc3a-45f3-a4d9-160e72088553@github.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
 <gkYDr4l-AQBjXzC3Te7uQhPj9obSHmknNeZm-8BRKfk=.4df1dab4-cc3a-45f3-a4d9-160e72088553@github.com>
Message-ID: <hNpWahWQY5FuYv1v768j0T8PQICpq6SDRiahJP41IfY=.a5f4f53e-6476-4879-9e54-53a63e796cfc@github.com>

On Fri, 29 Jan 2021 20:08:36 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This is a typo introduced by JDK-8255949.
>> Compiler will generate `ushr` for shifting right and accumulating four short integers.
>> It produces wrong results for specific case. The instruction should be `usra`.
>
> Marked as reviewed by dlong (Reviewer).

Why didn't the testing for JDK-8255949 catch this?  Do you need to fix the regression test too?

-------------

PR: https://git.openjdk.java.net/jdk16/pull/136

From kvn at openjdk.java.net  Fri Jan 29 20:33:46 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 29 Jan 2021 20:33:46 GMT
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers
In-Reply-To: <hNpWahWQY5FuYv1v768j0T8PQICpq6SDRiahJP41IfY=.a5f4f53e-6476-4879-9e54-53a63e796cfc@github.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
 <gkYDr4l-AQBjXzC3Te7uQhPj9obSHmknNeZm-8BRKfk=.4df1dab4-cc3a-45f3-a4d9-160e72088553@github.com>
 <hNpWahWQY5FuYv1v768j0T8PQICpq6SDRiahJP41IfY=.a5f4f53e-6476-4879-9e54-53a63e796cfc@github.com>
Message-ID: <dcfzzX2_xV6ZrSLkIZdJoL03fj1_BeO6CrIk-f-XZ0w=.b8a4f4f6-094a-475f-9ee8-ccd491ec9042@github.com>

On Fri, 29 Jan 2021 20:24:05 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Marked as reviewed by dlong (Reviewer).
>
> Why didn't the testing for JDK-8255949 catch this?  Do you need to fix the regression test too?

Yes, we need regression test for this fix. Or modify existing one to catch it.

-------------

PR: https://git.openjdk.java.net/jdk16/pull/136

From smonteith at openjdk.java.net  Fri Jan 29 21:06:41 2021
From: smonteith at openjdk.java.net (Stuart Monteith)
Date: Fri, 29 Jan 2021 21:06:41 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v4]
In-Reply-To: <Me-fcQw-HzYI6OAi7MOMigwKTzn603WYm6yeVetz9Wc=.c6e9a6d5-9f13-4010-a037-124dda6bf530@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <rdtmz-1qWqPh036NjaVt6BXeVZdHuIJOFCpnVIkoI4I=.e503ab3b-5259-40f6-b056-976d0efa5ae5@github.com>
 <zBnzf7Me1OV3TVIDvrbNQrr-pxgFSeRcTASH6wNCXGs=.81d032d4-2503-47b1-8c48-651ecf35f7fa@github.com>
 <Me-fcQw-HzYI6OAi7MOMigwKTzn603WYm6yeVetz9Wc=.c6e9a6d5-9f13-4010-a037-124dda6bf530@github.com>
Message-ID: <9WQB6haJP9fXJNp2yEPX3L9S7KQWznjuFrDxDGpEANE=.121fcca5-1f77-414d-8ba5-fe427281867c@github.com>

On Fri, 29 Jan 2021 02:14:06 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/vectorapi/VectorReshapeTest.java line 40:
>> 
>>> 38:  * @modules jdk.incubator.vector
>>> 39:  * @modules java.base/jdk.internal.vm.annotation
>>> 40:  * @run main/othervm -XX:CompileCommand=compileonly,jdk/incubator/vector/ByteVector.fromByteBuffer
>> 
>> -XX:CompileCommand=compileonly,jdk/incubator/vector/ByteVector.fromByteBuffer restricts the compilation to a single method for diagnostic purposes. The test runs much quicker without it, and still reproduces the issue.
>
> The test is changed to 'testng' mode, remove option compileonly will make the test pass the assert in jtreg test framework. But add the option will make it fail the assert.  So the option is left unchanged.

I accept that - running it away from standalone does change the behaviour sufficiently that the CompileCommand is necessary to run the test (the standalone test was developed without the CompileCommand being necessary).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From dcubed at openjdk.java.net  Fri Jan 29 23:00:53 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 29 Jan 2021 23:00:53 GMT
Subject: RFR: 8260674: ProblemList jdk/incubator/vector/VectorHash.java in
 Xcomp configs
Message-ID: <NBN_e7YKZGnTy_XDLzFJIZXINnPMV0H64hs0sgGEDhk=.ff314498-a696-484c-b3f2-e5bf2506c1ed@github.com>

A trivial fix to ProblemList jdk/incubator/vector/VectorHash.java in Xcomp configs.
I'm trying to reduce the noise is in the CI.

-------------

Commit messages:
 - 8260674: ProblemList jdk/incubator/vector/VectorHash.java in Xcomp configs

Changes: https://git.openjdk.java.net/jdk/pull/2321/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2321&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260674
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2321.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2321/head:pull/2321

PR: https://git.openjdk.java.net/jdk/pull/2321

From vlivanov at openjdk.java.net  Fri Jan 29 23:08:42 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 29 Jan 2021 23:08:42 GMT
Subject: RFR: 8260674: ProblemList jdk/incubator/vector/VectorHash.java in
 Xcomp configs
In-Reply-To: <NBN_e7YKZGnTy_XDLzFJIZXINnPMV0H64hs0sgGEDhk=.ff314498-a696-484c-b3f2-e5bf2506c1ed@github.com>
References: <NBN_e7YKZGnTy_XDLzFJIZXINnPMV0H64hs0sgGEDhk=.ff314498-a696-484c-b3f2-e5bf2506c1ed@github.com>
Message-ID: <k6TsjLprkb39omzf8rE7t6-3KaBlx68jcImfurAtt1w=.fe3d1a1a-c226-474c-b209-1891d4a95698@github.com>

On Fri, 29 Jan 2021 22:56:10 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/incubator/vector/VectorHash.java in Xcomp configs.
> I'm trying to reduce the noise is in the CI.

Looks good and trivial

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2321

From dcubed at openjdk.java.net  Fri Jan 29 23:16:40 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 29 Jan 2021 23:16:40 GMT
Subject: RFR: 8260674: ProblemList jdk/incubator/vector/VectorHash.java in
 Xcomp configs
In-Reply-To: <k6TsjLprkb39omzf8rE7t6-3KaBlx68jcImfurAtt1w=.fe3d1a1a-c226-474c-b209-1891d4a95698@github.com>
References: <NBN_e7YKZGnTy_XDLzFJIZXINnPMV0H64hs0sgGEDhk=.ff314498-a696-484c-b3f2-e5bf2506c1ed@github.com>
 <k6TsjLprkb39omzf8rE7t6-3KaBlx68jcImfurAtt1w=.fe3d1a1a-c226-474c-b209-1891d4a95698@github.com>
Message-ID: <gVjCS63AqgtTBx__Bb1ASffs-NkDHyPC7qOzqXObVAM=.5e84a140-5549-4ee1-8534-a685225ff399@github.com>

On Fri, 29 Jan 2021 23:05:49 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> A trivial fix to ProblemList jdk/incubator/vector/VectorHash.java in Xcomp configs.
>> I'm trying to reduce the noise is in the CI.
>
> Looks good and trivial

@iwanowww - Thanks for the fast review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2321

From dcubed at openjdk.java.net  Sat Jan 30 00:59:41 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 30 Jan 2021 00:59:41 GMT
Subject: Integrated: 8260674: ProblemList jdk/incubator/vector/VectorHash.java
 in Xcomp configs
In-Reply-To: <NBN_e7YKZGnTy_XDLzFJIZXINnPMV0H64hs0sgGEDhk=.ff314498-a696-484c-b3f2-e5bf2506c1ed@github.com>
References: <NBN_e7YKZGnTy_XDLzFJIZXINnPMV0H64hs0sgGEDhk=.ff314498-a696-484c-b3f2-e5bf2506c1ed@github.com>
Message-ID: <FkcuisvB28T8YlNkN9mduyjj0ELEqX2HlXtmiaDI9rE=.816a8926-3a1e-4655-9d05-8fa8530bb581@github.com>

On Fri, 29 Jan 2021 22:56:10 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/incubator/vector/VectorHash.java in Xcomp configs.
> I'm trying to reduce the noise in the CI.

This pull request has now been integrated.

Changeset: fb46c910
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fb46c910
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8260674: ProblemList jdk/incubator/vector/VectorHash.java in Xcomp configs

Reviewed-by: vlivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/2321

From dongbo at openjdk.java.net  Sat Jan 30 05:07:08 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Sat, 30 Jan 2021 05:07:08 GMT
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers [v2]
In-Reply-To: <dcfzzX2_xV6ZrSLkIZdJoL03fj1_BeO6CrIk-f-XZ0w=.b8a4f4f6-094a-475f-9ee8-ccd491ec9042@github.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
 <gkYDr4l-AQBjXzC3Te7uQhPj9obSHmknNeZm-8BRKfk=.4df1dab4-cc3a-45f3-a4d9-160e72088553@github.com>
 <hNpWahWQY5FuYv1v768j0T8PQICpq6SDRiahJP41IfY=.a5f4f53e-6476-4879-9e54-53a63e796cfc@github.com>
 <dcfzzX2_xV6ZrSLkIZdJoL03fj1_BeO6CrIk-f-XZ0w=.b8a4f4f6-094a-475f-9ee8-ccd491ec9042@github.com>
Message-ID: <AQEAN6KcNC9S4AHg2Voyu9SsUlNXDh5ThUDOailTFMA=.3b9c1a70-7436-4306-bc6d-a5e3d91f9166@github.com>

On Fri, 29 Jan 2021 20:31:16 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Why didn't the testing for JDK-8255949 catch this?  Do you need to fix the regression test too?
>
> Yes, we need regression test for this fix. Or modify existing one to catch it.

Did not run local tests for small loops in JDK-8255949.
Updated a test for all shift and accumulating operations which can catch this.

-------------

PR: https://git.openjdk.java.net/jdk16/pull/136

From dongbo at openjdk.java.net  Sat Jan 30 05:07:08 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Sat, 30 Jan 2021 05:07:08 GMT
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers [v2]
In-Reply-To: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
Message-ID: <rbNLvEZJjVxsg4XzoHlx9iR4qzqER9HdbqBEYK_THWU=.c63131e8-8334-4378-a4f0-9639269bc7c4@github.com>

> This is a typo introduced by JDK-8255949.
> Compiler will generate `ushr` for shifting right and accumulating four short integers.
> It produces wrong results for specific case. The instruction should be `usra`.

Dong Bo has updated the pull request incrementally with two additional commits since the last revision:

 - fix trailing whitespace
 - add tests for shift right and accumulate

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/136/files
  - new: https://git.openjdk.java.net/jdk16/pull/136/files/d97281ab..f212c5e6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=136&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=136&range=00-01

  Stats: 196 lines in 1 file changed: 196 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/136.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/136/head:pull/136

PR: https://git.openjdk.java.net/jdk16/pull/136

From github.com+25214855+casparcwang at openjdk.java.net  Sat Jan 30 12:08:56 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Sat, 30 Jan 2021 12:08:56 GMT
Subject: [jdk16] RFR: 8260473: [vector] ZGC: VectorReshape test produces
 incorrect results =?UTF-8?B?4oCm?=
In-Reply-To: <5OfnHC5N00VVv3pWcU9gsAHa23RbAAX7ReEw9Ct6eug=.4f095083-7050-487d-94e0-3befce6744c5@github.com>
References: <5OfnHC5N00VVv3pWcU9gsAHa23RbAAX7ReEw9Ct6eug=.4f095083-7050-487d-94e0-3befce6744c5@github.com>
Message-ID: <_Sakvj07dhVSGp-YnE5Tvu-Yb_WBI5Oo4ODNlTOP-XY=.853eddb8-a2a6-4371-bb41-380caf16a3da@github.com>

On Sat, 30 Jan 2021 12:02:25 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

> ?with ZGC enabled
> 
> https://bugs.openjdk.java.net/browse/JDK-8260473
> 
> Function "PhaseVector::expand_vunbox_node" creates a LoadNode, but forgets to make the LoadNode to pass gc barriers.
> 
> Testing: all Vector API related tests have passed.
> 
> Original pr: https://github.com/openjdk/jdk/pull/2253

-------------

PR: https://git.openjdk.java.net/jdk16/pull/139

From github.com+25214855+casparcwang at openjdk.java.net  Sat Jan 30 12:08:55 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Sat, 30 Jan 2021 12:08:55 GMT
Subject: [jdk16] RFR: 8260473: [vector] ZGC: VectorReshape test produces
 incorrect results =?UTF-8?B?4oCm?=
Message-ID: <5OfnHC5N00VVv3pWcU9gsAHa23RbAAX7ReEw9Ct6eug=.4f095083-7050-487d-94e0-3befce6744c5@github.com>

?with ZGC enabled

https://bugs.openjdk.java.net/browse/JDK-8260473

Function "PhaseVector::expand_vunbox_node" creates a LoadNode, but forgets to make the LoadNode to pass gc barriers.

Testing: all Vector API related tests have passed.

Original pr: https://github.com/openjdk/jdk/pull/2253

-------------

Commit messages:
 - 8260473: [vector] ZGC: VectorReshape test produces incorrect results with ZGC enabled

Changes: https://git.openjdk.java.net/jdk16/pull/139/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=139&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260473
  Stats: 174 lines in 2 files changed: 165 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/139.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/139/head:pull/139

PR: https://git.openjdk.java.net/jdk16/pull/139

From github.com+25214855+casparcwang at openjdk.java.net  Sat Jan 30 12:14:41 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Sat, 30 Jan 2021 12:14:41 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v7]
In-Reply-To: <x9QwadDTw4Wq1Xqx4aVDx7lDeha1WA-6hiFd9UoFaMU=.370c7738-f3ac-4be1-89cf-16f3310c7dab@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <mPKKzESQWrPm8Sn-2K_QJibH4_59x5k5c550SMh0sws=.0ed12218-71b3-49e8-a879-6d58f12046d3@github.com>
 <3qxMI_2q1rdcDoLFZ5Qil__d_shHCQaAkVU39VAGPdU=.9fbb67fa-a195-49d6-aa20-5991f34b61d0@github.com>
 <x9QwadDTw4Wq1Xqx4aVDx7lDeha1WA-6hiFd9UoFaMU=.370c7738-f3ac-4be1-89cf-16f3310c7dab@github.com>
Message-ID: <J9dWK9x7spsLS5M0hQlSPdXf5Cw7fagQw9YN3Ux5Seo=.fcd1f17a-6de4-49b6-812b-03ab072bb9c2@github.com>

On Fri, 29 Jan 2021 16:42:05 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/hotspot/share/opto/vector.cpp line 419:
>> 
>>> 417:     Node* vec_field_ld;
>>> 418:     {
>>> 419:       DecoratorSet decorators = C2_READ_ACCESS | C2_CONTROL_DEPENDENT_LOAD | IN_HEAP;
>> 
>> C2_READ_ACCESS will be set by "bs->load_at" so you can skip that. 
>> MO_UNORDERED is missing. That corresponds to "MemNode::unordered" in the original code.
>
> `C2_CONTROL_DEPENDENT_LOAD` is also redundant (though original code does that): it's just a plain load from a final instance field).

Fixed in the new pr: https://github.com/openjdk/jdk16/pull/139

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From github.com+25214855+casparcwang at openjdk.java.net  Sat Jan 30 12:18:41 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Sat, 30 Jan 2021 12:18:41 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v4]
In-Reply-To: <aEy95Uxy52lpFSDzmlCE9nilQ-S0G_W40FLOe-Z4THA=.16c0bb89-412c-43d6-a241-6125698d453a@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <rdtmz-1qWqPh036NjaVt6BXeVZdHuIJOFCpnVIkoI4I=.e503ab3b-5259-40f6-b056-976d0efa5ae5@github.com>
 <zBnzf7Me1OV3TVIDvrbNQrr-pxgFSeRcTASH6wNCXGs=.81d032d4-2503-47b1-8c48-651ecf35f7fa@github.com>
 <iYbXJvVqZy-ZetNKrrbPTT0jLTCrj_DEjBKPv8ckHVs=.b2263634-62a4-40a4-9ab8-248e3081dbb4@github.com>
 <Sm5e0TdFCKQztHlJGCs6Tsxc5AEpv711D_XBy_iLDs4=.940eabf1-69e9-4c67-a758-55f564f102dd@github.com>
 <j3eZ95EoTA292mgew_cghhGuaFTfJW0J5Fon27G2ibQ=.fa233153-a19e-4b28-869a-2299786178eb@github.com>
 <aEy95Uxy52lpFSDzmlCE9nilQ-S0G_W40FLOe-Z4THA=.16c0bb89-412c-43d6-a241-6125698d453a@github.com>
Message-ID: <s2MGmaX0AB5NlXYWii0yeFX00chKnDQLduWQydsAqEo=.8085e1fa-ace0-4455-923b-0e2e781b6334@github.com>

On Fri, 29 Jan 2021 16:47:53 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> > As far as I can see, during the parse phase, GraphKit contains the jvm state info which can be used to get the control and memory for creating new nodes. But during optimization, the jvm state info may be missing like the situation in PhaseVector::optimize_vector_boxes or Macro Expansion.
> 
> JVM state is irrelevant here (otherwise, `VectorUnbox` node would have captured relevant info during construction). What is actually missing is `GraphKit` instance lacks info about control and memory. You need to explicitly set it using `GraphKit::set_control()` and `GraphKit::set_all_memory()`.

Thank you for the explanation. @iwanowww 

> We need this patch to be based on the JDK 16 repository.
> 
> I will help out with the fix-request and sponsor-ship.

Thank you very much. @neliasso 
I have create a new patch based on JDK16 repo: https://github.com/openjdk/jdk16/pull/139

-------------

PR: https://git.openjdk.java.net/jdk/pull/2253

From dcubed at openjdk.java.net  Sat Jan 30 15:20:51 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 30 Jan 2021 15:20:51 GMT
Subject: RFR: 8260685: ProblemList 2 compiler/jvmci/compilerToVM tests in
 Xcomp configs
Message-ID: <v4RbI3f0G3ZbGKAl1luKIu-1w_jfD6McReGlxH2BCpw=.90fb4df9-18ea-4565-81da-89e26ff25529@github.com>

A trivial fix to ProblemList two tests in Xcomp configs:

compiler/jvmci/compilerToVM/IsMatureVsReprofileTest.java
compiler/jvmci/compilerToVM/IsMatureTest.java

-------------

Commit messages:
 - 8260685: ProblemList 2 compiler/jvmci/compilerToVM tests in Xcomp configs

Changes: https://git.openjdk.java.net/jdk/pull/2327/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2327&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260685
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2327.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2327/head:pull/2327

PR: https://git.openjdk.java.net/jdk/pull/2327

From dcubed at openjdk.java.net  Sat Jan 30 15:28:40 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 30 Jan 2021 15:28:40 GMT
Subject: RFR: 8260685: ProblemList 2 compiler/jvmci/compilerToVM tests in
 Xcomp configs
In-Reply-To: <1oQaeaam5G1Tha3mf0WMofQ3C5JOwTxak8aobxQ1cv4=.41cafe3a-be88-48f6-8258-091d862b5d31@github.com>
References: <v4RbI3f0G3ZbGKAl1luKIu-1w_jfD6McReGlxH2BCpw=.90fb4df9-18ea-4565-81da-89e26ff25529@github.com>
 <1oQaeaam5G1Tha3mf0WMofQ3C5JOwTxak8aobxQ1cv4=.41cafe3a-be88-48f6-8258-091d862b5d31@github.com>
Message-ID: <Cobl0ivWE7yqrMxBJD8_iWy8ShCCpgAJN8ZHlxLUrWY=.83e45d93-a069-4b81-b42a-6241f2f1f1c6@github.com>

On Sat, 30 Jan 2021 15:22:09 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> A trivial fix to ProblemList two tests in Xcomp configs:
>> 
>> compiler/jvmci/compilerToVM/IsMatureVsReprofileTest.java
>> compiler/jvmci/compilerToVM/IsMatureTest.java
>
> LGTM

@iignatev - Thanks for the fast review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2327

From iignatyev at openjdk.java.net  Sat Jan 30 15:28:40 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 30 Jan 2021 15:28:40 GMT
Subject: RFR: 8260685: ProblemList 2 compiler/jvmci/compilerToVM tests in
 Xcomp configs
In-Reply-To: <v4RbI3f0G3ZbGKAl1luKIu-1w_jfD6McReGlxH2BCpw=.90fb4df9-18ea-4565-81da-89e26ff25529@github.com>
References: <v4RbI3f0G3ZbGKAl1luKIu-1w_jfD6McReGlxH2BCpw=.90fb4df9-18ea-4565-81da-89e26ff25529@github.com>
Message-ID: <1oQaeaam5G1Tha3mf0WMofQ3C5JOwTxak8aobxQ1cv4=.41cafe3a-be88-48f6-8258-091d862b5d31@github.com>

On Sat, 30 Jan 2021 15:15:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList two tests in Xcomp configs:
> 
> compiler/jvmci/compilerToVM/IsMatureVsReprofileTest.java
> compiler/jvmci/compilerToVM/IsMatureTest.java

LGTM

-------------

Marked as reviewed by iignatyev (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2327

From dcubed at openjdk.java.net  Sat Jan 30 15:28:41 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 30 Jan 2021 15:28:41 GMT
Subject: Integrated: 8260685: ProblemList 2 compiler/jvmci/compilerToVM tests
 in Xcomp configs
In-Reply-To: <v4RbI3f0G3ZbGKAl1luKIu-1w_jfD6McReGlxH2BCpw=.90fb4df9-18ea-4565-81da-89e26ff25529@github.com>
References: <v4RbI3f0G3ZbGKAl1luKIu-1w_jfD6McReGlxH2BCpw=.90fb4df9-18ea-4565-81da-89e26ff25529@github.com>
Message-ID: <GMagJ0VGXbUBC934_Y4OVhBgmxT1fjgRpcY0tg7yiTE=.09aef083-8f5c-4464-827d-cc3519e3b160@github.com>

On Sat, 30 Jan 2021 15:15:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList two tests in Xcomp configs:
> 
> compiler/jvmci/compilerToVM/IsMatureVsReprofileTest.java
> compiler/jvmci/compilerToVM/IsMatureTest.java

This pull request has now been integrated.

Changeset: a61ff87c
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a61ff87c
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8260685: ProblemList 2 compiler/jvmci/compilerToVM tests in Xcomp configs

Reviewed-by: iignatyev

-------------

PR: https://git.openjdk.java.net/jdk/pull/2327

From vlivanov at openjdk.java.net  Sat Jan 30 18:06:45 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Sat, 30 Jan 2021 18:06:45 GMT
Subject: RFR: 8260501: [Vector API] Improve register usage for shift
 operations on x86 [v2]
In-Reply-To: <9DkaMJLyY1JEVVs7D1KfIjVQaIGyW-esEISk4zIPNs8=.3395e43c-28e0-47bf-910b-4cb4fff78e9e@github.com>
References: <eiKG7lnaASe7574tjTNKvcokiwA1mkp_c8rD6VK2iPI=.12a4a3c1-970f-4ce2-9d6c-1a0057a2f207@github.com>
 <KlokyrB2xpITspayhUgkmckPj8cB1M-jpkWfv1PSuAo=.ef99265d-0dc4-4dbe-b037-79dcaad77307@github.com>
 <mnBR-fYOjbg0Sjd-8OdFnhYVCFuOvY-lXx59m6Ho2F0=.e434f482-5c1b-4b07-add7-755b0b9799f8@github.com>
 <9DkaMJLyY1JEVVs7D1KfIjVQaIGyW-esEISk4zIPNs8=.3395e43c-28e0-47bf-910b-4cb4fff78e9e@github.com>
Message-ID: <QT1S7UDnp5bJBDflM3_430TEf3QF_0gpn8LFe2s47h0=.f0983b6b-e439-4cdd-b0d4-5eef107553d5@github.com>

On Thu, 28 Jan 2021 22:56:43 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Looks fine to me.
>> @iwanowww please submit mach5 testing for this change before integration.
>
>> Looks fine to me.
>> @iwanowww please submit mach5 testing for this change before integration.
> 
> Thanks @vnkozlov for your review.
> 
> @iwanowww , please let me know if it's OK on mach5.
> Thanks.

Test results (hs-tier1 - hs-tier4) are good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2257

From vlivanov at openjdk.java.net  Sat Jan 30 18:06:49 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Sat, 30 Jan 2021 18:06:49 GMT
Subject: [jdk16] RFR: 8260473: [vector] ZGC: VectorReshape test produces
 incorrect results with ZGC enabled
In-Reply-To: <5OfnHC5N00VVv3pWcU9gsAHa23RbAAX7ReEw9Ct6eug=.4f095083-7050-487d-94e0-3befce6744c5@github.com>
References: <5OfnHC5N00VVv3pWcU9gsAHa23RbAAX7ReEw9Ct6eug=.4f095083-7050-487d-94e0-3befce6744c5@github.com>
Message-ID: <AnmJJ1iKY2JuCYo2Ks5scQIteJOxfEqw2FdN7c2j8cE=.fb5329d5-2973-40d1-83c6-ad5f09ab188b@github.com>

On Sat, 30 Jan 2021 12:02:25 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8260473
> 
> Function "PhaseVector::expand_vunbox_node" creates a LoadNode, but forgets to make the LoadNode to pass gc barriers.
> 
> Testing: all Vector API related tests have passed.
> 
> Original pr: https://github.com/openjdk/jdk/pull/2253

Overall, looks good.

test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java line 47:

> 45:  * @modules java.base/jdk.internal.vm.annotation
> 46:  * @run testng/othervm -XX:CompileCommand=compileonly,jdk/incubator/vector/ByteVector.fromByteBuffer
> 47:  *      -XX:-TieredCompilation -XX:CICompilerCount=1 -XX:+UseZGC -Xbatch -Xmx256m VectorRebracket128Test

Why `-XX:CICompilerCount=1` and `-Xmx256m` are needed?

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/139

From jiefu at openjdk.java.net  Sun Jan 31 00:31:42 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sun, 31 Jan 2021 00:31:42 GMT
Subject: RFR: 8260501: [Vector API] Improve register usage for shift
 operations on x86 [v2]
In-Reply-To: <QT1S7UDnp5bJBDflM3_430TEf3QF_0gpn8LFe2s47h0=.f0983b6b-e439-4cdd-b0d4-5eef107553d5@github.com>
References: <eiKG7lnaASe7574tjTNKvcokiwA1mkp_c8rD6VK2iPI=.12a4a3c1-970f-4ce2-9d6c-1a0057a2f207@github.com>
 <KlokyrB2xpITspayhUgkmckPj8cB1M-jpkWfv1PSuAo=.ef99265d-0dc4-4dbe-b037-79dcaad77307@github.com>
 <mnBR-fYOjbg0Sjd-8OdFnhYVCFuOvY-lXx59m6Ho2F0=.e434f482-5c1b-4b07-add7-755b0b9799f8@github.com>
 <9DkaMJLyY1JEVVs7D1KfIjVQaIGyW-esEISk4zIPNs8=.3395e43c-28e0-47bf-910b-4cb4fff78e9e@github.com>
 <QT1S7UDnp5bJBDflM3_430TEf3QF_0gpn8LFe2s47h0=.f0983b6b-e439-4cdd-b0d4-5eef107553d5@github.com>
Message-ID: <xd6EuFfL9wAOanqYEM7IqaSTOmIS4c5NxuqBy5DNFbA=.11893c81-d04a-43c8-95f5-9c4a0b72804a@github.com>

On Sat, 30 Jan 2021 17:38:33 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>>> Looks fine to me.
>>> @iwanowww please submit mach5 testing for this change before integration.
>> 
>> Thanks @vnkozlov for your review.
>> 
>> @iwanowww , please let me know if it's OK on mach5.
>> Thanks.
>
> Test results (hs-tier1 - hs-tier4) are good.

Thanks @iwanowww .

-------------

PR: https://git.openjdk.java.net/jdk/pull/2257

From jiefu at openjdk.java.net  Sun Jan 31 00:31:43 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sun, 31 Jan 2021 00:31:43 GMT
Subject: Integrated: 8260501: [Vector API] Improve register usage for shift
 operations on x86
In-Reply-To: <eiKG7lnaASe7574tjTNKvcokiwA1mkp_c8rD6VK2iPI=.12a4a3c1-970f-4ce2-9d6c-1a0057a2f207@github.com>
References: <eiKG7lnaASe7574tjTNKvcokiwA1mkp_c8rD6VK2iPI=.12a4a3c1-970f-4ce2-9d6c-1a0057a2f207@github.com>
Message-ID: <4_FK7rOiuZmzowGWI51RtGjiUagl17NNNY5al94hLUg=.02a04125-2776-4fec-a1c2-aa25dcd4cb39@github.com>

On Wed, 27 Jan 2021 11:52:54 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> I found the register usage is less optimized for some shift operations.
> For example, vshiftL_imm [1]/vshiftI_imm require dst != src.
> But it's actually fine for the register allocator to assign dst == src.
> 
> Also, vshiftL [2]/vshiftI/vshiftS require dst != src.
> But it's actually required for UseAVX==0 only.
> For the most common cases (UseAVX > 0), it's fine to assign dst == src.
> 
> The fix splits vshiftS/vshiftI/vshiftL into UseAVX > 0 and UseAVX == 0 cases.
> And just removes the unreasonable requirement for vshiftI_imm and vshiftL_imm. 
> 
> Testing:
>   - jdk/incubator/vector/ on x64 with UseAVX=3/2/1/0, no regression
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L6058
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L6037

This pull request has now been integrated.

Changeset: 0da9cad5
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0da9cad5
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8260501: [Vector API] Improve register usage for shift operations on x86

Reviewed-by: vlivanov, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/2257

From jiefu at openjdk.java.net  Sun Jan 31 00:43:46 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sun, 31 Jan 2021 00:43:46 GMT
Subject: [jdk16] RFR: 8260473: [vector] ZGC: VectorReshape test produces
 incorrect results with ZGC enabled
In-Reply-To: <AnmJJ1iKY2JuCYo2Ks5scQIteJOxfEqw2FdN7c2j8cE=.fb5329d5-2973-40d1-83c6-ad5f09ab188b@github.com>
References: <5OfnHC5N00VVv3pWcU9gsAHa23RbAAX7ReEw9Ct6eug=.4f095083-7050-487d-94e0-3befce6744c5@github.com>
 <AnmJJ1iKY2JuCYo2Ks5scQIteJOxfEqw2FdN7c2j8cE=.fb5329d5-2973-40d1-83c6-ad5f09ab188b@github.com>
Message-ID: <INg3qtMQAPPNQZ30DZm9XqB-7BKjgh3nigpQVzlP1pE=.99521b3a-8f2b-4c66-9ae8-c83a0007f53c@github.com>

On Sat, 30 Jan 2021 17:33:08 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Why `-XX:CICompilerCount=1` and `-Xmx256m` are needed?

Thanks @iwanowww for your review.

I discussed the same question with @casparcwang offline.
The reason is:
 - Small heap (-Xmx256m) will help to trigger a gc.
 - compileonly and compilercount=1 will let the VM run slow enough to wait for a gc to be finished.
 
And @casparcwang told me that this bug seems not to be reproduced every time without these JVM args.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk16/pull/139

From dongbo at openjdk.java.net  Sun Jan 31 10:30:06 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Sun, 31 Jan 2021 10:30:06 GMT
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers [v3]
In-Reply-To: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
Message-ID: <HvyAy7ZfnJLdl7NkO98VwCOX9Ju4zQiJZ7AV2lNznmQ=.20283243-c16f-4e56-8153-72702a818495@github.com>

> This is a typo introduced by JDK-8255949.
> Compiler will generate `ushr` for shifting right and accumulating four short integers.
> It produces wrong results for specific case. The instruction should be `usra`.

Dong Bo has updated the pull request incrementally with one additional commit since the last revision:

  make empty ins_encode when shift >= 16 (chars)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/136/files
  - new: https://git.openjdk.java.net/jdk16/pull/136/files/f212c5e6..b7ef8fb8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=136&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=136&range=01-02

  Stats: 20 lines in 1 file changed: 0 ins; 16 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/136.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/136/head:pull/136

PR: https://git.openjdk.java.net/jdk16/pull/136

From dongbo at openjdk.java.net  Sun Jan 31 10:34:40 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Sun, 31 Jan 2021 10:34:40 GMT
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers [v3]
In-Reply-To: <AQEAN6KcNC9S4AHg2Voyu9SsUlNXDh5ThUDOailTFMA=.3b9c1a70-7436-4306-bc6d-a5e3d91f9166@github.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
 <gkYDr4l-AQBjXzC3Te7uQhPj9obSHmknNeZm-8BRKfk=.4df1dab4-cc3a-45f3-a4d9-160e72088553@github.com>
 <hNpWahWQY5FuYv1v768j0T8PQICpq6SDRiahJP41IfY=.a5f4f53e-6476-4879-9e54-53a63e796cfc@github.com>
 <dcfzzX2_xV6ZrSLkIZdJoL03fj1_BeO6CrIk-f-XZ0w=.b8a4f4f6-094a-475f-9ee8-ccd491ec9042@github.com>
 <AQEAN6KcNC9S4AHg2Voyu9SsUlNXDh5ThUDOailTFMA=.3b9c1a70-7436-4306-bc6d-a5e3d91f9166@github.com>
Message-ID: <OrMeQJItXcusPEf031k8wbL5j74RbyynGSQ3HM-1S0E=.9d440961-d955-4935-9dd8-8621052d1a35@github.com>

On Sat, 30 Jan 2021 05:01:09 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> Yes, we need regression test for this fix. Or modify existing one to catch it.
>
> Did not run local tests for small loops in JDK-8255949.
> Updated a test for all shift and accumulating operations which can catch this.

> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [hotspot-dev](mailto:hotspot-dev at openjdk.java.net):_
> 
> On 1/30/21 5:07 AM, Dong Bo wrote:
> 
> I don't understand. Looking at this:
> 
> instruct vsrla4S_imm(vecD dst, vecD src, immI shift) %{
> predicate(n->as_Vector()->length() == 4);
> match(Set dst (AddVS dst (URShiftVS src (RShiftCntV shift))));
> ins_cost(INSN_COST);
> format %{ "usra $dst, $src, $shift\t# vector (4H)" %}
> ins_encode %{
> int sh = (int)$shift$$constant;
> if (sh >= 16) {
> __ eor(as_FloatRegister($src$$reg), __ T8B,
> as_FloatRegister($src$$reg),
> as_FloatRegister($src$$reg));
> } else {
> __ usra(as_FloatRegister($dst$$reg), __ T4H,
> as_FloatRegister($src$$reg), sh);
> }
> %}
> ins_pipe(vshift64_imm);
> %}
> 
> What happens when the shift is >= 16? What happens to src and dst?
> 
> --
> Andrew Haley (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

This was wrong, both src and dst should have the same value as before.
Actually, when the shift is `>= 16`, the URShift is optimized to zero by the compiler.
So we don't have a `vsrla4S_imm` match if `shift >= 16`, the wrong `eor` is not generated.
Check the assembly code of the following test:
# test
public void shiftURightAccumulateChar() {
      for (int i = 0; i < count; i++) {
           charsD[i] = (char) (charsA[i] + (charsB[i] >>> 16));
      }
}
# assembly code, the `shift` is gone, only `move` left
1.17%  ?   0x0000ffff88075348:   ldr  q16, [x14,#16]
         ?   0x0000ffff8807534c:   add  x12, x19, x12
         ?   0x0000ffff88075350:   str  q16, [x12,#16]
  1.66%  ?   0x0000ffff88075354:   ldr  q16, [x14,#32]
         ?   0x0000ffff88075358:   str  q16, [x12,#32]
  2.03%  ?   0x0000ffff8807535c:   ldr  q16, [x14,#48]
         ?   0x0000ffff88075360:   str  q16, [x12,#48]
  1.39%  ?   0x0000ffff88075364:   ldr  q16, [x14,#64]
         ?   0x0000ffff88075368:   str  q16, [x12,#64]

-------------

PR: https://git.openjdk.java.net/jdk16/pull/136

From aph at redhat.com  Sun Jan 31 11:49:49 2021
From: aph at redhat.com (Andrew Haley)
Date: Sun, 31 Jan 2021 11:49:49 +0000
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers [v3]
In-Reply-To: <OrMeQJItXcusPEf031k8wbL5j74RbyynGSQ3HM-1S0E=.9d440961-d955-4935-9dd8-8621052d1a35@github.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
 <gkYDr4l-AQBjXzC3Te7uQhPj9obSHmknNeZm-8BRKfk=.4df1dab4-cc3a-45f3-a4d9-160e72088553@github.com>
 <hNpWahWQY5FuYv1v768j0T8PQICpq6SDRiahJP41IfY=.a5f4f53e-6476-4879-9e54-53a63e796cfc@github.com>
 <dcfzzX2_xV6ZrSLkIZdJoL03fj1_BeO6CrIk-f-XZ0w=.b8a4f4f6-094a-475f-9ee8-ccd491ec9042@github.com>
 <AQEAN6KcNC9S4AHg2Voyu9SsUlNXDh5ThUDOailTFMA=.3b9c1a70-7436-4306-bc6d-a5e3d91f9166@github.com>
 <OrMeQJItXcusPEf031k8wbL5j74RbyynGSQ3HM-1S0E=.9d440961-d955-4935-9dd8-8621052d1a35@github.com>
Message-ID: <6a306bd0-19a9-f8d2-a285-1239371f389e@redhat.com>

On 1/31/21 10:34 AM, Dong Bo wrote:
> This was wrong, both src and dst should have the same value as before.
> Actually, when the shift is `>= 16`, the URShift is optimized to zero by the compiler.
> So we don't have a `vsrla4S_imm` match if `shift >= 16`, the wrong `eor` is not generated.
> Check the assembly code of the following test:
> # test
> public void shiftURightAccumulateChar() {
>       for (int i = 0; i < count; i++) {
>            charsD[i] = (char) (charsA[i] + (charsB[i] >>> 16));
>       }
> }

We need to make sure this is in a regression test. Also, please make
sure that a shift if e.g. 35 works correctly.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From neliasso at openjdk.java.net  Sun Jan 31 21:32:46 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Sun, 31 Jan 2021 21:32:46 GMT
Subject: [jdk16] RFR: 8260473: [vector] ZGC: VectorReshape test produces
 incorrect results with ZGC enabled
In-Reply-To: <5OfnHC5N00VVv3pWcU9gsAHa23RbAAX7ReEw9Ct6eug=.4f095083-7050-487d-94e0-3befce6744c5@github.com>
References: <5OfnHC5N00VVv3pWcU9gsAHa23RbAAX7ReEw9Ct6eug=.4f095083-7050-487d-94e0-3befce6744c5@github.com>
Message-ID: <AGPNulG71oV0KAbLal6q7QtAD3p40phvXbPRAqBiu_w=.ddbd5b10-5b9a-49db-a644-5e6bf35ff5ee@github.com>

On Sat, 30 Jan 2021 12:02:25 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8260473
> 
> Function "PhaseVector::expand_vunbox_node" creates a LoadNode, but forgets to make the LoadNode to pass gc barriers.
> 
> Testing: all Vector API related tests have passed.
> 
> Original pr: https://github.com/openjdk/jdk/pull/2253

Approved. 

Now awaiting release team approval.

-------------

Marked as reviewed by neliasso (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/139