JDK 9 RFR of 6375303: Review use of caching in BigDecimal
Martin Buchholz
martinrb at google.com
Mon Mar 24 17:52:59 UTC 2014
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, STRING_CACHE_OFFSET);
> if (sc == null) {
> sc = layoutChars(true);
> if (!U.compareAndSwapObject(this, STRING_CACHE_OFFSET,
> null, sc)) {
> sc = (String) U.getObjectVolatile(this,
> STRING_CACHE_OFFSET);
> }
> }
> }
> 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, STRING_CACHE_OFFSET, null,
sc)) {
sc = (String) U.getObjectVolatile(this,
STRING_CACHE_OFFSET);
}
}
return sc;
}
More information about the core-libs-dev
mailing list