8020292: j.u.SplittableRandom

[Paul Sandoz]

On Aug 21, 2013, at 12:19 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> On 08/21/2013 05:43 AM, Paul Sandoz wrote:
>> On Aug 20, 2013, at 11:50 PM, Mike Duigou <mike.duigou at oracle.com> wrote:
>>>>> - Additional seed material might be desirable for "seeder". I worry
>>>>> about how many of the actual bits are random.
> 
> Backing up a bit: I tried using a SecureRandom seed.
> But then discovered that on some systems, this led to
> serious start-up stalls (up to 10 seconds or so) because
> /dev/random can delay while collecting entropy. For a non-secure
> RNG, this is unacceptable. On most Unix/linux systems,
> this is a known issue, and there is a workaround to instead
> use /dev/urandom. But using /dev/urandom is tantamount to
> just collecting some local information, so the default
> seeder does so itself which leads to faster startup.
> Note that the two main ingredients, absolute time (currentTimeMillis)
> and non-absolute time (nanoTime) are in general uncorrelated
> (they normally use different timers, with different precisions,
> on current JVMs). The hostname hash is a barely-useful tie-breaker
> in case they are.
> 
> I can't get myself to believe that adding information from
> various identityHashCodes would improve this, since they are
> dependent on the identityHashCode mechanics themselves
> doing better than this, which I don't think they do.
> 
>> 
>> I did ponder whether it is worthwhile defining a boolean system property that
>> if declared and true then SecureRandom is used.
>> 
> 
> Given the alternative of slowing down startup for all
> usages, this now strikes me as an OK CYA move.
> 

OK. Unless there are strong objections i will do this.

Paul.