JDK 9 RFR of 6375303: Review use of caching in BigDecimal (original) (raw)
Mike Duigou mike.duigou at oracle.com
Tue Mar 4 17:21:26 UTC 2014
- Previous message: JDK 9 RFR of 6375303: Review use of caching in BigDecimal
- Next message: JDK 9 RFR of 6375303: Review use of caching in BigDecimal
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: JDK 9 RFR of 6375303: Review use of caching in BigDecimal
- Next message: JDK 9 RFR of 6375303: Review use of caching in BigDecimal
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]