### Performance regression of DecimalFormat.format >From the output of perf, we can see the hottest regions contain atomic >instructions. But when run with JDK 11, there is no such problem. The reason >is the removed biased locking. The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods. So I added support for some new methods that accept StringBuilder which is lock-free.
### Performance regression of new DecimalFormat After comparing the flame graph between current jdk and jdk 11, the method java.text.DecimalFormatSymbols#findNonFormatChar takes a significant time. The performance becomes as good as jdk11 after replacing it with a simple loop implementation. ------------- Commit messages: - 8333396: Performance regression of new DecimalFormat and DecimalFormat.format Changes: https://git.openjdk.org/jdk/pull/19513/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333396 Stats: 318 lines in 11 files changed: 268 ins; 0 del; 50 mod Patch: https://git.openjdk.org/jdk/pull/19513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513 PR: https://git.openjdk.org/jdk/pull/19513
