On Tue, 11 Jun 2024 15:55:18 GMT, Shaojin Wen <d...@openjdk.org> wrote:
>> @wenshao have you published info about `TraceMergeStores` somewhere? It is
>> very well possible that the optimization does not apply in your code. Then
>> you would need to dig into the VM code and see why.
>
> @eme64 TraceMergeStores are here, but I can't understand these assembly codes
>
> # JavaCode
>
> class AbstractStringBuilder {
> private AbstractStringBuilder appendNull() {
> int count = this.count;
> ensureCapacityInternal(count + 4);
> byte[] val = this.value;
> if (isLatin1()) {
> val[count ] = 'n';
> val[count + 1] = 'u';
> val[count + 2] = 'l';
> val[count + 3] = 'l';
> } else {
> StringUTF16.putCharsAt(val, count, 'n', 'u', 'l', 'l');
> }
> this.count = count + 4;
> return this;
> }
> }
>
> class StringUTF16 {
> public static void putCharsAt(byte[] value, int i, char c1, char c2, char
> c3, char c4) {
> putChar(value, i , c1);
> putChar(value, i + 1, c2);
> putChar(value, i + 2, c3);
> putChar(value, i + 3, c4);
> }
> }
>
>
> # TraceMergeStores
>
> CompileCommand: compileonly *StringBuilder.appendNull bool compileonly = true
>
> Compiled method (n/a) 100 1 n
> java.lang.invoke.MethodHandle::linkToStatic(LLLLLLL)L (native)
> total in heap [0x00000001043b8088,0x00000001043b8230] = 424
> relocation [0x00000001043b8170,0x00000001043b8188] = 24
> main code [0x00000001043b81c0,0x00000001043b8230] = 112
>
> [Disassembly]
> --------------------------------------------------------------------------------
> [Constant Pool (empty)]
>
> --------------------------------------------------------------------------------
>
> [Verified Entry Point]
> # {method} {0x000000011842b8b8} 'linkToStatic'
> '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;'
> in 'java/lang/invoke/MethodHandle'
> # parm0: c_rarg1:c_rarg1
> = 'java/lang/Object'
> # parm1: c_rarg2:c_rarg2
> = 'java/lang/Object'
> # parm2: c_rarg3:c_rarg3
> = 'java/lang/Object'
> # parm3: c_rarg4:c_rarg4
> = 'java/lang/Object'
> # parm4: c_rarg5:c_rarg5
> = 'java/lang/Object'
> # parm5: c_rarg6:c_rarg6
> = 'java/lang/Object'
> # parm6: c_rarg7:c_rarg7
> = 'java/lang/invoke/MemberName'
> # [sp+0x0] (sp of caller)
> 0x00000001043b81c0: nop
> ;; verify_klass {
> 0x00000001043b81c4: cbz x7, 0x00000001043b81fc
> 0x00000001043b81c8: stp x8, x9, [sp, #-16]!
> 0x00000001043b81cc: ldr w9, [x7, #8]
> 0x00000001043b...
@wenshao The output you have here is not at all the `TraceMergeStores`, but the
assembly dump, probably from `PrintOptoAssembly`. In you entire log I never see
a single occurance of `TraceMergeStores`, so presumably no such optimisation
was done.
I suggest you play around with the examples from my PR
https://github.com/openjdk/jdk/pull/16245, and the `TraceMergeStores` flag.
That will give you some insight about how it works, and maybe give you a way
into understanding why your examples are not optimized.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2161132962
