8329538: Accelerate P256 on x86_64 using Montgomery intrinsic #18583

vpaprotsk · 2024-04-02T15:42:05Z

Performance. Before:

Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ±  6.491  ops/s
SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ±  4.954  ops/s
SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ± 36.979  ops/s
SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ± 45.487  ops/s
Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ± 26.584  ops/s
o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ± 23.547  ops/s
Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ± 10.970  ops/s

Performance, no intrinsic:

Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ±  42.420  ops/s
SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ± 133.566  ops/s
SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ±  54.071  ops/s
SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ±  35.920  ops/s
Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ± 29.858  ops/s
o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ± 28.722  ops/s
Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.574 ± 10.591  ops/s

Performance, with intrinsics

Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  10384.591 ±  65.274  ops/s
SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3   9592.912 ± 236.411  ops/s
SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3   3479.494 ±  44.578  ops/s
SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3   3402.147 ±  26.772  ops/s
Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  2527.678 ± 64.791  ops/s
o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  2541.258 ± 66.634  ops/s
Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
PolynomialP256Bench.benchMultiply           true  thrpt    3  3021.139 ± 98.289  ops/s

Summary on design (see code for 'ASCII art', references and details on math):

Added a new IntegerPolynomial field (MontgomeryIntegerPolynomialP256) with 52-bit limbs
- getElement(*)/fromMontgomery() to convert numbers into/out of the field
ECOperations is the primary use of the new field
- flattened some extra deep nested class hierarchy (also in prep for further other field optimizations)
- forParameters()/multiply()/setSum() generates numbers in the new field
ProjectivePoint/Montgomery{Imm|M}utable.asAffine() to convert out of the new field
Added Fuzz Testing and KAT verified with OpenSSL

Progress

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

Issue

JDK-8329538: Accelerate P256 on x86_64 using Montgomery intrinsic (Enhancement - P4)

Reviewers

Magnus Ihse Bursie (@magicus - Reviewer) ⚠️ Review applies to 82b6dae7
Anthony Scarpino (@ascarpino - Reviewer) ⚠️ Review applies to 8cd095dd
Sandhya Viswanathan (@sviswa7 - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 18583

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

Using diff file

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

Webrev

Link to Webrev Comment

- MontgomeryIntegerPolynomialP256 - Cleaned up montgomery in conversion; now automatically via Field.getElement() - removed toMontgomery() (and its interface) - Rearange and comment code, remove debug traces - (TODO: fix getElement(byte[])) - ECOperations - No more hashmap lookup on every multiply (ifs instead), removed trampoline - Regression; put back lazy loading of static constant table for better VM startup - Cleaned up tomontgomery conversion to use Field.getElement() - Flattened multilayer PointMultiplication (was ECOperations.PointMultiplier.LargeTable.P256 made even worse by new montgomery multipliers) - removed (pre-existing incorrect) use of member classes - Added comments and more comments - Made ECOperations.montgomeryOps private - Patched tests to use reflection to access ECOperations.montgomeryOps - stubGenerator_x86)64_poly_mont.cpp - Comments were very wrong, fixed/rewrote comments - Added ascii art for vector operations - Removed montgomery percolation in crypto ParameterSpec APIs - Enabled montgomery intrinsics by default - Fixed test cases (ECOperationsFussTest.java, ECOperationsKAT.java, MontgomeryPolynomialFuzzTest.java) - Typos from context switch - Fixes needed after refactoring - Use reflection to disable montgomery - getElement() refactored, unfix uses - Fixed PolynomialP256Bench microbenchmark - Need to remeasure - Removed changes in SignatureBench and KeyAggreementBench - Will use original with baseline SDK

bridgekeeper · 2024-04-02T15:42:26Z

👋 Welcome back vpaprotsk! 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-04-02T15:43:31Z

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

8329538: Accelerate P256 on x86_64 using Montgomery intrinsic

Reviewed-by: ihse, ascarpino, sviswanathan

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

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

9ca90cc: 8332610: Remove unused nWakeups in ObjectMonitor
92d3350: 8331920: ubsan: g1CardSetContainers.inline.hpp:266:5: runtime error: index 2 out of bounds for type 'G1CardSetHowl::ContainerPtr [2]' reported
4f1a10f: 8332360: JVM hangs at exit when running on a uniprocessor
c3bc23f: 8326306: RISC-V: Re-structure MASM calls and jumps
8a9d77d: 8320622: [TEST] Improve coverage of compiler/loopopts/superword/TestMulAddS2I.java on different platforms
3d511ff: 8329748: Change default value of AssertWXAtThreadSync to true
67f03f2: 8332533: RISC-V: Enable vector variable shift instructions for machines with RVV
5f804b2: 8329825: Clarify the value type for java.net.SocketOptions.SO_LINGER

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.

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 (@magicus, @jatin-bhateja, @ascarpino, @sviswa7) but any other Committer may sponsor as well.

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

openjdk · 2024-04-02T15:43:56Z

@vpaprotsk The following labels will be automatically applied to this pull request:

build
core-libs
graal
hotspot
security

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

mlbridge · 2024-04-02T16:10:53Z

Webrevs

AlanBateman · 2024-04-02T16:29:07Z

src/java.base/share/classes/module-info.java

        jdk.jfr,
-        jdk.unsupported;
+        jdk.unsupported,
+        jdk.crypto.ec;


jdk.crypto.ec has been hollowed out since JDK 22, the sun.security.ec are in java.base. So I don't think you need this qualified export.

Thanks, fixed. (Started this when jdk.crypto.ec was still in use.. missed a few spots during rebase I guess)

magicus

Build changes are trivially fine.
/reviewers 3

openjdk · 2024-04-03T09:47:29Z

@magicus
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 3 (with at least 1 Reviewer, 2 Authors).

jatin-bhateja

Few early comments.

Please update the copyright year of all the modified files.

You can even consider splitting this into two patches, Java side changes in one and x86 optimized intrinsic in next one.

jatin-bhateja · 2024-04-05T02:49:55Z

src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp

+  __ cmpl(length, 19);
+  __ jcc(Assembler::equal, L_Length19);
+
+  // Default copy loop


Please add appropriate loop entry alignment.

This is actually a 'switch statement default'. The default should never happen (See "Known Length comment on line 335"), but added because java code has that behavior. (i.e. in the unlikely case NIST adds a new elliptic curve to the existing standard?)

jatin-bhateja · 2024-04-05T07:19:28Z

src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp

+ATTRIBUTE_ALIGNED(64) uint64_t MODULUS_P256[] = {
+  0x000fffffffffffff, 0x00000fffffffffff,
+  0x0000000000000000, 0x0000001000000000,
+  0x0000ffffffff0000, 0x0000000000000000,
+  0x0000000000000000, 0x0000000000000000
+};
+static address modulus_p256() {
+  return (address)MODULUS_P256;


Long constants should have UL suffix.

Properly ULL, but good point, fixed

jatin-bhateja · 2024-04-05T07:50:15Z

src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp

+  __ bind(L_DefaultLoop);
+  __ cmpl(length, 0);
+  __ jcc(Assembler::less, L_Done);
+  assign_scalar(Address(aLimbs, 0), Address(bLimbs, 0), set, tmp, _masm);
+  __ subl(length, 16);
+  __ lea(aLimbs, Address(aLimbs,8));
+  __ lea(bLimbs, Address(bLimbs,8));
+  __ jmp(L_DefaultLoop);


Both sub and cmp are flag affecting instructions and are macro-fusible.
By doing a loop rotation i.e. moving the length <= 0 check outside the loop and pushing the loop exit check at bottom you can save additional compare checks.

Per-above, this is a switch statement (UNLIKELY) fallback. I can still add alignment and loop rotation, but being a fallback figured its more important to keep it small&readable...

It's all part of intrinsic, no harm in polishing it.

Done (normalized loop/backedge). There was actually a problem in the loop counter.. (i-=1 instead of i-=16). Can't include a test since classes are sealed, but verified manually.

vpaprotsk · 2024-04-05T17:44:47Z

@ascarpino Hi Tony, this is the ECC P256 PR we talked about last year, would appreciate your feedback.

ascarpino · 2024-04-10T17:18:55Z

In ECOperations.java, if I understand this correctly, it is to replace the existing PointMultiplier with montgomery-based PointMuliplier. But when I look at the code, I see both are still options. If I read this correctly, it checks for the old IntegerFieldModuloP, then looks for the new IntegerMontgomeryFieldModuloP. It appears to use the new one always.
Why doesn't it just replace the old implementation entry in the fields Map? Is there a reason to keep it around?

vpaprotsk · 2024-04-10T18:02:38Z

In ECOperations.java, if I understand this correctly, it is to replace the existing PointMultiplier with montgomery-based PointMuliplier. But when I look at the code, I see both are still options. If I read this correctly, it checks for the old IntegerFieldModuloP, then looks for the new IntegerMontgomeryFieldModuloP. It appears to use the new one always. Why doesn't it just replace the old implementation entry in the fields Map? Is there a reason to keep it around?

Hmm, thats a good point I haven't fully considered; i.e. (if I read correctly) "for CurveDB.P_256 remove the fallback path to non-montgomery entirely".. that might also help in cleaning a few things up in the construction. Maybe even get rid of this nested ECOperations inside ECOperations.. Perhaps nesting isnt a big deal, but all attempts to make the ECC stack clearer is positive!

One functional reason that might justify keeping it as-is, is fuzz-testing; with the fallback available, I am able to write the included Fuzz tests and have them check the values against the existing implementation. While I also included a few KAT tests using openssl-generated values, the fuzz tests check millions of values and it does add a lot more certainty about correctness of this code.

Can it be removed? For the operations that do not involve multiplication (i.e. setSum(*)), montgomery is expensive. I think I did go through the uses of this code some time back (i.e. ECDHE, ECDSA and KeyGeneration) and existing IntegerPolynomialP256 is no longer used (I should verify that again) and only P256OrderField remains non-montgomery. So removing references to IntegerPolynomialP256 in ECOperations should be possible and cleaner. Removing IntegerPolynomialP256 from MontgomeryIntegerPolynomialP256 is harder (fromMontgomery() uses IntegerPolynomialP256) but perhaps also worth some thought..

I tend to like ECOperationsFuzzTest.java and would prefer to keep it, but it could also be chucked up as part of 'scaffolding' and removed in name of code quality?

Thanks @ascarpino

PS: Perhaps there is some middle ground, remove the ECOperations montgomeryOps nesting, and construct (somehow?? singleton makes most things inaccessible..) the reference ECOperations in the fuzz test instead.. not sure how yet, but perhaps worth a further thought..

vpaprotsk · 2024-04-10T23:56:52Z

Few early comments.

Please update the copyright year of all the modified files.

You can even consider splitting this into two patches, Java side changes in one and x86 optimized intrinsic in next one.

Thanks Jatin, will fix!

ascarpino · 2024-04-11T17:15:21Z

In ECOperations.java, if I understand this correctly, it is to replace the existing PointMultiplier with montgomery-based PointMuliplier. But when I look at the code, I see both are still options. If I read this correctly, it checks for the old IntegerFieldModuloP, then looks for the new IntegerMontgomeryFieldModuloP. It appears to use the new one always. Why doesn't it just replace the old implementation entry in the fields Map? Is there a reason to keep it around?

Hmm, thats a good point I haven't fully considered; i.e. (if I read correctly) "for CurveDB.P_256 remove the fallback path to non-montgomery entirely".. that might also help in cleaning a few things up in the construction. Maybe even get rid of this nested ECOperations inside ECOperations.. Perhaps nesting isnt a big deal, but all attempts to make the ECC stack clearer is positive!

One functional reason that might justify keeping it as-is, is fuzz-testing; with the fallback available, I am able to write the included Fuzz tests and have them check the values against the existing implementation. While I also included a few KAT tests using openssl-generated values, the fuzz tests check millions of values and it does add a lot more certainty about correctness of this code.

I hadn't looked at your fuzz test until you mentioned it. I see you are using reflection to change the values. Is that what you mean by "fallback"? I'm assuming there is no to access the older implementation without reflection.

Can it be removed? For the operations that do not involve multiplication (i.e. setSum(*)), montgomery is expensive. I think I did go through the uses of this code some time back (i.e. ECDHE, ECDSA and KeyGeneration) and existing IntegerPolynomialP256 is no longer used (I should verify that again) and only P256OrderField remains non-montgomery. So removing references to IntegerPolynomialP256 in ECOperations should be possible and cleaner. Removing IntegerPolynomialP256 from MontgomeryIntegerPolynomialP256 is harder (fromMontgomery() uses IntegerPolynomialP256) but perhaps also worth some thought..

I tend to like ECOperationsFuzzTest.java and would prefer to keep it, but it could also be chucked up as part of 'scaffolding' and removed in name of code quality?

I wouldn't rip out the old implementation. I have been wondering if we should make the older implementation available, maybe by security property. I was looking at the static Maps at the top of ECOperations, forParameters, and the constructors where it checks if the montgomeryOps was null or set. It would be nice if we could have one set of fields Maps by putting the montgomery entry into the fields to replace it. I think that should work because IntegerMontgomeryFieldModuloP extends IntegerFieldModuloP. instanceof or other montgomeryOps checks would still need to exist because not all the fields support mongomery, and the older implementation would still be accessible for your fuzz tester. At least that is my theory.

Thanks @ascarpino

PS: Perhaps there is some middle ground, remove the ECOperations montgomeryOps nesting, and construct (somehow?? singleton makes most things inaccessible..) the reference ECOperations in the fuzz test instead.. not sure how yet, but perhaps worth a further thought..

It would be nice to remove the nesting and it would be nice to be a singleton. Maybe some combination of what I mentioned above chance can help that. I haven't fully thought this out either.

vpaprotsk · 2024-04-15T22:06:44Z

Few early comments.

Please update the copyright year of all the modified files.

You can even consider splitting this into two patches, Java side changes in one and x86 optimized intrinsic in next one.

Fixed all copyright years

git diff da8a095a19c90e7ee2b45fab9b533a1092887023 | lsdiff -p1 | while read line; do echo $line =========================; grep Copyright $line | grep -v 2024; done | less

Re splitting.. probably too late for that now.. (did consider it initially.. got hard to manage two changes while developing. And easier to justify the change when the entire patch is presented? but yes, far more code to review.. )

ascarpino

The changes look good and have passed testing

sviswa7 · 2024-05-16T17:49:56Z

src/hotspot/cpu/x86/vm_version_x86.cpp

  }

+#ifdef _LP64
+  if (supports_avx512ifma() && supports_avx512vlbw() && MaxVectorSize >= 64) {


No need to tie the intrinsic to MaxVectorSize setting.

sviswa7 · 2024-05-16T18:27:36Z

src/hotspot/share/opto/library_call.cpp

+  stubName = "intpoly_assign";
+
+  if (!stubAddr) return false;
+  if (stopped())  return true;


Line 7564 seems redundant here as there is no range check or anything like that before this.

Oh. That is what that is for... I thought it was some soft of 'VM quitting' short-circuit. Removed.

sviswa7 · 2024-05-16T22:48:14Z

src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp

+  // M = load(*modulus_p256)
+  __ evmovdquq(modulus, allLimbs, ExternalAddress(modulus_p256()), false, Assembler::AVX_512bit, rscratch);
+
+  // A = load(*aLimbs)


A little bit more description in comments on what the load step involves would be helpful. e.g. Load upper 4 limbs, shift left by 1 limb using perm, or in the lowest limb.

sviswa7 · 2024-05-16T23:21:36Z

src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp

+  XMMRegister mask52 = xmm23;
+  XMMRegister broadcast5 = xmm24;
+  KRegister limb0 = k1;
+  KRegister limb5 = k2;


limb5 and select are not being used anymore.

Thanks, fixed (and also broadcast5)

sviswa7 · 2024-05-16T23:28:23Z

src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp

+  // Save all 'SOE' registers
+  __ push(rbx);
+  #ifdef _WIN64
+  __ push(rsi);
+  __ push(rdi);
+  #endif
+  __ push(r12);
+  __ push(r13);
+  __ push(r14);
+  __ push(r15);
+


No need to save/restore rbx, r12, r14, r15. Only r13 is used as temp in montgomeryMultiply(aLimbs, bLimbs, rLimbs). That too could be easily changed to r8.

Seems I forgot to completely cleanup, thanks! (Originally copied from poly1305 stub)

sviswa7 · 2024-05-16T23:31:27Z

src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp

+  __ mov(aLimbs, c_rarg0);
+  __ mov(bLimbs, c_rarg1);
+  __ mov(rLimbs, c_rarg2);


We could directly call montgomeryMultiply(c_rarg0, c_rarg1, c_rarg2) then these moves are not necessary.

Gave them symbolic names and passed the gpr temp and parameter. vector register map still in the montgomeryMultiply function, but gprs explicitly passed in. 'close enough'?

sviswa7 · 2024-05-17T21:55:30Z

The intrinsics and the C2 changes look good to me.

vpaprotsk · 2024-05-17T22:17:26Z

Thanks Sandhya!

Now that I have @ascarpino approval as well, I plan to integrate next Tuesday.

TobiHartmann · 2024-05-21T07:11:53Z

I'll send this through our testing and will report back once it passed.

TobiHartmann · 2024-05-21T07:21:14Z

I'm getting some conflicts when trying to apply this to master. Could you please merge the PR?

vpaprotsk · 2024-05-21T17:38:53Z

Hi @TobiHartmann , merged with no issues for me. Could you please run the tests again? (I think Tony did run them, but can't hurt verifying again). Thanks!

TobiHartmann · 2024-05-22T05:00:18Z

Thanks! I submitted testing and will report back once it passed.

TobiHartmann · 2024-05-22T14:07:10Z

All tests passed.

vpaprotsk · 2024-05-22T14:19:36Z

Thanks Tobi!

/integrate

openjdk · 2024-05-22T14:20:23Z

@vpaprotsk
Your change (at version b1a3300) is now ready to be sponsored by a Committer.

sviswa7 · 2024-05-22T16:26:29Z

/sponsor

openjdk · 2024-05-22T16:27:30Z

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

9ca90cc: 8332610: Remove unused nWakeups in ObjectMonitor
92d3350: 8331920: ubsan: g1CardSetContainers.inline.hpp:266:5: runtime error: index 2 out of bounds for type 'G1CardSetHowl::ContainerPtr [2]' reported
4f1a10f: 8332360: JVM hangs at exit when running on a uniprocessor
c3bc23f: 8326306: RISC-V: Re-structure MASM calls and jumps
8a9d77d: 8320622: [TEST] Improve coverage of compiler/loopopts/superword/TestMulAddS2I.java on different platforms
3d511ff: 8329748: Change default value of AssertWXAtThreadSync to true
67f03f2: 8332533: RISC-V: Enable vector variable shift instructions for machines with RVV
5f804b2: 8329825: Clarify the value type for java.net.SocketOptions.SO_LINGER

Your commit was automatically rebased without conflicts.

openjdk · 2024-05-22T16:27:36Z

@sviswa7 @vpaprotsk Pushed as commit afed7d0.

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

TobiHartmann · 2024-06-05T11:18:32Z

Unfortunately, this caused a performance regression, see JDK-8333583. @vpaprotsk, please have a look.

vpaprotsk added 5 commits March 26, 2024 14:54

rebase

e36a552

conditionalAssign intrinsic

6285a33

Fix rebase typo

bc8d611

Remeasure performance

7bf06b7

openjdk bot added graal graal-dev@openjdk.org security security-dev@openjdk.org build build-dev@openjdk.org hotspot hotspot-dev@openjdk.org core-libs core-libs-dev@openjdk.org rfr Pull request is ready for review labels Apr 2, 2024

remove trailing whitespace

dbe6cd3

AlanBateman reviewed Apr 2, 2024

View reviewed changes

remove use of jdk.crypto.ec

82b6dae

magicus approved these changes Apr 3, 2024

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Apr 3, 2024

openjdk bot removed the ready Pull request is ready to be integrated label Apr 3, 2024

jatin-bhateja reviewed Apr 5, 2024

View reviewed changes

Comments from Jatin and Tony

6f9ac04

add message back

83b2131

openjdk bot added the rfr Pull request is ready for review label May 10, 2024

whitespace

8cd095d

ascarpino approved these changes May 13, 2024

View reviewed changes

sviswa7 reviewed May 16, 2024

View reviewed changes

vpaprotsk added 2 commits May 17, 2024 17:09

comments from Sandhya

5c360e3

shenandoah verifier

df4fe6f

sviswa7 approved these changes May 17, 2024

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label May 17, 2024

Merge remote-tracking branch 'origin/master' into ecc-montgomery

b1a3300

openjdk bot added the sponsor Pull request is ready to be sponsored label May 22, 2024

openjdk bot added the integrated Pull request has been integrated label May 22, 2024

openjdk bot closed this May 22, 2024

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review sponsor Pull request is ready to be sponsored labels May 22, 2024

graalvmbot mentioned this pull request May 22, 2024

[GR-54229] Port _intpoly_montgomeryMult_P256 and _intpoly_assign intrinsics. oracle/graal#8957

Closed

8329538: Accelerate P256 on x86_64 using Montgomery intrinsic #18583

8329538: Accelerate P256 on x86_64 using Montgomery intrinsic #18583

Uh oh!

Conversation

vpaprotsk commented Apr 2, 2024 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Webrev

Uh oh!

bridgekeeper bot commented Apr 2, 2024

Uh oh!

openjdk bot commented Apr 2, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented Apr 2, 2024

Uh oh!

mlbridge bot commented Apr 2, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

magicus left a comment

Choose a reason for hiding this comment

Uh oh!

openjdk bot commented Apr 3, 2024

Uh oh!

jatin-bhateja left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jatin-bhateja Apr 16, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vpaprotsk commented Apr 5, 2024

Uh oh!

ascarpino commented Apr 10, 2024

Uh oh!

vpaprotsk commented Apr 10, 2024

Uh oh!

vpaprotsk commented Apr 10, 2024

Uh oh!

ascarpino commented Apr 11, 2024

Uh oh!

vpaprotsk commented Apr 15, 2024

Uh oh!

ascarpino left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vpaprotsk commented Apr 2, 2024 •

edited by openjdk bot

Loading

openjdk bot commented Apr 2, 2024 •

edited

Loading

mlbridge bot commented Apr 2, 2024 •

edited

Loading

jatin-bhateja Apr 16, 2024 •

edited

Loading