RFR: 8296507: GCM using more memory than necessary with in-place operations [v3]

[Valerie Peng]

On Thu, 1 Dec 2022 04:19:37 GMT, Anthony Scarpino <ascarpino at openjdk.org> 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 update

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1053:

> 1051:                     return new byte[out.length];
> 1052:                 }
> 1053:                 inPlaceArray = (!encryption);

Is the "inPlaceArray" reset somewhere? When inOfs >= outOfs and the function will return on line 1051, the inPlaceArray value will not be set on line 1053. Is this intentional? My vacation is coming up and I can't finish off this review before I leave. I see that Jamil has approved it. No need to hold up this for me. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/11121