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