RFR: 8215371: Better nodes for concatenated string literals

[John Rose]

On Dec 14, 2018, at 9:31 AM, Liam Miller-Cushon <cushon at google.com> wrote:
> 
> What do you think? My prototype fix is kind of a work-around, but I think it's a modest improvement over the status quo. If there are ideas of a more principled solution I'm happy to investigate alternatives.

Slightly more principled solution (along one axis):  Treat string concat
as a similar form to existing signature-polymorphic methods invokeExact,
etc.  That treats it as a method call (rather than special control flow or
block structure), so common method-call code would apply.

Then at code generation time transform the sig-poly call down to indy
or open-coded StringBuilder stuff or whatever else the user has requested.

The advantage of sig-poly calls is that they don't try to dictate argument
types; they accept actual arguments as-is.  This is what you want to
preserve if you are going to try to hold a high-level form of AST and
defer lowering to indy or SBs to a later phase.

One disadvantage of sig-poly calls:  They are not defined for
more than 255 arguments, whereas varargs allow up to 2^31-1
arguments.  This could be handled by having the new "principled"
form of sig-poly invocation AST to *optionally* limit the number of
arguments (argument slots, TBE) to 255.

One reason I suggest this is that I think there are more uses likely
in the future for signature-polymorphic APIs and/or APIs which lower
late (after constant folding).  I don't think string append is unique,
at all, in this respect.  So if you want to think about a more general
AST pattern for loosely typed (TBE use-site typed) method calls,
where the methods might be intrinsics of some sort, and where the
arity limit is not just 255, and you want to preserve usual evaluation
order (i.e., not && or ?: or __Let), then late-bound method calls are
the natural semantics to reach for.  In that case, the sig-poly is a
good first cut.

Another consideration:  I aspire to, some day, change the translation
strategy for varargs and auto-boxing call sites to translate into relaxed
typed, signature polymorphic style, to avoid emitting bytecodes for
converting and boxing arguments and argument lists.  The point of
that is to defer conversion to the runtime, making the call site easier
to parse and hence optimize and/or raise to expression.  The JVM
would create adapter logic at link time (per call site) to manage the
difference between the use-site and def-site of the resolved method.
No language-level semantics need change; it's a translation strategy.
Could be prototyped today with indy (and I think Remi Forax has).

Another consideration:  Some day we might have better varargs
based on value types, which do not commit so many extra boxes
to the heap.  Again, a sig-poly static translation strategy with runtime
adapter generation will make it easier to engineer such a thing,
and even evolve it without recompilation.

HTH
— John


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181214/5e950cf2/attachment.html>