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

[Anthony Scarpino]

On 12/03/2015 02:40 PM, ecki at zusammenkunft.net wrote:
> Hello,
>
> That buffer sizing/expiring is a bit strange (the dynmic version
> stranger than the old one), I do not understand the need for it. The
> requests should not varry so much in size. Just reading something
> like 64bytes at a time (possibly nonblocking) should be fine. No need
> to look at the age of that buffer...

Admittedly I'm keeping the buffer expiring only for the possibility 
someone could watch the array to predict what an application could 
receive in random data.  I have no proof this can happen, but I have to 
assume that was a concern given it was its original designed.  If I 
could be sure that was not a concern, I'd eliminate it.

In cases where a large amount of random data was needed from many 
threads, like the end to end TLS perf testing, the larger buffer size 
eliminated the overheads of reading the device.

The dynamic nature of the buffer size was that I didn't feel it was best 
for java to consume so many random bytes, like 64K worth, if the 
application only consumed a few at intervals that were just beyond the 
expiration time.  Therefore I ended up with this, a dynamic buffer that 
could grow and shrink as needed.
>
> A cool implementation would be an actual single periodic refresher
> thread which does not block reading (until buffer is empty)... but
> that might change the semantic a bit (and could be better used with
> the new DRNG api for block-free reseeding).

The locking was a big thing here.  For example, in 
NativePRNG.implNextBytes() the cost of copying the array and doing the 
xor outside the the synchronized block was quicker for multithreaded 
performance than not doing the copy and xor'ing inside the synchronized 
block.  I had thought about a refresher thread, but I felt the more 
threads competing for the buffer would make it worse.

>
> Bernd
>