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

8277617: Adjust AVX3Threshold for copy/fill stubs #6512

Closed
wants to merge 7 commits into from

Conversation

sviswa7
Copy link

@sviswa7 sviswa7 commented Nov 23, 2021

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

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
Copy link

@bridgekeeper bridgekeeper bot commented Nov 23, 2021

👋 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
Copy link

@openjdk openjdk bot commented Nov 23, 2021

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

@openjdk openjdk bot added the hotspot label Nov 23, 2021
@sviswa7 sviswa7 marked this pull request as ready for review Nov 23, 2021
@openjdk openjdk bot added the rfr label Nov 23, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Nov 23, 2021

@dholmes-ora
Copy link
Member

@dholmes-ora dholmes-ora commented Nov 23, 2021

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

  1. It changes all use of AVX3Threshold to VM_Version::avx3_threshold()
  2. 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
Copy link
Member

@dholmes-ora dholmes-ora commented Nov 23, 2021

Plus some performance numbers would be useful. Thanks

@sviswa7
Copy link
Author

@sviswa7 sviswa7 commented Nov 23, 2021

@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
Copy link
Member

@dholmes-ora dholmes-ora commented Nov 23, 2021

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
Copy link
Author

@sviswa7 sviswa7 commented Nov 23, 2021

@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
Copy link
Member

@dholmes-ora dholmes-ora commented Nov 23, 2021

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

@sviswa7
Copy link
Author

@sviswa7 sviswa7 commented Nov 23, 2021

@dholmes-ora I have implemented your review comments.

@DamonFool
Copy link
Member

@DamonFool DamonFool commented Nov 23, 2021

@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
Copy link
Member

@dholmes-ora dholmes-ora commented Nov 23, 2021

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.

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

@jatin-bhateja jatin-bhateja Nov 23, 2021

Choose a reason for hiding this comment

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

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

Copy link
Author

@sviswa7 sviswa7 Nov 23, 2021

Choose a reason for hiding this comment

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

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

Copy link

@vitalyd vitalyd Nov 24, 2021

Choose a reason for hiding this comment

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

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.

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

Copy link
Member

@dholmes-ora dholmes-ora Nov 24, 2021

Choose a reason for hiding this comment

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

@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
Copy link
Author

@sviswa7 sviswa7 commented Nov 23, 2021

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

@sviswa7
Copy link
Author

@sviswa7 sviswa7 commented Nov 24, 2021

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

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

@jatin-bhateja jatin-bhateja left a comment

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

Copy link
Member

@dholmes-ora dholmes-ora left a comment

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

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

@dholmes-ora dholmes-ora Nov 25, 2021

Choose a reason for hiding this comment

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

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;

Copy link
Member

@jatin-bhateja jatin-bhateja Nov 27, 2021

Choose a reason for hiding this comment

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

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
Copy link

@neliasso neliasso commented Nov 29, 2021

/label hotspot-compiler

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

@openjdk openjdk bot commented Nov 29, 2021

@neliasso
The hotspot-compiler label was successfully added.

@openjdk openjdk bot removed the rfr label Nov 29, 2021
@neliasso
Copy link

@neliasso neliasso commented Dec 1, 2021

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.

Copy link

@neliasso neliasso left a comment

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
Copy link
Member

@DamonFool DamonFool commented Dec 1, 2021

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
Copy link
Member

@dholmes-ora dholmes-ora commented Dec 1, 2021

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
Copy link
Member

@DamonFool DamonFool commented Dec 1, 2021

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
Copy link
Author

@sviswa7 sviswa7 commented Dec 1, 2021

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
Copy link
Member

@DamonFool DamonFool commented Dec 1, 2021

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
Copy link

@mlbridge mlbridge bot commented Dec 2, 2021

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
Copy link
Member

@DamonFool DamonFool commented Dec 2, 2021

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
Copy link

@mlbridge mlbridge bot commented Dec 2, 2021

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
Copy link

@mlbridge mlbridge bot commented Dec 2, 2021

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
Copy link
Member

@DamonFool DamonFool commented Dec 2, 2021

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.

Copy link
Member

@DamonFool DamonFool left a comment

LGTM

@openjdk
Copy link

@openjdk openjdk bot commented Dec 2, 2021

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

@openjdk openjdk bot added the ready label Dec 2, 2021
@sviswa7
Copy link
Author

@sviswa7 sviswa7 commented Dec 2, 2021

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

Copy link

@neliasso neliasso left a comment

Looks good.

@dholmes-ora
Copy link
Member

@dholmes-ora dholmes-ora commented Dec 3, 2021

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

@sviswa7
Copy link
Author

@sviswa7 sviswa7 commented Dec 3, 2021

@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
Copy link
Author

@sviswa7 sviswa7 commented Dec 3, 2021

/integrate

@openjdk
Copy link

@openjdk openjdk bot commented Dec 3, 2021

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 openjdk bot closed this Dec 3, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Dec 3, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Dec 3, 2021

@sviswa7 Pushed as commit 24e16ac.

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

@sviswa7 sviswa7 deleted the copyclearopt branch Jun 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot hotspot-compiler integrated
6 participants