JDK 9 RFR of 6375303: Review use of caching in BigDecimal
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