RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread
chris.hegarty at oracle.com
Wed Jan 16 15:01:56 UTC 2013
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
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
> 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.)
More information about the core-libs-dev