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.
-------------
Commit messages:
- comment cleanup & finesse ByteBuffer implGCMCrypt better
- comment cleanup
- include byte[] methods as part of the heapBB change
- split len is not trigger
- initial
Changes: https://git.openjdk.org/jdk/pull/11121/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11121&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8296507
Stats: 102 lines in 1 file changed: 67 ins; 1 del; 34 mod
Patch: https://git.openjdk.org/jdk/pull/11121.diff
Fetch: git fetch https://git.openjdk.org/jdk pull/11121/head:pull/11121
PR: https://git.openjdk.org/jdk/pull/11121
