String concatenation tweaks

[Maurizio Cimadamore]

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.
>
>