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

[Aleksey Shipilev]

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.