JDK 9 RFR of 6375303: Review use of caching in BigDecimal

[Martin Buchholz]

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, 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;
>     }
>
>
> ...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.