RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread
peter.levart at gmail.com
Wed Jan 16 09:23:57 UTC 2013
The test I used is simple:
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
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:
>> 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.
More information about the core-libs-dev