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

Martin Buchholz martinrb at google.com
Mon Mar 24 19:25:31 UTC 2014

On Mon, Mar 24, 2014 at 11:25 AM, Peter Levart <peter.levart at gmail.com>wrote:

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>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.

Hmmm OK. I still slightly prefer my version, but I can see there is a tradeoff, and the difference is very small.

More information about the core-libs-dev mailing list