RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread

[Chris Hegarty]

Thanks to all for the reviews and suggestions here. As you probably 
seen, I pushed these changes to jdk8/tl earlier today (sorry, I missed 
Alan as an official reviewer on the changeset.). Consider it an initial 
version, pending any outcome from this, or other, discussions.

Also, 8006409: "ThreadLocalRandom should dropping padding fields from 
its serialized form", has been filed to follow up on the changes 
required to update the serial form.

For those watching, I was preferable to push on with these changes ( and 
I apologize if it appeared pushy ), as the Double/Long Adder/Accumulator 
implementation, Striped64, now has a dependency on this change. It has 
become unbearable to keep in sync with different version of across 
different repositories.

-Chris.


On 16/01/2013 11:48, Doug Lea wrote:
> On 01/16/13 03:59, Peter Levart wrote:
>
>> - Instead of Thread.threadLocalRandomSeed field it has a
>> Thread.threadLocalRandom reference field, pointing to an instance of TLR.
>> - The ThreadLocalRandom is not a singleton, but an instance per thread
>> (like
>> JDK7's).
>
> Yes, this is the "Plan B" I mentioned in mail last week.
> I had explored this. Both on performance and resource grounds,
> it is a little worse. Not hugely worse, but if we are going
> to improve TLR, then might as well take the best option.
>
> (Another reason to prefer current solution also serves as
> a reply to Tom: Yes we don't like using Unsafe just to
> bypass package-protection access control. But at least it
> is just accessing simple scalars, not references.)
>
> -Doug
>