RFR: 8098581 SecureRandom.nextBytes() hurts performance with small size requests

[Mike StJohns]

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
>
>