100218: BigInteger staticRandom field

David Holmes david.holmes at oracle.com
Wed Jan 4 00:15:10 UTC 2012


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



More information about the core-libs-dev mailing list