RFR: 8344766: AES/CTR slow at big payloads [v2]
Jatin Bhateja
jbhateja at openjdk.org
Wed Nov 27 13:49:40 UTC 2024
On Tue, 26 Nov 2024 15:19:25 GMT, Volodymyr Paprotski <vpaprotski at 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
More information about the hotspot-compiler-dev
mailing list