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

Joe Darcy joe.darcy at oracle.com
Tue Aug 11 23:03:49 UTC 2020

Looks fine; thanks,


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/

More information about the core-libs-dev mailing list