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