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

[Mike Duigou]

On Mar 11 2014, at 01:05 , Sergey Kuksenko <sergey.kuksenko at oracle.com> wrote:

> Brian, Mike.
> 
> Could you explain what is the problem with the old caching?

Concern over heap pollution with extra string copies was the motivation to ensure that only a single cached instance was ever returned.

> String is immutable, BigDecimal is immutable. So we have data race at that place, but it is safe data race.

Agreed that it is safe.

> What is the problem if we create several identical strings?

We can still create several identical strings. We will now only return the first assigned to stringCache. Other string instances will not escape.

> 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.  

> Setting cache via CAS -> performance penalty everywhere.

This happens only once per BigDecimal (or not at all if the string format is never generated).

> If you insist to use AtomicFieldUpdater - the better way is to use lazySet, not CAS.

That would seem to be inappropriate for this usage as lazySet would effectively remove that volatile.

Brian did some benchmarking of various alternatives which he can probably provide if we think it is relevant to the performance issue you're concerned with.

Mike