[External] : Re: String concatenation order of operations
Brian Goetz
brian.goetz at oracle.com
Wed Sep 8 22:01:00 UTC 2021
> It'd be nice to reconcile the implementation with the spec if
> possible, though. I wonder what the performance hit would be from
> calling toString on the arguments more eagerly to preserve the
> evaluation order.
The nature of indy leads to the structure we ended up with. The natural
way to do this is to have the various arguments passed as real stack
arguments, causing them to all be evaluated before being pushed through
the MH nest (which is where the string conversion happens, using
MethodHandle::filterArguments.) 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210908/fa8955e8/attachment.htm>
More information about the compiler-dev
mailing list