Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8286941: Add mask IR for partial vector operations for ARM SVE #9037

Closed
wants to merge 10 commits into from

Conversation

XiaohongGong
Copy link

@XiaohongGong XiaohongGong commented Jun 6, 2022

VectorAPI SVE backend supports vector operations whose vector length is smaller than the max vector length that the current hardware can support. We call them partial vector operations. For some partial operations like vector load/store and the reductions, we need to generate a mask based on the real vector length and use it to control the operations to make sure the results are correct.

For example, if the user defines an IntVector with 256-bit species, and runs it on a SVE hardware that supports 512-bit as the max vector size, all the 256-bit int vector operations are partial. And a mask that all the higher lanes than the real vector length are set to 0 is generated for some ops.

Currently the mask is generated in the backend that is together with the code generation for each op in the match rule. This will generate many duplicate instructions for operations that have the same vector type. Besides, the mask generation is loop invariant which could be hoisted outside of the loop.

Here is an example for vector load and add reduction inside a loop:

  ptrue   p0.s, vl8             ; mask generation
  ld1w    {z16.s}, p0/z, [x14]  ; load vector

  ptrue   p0.s, vl8             ; mask generation
  uaddv   d17, p0, z16.s        ; add reduction
  smov    x14, v17.s[0]

As we can see the mask generation code "ptrue" is duplicated. To improve it, this patch generates the mask IR and adds it to the partial vector ops before code generation. The duplicate mask generation instructions can be optimized out by gvn and hoisted outside of the loop.

Note that for masked vector operations, there is no need to generate additional mask even though the vector length is smaller than the max vector register size, as the original higher input mask bits have been cleared out.

Here is the performance gain for the 256-bit vector reductions work on an SVE 512-bit system:

  Benchmark                  size   Gain
  Byte256Vector.ADDLanes     1024   0.999
  Byte256Vector.ANDLanes     1024   1.065
  Byte256Vector.MAXLanes     1024   1.064
  Byte256Vector.MINLanes     1024   1.062
  Byte256Vector.ORLanes      1024   1.072
  Byte256Vector.XORLanes     1024   1.041
  Short256Vector.ADDLanes    1024   1.017
  Short256Vector.ANDLanes    1024   1.044
  Short256Vector.MAXLanes    1024   1.049
  Short256Vector.MINLanes    1024   1.049
  Short256Vector.ORLanes     1024   1.089
  Short256Vector.XORLanes    1024   1.047
  Int256Vector.ADDLanes      1024   1.045
  Int256Vector.ANDLanes      1024   1.078
  Int256Vector.MAXLanes      1024   1.123
  Int256Vector.MINLanes      1024   1.129
  Int256Vector.ORLanes       1024   1.078
  Int256Vector.XORLanes      1024   1.072
  Long256Vector.ADDLanes     1024   1.059
  Long256Vector.ANDLanes     1024   1.101
  Long256Vector.MAXLanes     1024   1.079
  Long256Vector.MINLanes     1024   1.099
  Long256Vector.ORLanes      1024   1.098
  Long256Vector.XORLanes     1024   1.110
  Float256Vector.ADDLanes    1024   1.033
  Float256Vector.MAXLanes    1024   1.156
  Float256Vector.MINLanes    1024   1.151
  Double256Vector.ADDLanes   1024   1.062
  Double256Vector.MAXLanes   1024   1.145
  Double256Vector.MINLanes   1024   1.140

This patch also adds 32-bit variants of SVE whileXX instruction with one more matching rule of VectorMaskGen (ConvI2L src). So after this patch, we save one sxtw instruction for most VectorMaskGen cases, like below:

  sxtw    x14, w14
  whilelo p0.s, xzr, x14  =>  whilelo p0.s, wzr, w14

Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue

Issue

  • JDK-8286941: Add mask IR for partial vector operations for ARM SVE

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/9037/head:pull/9037
$ git checkout pull/9037

Update a local copy of the PR:
$ git checkout pull/9037
$ git pull https://git.openjdk.org/jdk pull/9037/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 9037

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/9037.diff

@bridgekeeper
Copy link

bridgekeeper bot commented Jun 6, 2022

👋 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 openjdk bot added the rfr Pull request is ready for review label Jun 6, 2022
@openjdk
Copy link

openjdk bot commented Jun 6, 2022

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

@openjdk openjdk bot added the hotspot-compiler hotspot-compiler-dev@openjdk.org label Jun 6, 2022
@mlbridge
Copy link

mlbridge bot commented Jun 6, 2022

Copy link
Contributor

@vnkozlov vnkozlov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes I significant. I suggest to wait JDK 20 (next week).

@XiaohongGong
Copy link
Author

Sure. It's fine for me to wait the JDK 20. Thanks a lot for the advice!

@@ -2252,7 +2252,6 @@ bool Matcher::find_shared_visit(MStack& mstack, Node* n, uint opcode, bool& mem_
case Op_FmaVD:
case Op_FmaVF:
case Op_MacroLogicV:
case Op_LoadVectorMasked:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why it is removed?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for looking at this PR! This is removed since we added two combined rules in the aarch64_sve.ad (line-2383) like:

match(Set dst (VectorLoadMask (LoadVectorMasked mem pg)));

Setting Op_LoadVectorMasked as a root in matcher will make such rules not be matched. I'm also curious why this op is added here. Does it have any influence if I remove it? Thanks!

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jatin-bhateja, could you please help to check the influence about removing this? Kindly know your feedback about this. Thanks so much!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was added specifically for #302
It used for ArrayCopyPartialInlineSize code macroArrayCopy.cpp#L250
Yes, it is strange that it is forced to be in register always. The instruction in x86.ad should be enough to put it into register.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jatin-bhateja, could you please help to check the influence about removing this? Kindly know your feedback about this. Thanks so much!

I think, this can be modified, GVN based sharing should be sufficient here.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for looking at this part!

Node* MaskAllNode::Ideal(PhaseGVN* phase, bool can_reshape) {
// Transform (MaskAll m1 (VectorMaskGen len)) ==> (VectorMaskGen len)
// if the vector length in bytes is lower than the MaxVectorSize.
if (is_con_M1(in(1)) && length_in_bytes() < MaxVectorSize) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Due to #8877 such length check may not correct here.
And I don't see in(2)->Opcode() == Op_VectorMaskGen check.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think changes in #8877 influences the max vector length in superword? And since MaskAll is used for VectorAPI, the MaxVectorSize is still the right reference? @jatin-bhateja, could you please help to check whether this has any influence on x86 avx-512 system? Thanks so much!

And I don't see in(2)->Opcode() == Op_VectorMaskGen check.

Yes, the Op_VectorMaskGen is not generated for MaskAll when its input is a constant. We directly transform the MaskAll to VectorMaskGen here, since they two have the same meanings. Thanks!

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And I don't see in(2)->Opcode() == Op_VectorMaskGen check.

Yes, the Op_VectorMaskGen is not generated for MaskAll when its input is a constant. We directly transform the MaskAll to VectorMaskGen here, since they two have the same meanings. Thanks!

I'm sorry that my comment in line-1819 is not right which misunderstood you. I will change this later. Thanks!

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer to not transform MaskAll to VectorMaskGen now, since there are the match rules using MaskAll m1 both in sve and avx-512. Doing the transformation may influence those rules.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think changes in #8877 influences the max vector length in superword? And since MaskAll is used for VectorAPI, the MaxVectorSize is still the right reference? @jatin-bhateja, could you please help to check whether this has any influence on x86 avx-512 system? Thanks so much!
All these transforms are guarded and currently enabled only for AARCH64, do not think it will impact AVX512.

And I don't see in(2)->Opcode() == Op_VectorMaskGen check.

Yes, the Op_VectorMaskGen is not generated for MaskAll when its input is a constant. We directly transform the MaskAll to VectorMaskGen here, since they two have the same meanings. Thanks!

src/hotspot/share/opto/vectornode.cpp Outdated Show resolved Hide resolved
src/hotspot/share/opto/vectornode.cpp Outdated Show resolved Hide resolved
src/hotspot/share/opto/vectornode.cpp Outdated Show resolved Hide resolved
src/hotspot/share/opto/vectornode.cpp Show resolved Hide resolved
@XiaohongGong
Copy link
Author

Hi @vnkozlov , all your review comments are resolved. Could you please help to take a look at this PR again? Thanks so much!

Copy link
Contributor

@vnkozlov vnkozlov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for addressing my comments.
You need review from Jatin and someone familiar with aarch64 code (I did not look on it).

@@ -2252,7 +2252,6 @@ bool Matcher::find_shared_visit(MStack& mstack, Node* n, uint opcode, bool& mem_
case Op_FmaVD:
case Op_FmaVF:
case Op_MacroLogicV:
case Op_LoadVectorMasked:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was added specifically for #302
It used for ArrayCopyPartialInlineSize code macroArrayCopy.cpp#L250
Yes, it is strange that it is forced to be in register always. The instruction in x86.ad should be enough to put it into register.

src/hotspot/share/opto/vectornode.cpp Show resolved Hide resolved
@XiaohongGong
Copy link
Author

Thank you for addressing my comments. You need review from Jatin and someone familiar with aarch64 code (I did not look on it).

Sure, thanks a lot for the review!

@XiaohongGong
Copy link
Author

Hi @jatin-bhateja, could you please help to take a look at this PR, especially the changes to the LoadVectorMasked? Any feedback is welcome, thanks!

Node* mask = NULL;
// Generate a vector mask for vector operation whose vector length is lower than the
// hardware supported max vector length.
if (vt->length_in_bytes() < MaxVectorSize) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For completeness, length comparison check can be done against MIN(SuperWordMaxVectorSize, MaxVectorSize).
Even though SuperWordMaxVector differs from MaxVectorSize only for certain X86 targets and this control flow is only executed for AARCH64 SVE targets currently.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I agree with you to add the SuperWordMaxVectorSize reference. Thanks! I will change it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm afraid that we cannot directly use MIN(SuperWordMaxVectorSize, MaxVectorSize) here. As I know SuperWordMaxVectorSize is used to control the max vector limit specially for auto-vectorization. It should not have any influence to the VectorAPI max vector size. So if the supported max vector size for VetorAPI is larger than auto-vectorization, the transformation will be influenced. For example, if a SVE hardware supported 128-bytes max vector size, but the SuperWordMaxVectorSize is 64, the predicate will not be generated for vectors whose vector size is smaller than 128-bytes. And I think x86 also has the similar issue. I think we'd better need a unit method to compute the max_vector_size that can handle the differences for superword and VectorAPI. And then all the orignal max_vector_size should be replaced with it. WDYT?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, the max vector size used here should be referenced from the hardware supported max vector size, which should be MaxVectorSize for SVE. For those vectors whose vector size is SuperWordMaxVectorSize, but smaller than the hardware supported max size, we still need to generate a predicate for them to make sure the results are right. So using MaxVectorSize is necessary here.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The mask is generated based on the real vector length, which guarantees only the vector lanes that inside of its valid vector length will do the operations. Higher lanes do nothing. So if a VectorStore has a vector length which equals to SuperWordMaxVectorSize, but the MaxVectorSize is larger than the SuperWordMaxVectorSize, a mask will be generated based on the real length SuperWordMaxVectorSize. And only lanes under the SuperWordMaxVectorSize will be stored. So I cannot see the influence on the out of memory issue. Could you please give an example apart of x86 cases? Thanks so much!

BTW, I think flag SuperWordMaxVectorSize should be equal to MaxVectorSize by default for other platforms instead of 64. If a platform (liken SVE) supports >64 bytes max vector size for auto-vectorization, it can only generate the vectors with 64 bytes vector size. This seems unreasonable. So do you have any plan refactoring this flag, or removing the usages for it in future? Thanks!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The mask is generated based on the real vector length, which guarantees only the vector lanes that inside of its valid vector length will do the operations. Higher lanes do nothing. So if a VectorStore has a vector length which equals to SuperWordMaxVectorSize, but the MaxVectorSize is larger than the SuperWordMaxVectorSize, a mask will be generated based on the real length SuperWordMaxVectorSize. And only lanes under the SuperWordMaxVectorSize will be stored. So I cannot see the influence on the out of memory issue. Could you please give an example apart of x86 cases? Thanks so much!

Correct, got it, removed my above review comment.

BTW, I think flag SuperWordMaxVectorSize should be equal to MaxVectorSize by default for other platforms instead of 64. If a platform (liken SVE) supports >64 bytes max vector size for auto-vectorization, it can only generate the vectors with 64 bytes vector size. This seems unreasonable. So do you have any plan refactoring this flag, or removing the usages for it in future? Thanks!

@@ -939,7 +1010,7 @@ Node* LoadVectorMaskedNode::Ideal(PhaseGVN* phase, bool can_reshape) {
}
}
}
return NULL;
return LoadVectorNode::Ideal(phase, can_reshape);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These predicated nodes are concrete ones with fixed species and carry user specified mask, I am not clear why do we need a mask re-computation for predicated nodes.

Higher lanes of predicated operand should already be zero and mask attached to predicated node should be correct by construction, since mask lane count is always equal to vector lane count.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually we don't need to add an additional mask for these masked nodes for SVE. Please refer to the partial_op_sve_needed method in aarch64_sve.ad, which lists all the ops that needs this transformation. Thanks! LoadVectorNode::Ideal(phase, can_reshape) just because LoadVectorMaskedNode derived from LoadVectorNode, that it may derive its other transformations in future or for other platforms.

@@ -959,7 +1030,7 @@ Node* StoreVectorMaskedNode::Ideal(PhaseGVN* phase, bool can_reshape) {
}
}
}
return NULL;
return StoreVectorNode::Ideal(phase, can_reshape);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as LoadVectorMaskedNode, StoreVectorMaskedNode doesn't need the transformation as well.

@@ -2252,7 +2252,6 @@ bool Matcher::find_shared_visit(MStack& mstack, Node* n, uint opcode, bool& mem_
case Op_FmaVD:
case Op_FmaVF:
case Op_MacroLogicV:
case Op_LoadVectorMasked:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jatin-bhateja, could you please help to check the influence about removing this? Kindly know your feedback about this. Thanks so much!

I think, this can be modified, GVN based sharing should be sufficient here.

Comment on lines +1667 to +1669
if (Matcher::vector_needs_partial_operations(this, vt)) {
return VectorNode::try_to_gen_masked_vector(phase, this, vt);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a parent node of TrueCount/FirstTrue/LastTrue and MaskToLong which perform mask querying operation on concrete predicate operands, a transformation here looks redundant to me.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main reason to add the transformation here is: the FirstTrue needs the reference to the real vector length for SVE, that we need to generate a predicate when the vector length is smaller than the max vector size. Please check the changes of partial_op_sve_needed in aarch64_sve.ad.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Real vector length can be obtained by incoming input mask node.

Node* MaskAllNode::Ideal(PhaseGVN* phase, bool can_reshape) {
// Transform (MaskAll m1 (VectorMaskGen len)) ==> (VectorMaskGen len)
// if the vector length in bytes is lower than the MaxVectorSize.
if (is_con_M1(in(1)) && length_in_bytes() < MaxVectorSize) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think changes in #8877 influences the max vector length in superword? And since MaskAll is used for VectorAPI, the MaxVectorSize is still the right reference? @jatin-bhateja, could you please help to check whether this has any influence on x86 avx-512 system? Thanks so much!
All these transforms are guarded and currently enabled only for AARCH64, do not think it will impact AVX512.

And I don't see in(2)->Opcode() == Op_VectorMaskGen check.

Yes, the Op_VectorMaskGen is not generated for MaskAll when its input is a constant. We directly transform the MaskAll to VectorMaskGen here, since they two have the same meanings. Thanks!

Copy link
Member

@jatin-bhateja jatin-bhateja left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @XiaohongGong , thanks for your explanations, common IR changes looks good to me.

Comment on lines +1667 to +1669
if (Matcher::vector_needs_partial_operations(this, vt)) {
return VectorNode::try_to_gen_masked_vector(phase, this, vt);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Real vector length can be obtained by incoming input mask node.

Copy link

@nsjian nsjian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AArch64 changes look good to me.

@XiaohongGong
Copy link
Author

AArch64 changes look good to me.

Thanks for the review @nsjian !

@vnkozlov
Copy link
Contributor

I submitted testing. Will let you know results before approval.

@XiaohongGong
Copy link
Author

I submitted testing. Will let you know results before approval.

Thanks a lot for doing this!

@vnkozlov
Copy link
Contributor

I got failure in tier1:

test/hotspot/gtest/aarch64/test_assembler_aarch64.cpp:48: Failure
Expected equality of these values:
  insns[i]
    Which is: 624694305
  insns1[i]
    Which is: 624690209
Ours:
[MachCode]
  0x0000fffca812c698: 2104 3c25 
[/MachCode]
Theirs:
[MachCode]
  0x0000fffc9599d188: 2114 3c25 
[/MachCode]

@vnkozlov
Copy link
Contributor

I put output into RFE comment.

@XiaohongGong
Copy link
Author

I got failure in tier1:

test/hotspot/gtest/aarch64/test_assembler_aarch64.cpp:48: Failure
Expected equality of these values:
  insns[i]
    Which is: 624694305
  insns1[i]
    Which is: 624690209
Ours:
[MachCode]
  0x0000fffca812c698: 2104 3c25 
[/MachCode]
Theirs:
[MachCode]
  0x0000fffc9599d188: 2114 3c25 
[/MachCode]

Thanks for pointing out this! My fault. I called wrong assembler function in the new added tests. I will fix it soon!

@XiaohongGong
Copy link
Author

Hi @vnkozlov , the fix is pushed to this PR. Would you mind running the test again? Thanks so much!

@XiaohongGong
Copy link
Author

Hi @nick-arm , could you please help to take a look at the aarch64 part changes? Thanks so much for your time!

@vnkozlov
Copy link
Contributor

An other test failed in tier2: compiler/loopopts/superword/TestPickFirstMemoryState.java
Details are in RFE.

@XiaohongGong
Copy link
Author

An other test failed in tier2: compiler/loopopts/superword/TestPickFirstMemoryState.java Details are in RFE.

Thanks for the tests again! It seems this is the same issue with #2867 that the type of in(2) is Type::TOP. We need to add save the vector type for ReductionNode. I will fix it soon!

@XiaohongGong
Copy link
Author

Hi @vnkozlov , the fixing is pushed to the PR. I tested the failure case on a avx-512 machine, and the failure gone. Could you please help to run the test again? Thanks a lot!

@vnkozlov
Copy link
Contributor

vnkozlov commented Jul 5, 2022

I started new testing.

Copy link
Contributor

@vnkozlov vnkozlov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Results are good.

@openjdk
Copy link

openjdk bot commented Jul 6, 2022

@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:

8286941: Add mask IR for partial vector operations for ARM SVE

Reviewed-by: kvn, jbhateja, njian, ngasson

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 207 new commits pushed to the master branch:

  • 569de45: 8289620: gtest/MetaspaceUtilsGtests.java failed with unexpected stats values
  • 403a9bc: 8289436: Make the redefine timer statistics more accurate
  • a40c17b: 8289775: Update java.lang.invoke.MethodHandle[s] to use snippets
  • 2a6ec88: Merge
  • 0526402: 8289477: Memory corruption with CPU_ALLOC, CPU_FREE on muslc
  • b3a0e48: 8289439: Clarify relationship between ThreadStart/ThreadEnd and can_support_virtual_threads capability
  • 0b6fd48: 8288128: S390X: Fix crashes after JDK-8284161 (Virtual Threads)
  • 30e134e: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj()
  • 29ea642: 8287847: Fatal Error when suspending virtual thread after it has terminated
  • f640fc5: 8067757: Incorrect HTML generation for copied javadoc with multiple @throws tags
  • ... and 197 more: https://git.openjdk.org/jdk/compare/7e211d7daac32dca8f26f408d1a3b2c7805b5a2e...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.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Jul 6, 2022
@XiaohongGong
Copy link
Author

Results are good.

Thanks a lot for your time again!

@XiaohongGong
Copy link
Author

@nick-arm , could you please take a look at this change again? Thanks so much!

@XiaohongGong
Copy link
Author

Thanks for the reivew @nick-arm !

@XiaohongGong
Copy link
Author

/integrate

@openjdk
Copy link

openjdk bot commented Jul 7, 2022

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

  • 569de45: 8289620: gtest/MetaspaceUtilsGtests.java failed with unexpected stats values
  • 403a9bc: 8289436: Make the redefine timer statistics more accurate
  • a40c17b: 8289775: Update java.lang.invoke.MethodHandle[s] to use snippets
  • 2a6ec88: Merge
  • 0526402: 8289477: Memory corruption with CPU_ALLOC, CPU_FREE on muslc
  • b3a0e48: 8289439: Clarify relationship between ThreadStart/ThreadEnd and can_support_virtual_threads capability
  • 0b6fd48: 8288128: S390X: Fix crashes after JDK-8284161 (Virtual Threads)
  • 30e134e: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj()
  • 29ea642: 8287847: Fatal Error when suspending virtual thread after it has terminated
  • f640fc5: 8067757: Incorrect HTML generation for copied javadoc with multiple @throws tags
  • ... and 197 more: https://git.openjdk.org/jdk/compare/7e211d7daac32dca8f26f408d1a3b2c7805b5a2e...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Jul 7, 2022
@openjdk openjdk bot closed this Jul 7, 2022
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jul 7, 2022
@openjdk
Copy link

openjdk bot commented Jul 7, 2022

@XiaohongGong Pushed as commit a79ce4e.

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

@XiaohongGong XiaohongGong deleted the JDK-8286941 branch July 7, 2022 08:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot-compiler hotspot-compiler-dev@openjdk.org integrated Pull request has been integrated
5 participants