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

[Mike Duigou]

On Mar 24 2014, at 12:25 , Martin Buchholz <martinrb at google.com> wrote:

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

The other issue here, and why this thread has gone on so long, is that we've been trying to establish what the best idiom is (for 2014-????) for this lazy initialization situation so that we can reuse it with less thought and review. In this case the chances of race are fairly low and the cost of extra layoutChars is bearable. In other cases where we are likely to use the same idiom this is less likely true. Peter's current implementation has the advantage that is the best-right answer for lazy initialization even in the contended/expensive case. I look forward to revisiting this again when the new JMM primitives are available. :-)

Mike