String concatenation tweaks

Jan Lahoda jan.lahoda at oracle.com
Mon Jun 1 09:29:03 UTC 2015


Hi,

While I agree that use of invokedynamic to allow optimized String 
concatenation is very clever, using invokedynamic for so basic operation 
seems like an overkill to me. I suppose that many tools that 
read/analyze/manipulate the classfiles would need understand what this 
new code is doing etc.

Is there any chance JIT could detect and optimize the pattern? The 
advantage of that would not only be that existing classfiles would get 
the optimization, and maybe also (some) hand-written String 
concatenations could get the improved behavior as well?

Thanks,
    Jan

On 1.6.2015 09:49, Aleksey Shipilev wrote:
> Hi Peter,
>
> On 06/01/2015 12:33 AM, Peter Levart wrote:
>> On 05/31/2015 11:06 PM, Peter Levart wrote:
>>> On 05/31/2015 10:58 PM, Peter Levart wrote:
>>>> 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.
>
> If you read my notes about this:
>   http://cr.openjdk.java.net/~shade/scratch/string-concat-indy/notes.txt
>
> You will see the mention of "java.base is exempt from indy string
> concat, otherwise the initialization circularity ensues". Indeed, there
> is a patch that disables indy string concat for java.base:
>   http://cr.openjdk.java.net/~shade/scratch/string-concat-indy/patch-root-1.patch
>
>> This will also eliminate worries about startup time.
>
> It would not, because, as I was saying in the notes, the significant
> time is spent dealing with indy infrastructure for every user string
> concat. In other words, a simple smoke test with HelloWorld concating a
> simple string suffers quite a bit.
>
> Thanks,
> -Aleksey.
>
>


More information about the compiler-dev mailing list