On Tue, 26 Nov 2024 15:19:25 GMT, Volodymyr Paprotski <vpaprot...@openjdk.org> wrote:
>> This is a follow up to https://github.com/openjdk/jdk/pull/22086 for AES/CTR >> >> Before: >> >> Benchmark (algorithm) (dataSize) (keyLength) (provider) >> Mode Cnt Score Error Units >> AESBench.decrypt AES/CTR/NoPadding 30000000 128 SunJCE >> thrpt 3 16.491 ± 0.356 ops/s >> AESBench.decrypt2 AES/CTR/NoPadding 30000000 128 SunJCE >> thrpt 3 16.899 ± 0.013 ops/s >> AESBench.encrypt AES/CTR/NoPadding 30000000 128 SunJCE >> thrpt 3 16.477 ± 1.006 ops/s >> AESBench.encrypt2 AES/CTR/NoPadding 30000000 128 SunJCE >> thrpt 3 16.921 ± 0.038 ops/s >> >> After: >> >> Benchmark (algorithm) (dataSize) (keyLength) (provider) >> Mode Cnt Score Error Units >> AESBench.decrypt AES/CTR/NoPadding 30000000 128 SunJCE >> thrpt 3 218.910 ± 1.991 ops/s >> AESBench.decrypt2 AES/CTR/NoPadding 30000000 128 SunJCE >> thrpt 3 426.414 ± 2.988 ops/s >> AESBench.encrypt AES/CTR/NoPadding 30000000 128 SunJCE >> thrpt 3 218.882 ± 2.446 ops/s >> AESBench.encrypt2 AES/CTR/NoPadding 30000000 128 SunJCE >> thrpt 3 425.402 ± 4.205 ops/s > > Volodymyr Paprotski has updated the pull request incrementally with one > additional commit since the last revision: > > fix date src/java.base/share/classes/com/sun/crypto/provider/CounterMode.java line 57: > 55: > 56: // chunkSize is a multiple of block size and used to divide up > 57: // input data to trigger the intrinsic. This comment looks incorrect, a method marked as an intrinsic is always inline expanded by C2 compile during parsing or during incremental inlining if -XX:+InlineIncrement is used. I guess what you intend here is triggering an OSR compilation of loop by C2 compiler which in turn trigger intrinsic since C1 never intrinsifies crypto APIs ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22300#discussion_r1860693705
