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

[Brian Burkhalter]

On Mar 14, 2014, at 7:17 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> On Mar 14, 2014, at 3:39 AM, Peter Levart wrote:
> 
>> 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.
> 
> I'll update that and re-run some of the benchmarks later.

Following up on the content above and this earlier message in the thread:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-March/025676.html

I have posted a revised patch (NB: I know lines 2897-2906 should be elsewhere)

http://cr.openjdk.java.net/~bpb/6375303/webrev.01/

and updated benchmark source (using only ThreadLocalRandom.current())

http://cr.openjdk.java.net/~bpb/6375303/Bench6375303.java

and updated benchmark  results for three different variations

http://cr.openjdk.java.net/~bpb/6375303/6375303-bench-2.html

This version of toString() is from Peter and dispenses with the volatile qualifier on stringCache. At least on my system, there is no statistically significant micro-performance difference among the three versions tested, viz., baseline, toString() change only, toString() change plus other cleanup.

Any comments appreciated.

Thanks,

Brian