PING! Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal

[Paul Sandoz]

Hi Brian,

My inclination is "if it ain't broke... " and AFAICT nothing indicates toString it is particular broken [*], so perhaps just focus on the cleanup aspects and revisit the other when the JMM is updated (and maybe enhanced volatiles is ready)?

Paul.

[*] although i still question the use of thread locals, but that is a separate issue that requires more investigation and i don't know if if can be improved.

On Apr 10, 2014, at 10:45 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> Second day back from vacation so I guess it’s time to beat this horse again …
> 
> As there was no response to the message included below I am simply re-posting it.
> 
> Thanks,
> 
> Brian
> 
> On Mar 25, 2014, at 7:19 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
>> On Mar 25, 2014, at 1:58 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> 
>>> This is another example of a stable variable.
>>> 
>>> I would like to re-iterate my scepticism that such changes are necessary in this case (i am not sure if it is possible to create a benchmark that could better exacerbate the concurrent overlap of calls to layoutChars). But, i do agree the discussion has been useful and interesting.
>> 
>> I am happy either to leave the toString() code as it is or to change it to the variant with toStringSlow(). There is however other cleanup in the patch to consider. So it would be good to get consensus on the two points:
>> 
>> 1) Change toString() to variant using toStringSlow() or leave it as-is.
>> 2) Change non-toString() code as indicated in the patch or leave it as-is.
>> 
>> If “as-is” is the answer in both cases, then it’s simply a matter of resolving the enhancement as “not an issue.”
>> 
>> Thanks,
>> 
>> Brian
>