RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread
Zhong Yu
zhong.j.yu at gmail.com
Tue Jan 15 17:31:10 UTC 2013
>From user's point of view, there is nothing thread local about it - it
is more like one global random generator, which is unseedable and
unrepeatable. So why not call it a different name, like concurrent
random?
On Mon, Jan 14, 2013 at 4:17 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 14/01/2013 18:20, Chris Hegarty wrote:
>>
>> Ooooooh.... this change goes beyond my review capability!!! I thought we
>> were just eliminating the indirection of ThreadLocal, anyway...
>>
>> As a basic review I don't see anything obviously wrong, and I don't have a
>> problem with adding the fields to j.l.Thread, but I'm not in a position to
>> review in detail the algorithm used.
>>
>> Alan, did mention that he may be in a better position to do a detailed
>> review. I can also sponsor this change.
>
> I looked at the changes and they look good to me. The additional fields of
> java.lang.Thread shouldn't be an issue.
>
> The other thing I notice is that the serialized form of the original
> ThreadLocalRandom included the padding fields, I guess they should have been
> transient in the original implementation.
>
> -Alan.
More information about the core-libs-dev
mailing list