8323116: [REDO] Computational test more than 2x slower when AVX instructions are used #18503

vamsi-parasa · 2024-03-26T23:19:16Z

The goal of this small PR is improve the performance of convert instructions and address the slowdown when AVX>0 is used.

The performance data using the ComputePI.java benchmark (part of this PR) is as follows:

Benchmark (ns/op)	Stock JDK	This PR (AVX=3)	Speedup
ComputePI.compute_pi_dbl_flt	511.34	510.989	1.0
ComputePI.compute_pi_flt_dbl	2024.06	518.695	3.9
ComputePI.compute_pi_int_dbl	695.482	453.054	1.5
ComputePI.compute_pi_int_flt	799.268	449.83	1.8
ComputePI.compute_pi_long_dbl	802.992	454.891	1.8
ComputePI.compute_pi_long_flt	628.62	463.617	1.4

Benchmark (ns/op)	Stock JDK	This PR (AVX=0)	Speedup
ComputePI.compute_pi_dbl_flt	473.778	472.529	1.0
ComputePI.compute_pi_flt_dbl	536.004	538.418	1.0
ComputePI.compute_pi_int_dbl	458.08	460.245	1.0
ComputePI.compute_pi_int_flt	477.305	476.975	1.0
ComputePI.compute_pi_long_dbl	455.132	455.064	1.0
ComputePI.compute_pi_long_flt	474.734	476.571	1.0

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-8323116: [REDO] Computational test more than 2x slower when AVX instructions are used (Enhancement - P4)

Reviewers

Sandhya Viswanathan (@sviswa7 - Reviewer) ⚠️ Review applies to 970716f4
Vladimir Kozlov (@vnkozlov - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 18503

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

Using diff file

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

Webrev

Link to Webrev Comment

…uctions are used

bridgekeeper · 2024-03-26T23:19:45Z

👋 Welcome back vamsi-parasa! 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 · 2024-03-26T23:20:16Z

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

8323116: [REDO] Computational test more than 2x slower when AVX instructions are used

Reviewed-by: sviswanathan, kvn

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

dd930c5: 8329787: Fix typo in CLDRConverter
115f419: 8329659: Serial: Extract allowed_dead_ratio from ContiguousSpace
9ac3b77: 8329775: Serial: Remove unused declarations in serialFullGC.hpp
7475824: 8329510: Update ProblemList for JFileChooser/8194044/FileSystemRootTest.java
6439375: 8329533: TestCDSVMCrash fails on libgraal
3ebf8c9: 8329663: hs_err file event log entry for thread adding/removing should print current thread
be45de1: 8328627: JShell documentation should be clearer about "remote runtime system"
8648890: 8329749: Obsolete the unused UseNeon flag
fc18201: 8327111: Replace remaining usage of create_bool_from_template_assertion_predicate() which requires additional OpaqueLoop*Nodes transformation strategies
7c66465: 8325088: Overloads that differ in type parameters may be lost
... and 202 more: https://git.openjdk.org/jdk/compare/ab183e437c18b445e9c022a4d74de818d4ccecbe...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 (@sviswa7, @vnkozlov) 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).

openjdk · 2024-03-26T23:20:42Z

@vamsi-parasa 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 · 2024-03-26T23:47:36Z

Webrevs

sviswa7

Looks good to me.

openjdk · 2024-03-28T18:01:02Z

⚠️ @vamsi-parasa the full name on your profile does not match the author name in this pull requests' HEAD commit. If this pull request gets integrated then the author name from this pull requests' HEAD commit will be used for the resulting commit. If you wish to push a new commit with a different author name, then please run the following commands in a local repository of your personal fork:

$ git checkout cvt_jdk
$ git commit --author='Preferred Full Name <you@example.com>' --allow-empty -m 'Update full name'
$ git push

vamsi-parasa · 2024-04-01T17:10:42Z

Could I get one more review please?
Hello Tobias (@TobiHartmann) and Vladimir (@vnkozlov), could you please look into this small PR?

Thanks,
Vamsi

vnkozlov

I have one question for changes in assembler code.

I see you avoided xor for instruction with memory by executing them only without AVX.

I will run our performance testing to see if this change affects performance. Eric did run it but I don't know which version.

vnkozlov · 2024-04-03T21:17:22Z

src/hotspot/cpu/x86/assembler_x86.cpp

@@ -2031,7 +2031,7 @@ void Assembler::cvtsd2ss(XMMRegister dst, XMMRegister src) {
  NOT_LP64(assert(VM_Version::supports_sse2(), ""));
  InstructionAttr attributes(AVX_128bit, /* rex_w */ VM_Version::supports_evex(), /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false);
  attributes.set_rex_vex_w_reverted();
-  int encode = simd_prefix_and_encode(dst, dst, src, VEX_SIMD_F2, VEX_OPCODE_0F, &attributes);
+  int encode = simd_prefix_and_encode(dst, src, src, VEX_SIMD_F2, VEX_OPCODE_0F, &attributes);


Can you explain this change?

Similar to #18089, the purpose of this change is to remove the slowdown due to false dependency. For example, using the current (dst, dst, src) encoding in the case of VCVTSD2SS xmm1, xmm2, xmm3/m64, the instruction converts one double precision floating-point value in xmm3/m64 to one single precision floating-point value and merge with high bits in xmm2. This merge with high bits of xmm2 causes a false dependency as xmm1 and xmm2 are the same in (dst, dst, src) encoding.

We are removing the false dependency by (1) removing the m64 source in VCVTSDSS instruction encoding in the .ad file (2) load m64 source in src before calling VCVTSD2SS and explicitly zeroing out the of high bits in src using vmovsd src, m64 and then calling VCVTSD2SS dst, src, src. Thus dst[31:0] now gets the result of convert operation from src[63:0] and passing src as the non-destructive source (NDS) prevents the false dependancy.

Thanks,
Vamsi

Thank you for explaining.

This is a downcast from double precision to single precision value, thus only lower 32 bits of destination hold the actual results for conversion, upper 127:32 bits are copied from non destructive source operand for vex encoded instruction.

VCVTSD2SS (VEX.128 Encoded Version) ¶
DEST[31:0] := Convert_Double_Precision_To_Single_Precision_Floating_Point(SRC2[63:0]);
DEST[127:32] := SRC1[127:32]
DEST[MAXVL-1:128] := 0

User is only interested in lower 32 bit of destination and passing source as NDS will prevent false dependency for AVX targets since instruction dispatch will not be held for false dependency anymore and will be issued to OOO backend the moment source is ready

This change modifies the defined behaviours of cvtss2sd. Without AVX, it would retains the bits 64-127 of dst while with it the bits would be copied from src. I would suggest separating the matching rules instead.

Its a cleaver trick to dodge false dependency without compromising on correctness.

@jatin-bhateja I get it but IMO it shouldn't be the responsibility of the assembler to do that, the assembler should emit machine code in a manner that respects what is being written.

This is a downcast from double precision to single precision value, thus only lower 32 bits of destination hold the actual results for conversion, upper 127:32 bits are copied from non destructive source operand for vex encoded instruction.

Please see the updated description incorporating the correction dst[63:0] -> dst[31,0] for cvtss2sd

@vamsi-parasa

This change modifies the defined behaviours of cvtss2sd. Without AVX, it would retains the bits 64-127 of dst while with it the bits would be copied from src. I would suggest separating the matching rules instead.

Please address this, fyi in similar cases we created separate methods in the MacroAssembler such as movflt or movdbl. Feel free to disagree but I think the assembler should not behave differently compared to the corresponding assembly instruction.

vnkozlov · 2024-04-03T21:34:51Z

And I will run regular testing too.

vnkozlov · 2024-04-03T23:28:48Z

Next tests failed when running with -XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:+UseKNLSetting flags
compiler/intrinsics/zip/TestFpRegsABI.java
compiler/loopopts/superword/TestCmpInvar.java

#  Internal Error (/workspace/open/src/hotspot/cpu/x86/assembler_x86.cpp:11719), pid=955891, tid=955918
#  assert(((!attributes->uses_vl()) || (attributes->get_vector_len() == AVX_512bit) || (!_legacy_mode_vl) || (attributes->is_legacy_mode()))) failed: XMM register should be 0-15
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 23-internal-2024-04-03-2139260.vladimir.kozlov.jdkgit2, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x633784]  Assembler::vex_prefix_and_encode(int, int, int, Assembler::VexSimdPrefix, Assembler::VexOpcode, InstructionAttr*) [clone .constprop.1]+0x284
#
Current CompileTask:
C2:237   45 %  b        compiler.intrinsics.zip.TestFpRegsABI$TestIntrinsic::calcValue @ 6 (661 bytes)

Stack: [0x00007f03e044b000,0x00007f03e054b000],  sp=0x00007f03e0546830,  free space=1006k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x633784]  Assembler::vex_prefix_and_encode(int, int, int, Assembler::VexSimdPrefix, Assembler::VexOpcode, InstructionAttr*) [clone .constprop.1]+0x284  (assembler_x86.cpp:11719)
V  [libjvm.so+0x65e21e]  Assembler::pxor(XMMRegister, XMMRegister)+0x5e  (assembler_x86.cpp:8258)
V  [libjvm.so+0x3a5885]  convI2D_reg_regNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0x135  (x86_64.ad:10097)
V  [libjvm.so+0x14d4386]  PhaseOutput::scratch_emit_size(Node const*)+0x376  (output.cpp:3366)
V  [libjvm.so+0x14ccaca]  PhaseOutput::shorten_branches(unsigned int*)+0x34a  (output.cpp:544)
V  [libjvm.so+0x14de41a]  PhaseOutput::Output()+0xa1a  (output.cpp:345)
V  [libjvm.so+0x9ec52c]  Compile::Code_Gen()+0x4ac  (compile.cpp:3031)
V  [libjvm.so+0x9ef0a6]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1c36  (compile.cpp:894)

vamsi-parasa · 2024-04-04T02:35:19Z

Next tests failed when running with -XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:+UseKNLSetting flags compiler/intrinsics/zip/TestFpRegsABI.java compiler/loopopts/superword/TestCmpInvar.java

Thank you, Vladimir (@vnkozlov). Will look into the test and fix it.

vamsi-parasa · 2024-04-04T23:45:51Z

Next tests failed when running with -XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:+UseKNLSetting flags
compiler/intrinsics/zip/TestFpRegsABI.java

The KNL related failure was fixed in the latest commit by adding the check
if (UseAVX > 2 && !attributes->uses_vl()) in line 11713 for src/hotspot/cpu/x86/assembler_x86.cpp

Could you please have a look at this change?

Thanks,
Vamsi

vnkozlov · 2024-04-05T00:10:34Z

I will submit new testing.

vamsi-parasa · 2024-04-05T00:11:57Z

I will submit new testing.

Thank you Vladimir!

jatin-bhateja · 2024-04-05T03:27:48Z

src/hotspot/cpu/x86/assembler_x86.cpp

@@ -11710,7 +11710,7 @@ int Assembler::vex_prefix_and_encode(int dst_enc, int nds_enc, int src_enc, VexS
    }
  }

-  if (UseAVX > 2) {
+  if (UseAVX > 2 && !attributes->uses_vl()) {


This is already coved by below assertion

Without this check, the test is failing for KNL (-XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:+UseKNLSetting) as Vladimir mentioned. Is there a better way to handle the KNL case?

Yes, there is an easy way. For the instructs where you added the pxor instruction generation, you could change the dst register type from regF to vlRegF. This restricts the xmm register to xmm0-xmm15 for KNL, thereby not needing the evex encoding and in-turn not needing the avx512vl support for pxor.

and likewise from regD to vlRegD.

Yes, there is an easy way. For the instructs where you added the pxor instruction generation, you could change the dst register type from regF to vlRegF.

Thanks Sandhya, will make the changes and push an update.

jatin-bhateja · 2024-04-05T03:43:24Z

src/hotspot/cpu/x86/assembler_x86.cpp

@@ -2031,7 +2031,7 @@ void Assembler::cvtsd2ss(XMMRegister dst, XMMRegister src) {
  NOT_LP64(assert(VM_Version::supports_sse2(), ""));
  InstructionAttr attributes(AVX_128bit, /* rex_w */ VM_Version::supports_evex(), /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false);
  attributes.set_rex_vex_w_reverted();
-  int encode = simd_prefix_and_encode(dst, dst, src, VEX_SIMD_F2, VEX_OPCODE_0F, &attributes);
+  int encode = simd_prefix_and_encode(dst, src, src, VEX_SIMD_F2, VEX_OPCODE_0F, &attributes);


This is a downcast from double precision to single precision value, thus only lower 32 bits of destination hold the actual results for conversion, upper 127:32 bits are copied from non destructive source operand for vex encoded instruction.

VCVTSD2SS (VEX.128 Encoded Version) ¶
DEST[31:0] := Convert_Double_Precision_To_Single_Precision_Floating_Point(SRC2[63:0]);
DEST[127:32] := SRC1[127:32]
DEST[MAXVL-1:128] := 0

User is only interested in lower 32 bit of destination and passing source as NDS will prevent false dependency for AVX targets since instruction dispatch will not be held for false dependency anymore and will be issued to OOO backend the moment source is ready

merykitty · 2024-04-05T05:36:19Z

While changing vcvtss2sd dst, dst, src to vcvtss2sd dst, src, src looks fine, adding a pxor before every cvtsi2ss seems extra as it puts more pressure on the front-end. I propose to have a non-allocatable register such as xmm15 and use it as the first source register for these nodes. It also helps enable the memory version of these instructions without worrying about unwanted dependencies.

Cheers.

vnkozlov · 2024-04-05T17:46:17Z

My new testing passed.
But I want to hear an answer to @merykitty suggestion about using xmm15.

sviswa7 · 2024-04-05T18:17:00Z

@vnkozlov If I understand the proposal from @merykitty correctly, the suggestion is to reserve xmm15 as non allocatable throughout. This sounds like a big overhead for cases where every xmm register is usable say in a Vector API kernel. From Vamsi's microbenchmark runs, he has clearly shown that the gain of his optimization is way more than any overhead of doing pxor just before the converts.

vnkozlov · 2024-04-05T18:45:57Z

Okay. I will wait changes @sviswa7 suggested to use vlRegD and vlRegF.

vamsi-parasa · 2024-04-05T18:51:28Z

My new testing passed.

Thanks Vladimir!

I will wait changes @sviswa7 suggested to use vlRegD and vlRegF.

Will make the changes and let you know.

vamsi-parasa · 2024-04-05T19:50:14Z

Okay. I will wait changes @sviswa7 suggested to use vlRegD and vlRegF.

Please see the updated commit which uses vlRegD and vlRegF.

vnkozlov · 2024-04-05T20:02:52Z

Okay. I will wait changes @sviswa7 suggested to use vlRegD and vlRegF.

Please see the updated commit which uses vlRegD and vlRegF.

Okay. I need to run testing again.

merykitty · 2024-04-05T20:11:02Z

@sviswa7

Yes with my proposal we are losing 1 out of 16 registers, which is a cost. But emitting an additional instruction for every conversion from integer to floating point values is also a cost. A more conservative solution is to use the last register in the allocation chunk which will often be unused, and when it is used, the function should be crowded with other instructions such that this particular dependency will not have a profound effect.

From Vamsi's microbenchmark runs, he has clearly shown that the gain of his optimization is way more than any overhead of doing pxor just before the converts.

You cannot reach that conclusion, we are trading off here, and this benchmark is chosen because it is bottlenecked by that particular dependency. The situation may not be the same for the other cases.

Cheers,
Quan Anh

sviswa7 · 2024-04-05T22:30:35Z

@sviswa7

Yes with my proposal we are losing 1 out of 16 registers, which is a cost. But emitting an additional instruction for every conversion from integer to floating point values is also a cost. A more conservative solution is to use the last register in the allocation chunk which will often be unused, and when it is used, the function should be crowded with other instructions such that this particular dependency will not have a profound effect.

From Vamsi's microbenchmark runs, he has clearly shown that the gain of his optimization is way more than any overhead of doing pxor just before the converts.

You cannot reach that conclusion, we are trading off here, and this benchmark is chosen because it is bottlenecked by that particular dependency. The situation may not be the same for the other cases.

Cheers, Quan Anh

@merykitty I would like to disagree, decision to reserve a register for entire duration of program cannot be taken lightly.

vnkozlov · 2024-04-05T23:12:10Z

Executive (my ;^) decision: we go with current changes: no xmm15 reservation. I am starting (I hope final) testing round.

merykitty · 2024-04-06T01:44:40Z

@sviswa7 I didn't disagree with you, I just made a more conservative proposal that uses xmm15 here without reserving it, what do you think?

vnkozlov

My testing of v05 passed - no new failures.

vamsi-parasa · 2024-04-08T15:30:00Z

My testing of v05 passed - no new failures.

Thank you Vladimir!

vamsi-parasa · 2024-04-08T16:30:15Z

/integrate

openjdk · 2024-04-08T16:30:42Z

@vamsi-parasa
Your change (at version 8c34df8) is now ready to be sponsored by a Committer.

sviswa7 · 2024-04-08T18:41:01Z

@sviswa7 I didn't disagree with you, I just made a more conservative proposal that uses xmm15 here without reserving it, what do you think?

Let us go with Vladimir's executive decision for now and integrate this. Any improvements in subsequent PRs is always welcome.

sviswa7 · 2024-04-08T18:41:14Z

/sponsor

openjdk · 2024-04-08T18:41:34Z

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

9467720: 8329875: Serial: Move preservedMarks.inline.hpp to serialFullGC.cpp
a4dd2e9: 8329766: Serial: Refactor SerialBlockOffsetTable API
212a253: 8329623: NegativeArraySizeException encoding large String to UTF-8
dd930c5: 8329787: Fix typo in CLDRConverter
115f419: 8329659: Serial: Extract allowed_dead_ratio from ContiguousSpace
9ac3b77: 8329775: Serial: Remove unused declarations in serialFullGC.hpp
7475824: 8329510: Update ProblemList for JFileChooser/8194044/FileSystemRootTest.java
6439375: 8329533: TestCDSVMCrash fails on libgraal
3ebf8c9: 8329663: hs_err file event log entry for thread adding/removing should print current thread
be45de1: 8328627: JShell documentation should be clearer about "remote runtime system"
... and 205 more: https://git.openjdk.org/jdk/compare/ab183e437c18b445e9c022a4d74de818d4ccecbe...master

Your commit was automatically rebased without conflicts.

openjdk · 2024-04-08T18:41:42Z

@sviswa7 @vamsi-parasa Pushed as commit 7e5ef79.

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

8323116: [REDO] Computational test more than 2x slower when AVX instr…

Loading
Loading status checks…

d9e6568

…uctions are used

openjdk bot added the hotspot-compiler label Mar 26, 2024

fix whitespace changes

Loading
Loading status checks…

556f3bb

vamsi-parasa marked this pull request as ready for review March 26, 2024 23:44

openjdk bot added the rfr label Mar 26, 2024

vamsi-parasa added 5 commits March 27, 2024 15:32

Update TestConvertImplicitNullCheck.java

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.

GPG key ID: B5690EEEBB952194

Verified
Learn about vigilant mode

Loading
Loading status checks…

588a4e0

Update ComputePI.java

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.

GPG key ID: B5690EEEBB952194

Verified
Learn about vigilant mode

Loading
Loading status checks…

8e9fb39

Update ComputePI.java

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.

GPG key ID: B5690EEEBB952194

Verified
Learn about vigilant mode

Loading
Loading status checks…

1b17e84

fix cause for failing PowTests.java

Loading
Loading status checks…

fad7180

fix L2F cvtsi2ssq

Loading
Loading status checks…

970716f

sviswa7 approved these changes Mar 28, 2024

View reviewed changes

openjdk bot added the ready label Mar 28, 2024

vnkozlov reviewed Apr 3, 2024

View reviewed changes

fix failure for KNL

Loading
Loading status checks…

b4a11ba

jatin-bhateja reviewed Apr 5, 2024

View reviewed changes

change reg to vlReg to fix KNL failure

Loading
Loading status checks…

8c34df8

vnkozlov approved these changes Apr 6, 2024

View reviewed changes

openjdk bot added the sponsor label Apr 8, 2024

openjdk bot added the integrated label Apr 8, 2024

openjdk bot closed this Apr 8, 2024

openjdk bot removed ready rfr sponsor labels Apr 8, 2024

8323116: [REDO] Computational test more than 2x slower when AVX instructions are used #18503

8323116: [REDO] Computational test more than 2x slower when AVX instructions are used #18503

Conversation

vamsi-parasa commented Mar 26, 2024 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Reviewing

Webrev

bridgekeeper bot commented Mar 26, 2024

openjdk bot commented Mar 26, 2024 • edited Loading

openjdk bot commented Mar 26, 2024

mlbridge bot commented Mar 26, 2024 • edited Loading

Webrevs

sviswa7 left a comment

Choose a reason for hiding this comment

openjdk bot commented Mar 28, 2024

vamsi-parasa commented Apr 1, 2024

vnkozlov left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vamsi-parasa Apr 4, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vnkozlov commented Apr 3, 2024

vnkozlov commented Apr 3, 2024

vamsi-parasa commented Apr 4, 2024

vamsi-parasa commented Apr 4, 2024

vnkozlov commented Apr 5, 2024

vamsi-parasa commented Apr 5, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

merykitty commented Apr 5, 2024

vnkozlov commented Apr 5, 2024

sviswa7 commented Apr 5, 2024

vnkozlov commented Apr 5, 2024

vamsi-parasa commented Apr 5, 2024

vamsi-parasa commented Apr 5, 2024

vnkozlov commented Apr 5, 2024

merykitty commented Apr 5, 2024

sviswa7 commented Apr 5, 2024

vnkozlov commented Apr 5, 2024

merykitty commented Apr 6, 2024

vnkozlov left a comment

Choose a reason for hiding this comment

vamsi-parasa commented Apr 8, 2024

vamsi-parasa commented Apr 8, 2024

openjdk bot commented Apr 8, 2024

sviswa7 commented Apr 8, 2024

sviswa7 commented Apr 8, 2024

openjdk bot commented Apr 8, 2024

openjdk bot commented Apr 8, 2024

vamsi-parasa commented Mar 26, 2024 •

edited by openjdk bot

Loading

openjdk bot commented Mar 26, 2024 •

edited

Loading

mlbridge bot commented Mar 26, 2024 •

edited

Loading

vamsi-parasa Apr 4, 2024 •

edited

Loading