Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks

[Paul Sandoz]

On Aug 26, 2013, at 2:19 PM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

> Hi Brian,
> 
> On 08/24/2013 03:39 AM, Brian Burkhalter wrote:
>> file:///Users/bpb/Work/JSL/jdk/jdk8/tl8/jdk/7189139/index.html
>> 
>> would be appreciated.
> 
> I'm puzzled over this fix.
> 
> Isn't the scalability bottleneck being inherent to SecureRandom, because
> it piggybacks on the system entropy pool, which is depleted every so
> often? What good the thread-local instances of SR actually bring to us?
> 


Right, see here:

  http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/009176.html

"I spent some time looking at the implementation of SecureRandom and of sun.security.provider.NativePRNG. The implementation of NativePRNG uses a static singleton to perform all of the work, so that looked like the concurrency bottleneck. But when I rewrote that class, it turns out that even removing all of the Java level concurrency bottlenecks, we still can't generate concurrent secure random numbers, because the NativePRNG reads /dev/urandom for each byte, and that is inherently sequential and is the bottleneck to the entire process of generating secure random numbers."


> As discussed in the relevant threads in the original bug report, the
> actual fix should be a very accurate replacement of SR with some other
> faster and reliable RNG to avoid the inherent scalability bottlenecks.
> 

I don't know about the PRNG requirements for Miller-Rabin but the changes to TLR in review might be a possible substitute for SR in this case, since TLR will be updated to use the same PRNG algorithm as SplittableRandom, which passes DieHarder tests.  Otherwise, i think we may just be stuck with SR.

Paul.

>> Rudimentary testing with JMH 
>> (http://openjdk.java.net/projects/code-tools/jmh/) did not reveal any
>> deleterious performance effects in single-threaded operation nor any
>> obvious improvements in the dual threaded case but testing was done
>> on on my aging Core 2 Duo notebook and is not likely representative
>> of anything approaching real world conditions.
> 
> That further reinforces my belief this particular change is not really
> required :)
> 
> -Aleksey.
>