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

[Paul Sandoz]

On Mar 11, 2014, at 9:05 AM, Sergey Kuksenko <sergey.kuksenko at 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.