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

[Peter Levart]

Hi Aleksey,

The test I used is simple:

https://raw.github.com/plevart/lambda-hacks/master/jdk-test/src/org/openjdk/tests/java/util/concurrent/atomic/RandomTest.java

I ran it on a i7-2600K (4 cores x 2 threads) PC with Linux OS and a JDK8 
build from lambda repo using default JVM options (that means 
+UseCompressedOops enabled by default).

Can you give the sources of your tests so I could try to run them on my 
machine?

Regards, Peter

On 01/16/2013 10:13 AM, Aleksey Shipilev wrote:
> Hi Peter,
>
> This is an interesting experiment.
>
> On 01/16/2013 12:59 PM, Peter Levart wrote:
>> 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.
> I find this hard to believe, since the baseline experiment I did in the
> conceiving note in this thread actually tells otherwise:
>
> JDK8 (baseline, 4 threads)
>                TLR.nextInt():  6.4 +- 0.1 ns/op
>      TLR.current().nextInt(): 16.1 +- 0.4 ns/op
>           TL.get().nextInt(): 19.1 +- 0.6 ns/op
>
> JDK8 (patched, 4 threads)
>                TLR.nextInt():  6.5 +- 0.2 ns/op
>      TLR.current().nextInt():  6.4 +- 0.1 ns/op
>           TL.get().nextInt(): 17.2 +- 2.0 ns/op
>
> That is, TLR.current().nextInt() is as fast as the already-acquired
> TLR.nextInt() even in the baselined case, which pretty much means we hit
> the lower bound for possible infrastructure overheads, and we actually
> compute. Note that the changes in next() did not degrade the performance
> either. Please check your microbenchmarks.
>
>> 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.
> This is the spec change; potentially breaks the code (instead of "just"
> degrading performance). I would not like to see that pushed into JDK.
>
>> - Could reinstate the padding fields (or @Contended long rnd) if needed
>> (the tests were done without padding)
> Hardly a benefit, since Thread can be padded as well, and padding there
> will yield better footprint.
>
> -Aleksey.
>
>