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

[Mike Duigou]

I
On Mar 19 2014, at 15:01 , Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

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

Since the Unsafe.getObjectVolatile() allows use of volatile semantics without having to declare the field volatile I think this is a better idiom than what I had previously suggested. Hopefully this is a pattern we can use elsewhere.

Are the java.util.concurrent.atomic imports still needed?

I have not reviewed the other changes.

Mike