RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom

[Peter Levart]

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
>
>
>