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
