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

Aleksey Shipilev aleksey.shipilev at oracle.com
Wed Jan 16 09:13:18 UTC 2013

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/TLRbenchmarkresults.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.

More information about the core-libs-dev mailing list