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

[Peter Levart]

On 03/11/2014 06:07 PM, Mike Duigou wrote:
>> >You are making stringCache volatile -> performance penalty on ARM & PPC.
> It is understood that the volatile is not "free". For this purpose it was believed that the performance cost was a fair trade off to avoid the heap pollution. Regardless of the decision in this case the method used would seem to be the best caching pattern available. We do need to establish when it is appropriate to use this solution and what the tradeoffs are that would make other solutions more appropriate.
>

Hi,

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

     private static final Unsafe U = Unsafe.getUnsafe();
     private static final long STRING_CACHE_OFFSET;
     static {
         try {
             STRING_CACHE_OFFSET = 
U.objectFieldOffset(BigDecimal.class.getDeclaredField("stringCache"));
         } catch (NoSuchFieldException e) {
             throw new Error(e);
         }
     }



Regards, Peter