RFR: 8261847: performace of java.lang.Record::toString should be improved [v4]

Claes Redestad redestad at openjdk.java.net
Mon Nov 22 16:00:31 UTC 2021


On Sun, 21 Nov 2021 00:29:46 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR which aims to optimize the implementation of the `toString` method we provide for records. A benchmark comparing the implementation we are providing for records with lombok found out that lombok is much faster mainly because our implementation uses `String::format`. This fix is basically delegating on StringConcatFactory::makeConcatWithConstants which is faster.
>> 
>> TIA
>> 
>> This is the result of the benchmark comparing records to lombok with vanilla JDK:
>> 
>> Benchmark                          Mode  Cnt    Score    Error  Units
>> MyBenchmark.base                   avgt    4    0.849 ±  0.111  ns/op
>> MyBenchmark.equals_record          avgt    4    7.343 ±  2.740  ns/op
>> MyBenchmark.equals_value           avgt    4    6.644 ±  1.920  ns/op
>> MyBenchmark.record_hash_code       avgt    4    5.763 ±  3.882  ns/op
>> MyBenchmark.record_to_string       avgt    4  262.626 ± 12.574  ns/op               <------ Before
>> MyBenchmark.value_class_to_string  avgt    4   30.325 ± 21.389  ns/op
>> MyBenchmark.value_hash_code        avgt    4    5.048 ±  3.936  ns/op
>> 
>> 
>> after this patch:
>> 
>> Benchmark                          Mode  Cnt   Score   Error  Units
>> MyBenchmark.base                   avgt    4   0.680 ± 0.185  ns/op
>> MyBenchmark.equals_record          avgt    4   5.599 ± 1.348  ns/op
>> MyBenchmark.equals_value           avgt    4   5.718 ± 4.633  ns/op
>> MyBenchmark.record_hash_code       avgt    4   4.628 ± 4.368  ns/op
>> MyBenchmark.record_to_string       avgt    4  26.791 ± 1.817  ns/op                 <------- After
>> MyBenchmark.value_class_to_string  avgt    4  35.473 ± 2.626  ns/op
>> MyBenchmark.value_hash_code        avgt    4   6.152 ± 5.101  ns/op
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   setting max split size to 20

Marked as reviewed by redestad (Reviewer).

src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 276:

> 274:         int namesIndex = 0;
> 275:         do {
> 276:             /* StringConcatFactory::makeConcatWithConstants can only deal with 200 spots, longs and double occupy two

typos: spot -> slot, chunck -> chunk, diference -> difference

src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 314:

> 312:                     ).getTarget();
> 313:                     mhs[splitIndex] = MethodHandles.filterArguments(mhs[splitIndex], 0, currentSplitGetters);
> 314:                     mhs[splitIndex] = MethodHandles.permuteArguments(

This is some gnarly logic. Could we add some comments on what permuteArguments with a reorder array of just zeros is doing here?

src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 330:

> 328: 
> 329:     /**
> 330:      * Chops the getters into smaller chunks according to the maximum number of spots

typo: spots -> slots

src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 333:

> 331:      * StringConcatFactory::makeConcatWithConstants can chew
> 332:      * @param getters the current getters
> 333:      * @return chunks that wont surpass the maximum number of spots StringConcatFactory::makeConcatWithConstants can chew

ditto

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

PR: https://git.openjdk.java.net/jdk/pull/6403


More information about the core-libs-dev mailing list