8020292: j.u.SplittableRandom

[Doug Lea]

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.

-Doug