JDK 9 RFR of 6375303: Review use of caching in BigDecimal
brian.burkhalter at oracle.com
Fri Mar 7 20:54:56 UTC 2014
On Mar 3, 2014, at 4:14 PM, Brian Burkhalter wrote:
> 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.
If this looks copacetic, would a JDK 9 Reviewer kindly proffer their Imprimatur?
More information about the core-libs-dev