String concatenation tweaks

[Peter Levart]

On 05/31/2015 11:06 PM, Peter Levart wrote:
>
>
> On 05/31/2015 10:58 PM, Peter Levart wrote:
>>
>>
>> On 05/28/2015 11:22 PM, Aleksey Shipilev wrote:
>>> On 05/26/2015 04:31 PM, Remi Forax wrote:
>>>> On 05/25/2015 09:01 PM, Aleksey Shipilev wrote:
>>>>> The performance is interesting. It seems to break OptimizeStringConcat,
>>>>> and so it's a performance win only on non-optimized chains, like
>>>>> string_string_long. The allocation pressure is slightly higher as well,
>>>>> seems to be because int[] from the collector is not scalarized.
>>>> I wonder if the two things are not related, fail to unroll -> creation
>>>> of int[] -> non constant value for the StringBuilder constructor ->
>>>> break of OptimizeStringConcat optimization.
>>> Merged:
>>>    http://cr.openjdk.java.net/~shade/scratch/string-concat-indy/
>>>
>>> It seems OptimizeStringConcat expects a particular C2 IR graph shape,
>>> and it might be hard to reproduce on MHs. Anyhow, your new FULL_MH now
>>> performs the same as INNER_SIZED when OptimizeStringConcat fails, both
>>> throughput-performance- and allocation-wise on small count of int arguments.
>>>
>>> Please note I added a simple regression test, and munged the code to
>>> make it pass. StringBuilder::append overloads are not present for every
>>> type, and also we need to bypass StringBuffers/CharSequences.
>>>
>>> It would seem INNER_SIZED is a good strategy to default to, and
>>> subsequent JDK improvements can be done after the infrastructure lands.
>>> The whole point for this change is to open the door for these
>>> improvements. Meanwhile, I put together a very rough JEP draft here, and
>>> I would appreciate comments and corrections:
>>>   http://cr.openjdk.java.net/~shade/scratch/string-concat-indy/jep.txt
>>>
>>> Thanks,
>>> -Aleksey
>>
>> Hi,
>>
>> This is a noble goal. I will just warn you about the possible 
>> initialization problems. String concatenation is a very rudimentary 
>> operation and might be used very early in the startup of the JVM. If 
>> it is used before the system class loader is initialized (before the 
>> main method is executed), you will be faced with the following issue 
>> at least:
>>
>> http://mail.openjdk.java.net/pipermail/mlvm-dev/2015-March/006386.html
>>
>> ...so we might need to fix these early java.lang.invoke 
>> initialization problems 1st.
>
> Not to mention that java.lang.invoke infrastructure (at least the part 
> that is used to support invokedynamic etc.) should then *not* use 
> string concatenation...

One way to tackle this is to have a javac option to emit classical 
StringBuilder-based code and then build the (java.base module at least) 
with this option. So only other modules and user code would use indy 
based concatenation. This will also eliminate worries about startup 
time. But code in java.base module would then not be able to benefit 
from possible improvements in indy based concatenation. Do we need a 
minimal java.kernel module which would include just java.lang.invoke and 
it's dependencies?

Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150531/79583e61/attachment.html>