JDK 9 RFR of 6375303: Review use of caching in BigDecimal (original) (raw)

Brian Burkhalter brian.burkhalter at oracle.com
Fri Mar 7 20:54:56 UTC 2014

On Mar 3, 2014, at 4:14 PM, Brian Burkhalter wrote:

PING-INg-Ing-ing!

This review request concerns this issue and proposed patch:

issue https://bugs.openjdk.java.net/browse/JDK-6375303 patch http://cr.openjdk.java.net/~bpb/6375303/webrev.00/

On Mar 4, 2014, at 9:21 AM, Mike Duigou wrote:

On Mar 4 2014, at 07:13 , Peter Levart <peter.levart at gmail.com> wrote:

On 03/04/2014 01:14 AM, Brian Burkhalter wrote: - add AtomicReferenceFieldUpdater-type constant for stringCache initialization

Hi Brian, By using volatile read and CAS, there's still a chance that multiple concurrent threads will be invoking the layoutChars(true) concurrently, but you guarantee that only a single instance of String will ever be returned as a result of the toString() method. Is that what you were pursuing? Yes. (I provided the AtomicReferenceFieldUpdater code). The previous implementation had a benign data race that could result in a later layoutChars result replacing an earlier result and multiple string instances being returned. The new implementation, at small cost, prevents multiple different instances from being returned. Mike

If this looks copacetic, would a JDK 9 Reviewer kindly proffer their Imprimatur?

Thanks,

Brian

More information about the core-libs-dev mailing list