8277617: Adjust AVX3Threshold for copy/fill stubs #6512

sviswa7 · 2021-11-23T01:23:04Z

Currently 32-byte instructions are used for small array copy and clear.
This can be optimized by using 64-byte instructions.

Please review.

Best Regards,
Sandhya

Progress

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

Issue

JDK-8277617: Adjust AVX3Threshold for copy/fill stubs

Reviewers

Jatin Bhateja (@jatin-bhateja - Committer) ⚠️ Review applies to 021bc65
David Holmes (@dholmes-ora - Reviewer) ⚠️ Review applies to 190f974
Nils Eliasson (@neliasso - Reviewer) ⚠️ Review applies to 190f974
Jie Fu (@DamonFool - Reviewer) ⚠️ Review applies to 190f974

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 6512

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

Using diff file

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

bridgekeeper · 2021-11-23T01:24:27Z

👋 Welcome back sviswanathan! 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-11-23T01:26:12Z

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

hotspot

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-11-23T01:35:28Z

Webrevs

dholmes-ora · 2021-11-23T02:12:38Z

This isn't my area but I'm a bit perplexed by the changes. AFAICS this patch does 2 things:

It changes all use of AVX3Threshold to VM_Version::avx3_threshold()
It defines VM_Version::avx3_threshold() as:
static int avx3_threshold() { return (supports_serialize() ? 0: AVX3Threshold); }

but I am at a loss to understand what supports_serialize() has to do with using 64-byte instructions for array copy and clear. ??

Thanks,
David

dholmes-ora · 2021-11-23T02:14:46Z

Plus some performance numbers would be useful. Thanks

sviswa7 · 2021-11-23T02:44:39Z

@dholmes-ora We see about 25% gain on a micro on our latest platform. There is no cpuid bit for this, so the closest was to check for the new serialize ISA supported on this platform.

dholmes-ora · 2021-11-23T02:54:51Z

But what exactly is it that you are checking for? What is the connection between the ISA version and the decision to effectively zero out AVX3Threshold?

sviswa7 · 2021-11-23T04:25:23Z

@dholmes-ora The Intel platforms that supports this ISA has improved implementation of 64-byte load/stores. I could not find any other better way to check in the absence of cupid bit.
If it helps, I could further restrict it to (is_intel_family_core() && supports_serialize()). Also, I can add a comment towards this to the avx3_threshold() method.

dholmes-ora · 2021-11-23T04:50:42Z

@sviswa7 that further restriction and an explanatory comment would be appreciated. Thanks.

sviswa7 · 2021-11-23T05:24:41Z

@dholmes-ora I have implemented your review comments.

DamonFool · 2021-11-23T06:05:48Z

@dholmes-ora We see about 25% gain on a micro on our latest platform. There is no cpuid bit for this, so the closest was to check for the new serialize ISA supported on this platform.

It would be better to add a jmh test for this opt.
Thanks.

dholmes-ora · 2021-11-23T06:49:07Z

Sorry @sviswa7 but could you explain in the comment why/how avx3_threshold reporting zero impacts the use 64-byte load/store - the connection is not at all obvious for anyone not fully conversant with AVX3 and how it is used by the code. Thanks.

jatin-bhateja · 2021-11-23T19:02:40Z

src/hotspot/cpu/x86/vm_version_x86.hpp

+  static int avx3_threshold() { return ((is_intel_family_core() &&
+                                supports_serialize()) ? 0: AVX3Threshold); }


Hi @sviswa7 , Should we not return a zero threshold only if user does not explicitly set AVX3Threshold i.e. in default case.

@jatin-bhateja On these platforms it is beneficial to set the threshold to zero for copy and clear operations and hence the override. I have described that in the comment in detail as well.

Hi @vitalyd, thanks for making a comment in an OpenJDK project!

All comments and discussions in the OpenJDK Community must be made available under the OpenJDK Terms of Use. If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please Use "Add GitHub user vitalyd for the summary.

If you are not an OpenJDK Author, Committer or Reviewer, simply check the box below to accept the OpenJDK Terms of Use for your comments.

I agree to the OpenJDK Terms of Use for all comments I make in a project in the OpenJDK GitHub organization.

Your comment will be automatically restored once you have accepted the OpenJDK Terms of Use.

@sviswa7 I tend to agree with @jatin-bhateja . AVX3Threshold is a diagnostic flag so if someone has deliberately modified it so they can measure something, your change will make that impossible on newer systems. You may want to define a static field to store the actual value for avx3_threshold() to return and initialize it during VM initialization. Or lazy initialize it on first use.

sviswa7 · 2021-11-23T22:20:53Z

@DamonFool There are jmh tests for Arraycopy in test/micro/org/openjdk/bench/java/lang/Arraycopy.java.

sviswa7 · 2021-11-24T16:51:48Z

@dholmes-ora @jatin-bhateja I have added a check for FLAG_IS_DEFAULT before overriding the threshold. Let me know if this looks ok to you.

jatin-bhateja

Thanks @sviswa7 , changes looks good to me.
Best Regards

dholmes-ora

General change looks okay but I have a query below about startup overhead.

Also what testing has been done for this aside from the benchmarking? AFAICS there is only a single test that currently sets AVX3Threshold to zero so we have very little test coverage for that. With this change it will be zero all the time on some systems and so will now be exercising code paths that do not normally get executed.

Thanks,
David

dholmes-ora · 2021-11-25T05:10:49Z

src/hotspot/cpu/x86/vm_version_x86.cpp

+int VM_Version::avx3_threshold() {
+  if (FLAG_IS_DEFAULT(AVX3Threshold)) {
+    return ((is_intel_family_core() &&
+             supports_serialize()) ? 0: AVX3Threshold);
+  } else {
+    return AVX3Threshold;
+  }
+}


I am somewhat concerned about the overhead of evaluating this each time it is used. I realize these will only be startup costs while generating the stubs, not part of the stubs themselves, but it still may be a startup impact. Can you run a startup benchmark to see if there is any problem?

I was also thinking the more direct formulation would just be:
return (is_intel_family_core() && supports_serialize() && FLAG_IS_DEFAULT(AVX3Threshold)) ? 0 : AVX3Threshold;

Hi @sviswa7 agree with @dholmes-ora , instead of calling multiple times in a stub can we not call it only once per stub? Since stubs are assembled once and not relocated hence it should be okay to call this method only once for stubs which are going to benefit form this change.

neliasso · 2021-11-29T09:31:32Z

/label hotspot-compiler

openjdk · 2021-11-29T09:32:19Z

@neliasso
The hotspot-compiler label was successfully added.

neliasso · 2021-12-01T09:20:48Z

We don't use the 64-byte instructions as default on Intel's old AVX512 platforms, right? If so, is it possible a performance regression for the old platforms after this patch? Thanks.

As I understand it - old AVX512 platforms will continue to work as before. The new case is that new platforms (that have avx_threshold set to 0) will use 64 byte instructions. But it would be nice with some benchmarks that verify that there are no regression on old avx512 hardware.

neliasso

I am happy with the change but would like to see some benchmarks that verify that there are no regressions - [before/after]*[avx2/old avx512/new avx512]. You have already posted some of them - please complete with the missing ones.

DamonFool · 2021-12-01T09:39:18Z

As I understand it - old AVX512 platforms will continue to work as before.

According to @sviswa7 's comments (no cupid bit for the latest ISA), is_intel_family_core() && supports_serialize() can't distinguish all the old AVX512 platforms from the latest ones.
So I think it may be possible some old AVX512 machines will behave differently after this opt.

@sviswa7 , can you further explain what's the difference of the 64-byte instructions between Intel's old and latest AVX512 platforms?
Why can't we enable them as default on old platforms?
Thanks.

dholmes-ora · 2021-12-01T12:41:14Z

As I understand it - old AVX512 platforms will continue to work as before.

According to @sviswa7 's comments (no cupid bit for the latest ISA), is_intel_family_core() && supports_serialize() can't distinguish all the old AVX512 platforms from the latest ones. So I think it may be possible some old AVX512 machines will behave differently after this opt.

I do not see such comments. From my previous questions on this it was indicated that any CPU that supports serialize has the improved performance.

DamonFool · 2021-12-01T13:51:33Z

From my previous questions on this it was indicated that any CPU that supports serialize has the improved performance.

If so, CPUs that don't support serialize would behave as before.
Then there shouldn't be any performance regression.

sviswa7 · 2021-12-01T18:41:33Z

Yes, the patch doesn't change behavior on AVX2 and older AVX512 systems.

The additional performance numbers with the patch requested by Nils are as below:

Old AVX512
Before:

Benchmark                                    Mode  Cnt   Score   Error  Units
ArrayCopy.arrayCopyObject                    avgt    5  18.650 ± 2.773  ns/op
ArrayCopy.arrayCopyObjectNonConst            avgt    5  20.241 ± 1.398  ns/op
ArrayCopy.arrayCopyObjectSameArraysBackward  avgt    5  16.252 ± 0.076  ns/op
ArrayCopy.arrayCopyObjectSameArraysForward   avgt    5  15.965 ± 0.172  ns/op

After:

Benchmark                                    Mode  Cnt   Score   Error  Units
ArrayCopy.arrayCopyObject                    avgt    5  17.701 ± 2.623  ns/op
ArrayCopy.arrayCopyObjectNonConst            avgt    5  20.588 ± 0.775  ns/op
ArrayCopy.arrayCopyObjectSameArraysBackward  avgt    5  16.219 ± 0.066  ns/op
ArrayCopy.arrayCopyObjectSameArraysForward   avgt    5  15.937 ± 0.185  ns/op

AVX2
Before:

Benchmark                                    Mode  Cnt   Score   Error  Units
ArrayCopy.arrayCopyObject                    avgt    5  23.801 ± 0.090  ns/op
ArrayCopy.arrayCopyObjectNonConst            avgt    5  24.376 ± 0.867  ns/op
ArrayCopy.arrayCopyObjectSameArraysBackward  avgt    5  14.015 ± 0.016  ns/op
ArrayCopy.arrayCopyObjectSameArraysForward   avgt    5  15.355 ± 0.024  ns/op

After:

Benchmark                                    Mode  Cnt   Score   Error  Units
ArrayCopy.arrayCopyObject                    avgt    5  23.373 ± 0.629  ns/op
ArrayCopy.arrayCopyObjectNonConst            avgt    5  24.390 ± 0.875  ns/op
ArrayCopy.arrayCopyObjectSameArraysBackward  avgt    5  13.995 ± 0.056  ns/op
ArrayCopy.arrayCopyObjectSameArraysForward   avgt    5  15.383 ± 0.051  ns/op

DamonFool · 2021-12-01T23:19:47Z

Yes, the patch doesn't change behavior on AVX2 and older AVX512 systems.

Thanks for your clarification.
But it still remains unknown why the 64-byte instructions shouldn't be used on CPUs which don't support serialize.

I will test the 64-byte instructions on older AVX512 systems today and feedback here.

mlbridge · 2021-12-02T00:01:54Z

Mailing list message from David Holmes on hotspot-dev:

On 1/12/2021 5:11 pm, Jie Fu wrote:

On Wed, 1 Dec 2021 03:38:00 GMT, Jie Fu <jiefu at openjdk.org> wrote:

@dholmes-ora We see about 25% gain on a micro on our latest platform. There is no cpuid bit for this, so the closest was to check for the new serialize ISA supported on this platform.

It would be better to add a jmh test for this opt.
Thanks.

@DamonFool There are jmh tests for Arraycopy in test/micro/org/openjdk/bench/java/lang/Arraycopy.java.

So how about posting the detailed perf data before and after this patch?
Thanks.

@DamonFool There are jmh tests for Arraycopy in test/micro/org/openjdk/bench/java/lang/Arraycopy.java.

So how about posting the detailed perf data before and after this patch? Thanks.

Before: Benchmark Mode Cnt Score Error Units ArrayCopy.arrayCopyObject avgt 5 19.538 ? 0.073 ns/op ArrayCopy.arrayCopyObjectNonConst avgt 5 20.513 ? 0.104 ns/op ArrayCopy.arrayCopyObjectSameArraysBackward avgt 5 15.919 ? 0.652 ns/op ArrayCopy.arrayCopyObjectSameArraysForward avgt 5 15.669 ? 0.359 ns/op

After: Benchmark Mode Cnt Score Error Units ArrayCopy.arrayCopyObject avgt 5 16.957 ? 0.584 ns/op ArrayCopy.arrayCopyObjectNonConst avgt 5 17.221 ? 0.036 ns/op ArrayCopy.arrayCopyObjectSameArraysBackward avgt 5 12.952 ? 0.068 ns/op ArrayCopy.arrayCopyObjectSameArraysForward avgt 5 13.562 ? 0.124 ns/op

Thanks @sviswa7 for your sharing.
So the performance number looks good on Intel's latest AVX512 platform.

We don't use the 64-byte instructions as default on Intel's old AVX512 platforms, right?
If so, is it possible a performance regression for the old platforms after this patch?
Thanks.

The old platforms, for which serialize() is not true, will just use
AVX3Threshold as they do today.

David
----

DamonFool · 2021-12-02T02:28:57Z

Yes, the patch doesn't change behavior on AVX2 and older AVX512 systems.

Thanks for your clarification. But it still remains unknown why the 64-byte instructions shouldn't be used on CPUs which don't support serialize.

I will test the 64-byte instructions on older AVX512 systems today and feedback here.

Here is the performance data on our older AVX512 platform which doesn't support serialize.

Even without serialize , the performance has been improved with 64-byte instructions.
E.g., for ArrayCopy.arrayCopyObjectNonConst, it has been improved by ~15%.

So it seems unfair only enable 64-byte instructions for the latest Intel AVX512 platforms.

Still, I would like to know why we don't use 64-byte instructions on platforms without serialize support.
Thanks.

Results with 32-byte instructions.

==> perf32-1.log <==
Benchmark                                    Mode  Cnt   Score   Error  Units
ArrayCopy.arrayCopyObject                    avgt    5  24.070 ± 0.013  ns/op
ArrayCopy.arrayCopyObjectNonConst            avgt    5  27.517 ± 0.023  ns/op
ArrayCopy.arrayCopyObjectSameArraysBackward  avgt    5  21.127 ± 0.008  ns/op
ArrayCopy.arrayCopyObjectSameArraysForward   avgt    5  21.934 ± 0.009  ns/op

==> perf32-2.log <==
Benchmark                                    Mode  Cnt   Score   Error  Units
ArrayCopy.arrayCopyObject                    avgt    5  24.511 ± 0.027  ns/op
ArrayCopy.arrayCopyObjectNonConst            avgt    5  27.240 ± 0.034  ns/op
ArrayCopy.arrayCopyObjectSameArraysBackward  avgt    5  21.065 ± 0.013  ns/op
ArrayCopy.arrayCopyObjectSameArraysForward   avgt    5  21.956 ± 0.161  ns/op

==> perf32-3.log <==
Benchmark                                    Mode  Cnt   Score   Error  Units
ArrayCopy.arrayCopyObject                    avgt    5  25.357 ± 0.006  ns/op
ArrayCopy.arrayCopyObjectNonConst            avgt    5  27.513 ± 1.468  ns/op
ArrayCopy.arrayCopyObjectSameArraysBackward  avgt    5  20.984 ± 0.024  ns/op
ArrayCopy.arrayCopyObjectSameArraysForward   avgt    5  20.945 ± 1.346  ns/op

Results with 64-byte instructions.

==> perf64-1.log <==
Benchmark                                    Mode  Cnt   Score   Error  Units
ArrayCopy.arrayCopyObject                    avgt    5  23.425 ± 0.003  ns/op
ArrayCopy.arrayCopyObjectNonConst            avgt    5  23.530 ± 0.002  ns/op
ArrayCopy.arrayCopyObjectSameArraysBackward  avgt    5  20.174 ± 0.074  ns/op
ArrayCopy.arrayCopyObjectSameArraysForward   avgt    5  19.942 ± 0.134  ns/op

==> perf64-2.log <==
Benchmark                                    Mode  Cnt   Score   Error  Units
ArrayCopy.arrayCopyObject                    avgt    5  22.429 ± 0.012  ns/op
ArrayCopy.arrayCopyObjectNonConst            avgt    5  25.189 ± 0.031  ns/op
ArrayCopy.arrayCopyObjectSameArraysBackward  avgt    5  20.093 ± 0.004  ns/op
ArrayCopy.arrayCopyObjectSameArraysForward   avgt    5  20.400 ± 1.213  ns/op

==> perf64-3.log <==
Benchmark                                    Mode  Cnt   Score   Error  Units
ArrayCopy.arrayCopyObject                    avgt    5  23.472 ± 0.002  ns/op
ArrayCopy.arrayCopyObjectNonConst            avgt    5  23.534 ± 0.031  ns/op
ArrayCopy.arrayCopyObjectSameArraysBackward  avgt    5  20.232 ± 0.150  ns/op
ArrayCopy.arrayCopyObjectSameArraysForward   avgt    5  21.921 ± 0.008  ns/op

mlbridge · 2021-12-02T02:48:52Z

Mailing list message from David Holmes on hotspot-dev:

On 1/12/2021 11:54 pm, Jie Fu wrote:

On Wed, 1 Dec 2021 12:41:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

From my previous questions on this it was indicated that any CPU that supports `serialize` has the improved performance.

If so, CPUs that don't support `serialize` would behave as before.
Then there shouldn't be any performance regression.

Yes, which is exactly why we have been saying this should not affect
"old" CPUs.

David

mlbridge · 2021-12-02T02:53:52Z

Mailing list message from David Holmes on hotspot-dev:

On 2/12/2021 12:32 pm, Jie Fu wrote:

On Wed, 1 Dec 2021 23:19:47 GMT, Jie Fu <jiefu at openjdk.org> wrote:

Yes, the patch doesn't change behavior on AVX2 and older AVX512 systems.

Thanks for your clarification. But it still remains unknown why the 64-byte instructions shouldn't be used on CPUs which don't support `serialize`.

I will test the 64-byte instructions on older AVX512 systems today and feedback here.

Here is the performance data on our older AVX512 platform which doesn't support `serialize`.

Even without `serialize` , the performance has been improved with 64-byte instructions.
E.g., for `ArrayCopy.arrayCopyObjectNonConst`, it has been improved by ~15%.

So it seems unfair only enable 64-byte instructions for the latest Intel AVX512 platforms.

Still, I would like to know why we don't use 64-byte instructions on platforms without `serialize` support.

Because, as previously stated, there is no actual way to identify those
CPUs. But we know that if they support serialize then they also support
the faster 64-bit ops. But that doesn't means that if they don't support
serialize that they don't support the faster 64-bit ops. So all that is
available for choosing whether to use them or not is whether serialize
is supported.

David

DamonFool · 2021-12-02T03:34:47Z

Because, as previously stated, there is no actual way to identify those
CPUs. But we know that if they support serialize then they also support
the faster 64-bit ops. But that doesn't means that if they don't support
serialize that they don't support the faster 64-bit ops. So all that is
available for choosing whether to use them or not is whether serialize
is supported.

OK, make sense!
Since it won't make things worse for the "old" systems, I'm fine with it.
Thanks.

DamonFool

LGTM

openjdk · 2021-12-02T03:36:17Z

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

8277617: Adjust AVX3Threshold for copy/fill stubs

Reviewed-by: jbhateja, dholmes, neliasso, jiefu

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 1 new commit pushed to the master branch:

38f525e: 8275821: Optimize random number generators developed in JDK-8248862 using Math.unsignedMultiplyHigh()

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
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.

sviswa7 · 2021-12-02T17:42:42Z

@dholmes-ora @DamonFool @jatin-bhateja @neliasso Thanks a lot for the review. If no further objections, I plan to integrate this PR tomorrow (Friday 12/3).

neliasso

Looks good.

dholmes-ora · 2021-12-03T03:38:32Z

Please check the GHA test results before integrating - there is a failing compiler test.

…earopt

sviswa7 · 2021-12-03T18:14:55Z

@dholmes-ora I looked at the results. The failure in compiler/c2/irTests/TestUnsignedComparison.java for x86_32 is unrelated to this patch ( https://bugs.openjdk.java.net/browse/JDK-8277324) and was fixed recently. A merge with master should fix that.

sviswa7 · 2021-12-03T21:04:11Z

/integrate

openjdk · 2021-12-03T21:06:33Z

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

2b87c2b: 8277793: Support vector F2I and D2L cast operations for X86
e1cde19: 8278247: KeyStoreSpi::engineGetAttributes does not throws KeyStoreException
a729a70: 8225181: KeyStore should have a getAttributes method
38f525e: 8275821: Optimize random number generators developed in JDK-8248862 using Math.unsignedMultiplyHigh()

Your commit was automatically rebased without conflicts.

openjdk · 2021-12-03T21:06:58Z

@sviswa7 Pushed as commit 24e16ac.

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

8277617: Optimize array copy and clear on x86_64

54aa9ce

openjdk bot added the hotspot label Nov 23, 2021

sviswa7 marked this pull request as ready for review Nov 23, 2021

openjdk bot added the rfr label Nov 23, 2021

restrict to Intel core and add comment

e0cb890

update comment for avx3_threshold() with more details

c90e700

jatin-bhateja reviewed Nov 23, 2021

View changes

Override threshold only if flag is default

021bc65

sviswa7 changed the title ~~8277617: Optimize array copy and clear on x86_64~~ 8277617: Adjust AVX3Threshold for copy/fill stubs Nov 24, 2021

jatin-bhateja approved these changes Nov 24, 2021

View changes

dholmes-ora reviewed Nov 25, 2021

View changes

openjdk bot added the hotspot-compiler label Nov 29, 2021

Implement review comments

b44b63e

openjdk bot removed the rfr label Nov 29, 2021

neliasso suggested changes Dec 1, 2021

View changes

DamonFool approved these changes Dec 2, 2021

View changes

openjdk bot added the ready label Dec 2, 2021

neliasso approved these changes Dec 2, 2021

View changes

dholmes-ora approved these changes Dec 3, 2021

View changes

Merge branch 'master' of https://git.openjdk.java.net/jdk into copycl…

9cbfc37

…earopt

openjdk bot closed this Dec 3, 2021

openjdk bot added integrated and removed ready rfr labels Dec 3, 2021

eastig mentioned this pull request May 17, 2022

8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs #8731

Open

3 tasks

sviswa7 deleted the copyclearopt branch Jun 1, 2022

		static int avx3_threshold() { return ((is_intel_family_core() &&
		supports_serialize()) ? 0: AVX3Threshold); }

8277617: Adjust AVX3Threshold for copy/fill stubs #6512

8277617: Adjust AVX3Threshold for copy/fill stubs #6512

Conversation

sviswa7 commented Nov 23, 2021 • edited by openjdk[bot] bot

Progress

Issue

Reviewers

Reviewing

bridgekeeper bot commented Nov 23, 2021

openjdk bot commented Nov 23, 2021

mlbridge bot commented Nov 23, 2021 • edited

Webrevs

dholmes-ora commented Nov 23, 2021

dholmes-ora commented Nov 23, 2021

sviswa7 commented Nov 23, 2021

dholmes-ora commented Nov 23, 2021

sviswa7 commented Nov 23, 2021

dholmes-ora commented Nov 23, 2021

sviswa7 commented Nov 23, 2021

DamonFool commented Nov 23, 2021

dholmes-ora commented Nov 23, 2021

jatin-bhateja Nov 23, 2021

Choose a reason for hiding this comment

sviswa7 Nov 23, 2021

Choose a reason for hiding this comment

vitalyd Nov 24, 2021 • edited by bridgekeeper[bot] bot

Choose a reason for hiding this comment

dholmes-ora Nov 24, 2021

Choose a reason for hiding this comment

sviswa7 commented Nov 23, 2021

sviswa7 commented Nov 24, 2021

jatin-bhateja left a comment

dholmes-ora left a comment

dholmes-ora Nov 25, 2021

Choose a reason for hiding this comment

jatin-bhateja Nov 27, 2021

Choose a reason for hiding this comment

neliasso commented Nov 29, 2021

openjdk bot commented Nov 29, 2021

neliasso commented Dec 1, 2021

neliasso left a comment

DamonFool commented Dec 1, 2021

dholmes-ora commented Dec 1, 2021

DamonFool commented Dec 1, 2021

sviswa7 commented Dec 1, 2021

DamonFool commented Dec 1, 2021

mlbridge bot commented Dec 2, 2021

DamonFool commented Dec 2, 2021

mlbridge bot commented Dec 2, 2021

mlbridge bot commented Dec 2, 2021

DamonFool commented Dec 2, 2021

DamonFool left a comment

openjdk bot commented Dec 2, 2021 • edited

sviswa7 commented Dec 2, 2021

neliasso left a comment

dholmes-ora commented Dec 3, 2021

sviswa7 commented Dec 3, 2021

sviswa7 commented Dec 3, 2021

openjdk bot commented Dec 3, 2021

openjdk bot commented Dec 3, 2021

sviswa7 commented Nov 23, 2021 •

edited by openjdk[bot] bot

mlbridge bot commented Nov 23, 2021 •

edited

vitalyd Nov 24, 2021 •

edited by bridgekeeper[bot] bot

openjdk bot commented Dec 2, 2021 •

edited