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

[Sergey Kuksenko]

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


On 03/04/2014 09:21 PM, Mike Duigou wrote:
>
> On Mar 4 2014, at 07:13 , Peter Levart <peter.levart at gmail.com> wrote:
>
>> On 03/04/2014 01:14 AM, Brian Burkhalter wrote:
>>> - add AtomicReferenceFieldUpdater-type constant for stringCache initialization
>>
>> Hi Brian,
>>
>> By using volatile read and CAS, there's still a chance that multiple concurrent threads will be invoking the layoutChars(true) concurrently, but you guarantee that only a single instance of String will ever be returned as a result of the toString() method. Is that what you were pursuing?
>
> Yes. (I provided the AtomicReferenceFieldUpdater code). The previous implementation had a benign data race that could result in a later layoutChars result replacing an earlier result and multiple string instances being returned. The new implementation, at small cost, prevents multiple different instances from being returned.
>
> Mike
>

-- 
Best regards,
Sergey Kuksenko