On Mon, 12 Oct 2026 03:34:28 GMT, Shawn Emery <[email protected]> wrote:
>> Cool - very impressive performance improvements! > >> Cool - very impressive performance improvements! > > Thank you. I've since made an additional change that eliminates a temporary > object which results in an additional ~13% improvement for both > architectures tested. > > @vpaprotsk could you please review these changes as your optimization work > with the P-256 curve in Java makes you a prime (no pun intended) candidate > for review of these changes. > @smemery Looks good so far... I wrote myself a fuzz test (modified my > montgomery p256 one really) and everything is passing after some very long > runs. Thank you for your testing. > Want to stare at the code a bit more though, this one was tricky bit of > machinery and the negative biasing always tripped me up. (PS: I wonder.. what > would it take to get the whole generator up to 64 bits? You might already be > halfway there?) The P-384 EC callers for key generation, key agreement, signing, and verification do not accumulate enough field additions to overflow a `long` limb, so you would need to call internal methods, e.g. setSum(), iteratively in order to do so. However, I'm mostly concerned about covering the EC call paths rather than sequences of arbitrary field operations. ------------- PR Comment: https://git.openjdk.org/jdk/pull/33193#issuecomment-6186224785
