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

[Peter Levart]

Hello,

I did an experiment with an alternative implementation of TLR:

http://dl.dropbox.com/u/101777488/TLR/webrev.01/index.html

This version is a modified proposed version. It has the following 
differences:

- 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).
- ThreadLocalRandom has a reference to constructing Thread, so it can 
check the validity of calling thread.

I did some micro benchmarks and here are the results:

http://dl.dropbox.com/u/101777488/TLR/TLR_benchmark_results.txt

Results indicate that usage pattern: Thread.current().nextInt() is as 
fast as proposed variant while the nextInt() method itself is as fast as 
JDK7's, which is some 20% faster than proposed variant. So the 
alternative implementation seems to be faster and it has the following 
additional benefits:

- Checks the calling thread and throws when called from invalid thread.
- Could reinstate the padding fields (or @Contended long rnd) if needed 
(the tests were done without padding)

It does have a memory overhead of one object per using thread. Not too 
much I think.


Regards, Peter

On 01/15/2013 05:33 PM, Chris Hegarty wrote:
> Updated webrev:
>   http://cr.openjdk.java.net/~chegar/8005926/webrev.01/webrev/
>
>  * based on Aleksey initial webrev
>  * applied serialPersistentFields, writeObject, readResolve
>    ( as suggested by Heinz )
>  * did not apply readObject. It is unnecessary, defaultReadObject
>    will read all the fields off the stream
>
> readResolve is necessary to give us "good" behavior ( as noted 
> previously ).
>
> Once integrated, I will file a new bug to track the possible change of 
> serialized form of TLR, and this can then remove 
> serialPersistentFields and writeObject, if successful.
>
> -Chris.
>
>
> On 01/15/2013 01:57 PM, Alan Bateman wrote:
>> On 15/01/2013 13:49, Chris Hegarty wrote:
>>>
>>> But wouldn't there be an issue with JDK7 TLR streams being
>>> deserialized by JDK8, pad fields would be left in the Object input
>>> steam? If so, then we're down the road of having to have a readObject,
>>> etc... and possibly back to serialPersistentFields?
>> Technically deleting fields is an incompatible change as the stream will
>> not contain the fields. If someone is crazy enough to serialize with
>> jdk8 TLR and send it to a jdk7 release then the fields will have their
>> default value (as the values aren't in the stream). As the fields aren't
>> used then I don't think this should make a difference. Going the other
>> way shouldn't be an issue either as the pad fields will be ignored.
>>
>> -Alan.