RFR: 8296507: GCM using more memory than necessary with in-place operations
Anthony Scarpino
ascarpino at openjdk.org
Tue Nov 15 22:48:45 UTC 2022
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
More information about the security-dev
mailing list