String concatenation tweaks

[Louis Wasserman]

I think I almost certainly would, but I confess I've lost track of what
exactly it is you want from me.  =)

On Thu, Jun 4, 2015 at 6:48 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>
>
> On 04/06/15 14:41, Aleksey Shipilev wrote:
> > On 06/04/2015 03:56 PM, Aleksey Shipilev wrote:
> >> On 06/04/2015 03:35 PM, Maurizio Cimadamore wrote:
> >>> Well, yes - but adding a new indy is not something that comes for free.
> >>> We are currently fighting to get specialization to work correctly with
> >>> lambdas, and it turns out that having an indy, as Brian said, is like
> >>> having an entirely new bytecode - so, for every new 'officially
> >>> supported' bootstrap that we add, we will need to find ways to make
> that
> >>> work with whatever new feature XYZ we could come up in the future.
> >> Yes. This is why we better spend time figuring if the proposed indy
> >> interface is enough/future-proof.
> > In other words, we do indeed introducing something similar to a new
> > bytecode, a long missing "string concat". Would you argue we need to
> > continue band-aiding the impedance between JLS allowing String concat
> > and JVMS not having the appropriate facilities for it -- and forcing the
> > VM implementations to recognize all these translated forms? Indy allows
> > us to overcome this impedance with one leap.
> You asked for a review :-)
>
> My feeling is that this is a game of diminishing returns; and I simply
> think that before dismissing alternatives, we should take them into
> account in case there are any surprises. That's what I would do if I had
> submittted the JEP.
>
> I'm sure Louis would be more than happy to provide a patch to add some
> additional depth to your current benchmarks.
>
> Maurizio
> >
> > This also opens up the way into using the (potentially unsafe) private
> > APIs for concat on VM side, like fixed-length string builders proposed
> > in this thread. Doing the same on javac side would mean these private
> > APIs have to be leaked into public.
> >
> > Thanks,
> > -Aleksey.
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150604/e735997c/attachment.html>