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