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

[Anthony Scarpino]

Andrew's fix looked much more complicated than running a simple loop in 
the byte code.  The way I read CompileCommand, I don't think it applies 
to intrinsics, or at least I don't see how it relates to make this easier.

The slow start seems to be getting enough attention that addressing it 
is probably easier than arguing why it's not a problem.

Tony


On 2/6/19 12:23 PM, Adam Petcher wrote:
> 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