Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks
paul.sandoz at oracle.com
Mon Aug 26 13:15:00 UTC 2013
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:
>> 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 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.
>> 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 :)
More information about the core-libs-dev