String concatenation metaprotocol Was: String concatenation tweaks

[Peter Levart]

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

>
> 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/b814095b/attachment-0001.html>