-
Enhancement
-
Resolution: Fixed
-
P3
-
8, 9
-
b103
-
x86
-
generic
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8230012 | 8u241 | David Buck | P3 | Resolved | Fixed | b01 |
| JDK-8234997 | emb-8u241 | David Buck | P3 | Resolved | Fixed | team |
The request is to leverage the parallel nature of AES in Counter (CTR) Mode. In a single threaded implementation, this can be achieved by issuing independent x86 AES-NI instructions.
Presently, there is an intrinsic for AESCrypt.implEncryptBlock(), which is called by CounterMode.crypt() method. However, the intrinsic works on one block at a time. The x86 AES-NI instructions have a latency of 6 or 7 clocks depending on the architecture. Since every AESENC instructions issued by this intrinsic is dependent on the earlier one, it does not take advantage of the CPU pipeline.
We can optimize the performance of CounterMode.crypt() method by 4x-6x by issuing independent instructions from up to 6 blocks in parallel.
Presently, there is an intrinsic for AESCrypt.implEncryptBlock(), which is called by CounterMode.crypt() method. However, the intrinsic works on one block at a time. The x86 AES-NI instructions have a latency of 6 or 7 clocks depending on the architecture. Since every AESENC instructions issued by this intrinsic is dependent on the earlier one, it does not take advantage of the CPU pipeline.
We can optimize the performance of CounterMode.crypt() method by 4x-6x by issuing independent instructions from up to 6 blocks in parallel.
- backported by
-
JDK-8230012 enhancing CounterMode.crypt() for AESCrypt.implEncryptBlock()
-
- Resolved
-
-
-
- Resolved
-
- relates to
-
JDK-8146581 Minor corrections to the patch submitted for earlier bug id - 8143925
-
- Resolved
-
-
-
- Closed
-
-
-
- Resolved
-
