RFR: 8333893: Optimization for StringBuilder append boolean & null [v4]

[Emanuel Peter]

On Tue, 11 Jun 2024 15:55:18 GMT, Shaojin Wen <duke at 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