RFR: 8253821: Improve ByteBuffer performance with GCM [v5]

[Valerie Peng]

On Thu, 26 Nov 2020 02:14:40 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> 8253821: Improve ByteBuffer performance with GCM
>
> Anthony Scarpino has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - test updates
>  - test check mixup
>  - Overlap protection
>  - Updated code comments, all tests pass
>  - Updated code comments, all tests pass

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

> 908:         // Decrypt the all the input data and put it into dst
> 909:         doLastBlock(buffer, ct, dst);
> 910:         dst.limit(dst.position());

Based on Cipher javadoc, the output buffer's limit should remain the same, just its position be advanced by the number of bytes written into it. So, we should not call limit(int) to set a new limit on user-specified ByteBuffer objects.

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

> 998:         tmp.position(dst.position());
> 999:         bb.put(tmp);
> 1000:         bb.flip();

Since we don't need to read the content of output buffer, I suppose we can just do ByteBuffer.allocate(dst.remaining())?

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

> 933:      */
> 934:     ByteBuffer overlapDetection(ByteBuffer src, ByteBuffer dst) {
> 935:         if (src.isDirect() && dst.isDirect()) {

originalDst is only set to null at construction time. It should be reset here or in restoreDst(). Otherwise, there may be some strange interaction between various ByteBuffer calls using the same Cipher object. Say, the first call uses an extra copy and set originalDst, then the second call does not, but originalDst is still non-null.

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

PR: https://git.openjdk.java.net/jdk/pull/411