Hi Doug,
On 12/06/2014 05:14 PM, Doug Lea wrote:
On 12/04/2014 07:22 PM, Doug Lea wrote:
Because Random, SplittableRandom, and ThreadLocalRandom all use the
same basic approach, they can/should use the same mechanism.
In other words, to establish a common default-constructor-seed
generator internal to the JDK. So we only need one environmental
seed to start it off, and can remove some redundancies.
In jdk9 with modules you could move the seed generator into a public
class in a package that is not exported from java.base module (for
example: java.util.concurrent.internal). Standalone j.u.c builds can be
unchanged then.
Placing the mechanics in TLR seems to work out best.
Well, except that on Windows, we'd still need to create
a .dll just for the sake of calling CryptGenRandom (or
RtlGenRandom?), which seems like a bad move all around.
If we are trying to reduce initialization costs,
it would be better and faster if this were integrated
with other platform-specific JVM startup. (Requiring a
separate .dll also makes it impossible for us to create
standalone j.u.c builds for previews etc.) Which brings
us back to establishing some means of getting from the JVM,
only once, 8 bytes of environmentally-derived bits for a
within-JDK caller. Doing this might be a good opportunity
for exploiting any upcoming modularity support. Or short of
that, placing it in an existing JVM interface class like Unsafe.
Any thoughts?
What about if we change some existing J2SE API to be more
resource/initialization-friendly. java.util.UUID currently uses
SecureRandom. It could be changed to use /dev/urandom or RtlGenRandom
instead (with a fall-back to non-blocking SecureRandom). Each random
UUID instance contains 16 cryptographically strong random bytes (minus 6
bits that are overwritten with UUID variant/version bits).
Regards, Peter
(Also, at some point we might reconsider our cowardice about not
improving the internal java.util.Random algorithm. j.u.Random is
much more commonly used, and does not fare well on quality tests.
On the other hand, the more that users instead choose to use
SR or TLR, the better.)
The main problem is code (not just JDK test code) that hardwires
expected Random.next* output under given seeds. Which might be
enough reason to leave it alone.
Do any CCC members have an opinion?
As a lesser but still worthwhile target though, I can't think of
a reason not to change java.lang.Math.random() to use TLR
to get faster and better-quality values. (Because there is no
way to explicitly seed Math.random, there is no hardwiring problem.)
Some existing javadoc for it saying that it creates a new
java.util.Random() should be deleted, although I don't
think it has any user-visible impact.
http://docs.oracle.com/javase/8/docs/api/java/lang/Math.html#random--
-Doug
