Profiling for crypter's decryption for ALTS Channel.

[veblush]

Under heavy traffic using ALTS, I briefly profiled the client to see where the cpu time went through VisualVM. It seems that it spent significant time running javax.crypto.ShortBufferException.<init> ()

Hot spots (VisualVM)

io.netty.channel.epoll.Native.epollWait0[native] ()	23,995 ms (89.6%)	23,995 ms (9.4%)
org.conscrypt.NativeCrypto.EVP_AEAD_CTX_open[native] ()	994 ms (3.7%)	994 ms (0.4%)
io.netty.channel.unix.FileDescriptor.readAddress[native] ()	891 ms (3.3%)	891 ms (0.4%)
> javax.crypto.ShortBufferException.<init> ()	390 ms (1.5%)	390 ms (0.2%)
org.conscrypt.NativeCrypto.EVP_aead_aes_128_gcm[native] ()	208 ms (0.8%)	208 ms (0.1%)
io.netty.util.internal.PlatformDependent0.copyMemoryWithSafePointPolling ()	201 ms (0.8%)	201 ms (0.1%)

Callstack for javax.crypto.ShortBufferException. (VisualVM)

io.grpc.alts.internal.AltsTsiFrameProtector$Unprotector.handlePayload ()	296 ms (4.5%)	296 ms (4.5%)
 ...
  io.grpc.alts.internal.AesGcmAeadCrypter.decryptAad ()	196 ms (3%)	196 ms (3%)
   javax.crypto.Cipher.doFinal ()	196 ms (3%)	196 ms (3%)
    javax.crypto.CipherSpi.engineDoFinal ()	196 ms (3%)	196 ms (3%)
     javax.crypto.CipherSpi.bufferCrypt ()	196 ms (3%)	196 ms (3%)
      org.conscrypt.OpenSSLCipher$EVP_AEAD.engineDoFinal ()	196 ms (3%)	196 ms (3%)
       org.conscrypt.OpenSSLCipher.engineDoFinal ()	98.8 ms (1.5%)	98.8 ms (1.5%)
        javax.crypto.ShortBufferException.<init> ()	97.2 ms (1.5%)	97.2 ms (1.5%)

Not sure how much these numbers reflect reality but it seems that there is room to improve. The reason why ShortBufferException is created and thrown is to trigger the caller to allocate a bigger output buffer. (code) Once it's caught, the caller CipherSpi will create a temporary big enough buffer, decrypt the data into it by recalling the cipher, and copy it into the origianl output buffer. (code)

Since this routine is being heavily called, it'd be great to have some optimization not to have ShortBufferException and cost caused by a temporary buffering.

Environment

gRPC Java: 1.27.1
Conscrypt: 1.4.1
OpenJDK 64-Bit: 1.8.0_242

[sanjaypujare]

Interesting. Just wondering, what optimization can gRPC do here? The interaction you described is between Conscrypt and Javax.crypto and I didn't see a way gRPC can avoid/minimize the ShortBufferException.

[veblush]

If there is a way for AesGcmAeadCrypter to control an output buffer, it can be done in gRPC. Actually OpenSSL and Conscrypt don't too much thing to maintain buffer. Usually they just use given buffers from callers. In this case, gRPC's AesGcmAeadCrypter.

[sanjaypujare]

Okay, looks like it is the plaintext parameter to AesGcmAeadCrypter.decrypt() then.

[veblush]

With help of @ejona86, I ran a benchmark again with the change on AltsTsiFrameProtector to use directBuffer instead of heapBuffer to avoid ShortBufferException. But it turns out that it does harm more than good. This definitely removes the usage of ShortBufferException but it makes Conscrypt to copy a bigger size of output buffer when crossing the boundary of JNI.

[ejona86]

Closing, since it seems there isn't any better method for gRPC at the moment. That isn't to say there isn't an optimization that could be done here, but it seems like it will need noticeable changes to Conscrypt first

[veblush]

Note that Java 11 addressed this problem with JDK-8178374.