On Mar 11, 2014, at 9:05 AM, Sergey Kuksenko <sergey.kukse...@oracle.com> wrote:

> Brian, Mike.
> 
> Could you explain what is the problem with the old caching?
> String is immutable, BigDecimal is immutable. So we have data race at that 
> place, but it is safe data race. What is the problem if we create several 
> identical strings?

I was wondering the same. Not convinced it is so very important for toString() 
to guarantee one and only one reference to the same value. I would be inclined 
to leave this alone unless some data indicates otherwise.

I do question the use of the ThreadLocal to in effect cache a StringBuilder and 
char array of 19 characters for memory reuse (that is "heap pollution" per 
thread! :-) ). This code was introduced ~5 years ago, perhaps it is time to 
revisit and measure using SPEC* benchmarks?

Paul.


> You are making stringCache volatile -> performance penalty on ARM & PPC.
> Setting cache via CAS -> performance penalty everywhere.
> 
> If you insist to use AtomicFieldUpdater - the better way is to use lazySet, 
> not CAS.

Reply via email to