On 4/01/2012 10:08 AM, David Holmes wrote:
Hi Paul,
For some reason this email, despite being dated Dec 14, only just
appeared in my inbox on Jan 3!
Oops! I missed the fact a copy of this email also turned up on Dec 15
and that I already replied to it.
Comments still apply. Need to understand the context in which this
becomes a bottleneck and the performance implications for non-concurrent
use.
David
On 14/12/2011 12:44 AM, Paul Ciprich wrote:
All,
I've created a bug report to address a scalability problem with
BigInteger's staticRandom field. The problem is that the shared
staticRandom field causes bottlenecks with parallel code. The proposed
solution is to change the staticRandom field to a ThreadLocal and
eliminate
the bottleneck by giving each thread its own copy of the SecureRandom
object. Bug 100218 contains a patch with the proposed change if it is
deemed acceptable.
As I mention in the bug report we have to ensure that we don't add
unacceptable overhead to the non-concurrent case. Also I'm wondering if
anyone might be relying on the existing SecureRandom instance being shared?
Can you clarify the context for the proposed fix: what code is the
bottleneck (isProbablePrime?), under what conditions - is it a
microbenchmark or real code?
Thanks,
David Holmes
