The more I look at this the less I'm comfortable with the change to
non-synchronized.
In general, there shouldn't be a need for a large amount of random data,
especially not between multiple threads, so I'm not too sure the
performance argument holds.
What I do worry about is a provider that's not particularly smart about
how it does things offering up data and not updating internal pointers
in a synchronized manner resulting in the possibility of the same
"random" data being served to multiple requestors. I think placing the
synchronization at the glue class may be a better choice than depending
on each and every provider doing the right thing.
Just a thought - Mike
On 12/3/2015 1:38 PM, Seán Coffey wrote:
Hey Tony,
looks like a fix that could come back to jdk8u-dev at some stage.
Thanks for taking this one on.
Adding SecureRandom to the sunpkcs11-solaris.cfg file is a nice move.
Would you agree that JDK-8058455 could be closed out as a duplicate ?
Regards,
Sean.
On 01/12/2015 23:44, Anthony Scarpino wrote:
Hi all,
I'd like a review of this change. It improves nextBytes()
performance by allowing the random buffer to grow and shrink as
random data is needed and remove the high level synchronization. Also
disable SecureRandom for Solaris PKCS11 as it's not as fast as native.
http://cr.openjdk.java.net/~ascarpino/8098581/webrev/
Thanks
Tony
