JEP draft: Enhanced pseudo-random number generators

AuthorGuy Steele
OwnerGuy Steele
Created2017/12/07 19:09
Updated2017/12/11 19:27
TypeFeature
StatusDraft
Componentcore-libs / java.util
ScopeSE
Discussioncore dash libs dash dev at openjdk dot java dot net
EffortS
DurationS
Priority4
Issue8193209

Summary

Provide new interface types and implementations for pseudorandom number generators (PRNGs), including jumpable PRNGs and an additional splittable PRNG algorithm (TwinLinear). Refactor classes Random, ThreadLocalRandom, and SplittableRandom appropriately.

Goals

Non-Goals

It is not a goal to provide implementations of numerous other PRNG algorithms, only to provide a framework that can accommodate numerous other PRNG algorithms if others wish to code them.

Success Metrics

The output of TwinLinear should pass the existing well-known TestU01 and PractRand test suites.

Jumpable PRNG algorithms should pass tests (TBD) that verify the commutativity of certain operations.

Motivation

We see five opportunities for improvement in the area of pseudorandom number generators in Java:

Description

We propose to create four new interfaces: RNG, SplittableRNG, JumpableRNG, and ArbitrarilyJumpableRNG. Roughly speaking:

We propose to refactor Random, ThreadLocalRandom, and SplittableRandom so as to share most of their implementation code. This refactoring would create new abstract classes AbstractRNG, AbstractSplittableRNG, AbstractJumpableRNG, and AbstractArbitrarilyJumpableRNG, each of which requires an extending class to provide only implementations for methods nextInt(), nextLong(), and either split() or jump() or jump(distance) if relevant.

We propose to add a new class TwinLinearRandom that extends AbstractSplittableRNG (and therefore implements SplittableRNG and RNG). (The current prototype version of this class requires just 70 lines of code.)

We will review existing use of random number generation in the JDK and possibly refactor to use the new interfaces.

Alternatives

We considered simply introducing new interfaces while leaving the implementations of Random, ThreadLocalRandom, and SplittableRandom as is. This would help to make PRNG objects more easily interchangeable but would not make it any easier to implement them.

We considered refactoring Random, ThreadLocalRandom, and SplittableRandom without changing their functionality or adding any new interfaces. We believe this would reduce their overall memory footprint, but do nothing to make future PRNG algorithms easier to implement or use.

Testing