I On Mar 19 2014, at 15:01 , Brian Burkhalter <brian.burkhal...@oracle.com> wrote:
> > On Mar 14, 2014, at 7:17 AM, Brian Burkhalter <brian.burkhal...@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
