RFR: 8352316: More MergeStoreBench [v7]

Shaojin Wen swen at openjdk.org
Thu Apr 3 12:19:57 UTC 2025


On Wed, 2 Apr 2025 06:46:41 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add StringBuilderUnsafePut
>
> test/micro/org/openjdk/bench/vm/compiler/MergeStoreBench.java line 693:
> 
>> 691:         }
>> 692:         BH.consume(off);
>> 693:     }
> 
> This is a copy pattern, not MergeStores.

As above, STR_4 is a string constant of length 4. Can it be optimized to write a long?

> test/micro/org/openjdk/bench/vm/compiler/MergeStoreBench.java line 735:
> 
>> 733:         }
>> 734:         BH.consume(off);
>> 735:     }
> 
> @wenshao This is a copy pattern. Not a MergeStore pattern. So I can tell you already now that it will not be optimized by MergeStores ;)

If STR_4_BYTES_UTF16 is a StableValue, is it possible to optimize to writing a long?

> test/micro/org/openjdk/bench/vm/compiler/MergeStoreBench.java line 799:
> 
>> 797:         }
>> 798:         BH.consume(off);
>> 799:     }
> 
> @wenshao Why would MergeStores work here? This is is a copy pattern. That is not at all covered by MergeStores.

This is a constant of length 5. Can it be optimized to write a combination of int + byte?

> test/micro/org/openjdk/bench/vm/compiler/MergeStoreBench.java line 856:
> 
>> 854:         }
>> 855:         BH.consume(sb.length());
>> 856:     }
> 
> Why would you expect MergeStores to work here?

STR_5 is a string constant with a length of 5. Is it possible to optimize it into an implementation similar to str5StringBuilderUnsafePut? The performance can be greatly improved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24108#discussion_r2026870739
PR Review Comment: https://git.openjdk.org/jdk/pull/24108#discussion_r2026869185
PR Review Comment: https://git.openjdk.org/jdk/pull/24108#discussion_r2026866952
PR Review Comment: https://git.openjdk.org/jdk/pull/24108#discussion_r2026875472


More information about the hotspot-compiler-dev mailing list