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
