On Mar 11, 2014, at 9:05 AM, Sergey Kuksenko <[email protected]> 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.
