On Mon, 21 Nov 2022 18:20:09 GMT, Anthony Scarpino <[email protected]>
wrote:
>> I would like a review of an update to the GCM code. A recent report showed
>> that GCM memory usage for TLS was very large. This was a result of in-place
>> buffers, which TLS uses, and how the code handled the combined intrinsic
>> method during decryption. A temporary buffer was used because the combined
>> intrinsic does gctr before ghash which results in a bad tag. The fix is to
>> not use the combined intrinsic during in-place decryption and depend on the
>> individual GHASH and CounterMode intrinsics. Direct ByteBuffers are not
>> affected as they are not used by the intrinsics directly.
>>
>> The reduction in the memory usage boosted performance back to where it was
>> before despite using slower intrinsics (gctr & ghash individually). The
>> extra memory allocation for the temporary buffer out-weighted the faster
>> intrinsic.
>>
>>
>> JDK 17: 122913.554 ops/sec
>> JDK 19: 94885.008 ops/sec
>> Post fix: 122735.804 ops/sec
>>
>> There is no regression test because this is a memory change and test
>> coverage already existing.
>
> Anthony Scarpino has updated the pull request incrementally with one
> additional commit since the last revision:
>
> comment cleanup & finesse ByteBuffer implGCMCrypt better
src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line
778:
> 776: gctr, ghash);
> 777: } else {
> 778: int ofs = src.arrayOffset() + src.position();
Isn't this also used on line 774? Why not move this up and directly refer to it
for both places?
-------------
PR: https://git.openjdk.org/jdk/pull/11121