[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