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

Peter Levart peter.levart at gmail.com
Mon Mar 24 18:25:22 UTC 2014

On 03/24/2014 06:52 PM, Martin Buchholz wrote:

On Wed, Mar 12, 2014 at 1:45 AM, Peter Levart <peter.levart at gmail.com_ _<mailto:peter.levart at gmail.com>> wrote: What would the following cost? private transient String stringCache; public String toString() { String sc = stringCache; if (sc == null) { sc = (String) U.getObjectVolatile(this, STRINGCACHEOFFSET); if (sc == null) { sc = layoutChars(true); if (!U.compareAndSwapObject(this, STRINGCACHEOFFSET, null, sc)) { sc = (String) U.getObjectVolatile(this, STRINGCACHEOFFSET); } } } return sc; } I feel I'm missing something. If read -> volatile read -> CAS works, then why wouldn't read -> CAS work and be slightly preferable, because "races are unlikely"? public String toString() { String sc = stringCache; if (sc == null) { sc = layoutChars(true); if (!U.compareAndSwapObject(this, STRINGCACHEOFFSET, null, sc)) { sc = (String) U.getObjectVolatile(this, STRINGCACHEOFFSET); } } return sc; }

...yeah, I thought about that too. In any case, the overhead of volatile re-read is negligible in this case, since it happens on slow-path and it might reduce the chance of superfluos calls to layoutChars.

Regards, Peter

More information about the core-libs-dev mailing list