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/
