On Mon, 4 May 2026 09:33:14 GMT, Andrew Haley <[email protected]> wrote:
>> --------- >> - [X] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6296: > >> 6294: // } >> 6295: // } >> 6296: // > > Should we change the Java implementation to match? No. In this PR we are changing the Java implementation the opposite way. It is because the existing (matching) implementation is better for the intrinsics, as they can work on more values in parallel using 16-bit operations, while the new Java implementation uses a faster algorithms using 64-bit values. > src/java.base/share/classes/com/sun/crypto/provider/ML_KEM.java line 355: > >> 353: 1143, 2186, 2150, 1179, 2775, 554, 886, 2443, >> 354: 1722, 1607, 1212, 2117, 1874, 1455, 1029, 2300, >> 355: 2110, 1219, 2935, 394, 885, 2444, 2154, 1175 > > How are these magic constants generated? It is a rearrangement of the elements of the table in the spec (FIPS 203) so that the algorithm can use the values sequentially. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30991#discussion_r3181738725 PR Review Comment: https://git.openjdk.org/jdk/pull/30991#discussion_r3181739560
