[External] : Re: String concatenation order of operations
forax at univ-mlv.fr
Fri Sep 17 13:25:43 UTC 2021
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the compiler-dev