RFR: 8315585: Optimization for decimal to string [v3]

[温绍锦]

On Tue, 5 Sep 2023 15:46:17 GMT, 温绍锦 <duke at openjdk.org> wrote:

>> BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal.
>> 
>> The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance.
>> 
>> Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering.
>> 
>> The performance data is as follows: 
>> 
>> ## 1. benchmark script
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.math.BigDecimals.*ToPlainString"
>> make test TEST="micro:java.math.BigDecimals.*ToEngineering"
>> 
>> 
>> ## 2. benchmark environment
>> * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i)
>> * cpu intel xeon sapphire rapids (x64)
>> 
>> ## 3. benchmark result
>> 
>> -BigDecimals.testHugeToPlainString         avgt   15   188.691 ±  0.822  ns/op  (baseline)
>> -BigDecimals.testLargeToPlainString        avgt   15    36.656 ±  0.065  ns/op
>> -BigDecimals.testSmallToPlainString        avgt   15    34.342 ±  0.068  ns/op
>> -BigDecimals.testToPlainString             avgt   15  1719.494 ± 24.886  ns/op
>> 
>> +Benchmark                                 Mode  Cnt     Score    Error  Units (optimize)
>> +BigDecimals.testHugeToPlainString         avgt   15   133.972 ?  0.328  ns/op (+40.84%)
>> +BigDecimals.testLargeToPlainString        avgt   15    14.957 ?  0.047  ns/op (145.07%)
>> +BigDecimals.testSmallToPlainString        avgt   15    12.045 ?  0.036  ns/op (+185.11)
>> +BigDecimals.testToPlainString             avgt   15  1643.500 ?  3.217  ns/op (+4.62%)
>> 
>> -Benchmark                                 Mode  Cnt     Score    Error  Units (baseline)
>> -BigDecimals.testHugeToEngineeringString   avgt   15   207.621 ±  5.018  ns/op
>> -BigDecimals.testLargeToEngineeringString  avgt   15    35.658 ±  3.144  ns/op
>> -BigDecimals.testSmallToEngineeringString  avgt   15    15.142 ±  0.053  ns/op
>> -BigDecimals.testToEngineeringString       avgt   15  1813.959 ± 12.842  ns/op
>> 
>> +Benchmark                                 Mode  Cnt     Score    Error  Units (optimize)
>> +BigDecimals.testHugeToEngineeringString   avgt   15   142.110 ?  0.987  ns/op (+45.09%)
>> +BigDecimals.testLargeToEngineeringStr...
>
> 温绍锦 has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into optimization_for_decimal_to_string
>  - BigInteger use a separate jla
>  - update copyright info
>  - optimization for decimal to string

Reducing code duplication with JavaLangAccess is a good suggestion,  I'm waiting for #14699 to be merged.

I am the author of the json library [fastjson](https://github.com/alibaba/fastjson) and [fastjson2](https://github.com/alibaba/fastjson2).  When serializing BigDecimal type data to JSON, I found that BigDecimal has performance improvements. 

Including the following methods:
* toString
* toPlainString
* new BigDecimal(String)

These optimizations are not only useful for [fastjson](https://github.com/alibaba/fastjson) and [fastjson2](https://github.com/alibaba/fastjson2), but also for [gson](https://github.com/google/gson)/[jackson](https://github.com/FasterXML/jackson-databind) and many other libraries.

The optimization of #9410 is doubleValue, which is not related to toString/toPlainString.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15555#issuecomment-1707520521