String concatenation metaprotocol Was: String concatenation tweaks

[Remi Forax]

On 06/07/2015 03:53 PM, Peter Levart wrote:
>
>
> 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

Hi Peter,
to answer to your question the limit of 255 parameters is applied twice 
(because at least for the first call through invokedynamic you have two 
calls).
When a bootstrap method is called, you can not pass more than 252 
bootstrap constants, 255 - 3 because the first 3 parameters of the 
bootstrap method are fixed by the spec. Then the invokedynamic call by 
iteself, which is a function pointer call which is also limited to 255 
parameters.

so for the string concatenation, you can not have more than 255 variable 
arguments and 252 constant arguments.

regards,
Rémi


>
>>
>>>
>>> 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/20150609/d3122d20/attachment.html>