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

Paul Sandoz paul.sandoz at oracle.com
Tue Dec 2 12:41:44 UTC 2014


On Dec 2, 2014, at 1:17 PM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 12/02/2014 05:02 AM, Paul Sandoz wrote:
>> Hi,
>> 
>> Please find below a patch to remove the networking code computing a seed in ThreadLocal/SplittableRandom.
>> 
> 
> Thanks for pushing this through.
> (I also adjusted 166 sources accordingly.)
> One more touch-up for SplittableRandom is to remove mention
> of network interface in internal comments:
> 
> ***************
> *** 140,150 ****
>       * other cases, this split must be performed in a thread-safe
>       * manner, so we use an AtomicLong to represent the seed rather
>       * than use an explicit SplittableRandom. To bootstrap the
> !      * defaultGen, we start off using a seed based on current time and
> !      * network interface address unless the java.util.secureRandomSeed
> !      * property is set. This serves as a slimmed-down (and insecure)
> !      * variant of SecureRandom that also avoids stalls that may occur
> !      * when using /dev/random.
>       *
>       * It is a relatively simple matter to apply the basic design here
>       * to use 128 bit seeds. However, emulating 128bit arithmetic and
> --- 139,148 ----
>       * other cases, this split must be performed in a thread-safe
>       * manner, so we use an AtomicLong to represent the seed rather
>       * than use an explicit SplittableRandom. To bootstrap the
> !      * defaultGen, we start off using a seed based on current time
> !      * unless the java.util.secureRandomSeed property is set. This
> !      * serves as a slimmed-down (and insecure) variant of SecureRandom
> !      * that also avoids stalls that may occur when using /dev/random.
>       *
>       * It is a relatively simple matter to apply the basic design here
>       * to use 128 bit seeds. However, emulating 128bit arithmetic and
> ***************
> 

Thanks, updated my copy,
Paul.




More information about the core-libs-dev mailing list