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

Paul Sandoz paul.sandoz at
Mon Aug 26 13:15:00 UTC 2013

On Aug 26, 2013, at 2:19 PM, Aleksey Shipilev <aleksey.shipilev at> 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:

"I spent some time looking at the implementation of SecureRandom and of 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.


>> Rudimentary testing with 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.

More information about the core-libs-dev mailing list