RFR[s]: 8201633 Problems with AES-GCM native acceleration

[Adam Petcher]

I'm still not sold on this---it seems like a specific solution to a 
single instance of a more general problem.

Have you investigated any tweaks to the JVM or compiler settings? Andrew 
prototyped something[1], but it looks like this is also specific to GCM. 
A more general solution would be some way to tell the JVM that some 
method should always be compiled. I think this is the exact problem that 
motivated per-method compile thresholds[2], though it's not clear if the 
current implementation of that feature helps us here.

[1] http://cr.openjdk.java.net/~aph/gctr/
[2] https://bugs.openjdk.java.net/browse/JDK-8059606

On 2/5/2019 6:52 PM, Anthony Scarpino wrote:
>
> I need a review of this change which is to help the AES/GCM intrinsic 
> activate on large data sizes.  It's not the ideal resolution, which 
> splits up the crypto operation in chucks, but I significantly improves 
> performance for larger data sizes. Additionally there is an 
> optimization to not allocated and use an unnecessary buffer in the 
> init()-doFinal() case  that helped performance with large data sizes. 
> The final result was a 1MB file is encrypted at 2GB/sec vs 250MB/sec.
>
> This change is not meant to fix all possible performance bottlenecks.
>
> http://cr.openjdk.java.net/~ascarpino/8201633/webrev/
>
> Tony