Florian had posted months back about it giving 10x improvement. Hardware acceleration is an separate project as it is mostly changes to hotspot.
Tony > On Jan 15, 2015, at 11:31 AM, Michael StJohns <mstjo...@comcast.net> wrote: > > Just for curiosity, what was the improvement in performance? > > I'm wondering if it might be worthwhile to see if its possible to add a > plugin to use the hardware instructions: > > http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/communications-ia-galois-counter-mode-paper.pdf > > Mike > > At 06:10 AM 1/15/2015, Florian Weimer wrote: >>> On 08/18/2014 02:32 PM, Florian Weimer wrote: >>> This change addresses a severe performance regression, first introduced >>> in JDK 8, triggered by the negotiation of a GCM cipher suite in the TLS >>> implementation. This regression is a result of the poor performance of >>> the implementation of the GHASH function. >>> >>> I first tried to eliminate just the allocations in blockMult while still >>> retaining the byte arrays. This did not substantially increase >>> performance in my micro-benchmark. I then replaced the 16-byte arrays >>> with longs, replaced the inner loops with direct bit fiddling on the >>> longs, eliminated data-dependent conditionals (which are generally >>> frowned upon in cryptographic algorithms due to the risk of timing >>> attacks), and split the main loop in two, one for each half of the hash >>> state. This is the result: >>> >>> <https://fweimer.fedorapeople.org/openjdk/ghash-performance/> >> >> Updated webrev: <http://cr.openjdk.java.net/~fweimer/ghash/webrev.00/> >> >> Anthony, could you file a bug so that I can include its number? Thanks. >> >> -- >> Florian Weimer / Red Hat Product Security > >
