class SplittableRandom

Guy Steele guy.steele at
Fri Jul 19 15:10:59 UTC 2013

On Jul 19, 2013, at 1:05 AM, Kasper Nielsen <kasperni at> wrote:

Thanks so much for your feedback!  Your points are well taken.

> Telling people that your random source passes the die-hard test but at the
> same time only using the current time as the seed is just pure evil.
> Imagine spinning up a couple of thousands images with a JVM on Amazon. You
> are going to see collisions among the seed values a lot sooner than you
> think. Especially if the granularity of System.nanoTime() is not actual 1
> nanosecond. You need to use some kind of random source for the seeding or
> at least mix in the process ID/host ID with the current time.
> Obviously RDRAND would be a good choice if available. This is a problem
> Random and TLR suffers from as well.

I agree that this is a problem, and in fact have already looked at ways to get
other environmental information to mix into the initial seed.  The problem
is making it Write Once, Run Anywhere---what environmental information
other than time-of-day is reliably available on all platforms?

It should be noted that the programmer has an easily available workaround:
use the constructor that accepts a 64-bit seed.  If the programmer gathers
environmental data and then uses this constructor, if every JVM image manages
to have a different seed, then all the RNGs will be different.  Of course, either way,
we are unable to guarantee much more than that they will have started in different
places on the period of length 2^64.  The REALLY good thing to do, if all those
JVM images are collaborating, would be for one of the processes to create one
original RNG, then split it and send it the new one (via serialization?? TBD) 
to another process, then further recursively split as needed.

> Also I'm really worried about the seed value of just 64 bit. That is not a
> lot if SR is sold as a quality random number generator. People are going to
> experience collisions (albeit rarely) while using it.

Again I agree with you, and I have been working this week on a 128-bit-seed
version, still being tested on both the quality and speed dimensions.


More information about the core-libs-dev mailing list