JDK 9 RFR of 6375303: Review use of caching in BigDecimal (original) (raw)

Paul Sandoz paul.sandoz at oracle.com
Wed Mar 12 09:35:41 UTC 2014

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.

More information about the core-libs-dev mailing list