JDK 9 RFR of 6375303: Review use of caching in BigDecimal

[Peter Levart]

On 03/14/2014 01:29 AM, Brian Burkhalter wrote:
>
> On Mar 12, 2014, at 2:08 AM, Peter Levart wrote:
>
>> Huh! This is a ThreadLocalRandom anti-pattern. Thou should not use a 
>> ThreadLocalRandom instance in a thread that did not obtain it via a 
>> call to ThreadLocalRandom.current()…
>
> Good point.
>
>> You could create a new BigInteger(512,*rnd*) in the static 
>> initializer and use it to create new BigDecima(bigInteger) in 
>> testFirstToStrin.
>
> I simply replaced ThreadLocalRandom with Random which probably creates 
> a bottleneck but there is no significant difference in the results.

That's probably because the time spent computing the toString 
representation initially (the concurrent part of testFirstToString 
benchmark) takes much more time than computing the random number (the 
synchronized/serialized part). The difference would probably show with 
bigger number of threads on a suitable machine of course.

But in general it would be better to just use 
"ThreadLocalRandom.current()" everywhere you use "rnd" variable. This is 
precisely it's purpose - a random number generator that is never 
contended. The overhead of ThreadLocalRandom.current() call is hardly 
measurable by itself.

Regards, Peter

>
> http://cr.openjdk.java.net/~bpb/6375303/Bench6375303.java 
> <http://cr.openjdk.java.net/%7Ebpb/6375303/Bench6375303.java>
> http://cr.openjdk.java.net/~bpb/6375303/6375303-bench.html 
> <http://cr.openjdk.java.net/%7Ebpb/6375303/6375303-bench.html>
>
> Thanks,
>
> Brian