Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks)

Doug Lea dl at cs.oswego.edu
Tue Sep 3 23:46:10 UTC 2013


On 09/03/2013 03:06 PM, Brian Burkhalter wrote:
> So it looks like there are two decisions to be made on this topic:
>
> On Sep 3, 2013, at 1:21 AM, Paul Sandoz wrote:
>
>>>> add the following method to BigInteger
>>>> public boolean isProbablePrime(int certainty, Random end) ,
>>>> which allows primality testing with arbitrary Random objects.
>>>> In many cases, using a well seeded normal Random object will work
>>>> just fine, and this will give users the ability to provide their own
>>>> Random objects
>>>
>>> This sounds like a very good solution to me.  That way someone can decide whether they want to take the hit with SecureRandom, or if Random is good enough.
>>>
>>
>> Yes.
>
> 1) Add BigInteger.isProbablePrime(int certainty, Random rnd) {}
>
>>> So offhand, I wouldn't commit to saying if SecureRandom is necessary or not, but it wouldn't surprise me.
>>>
>>
>> My intuition is that the new algorithm for TLR might be sufficient as input to this Monte-Carlo algorithm, but i don't have any hard empirical data.
>
> 2) Replace SR with TLR as the default Random in BigInteger.passesMillerRabin(int iterations, Random rnd) {}.
>
> Any further comments from those adept at this topic?

I assume you mean to change line 898:

         if (rnd == null) {
             rnd = ThreadLocalRandom.current();; // was: getSecureRandom();
         }

This seems fine in terms of sufficient RNG quality and better
performance. Also in terns of being for sure thread-safe
even though it uses no locks/sync: there are no possible async
or parallel calls from entry into this method, so using
thread-local one is fine.

The new SplittableRandom class might be a better choice but
can't be used here because it doesn't subclass Random. Oh well.

-Doug




More information about the core-libs-dev mailing list