com.sun.crypto.provider.GHASH performance fix

Florian Weimer fweimer at
Tue Jan 20 09:37:59 UTC 2015

On 01/16/2015 09:18 AM, Anthony Scarpino wrote:
>> On Jan 15, 2015, at 12:26 PM, Florian Weimer <fweimer at> wrote:
>> Yes, they are going to help quite a bit as well.  The other thing we need to fix for TLS is that AES-GCM is a garbage collector stress test.  Last time I looked, for each transferred byte, there were four bytes allocated on the heap.
> What exactly are you referring to here?  Is there a problem in TLS where it is using too much memory for AES-GCM specifically or AES-GCM itself is using too much memory?  What test did you do to see this heap allocation or is this code inspection?

I ran several large HTTPS downloads (of varying sizes), using AES-GCM at
the TLS layer, and noticed that the allocation profile shown by hprof
has several allocation sites where the amount scales with download size.

The cause is a bit difficult to discern.  One aspect is that the AES-GCM
implementation creates a temporary buffer if the input and output buffer
is identical.

Florian Weimer / Red Hat Product Security

More information about the security-dev mailing list