com.sun.crypto.provider.GHASH performance fix
Florian Weimer
fweimer at redhat.com
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 redhat.com> 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