8269568: JVM crashes when running VectorMask query tests #168

XiaohongGong · 2021-06-29T08:56:44Z

This is a follow-up patch for [1]. When we are trying to add the VectorMask query implementation for Arm NEON, we found the jtreg tests for VectorMask.trueCount/firstTrue/lastTrue is not effective. The tests failure cannot be reported as expected. The main reason is that the Vector API methods are not hot enough to be compiled by C2 compiler. Wrap the main test codes inside a loop can make the tests effective.

With the tests taking effect, we can see a JVM crash due to the following assertion:

  vector/src/hotspot/share/opto/vectornode.hpp:879), pid=168241, tid=168257
  # Error: assert(mask->Opcode() == Op_VectorStoreMask) failed

The mask input might be other vector nodes like "LoadVectorNode", since there is an optimization for "VectorStoreMask":

  VectorStoreMask (VectorLoadMask value) ==> value

Changing the code to check whether its element basic type is "T_BOOLEAN" is more reasonable.

[1] https://bugs.openjdk.java.net/browse/JDK-8256973

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8269568: JVM crashes when running VectorMask query tests

Reviewers

Paul Sandoz (@PaulSandoz - Reviewer) ⚠️ Review applies to 8e3fcfa
Jie Fu (@DamonFool - Reviewer) ⚠️ Review applies to 8e3fcfa
Jatin Bhateja (@jatin-bhateja - Committer)
Sandhya Viswanathan (@sviswa7 - Reviewer)

Contributors

Sandhya Viswanathan <sviswanathan@openjdk.org>

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk17 pull/168/head:pull/168
$ git checkout pull/168

Update a local copy of the PR:
$ git checkout pull/168
$ git pull https://git.openjdk.java.net/jdk17 pull/168/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 168

View PR using the GUI difftool:
$ git pr show -t 168

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk17/pull/168.diff

bridgekeeper · 2021-06-29T09:03:48Z

👋 Welcome back xgong! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2021-06-29T09:06:14Z

@XiaohongGong The following label will be automatically applied to this pull request:

hotspot-compiler

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2021-06-29T09:10:26Z

Webrevs

DamonFool · 2021-06-29T09:48:16Z

How about the running time of these tests after the change?
Thanks.

DamonFool · 2021-06-29T11:16:31Z

The improved tests also find more bugs of vector mask operations on x86.
Would you like to fix them together?

PaulSandoz

IIRC we wrote them as smoke tests because they were not intrinsic. We need to think more carefully about converting them from smoke tests.

Ideally we should convert them to kernel tests, but that is more work. Instead we can copy the generated pattern and do the following:

move the assertion outside of the loops (it will generate garbage with string concatenation)
assert over arrays, thereby also moving the actual scalar computation result outside the loops. The simplest approach is to create an int[] array of the same length as the input and write the reduced result at index i. Thus it's sparse.

That should result in an inner loop body that is very focused on exercising the intrinsic method. It will also likely reduce the test execution times.

dean-long

Seems reasonable.

openjdk · 2021-06-29T18:04:18Z

@XiaohongGong This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8269568: JVM crashes when running VectorMask query tests

Co-authored-by: Sandhya Viswanathan <sviswanathan@openjdk.org>
Reviewed-by: psandoz, jiefu, jbhateja, sviswanathan

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 48 new commits pushed to the master branch:

0f4e07b: 8269661: JNI_GetStringCritical does not lock char array
df1364b: 8269575: C2: assert(false) failed: graph should be schedulable after JDK-8252372
6d8fc72: 8268883: C2: assert(false) failed: unscheduable graph
4ad8b04: 8268369: SIGSEGV in PhaseCFG::implicit_null_check due to missing null check
5b8e1a2: 8266595: jdk/jfr/jcmd/TestJcmdDump.java with slowdebug bits fails with AttachNotSupportedException
e14801c: 8269668: [aarch64] java.library.path not including /usr/lib64
97e0e9e: 8268775: Password is being converted to String in AccessibleJPasswordField
1c18f91: 8269768: JFR Terminology Refresh
6f0e8e7: 8269775: compiler/codegen/ClearArrayTest.java failed with "assert(false) failed: bad AD file"
c4ea13e: 8269543: The warning for System::setSecurityManager should only appear once for each caller
... and 38 more: https://git.openjdk.java.net/jdk17/compare/56240690f62f9048a45a53525efccffdec235a8d...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@PaulSandoz, @dean-long, @DamonFool, @jatin-bhateja, @sviswa7) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

XiaohongGong · 2021-06-30T01:38:06Z

How about the running time of these tests after the change?
Thanks.

I tested the running time, and seems it almost have nothing influence to the whole tests running time. Thanks!

XiaohongGong · 2021-06-30T01:41:39Z

The improved tests also find more bugs of vector mask operations on x86.
Would you like to fix them together?

Hi @DamonFool , thanks for looking at this PR! I also met the tests failures on some x86 machine. Seems something is wrong with the backend implementation. However, unfortunately I'm not very familiar with x86 instructions. So maybe @jatin-bhateja could help to take a look please? Thanks so much!

XiaohongGong · 2021-06-30T01:45:15Z

IIRC we wrote them as smoke tests because they were not intrinsic. We need to think more carefully about converting them from smoke tests.

Thanks for looking at this PR @PaulSandoz ! Yes, I think this need more work and more carefully to move them from the smoke tests. Maybe we can revisit them in future?

Ideally we should convert them to kernel tests, but that is more work. Instead we can copy the generated pattern and do the following:

move the assertion outside of the loops (it will generate garbage with string concatenation)

assert over arrays, thereby also moving the actual scalar computation result outside the loops. The simplest approach is to create an int[] array of the same length as the input and write the reduced result at index i. Thus it's sparse.

That should result in an inner loop body that is very focused on exercising the intrinsic method. It will also likely reduce the test execution times.

Agree, I will move the assertion outside of the loop first. Thanks so much!

DamonFool · 2021-06-30T13:38:57Z

The improved tests also find more bugs of vector mask operations on x86.
Would you like to fix them together?

Hi @DamonFool , thanks for looking at this PR! I also met the tests failures on some x86 machine. Seems something is wrong with the backend implementation. However, unfortunately I'm not very familiar with x86 instructions. So maybe @jatin-bhateja could help to take a look please? Thanks so much!

After some investigation, I believe the failure is caused by the incorrect code-gen for VectorStoreMask on x86.

Something like this would fix the failures:

diff --git a/src/hotspot/cpu/x86/x86.ad b/src/hotspot/cpu/x86/x86.ad
index ed34ab7..a837549 100644
--- a/src/hotspot/cpu/x86/x86.ad
+++ b/src/hotspot/cpu/x86/x86.ad
@@ -7545,29 +7545,32 @@ instruct vstoreMask2B_evex(vec dst, vec src, immI_2 size) %{
   ins_pipe( pipe_slow );
 %}

-instruct storeMask4B(vec dst, vec src, immI_4 size) %{
+instruct storeMask4B(vec dst, vec src, immI_4 size, vec tmp) %{
   predicate (vector_length(n) <= 4 && UseAVX <= 2);
   match(Set dst (VectorStoreMask src size));
   format %{ "vector_store_mask $dst,$src\t!" %}
+  effect(TEMP dst, TEMP tmp);
   ins_encode %{
     assert(UseSSE >= 3, "required");
+    __ pxor($tmp$$XMMRegister, $tmp$$XMMRegister);
     __ pabsd($dst$$XMMRegister, $src$$XMMRegister);
-    __ packssdw($dst$$XMMRegister, $dst$$XMMRegister);
-    __ packsswb($dst$$XMMRegister, $dst$$XMMRegister);
+    __ packssdw($dst$$XMMRegister, $tmp$$XMMRegister);
+    __ packsswb($dst$$XMMRegister, $tmp$$XMMRegister);
   %}
   ins_pipe( pipe_slow );
 %}

-instruct vstoreMask4B(vec dst, vec src, immI_4 size) %{
+instruct vstoreMask4B(vec dst, vec src, immI_4 size, vec tmp) %{
   predicate(vector_length(n) == 8 && UseAVX <= 2);
   match(Set dst (VectorStoreMask src size));
   format %{ "vector_store_mask $dst,$src\t!" %}
-  effect(TEMP dst);
+  effect(TEMP dst, TEMP tmp);
   ins_encode %{
     int vlen_enc = Assembler::AVX_128bit;
+    __ pxor($tmp$$XMMRegister, $tmp$$XMMRegister);
     __ vextracti128($dst$$XMMRegister, $src$$XMMRegister, 0x1);
     __ vpackssdw($dst$$XMMRegister, $src$$XMMRegister, $dst$$XMMRegister, vlen_enc);
-    __ vpacksswb($dst$$XMMRegister, $dst$$XMMRegister, $dst$$XMMRegister, vlen_enc);
+    __ vpacksswb($dst$$XMMRegister, $dst$$XMMRegister, $tmp$$XMMRegister, vlen_enc);
     __ vpabsb($dst$$XMMRegister, $dst$$XMMRegister, vlen_enc);
   %}
   ins_pipe( pipe_slow );
@@ -7613,8 +7616,9 @@ instruct storeMask8B_avx(vec dst, vec src, immI_8 size, legVec vtmp) %{
     __ vpshufps($dst$$XMMRegister, $src$$XMMRegister, $src$$XMMRegister, 0x88, Assembler::AVX_256bit);
     __ vextracti128($vtmp$$XMMRegister, $dst$$XMMRegister, 0x1);
     __ vblendps($dst$$XMMRegister, $dst$$XMMRegister, $vtmp$$XMMRegister, 0xC, vlen_enc);
-    __ vpackssdw($dst$$XMMRegister, $dst$$XMMRegister, $dst$$XMMRegister, vlen_enc);
-    __ vpacksswb($dst$$XMMRegister, $dst$$XMMRegister, $dst$$XMMRegister, vlen_enc);
+    __ pxor($vtmp$$XMMRegister, $vtmp$$XMMRegister);
+    __ vpackssdw($dst$$XMMRegister, $dst$$XMMRegister, $vtmp$$XMMRegister, vlen_enc);
+    __ vpacksswb($dst$$XMMRegister, $dst$$XMMRegister, $vtmp$$XMMRegister, vlen_enc);
     __ vpabsb($dst$$XMMRegister, $dst$$XMMRegister, vlen_enc);
   %}
   ins_pipe( pipe_slow );

But I'm afraid there are more rules which need to be fixed.
So I've filed JDK-8269679.

Please feel free to go ahead.
Thanks.

dean-long

I am seeing testing failures.

sviswa7 · 2021-06-30T23:37:44Z

@XiaohongGong The following should fix this for x86:

diff --git a/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp b/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
index 147bcb8..b548877 100644
--- a/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
+++ b/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
@@ -3870,6 +3870,9 @@ void C2_MacroAssembler::vector_mask_operation(int opc, Register dst, XMMRegister
   vpsubb(xtmp, xtmp, mask, vec_enc);
   evpmovb2m(ktmp, xtmp, vec_enc);
   kmovql(tmp, ktmp);
+  if (masklen < 64) {
+    andq(tmp, (((jlong)1 << masklen) - 1));
+  }
   switch(opc) {
     case Op_VectorMaskTrueCount:
       popcntq(dst, tmp);
@@ -3894,6 +3897,9 @@ void C2_MacroAssembler::vector_mask_operation(int opc, Register dst, XMMRegister
   vpxor(xtmp, xtmp, xtmp, vec_enc);
   vpsubb(xtmp, xtmp, mask, vec_enc);
   vpmovmskb(tmp, xtmp, vec_enc);
+  if (masklen < 64) {
+    andq(tmp, (((jlong)1 << masklen) - 1));
+  }
   switch(opc) {
     case Op_VectorMaskTrueCount:
       popcntq(dst, tmp);

Please include this in your PR.

DamonFool · 2021-07-01T00:14:08Z

@XiaohongGong The following should fix this for x86:

diff --git a/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp b/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
index 147bcb8..b548877 100644
--- a/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
+++ b/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
@@ -3870,6 +3870,9 @@ void C2_MacroAssembler::vector_mask_operation(int opc, Register dst, XMMRegister
   vpsubb(xtmp, xtmp, mask, vec_enc);
   evpmovb2m(ktmp, xtmp, vec_enc);
   kmovql(tmp, ktmp);
+  if (masklen < 64) {
+    andq(tmp, (((jlong)1 << masklen) - 1));
+  }
   switch(opc) {
     case Op_VectorMaskTrueCount:
       popcntq(dst, tmp);
@@ -3894,6 +3897,9 @@ void C2_MacroAssembler::vector_mask_operation(int opc, Register dst, XMMRegister
   vpxor(xtmp, xtmp, xtmp, vec_enc);
   vpsubb(xtmp, xtmp, mask, vec_enc);
   vpmovmskb(tmp, xtmp, vec_enc);
+  if (masklen < 64) {
+    andq(tmp, (((jlong)1 << masklen) - 1));
+  }
   switch(opc) {
     case Op_VectorMaskTrueCount:
       popcntq(dst, tmp);

Please include this in your PR.

The fix seems to be tricky.
So do you think we need to change the code-gen like this #168 (comment) ? @sviswa7

sviswa7 · 2021-07-01T00:20:36Z

@DamonFool This is the cleanest solution I could think of.
The problem comes only with newly added intrinsic where firstTrue, lastTrue, trueCount become consumers to VectorStoreMask. All the other consumers of VectorStoreMask consume the right number of bits.
The fix is to make the new intrinsic also consume the right number of bits by doing the 'and' masking.

DamonFool · 2021-07-01T00:25:27Z

@DamonFool This is the cleanest solution I could think of.
The problem comes only with newly added intrinsic where firstTrue, lastTrue, trueCount become consumers to VectorStoreMask. All the other consumers of VectorStoreMask consume the right number of bits.
The fix is to make the new intrinsic also consume the right number of bits by doing the 'and' masking.

But we actually do not and masking with AVX3.
So I'm afraid the root cause is the incorrect code-gen for VectorStoreMask.

sviswa7 · 2021-07-01T01:07:59Z

@DamonFool This small patch fixes the problem at hand and at the minimum should go in with JDK 17. You have filed the JDK-8269679 for a more robust fix. Also the masking support is being overhauled as part of JDK 18. Your thoughts?

DamonFool · 2021-07-01T01:30:43Z

@DamonFool This small patch fixes the problem at hand and at the minimum should go in with JDK 17. You have filed the JDK-8269679 for a more robust fix. Also the masking support is being overhauled as part of JDK 18. Your thoughts?

Actually, instruct like storeMask1B and storeMask2B don't need and masking for both AVX2 and AVX3.
But to lower the risk of JDK17, I agree with you.
Thanks.

sviswa7 · 2021-07-01T02:06:30Z

Thanks @DamonFool.

XiaohongGong · 2021-07-01T02:11:18Z

@XiaohongGong The following should fix this for x86:

diff --git a/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp b/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
index 147bcb8..b548877 100644
--- a/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
+++ b/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
@@ -3870,6 +3870,9 @@ void C2_MacroAssembler::vector_mask_operation(int opc, Register dst, XMMRegister
   vpsubb(xtmp, xtmp, mask, vec_enc);
   evpmovb2m(ktmp, xtmp, vec_enc);
   kmovql(tmp, ktmp);
+  if (masklen < 64) {
+    andq(tmp, (((jlong)1 << masklen) - 1));
+  }
   switch(opc) {
     case Op_VectorMaskTrueCount:
       popcntq(dst, tmp);
@@ -3894,6 +3897,9 @@ void C2_MacroAssembler::vector_mask_operation(int opc, Register dst, XMMRegister
   vpxor(xtmp, xtmp, xtmp, vec_enc);
   vpsubb(xtmp, xtmp, mask, vec_enc);
   vpmovmskb(tmp, xtmp, vec_enc);
+  if (masklen < 64) {
+    andq(tmp, (((jlong)1 << masklen) - 1));
+  }
   switch(opc) {
     case Op_VectorMaskTrueCount:
       popcntq(dst, tmp);

Please include this in your PR.

Thanks for the fix @sviswa7 ! I will include it in the latest commit. Thanks!

XiaohongGong · 2021-07-01T07:41:15Z

/contributor add sandhya.viswanathan@intel.com

openjdk · 2021-07-01T07:41:54Z

@XiaohongGong Could not parse sandhya.viswanathan@intel.com as a valid contributor.
Syntax: /contributor (add|remove) [@user | openjdk-user | Full Name <email@address>]. For example:

/contributor add @openjdk-bot
/contributor add duke
/contributor add J. Duke <duke@openjdk.org>

XiaohongGong · 2021-07-01T07:47:50Z

Hi @sviswa7 @DamonFool @dean-long , the x86 issue is fixed with @sviswa7 's patch. I'v tested the Vector API tests internally and they all pass. Could you please take a look at it again? Thanks so much!

DamonFool

Changes in HotSpot LGTM.
Thanks for fixing it.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp

PaulSandoz

Very nice update to the test.

test/jdk/jdk/incubator/vector/templates/Unit-Miscellaneous.template

XiaohongGong · 2021-07-02T04:24:07Z

Hi @sviswa7 @PaulSandoz , all your comments have been addressed! Thanks so much for the review!

dean-long · 2021-07-02T05:29:23Z

I'm seeing some tests timing out. @PaulSandoz how did your testing go?

PaulSandoz · 2021-07-02T14:33:42Z

I'm seeing some tests timing out. @PaulSandoz how did your testing go?

For me there were no timeouts Can you provide more details?

PaulSandoz · 2021-07-02T16:59:36Z

I'm seeing some tests timing out. @PaulSandoz how did your testing go?

For me there were no timeouts Can you provide more details?

Vector tests for run as part of hs-tier1, hs-tier2, and hs-tier3 are fine. You might be observing time outs in unrelated tests.

dean-long · 2021-07-02T19:03:22Z

The timeouts were in 4 different jdk/incubator/vector tests, but all were on the same machine linux-aarch64 machine, and all were fastdebug builds, tier3, with ZGC.

XiaohongGong · 2021-07-05T01:46:49Z

The timeouts were in 4 different jdk/incubator/vector tests, but all were on the same machine linux-aarch64 machine, and all were fastdebug builds, tier3, with ZGC.

Do these tests also time out without this patch? Could you please provider more details to the tests (the timing out log or the test itself...). I'm not sure, but I guess the timing out is not related to this patch?

XiaohongGong · 2021-07-05T06:44:55Z

The timeouts were in 4 different jdk/incubator/vector tests, but all were on the same machine linux-aarch64 machine, and all were fastdebug builds, tier3, with ZGC.

Do these tests also time out without this patch? Could you please provider more details to the tests (the timing out log or the test itself...). I'm not sure, but I guess the timing out is not related to this patch?

I ran the Vector API tests with ZGC on all kinds of aarch64 machines that we have, and all the tests pass without the timing out.

dean-long · 2021-07-05T21:23:15Z

It's probably just a glitch on one of our test machines. I checked the results again and the tests ran fine with ZGC on other linux-aarch64 test machines.

XiaohongGong · 2021-07-06T08:07:31Z

It's probably just a glitch on one of our test machines. I checked the results again and the tests ran fine with ZGC on other linux-aarch64 test machines.

OK, that's very fine! Thanks so much!

XiaohongGong · 2021-07-06T08:07:45Z

/integrate

openjdk · 2021-07-06T08:08:38Z

@XiaohongGong
Your change (at version 4f006a5) is now ready to be sponsored by a Committer.

DamonFool · 2021-07-06T08:15:00Z

/sponsor

openjdk · 2021-07-06T08:17:37Z

Going to push as commit 2b20778.
Since your change was applied there have been 48 commits pushed to the master branch:

0f4e07b: 8269661: JNI_GetStringCritical does not lock char array
df1364b: 8269575: C2: assert(false) failed: graph should be schedulable after JDK-8252372
6d8fc72: 8268883: C2: assert(false) failed: unscheduable graph
4ad8b04: 8268369: SIGSEGV in PhaseCFG::implicit_null_check due to missing null check
5b8e1a2: 8266595: jdk/jfr/jcmd/TestJcmdDump.java with slowdebug bits fails with AttachNotSupportedException
e14801c: 8269668: [aarch64] java.library.path not including /usr/lib64
97e0e9e: 8268775: Password is being converted to String in AccessibleJPasswordField
1c18f91: 8269768: JFR Terminology Refresh
6f0e8e7: 8269775: compiler/codegen/ClearArrayTest.java failed with "assert(false) failed: bad AD file"
c4ea13e: 8269543: The warning for System::setSecurityManager should only appear once for each caller
... and 38 more: https://git.openjdk.java.net/jdk17/compare/56240690f62f9048a45a53525efccffdec235a8d...master

Your commit was automatically rebased without conflicts.

openjdk · 2021-07-06T08:17:55Z

@DamonFool @XiaohongGong Pushed as commit 2b20778.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

8269568: JVM crashes when running VectorMask query tests

bb209f1

openjdk bot added the rfr Pull request is ready for review label Jun 29, 2021

openjdk bot added the hotspot-compiler hotspot-compiler-dev@openjdk.java.net label Jun 29, 2021

PaulSandoz reviewed Jun 29, 2021

View reviewed changes

dean-long approved these changes Jun 29, 2021

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Jun 29, 2021

dean-long suggested changes Jun 30, 2021

View reviewed changes

openjdk bot removed the ready Pull request is ready to be integrated label Jun 30, 2021

XiaohongGong added 2 commits July 1, 2021 07:35

Fix x86 backend codegen issue

154ea71

Refactor VectorMask query tests

8e3fcfa

DamonFool approved these changes Jul 1, 2021

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Jul 1, 2021

jatin-bhateja reviewed Jul 1, 2021

View reviewed changes

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp Outdated Show resolved Hide resolved

PaulSandoz approved these changes Jul 1, 2021

View reviewed changes

test/jdk/jdk/incubator/vector/templates/Unit-Miscellaneous.template Outdated Show resolved Hide resolved

Update x86 fixes and tests to make them cleaner

4f006a5

jatin-bhateja approved these changes Jul 2, 2021

View reviewed changes

sviswa7 approved these changes Jul 2, 2021

View reviewed changes

openjdk bot added the sponsor Pull request is ready to be sponsored label Jul 6, 2021

openjdk bot closed this Jul 6, 2021

openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review sponsor Pull request is ready to be sponsored labels Jul 6, 2021

XiaohongGong deleted the JDK-8269568 branch July 7, 2021 00:54

XiaohongGong mentioned this pull request Jul 7, 2021

8269725: AArch64: Add VectorMask query implementation for NEON openjdk/jdk#4699

Closed

3 tasks

8269568: JVM crashes when running VectorMask query tests #168

8269568: JVM crashes when running VectorMask query tests #168

Conversation

XiaohongGong commented Jun 29, 2021 • edited by openjdk bot

Progress

Issue

Reviewers

Contributors

Reviewing

bridgekeeper bot commented Jun 29, 2021

openjdk bot commented Jun 29, 2021

mlbridge bot commented Jun 29, 2021 • edited

Webrevs

DamonFool commented Jun 29, 2021

DamonFool commented Jun 29, 2021

PaulSandoz left a comment

Choose a reason for hiding this comment

dean-long left a comment

Choose a reason for hiding this comment

openjdk bot commented Jun 29, 2021 • edited

XiaohongGong commented Jun 30, 2021

XiaohongGong commented Jun 30, 2021

XiaohongGong commented Jun 30, 2021

DamonFool commented Jun 30, 2021

dean-long left a comment

Choose a reason for hiding this comment

sviswa7 commented Jun 30, 2021 • edited

DamonFool commented Jul 1, 2021

sviswa7 commented Jul 1, 2021

DamonFool commented Jul 1, 2021

sviswa7 commented Jul 1, 2021

DamonFool commented Jul 1, 2021

sviswa7 commented Jul 1, 2021

XiaohongGong commented Jul 1, 2021

XiaohongGong commented Jul 1, 2021

openjdk bot commented Jul 1, 2021

XiaohongGong commented Jul 1, 2021

DamonFool left a comment

Choose a reason for hiding this comment

PaulSandoz left a comment

Choose a reason for hiding this comment

XiaohongGong commented Jul 2, 2021

dean-long commented Jul 2, 2021

PaulSandoz commented Jul 2, 2021

PaulSandoz commented Jul 2, 2021

dean-long commented Jul 2, 2021

XiaohongGong commented Jul 5, 2021

XiaohongGong commented Jul 5, 2021

dean-long commented Jul 5, 2021

XiaohongGong commented Jul 6, 2021

XiaohongGong commented Jul 6, 2021

openjdk bot commented Jul 6, 2021

DamonFool commented Jul 6, 2021

openjdk bot commented Jul 6, 2021

openjdk bot commented Jul 6, 2021

XiaohongGong commented Jun 29, 2021 •

edited by openjdk bot

mlbridge bot commented Jun 29, 2021 •

edited

openjdk bot commented Jun 29, 2021 •

edited

sviswa7 commented Jun 30, 2021 •

edited