StringBuilder buffer allocation support in compiler

[Laszlo Hornyak]

Hi Vitaly,

I tested with server VM and the test code has some warmup so that the JIT
should have enough time to kick in, but I will check stringopts if it
should do some relevant optimization.



On Thu, Jun 5, 2014 at 9:43 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:

> Hi Laszlo,
>
> I believe server jit compiler has an optimization pass that will attempt
> at fusing this type of pattern into one string allocation -- see
> src/share/vm/opto/stringopts.[h|c]pp in the sources.  Have you tried
> benchmarking this after jit compiler gets a crack at it?
>
>
> On Thu, Jun 5, 2014 at 3:27 PM, Laszlo Hornyak <laszlo.hornyak at gmail.com>
> wrote:
>
>> Hi,
>>
>> Given this sample code
>>
>>     public static String sayHello(String name, int age) {
>>         return "Hello " + name + ", this is your " + age + "th birthday";
>>     }
>>
>> The compiler will generate this bytecode:
>>        0: new           #11                 // class
>> java/lang/StringBuilder
>>        3: dup
>>        4: invokespecial #12                 // Method
>> java/lang/StringBuilder."<init>":()V
>>        7: ldc           #19                 // String Hello
>>        9: invokevirtual #15                 // Method
>> java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
>>       12: aload_0
>>       13: invokevirtual #15                 // Method
>> java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
>>       16: ldc           #20                 // String , this is your
>>       18: invokevirtual #15                 // Method
>> java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
>>       21: iload_1
>>       22: invokevirtual #13                 // Method
>> java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
>>       25: ldc           #21                 // String th birthday
>>       27: invokevirtual #15                 // Method
>> java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
>>       30: invokevirtual #17                 // Method
>> java/lang/StringBuilder.toString:()Ljava/lang/String;
>>       33: areturn
>>
>> The most interesting line is:
>>        4: invokespecial #12                 // Method
>> java/lang/StringBuilder."<init>":()V
>>
>>
>> Since all the string literals are given for the compiler, it could give
>> an estimation on the required buffer size to the StringBuilder constructor.
>> In this example the string literals already take 32 characters, plus a
>> string representation of an integer takes up to 12 characters. The String
>> size is 0 to Integer.MAX_VALUE, but 16 might be a good default. In this
>> case a constructor call could be generated to allocate a buffer with 50
>> characters and some (possibly all) buffer re-allocation could be saved in
>> the subsequent append calls.
>> The performance gain seems to be significant since the subsequent buffer
>> allocations can take up to 30-40 percent of the execution time.
>> Is there a specific reason for the java compiler not to support
>> pre-allocation of StringBuilder buffer based on string literals and
>> parameters?
>>
>> Thank you,
>> Laszlo
>>
>>
>> --
>>
>> EOF
>>
>
>


-- 

EOF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140605/4a9af522/attachment.html>