[External] : Re: String concatenation order of operations

[Remi Forax]

> From: "John Rose" <john.r.rose at oracle.com>
> To: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "Liam Miller-Cushon" <cushon at google.com>, "compiler-dev"
> <compiler-dev at openjdk.java.net>
> Sent: Vendredi 17 Septembre 2021 08:51:07
> Subject: Re: [External] : Re: String concatenation order of operations

> On Sep 8, 2021, at 3:01 PM, Brian Goetz < [ mailto:brian.goetz at oracle.com |
> brian.goetz at oracle.com ] > wrote:

>> We'd essentially have to write a new bootstrap (but leave the old one in place),
>> and have the compiler generate bytecode to do the string conversion as the
>> values are being pushed on the stack. This requires a different bootstrap and a
>> different calling convention. So old bytecode will stay around, and the old
>> bootstrap would have to be kept around ... pretty disruptive.

> Wouldn’t be enough for javac to run toString() on arguments that need it, and
> pass those (to the *old* indy mechanism) as strings?

> If javac can determine that toString() can be safely delayed (for String and
> primitive boxes, for example) then it doesn’t need to call toString() eagerly.

> But in order to fix this issue, it may be necessary to run toString() calls
> while arguments are being computed for the indy.

It will be less efficient because the StringConcatFactory for a primitive type does not create the intermediary String objects. 

> Yuck

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210917/ab322e6a/attachment.htm>