String concatenation metaprotocol Was: String concatenation tweaks

Peter Levart peter.levart at gmail.com
Sun Jun 7 13:53:30 UTC 2015



On 06/07/2015 03:44 PM, Peter Levart wrote:
>
>
> On 06/05/2015 11:12 AM, Remi Forax wrote:
>> Aleksey,
>> there is something that the current translation doesn't do,
>> with by example, "foo" + a + "bar", javac know that "foo" and "bar" 
>> are constants but doesn't propagate this information to the bootstrap 
>> method, the invokedynamic call will use 3 arguments instead of one ; 
>> the only the value of 'a' can changed and the two others can be sent 
>> as bootstrap constants.
>>
>> This would help the dynamic part because calculating the length of 
>> "foo" and "bar" will be done once in the bootstrap method instead of 
>> being done each time. In the example below, if 'a' is a primitive 
>> type, it can be a huge win because the total length of the buffer 
>> becomes a constant.
>>
>> All we need for that is to define a way to describe how the arguments 
>> of the call and the bootstrap arguments are interleaved. Let say we 
>> use a String with 'A' for classical argument and 'B' for a bootstrap 
>> argument,
>> in that case "foo" + a + "bar" interleaving is "BAB", so the 
>> corresponding bytecode is
>>   iload 0  // load a
>>   invokedynamic "BAB" (I)Ljava/lang/String ["foo", "bar"]
>>
>> And 'null' is a special case because it's a compiler constant but it 
>> can not be encoded as a constant pool constant,
>> the best IMO is to consider that instead of trying to encode 'null', 
>> it's better to encode "null" as a String.
>
> Hm,
>
> You are building a DSL for string concatenation, right? What about the 
> bootstrap parameters being a single String with all the constant 
> strings concatenated followed by a sequence of indexes (one for each 
> variable parameter) pointing into the constant string to where each of 
> the parameters is to be inserted?
>
> Above example would look like:
>
> invokedynamic "foobar" (I)Ljava/lang/String; [3]
>
> Choosen strategy could use the passed-in constant string itself 
> (constant pool replacement) as the source of characters when building 
> the final concatenated string without splitting it.
>
> Is the limit of 255 parameters in invokedynamic including bootstrap 
> arguments or are they separate?
>
> Regards, Peter

One thing to watch out is that these could lead to the explosion of 
shapes. Majority of concatenation expressions do contain at least one 
constant string and it is rarely equal to some other constant string in 
an equivalent concatenation expression found somewhere else...

Regards, Peter

>
>>
>> cheers,
>> Rémi
>>
>> On 05/21/2015 02:15 PM, Aleksey Shipilev wrote:
>>> On 05/15/2015 01:06 AM, Aleksey Shipilev wrote:
>>>> It actually does not seem that scary. javac changes seem minimal,
>>>> because they basically mirror [1] what is already done for current
>>>> String concat and lambda desugaring.
>>>>
>>>> JDK side of changes is not too scary as well [2], and it readily lends
>>>> itself to different implementation strategies, including precomputing
>>>> the argument lengths. I realized too late it does not check for 
>>>> argument
>>>> nullity properly, but this is a proof-of-concept patch anyway.
>>> Updated patches:
>>> http://cr.openjdk.java.net/~shade/scratch/string-concat-indy/
>>>
>>> INNER_SIZED strategy is enabled by default for everything except
>>> java.base. This, and a few other touchups make the patched JDK to build
>>> cleanly, and pass the most java/lang and java/util jtreg tests (there
>>> are seem to be some failures in Indify-based tests).
>>>
>>> Thanks,
>>> -Aleksey
>>>
>>>
>>>
>>
>

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


More information about the compiler-dev mailing list