Re: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v10]
On Fri, 29 Aug 2025 13:48:52 GMT, Volkan Yazici wrote: >> `NoRepl`-suffixed `String` methods denote methods that do not replace >> invalid characters, but throw `CharacterCodingException` on encounter. This >> behavior cannot easily be derived from the method footprints, has been a >> source of confusion for maintainers, and is not uniformly adopted, e.g., >> `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. >> This PR replaces the `NoRepl` suffix with `NoReplacement` in method names >> and consistently uses `throws CCE` in method footprints. > > Volkan Yazici has updated the pull request incrementally with two additional > commits since the last revision: > > - Improve Javadoc of touched `encode*()` methods > - Rename `exceptionClass` to `exClass` The new `OrThrow` name is much better! - Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26413#pullrequestreview-3171057352
Re: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v10]
On Fri, 29 Aug 2025 13:48:52 GMT, Volkan Yazici wrote: >> `NoRepl`-suffixed `String` methods denote methods that do not replace >> invalid characters, but throw `CharacterCodingException` on encounter. This >> behavior cannot easily be derived from the method footprints, has been a >> source of confusion for maintainers, and is not uniformly adopted, e.g., >> `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. >> This PR replaces the `NoRepl` suffix with `NoReplacement` in method names >> and consistently uses `throws CCE` in method footprints. > > Volkan Yazici has updated the pull request incrementally with two additional > commits since the last revision: > > - Improve Javadoc of touched `encode*()` methods > - Rename `exceptionClass` to `exClass` Thanks for the updates, I don't have any more comments. - Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26413#pullrequestreview-3171050605
Re: RFR: 8365581: Optimize Java implementation of P256 arithmetic [v3]
On Thu, 21 Aug 2025 23:30:08 GMT, Ben Perez wrote: >> There are several places where MontgomeryIntegerPolynomialP256.mult() can be >> optimized. In particular, since modulus[2] = 0 several multiplications can >> be removed. Other multiplications can be replaced by shifts, which also >> saves time. Preliminary tests indicate an improvement between 5-10%. > > Ben Perez has updated the pull request incrementally with one additional > commit since the last revision: > > minor edit Can you also simplify the line near the end of the method where you're doing: `c2 = c7 - modulus[2] + (c1 >> BITS_PER_LIMB);` to be `c2 = c7 + (c1 >> BITS_PER_LIMB);`? - PR Comment: https://git.openjdk.org/jdk/pull/26792#issuecomment-3239343260
