RFR: 8245455: Remove alternative StringConcatFactory strategies

[Claes Redestad]

On 2020-05-22 13:56, Aleksey Shipilev wrote:
> On 5/22/20 1:53 PM, Claes Redestad wrote:
>> Do you have any example of a case when one of the fallbacks was used to
>> work around any issues? We've heard of no such case.
> 
> For example, the bug in j.l.invoke caused semantic bug in String concat:
>    https://bugs.openjdk.java.net/browse/JDK-8200118
>    https://bugs.openjdk.java.net/browse/JDK-8194554

Good correctness fixes, both to underlying j.l.invoke machinery and the
default strategy.

What I'm asking for is whether there exist any operational issues that
means users have to use any of the fallback strategies in the wild on
JDK 11/14 today. That would be a good argument to keep maintaining the
code, but I've not heard of such a case.

For testing and verifying the correctness of dynamic concat callsites we
have the javac fallback to emit SB chains (-XDstringConcat=inline) -
maintaining another fallback strategy is duplication of effort and a
source of potential bugs in its own right.

/Claes

> 
>> BC_SB has a rather intricate dependency on ASM, and recent stabilization
>> work done to the default strategy will need to be duplicated. If we were
>> to keep a fallback (which I don't think we actually need), I'd prefer
>> keeping either MH_SB_SIZED or MH_SB_SIZED_EXACT.
> 
> See above. I believe we better have the fallback that does not enter the meat of j.l.invoke at all.
>