8245304: Re-examine ThreadLocal usage in java.math.BigDecimal

[Joe Darcy]

Looks fine; thanks,

-Joe

On 8/11/2020 10:32 AM, Brian Burkhalter wrote:
> To fix [1], please consider [2] which replaces the ThreadLocal “threadLocalStringBuilderHelper” with straightforward use of a StringBuilderHelper instance. The initial capacity of the StringBuilder instance variable of StringBuilderHelper is also doubled from 16 to 32.
>
> Microbenchmarking was effected primarily using BigDecimal.toEngineeringString(). This method and toString() both invoke layoutChars() which used the ThreadLocal. The toString() method caches its return value but toEngineeringString() does not.
>
> Benchmarking using a single Thread did not show any regression for toEngineeringString() and in fact showed a slight improvement. Since toEngineeringString() does not cache its result, one would expect the benchmarks for toString() not to deteriorate either, and simple benchmarking validated this.
>
> Given the absence of any measurable performance regression it appears that this ThreadLocal may safely be removed.
>
> Thanks,
>
> Brian
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8245304
> [2] http://cr.openjdk.java.net/~bpb/8245304/webrev.00/