RFR: JDK-8273914: Indy string concat changes order of operations [v5]

[Liam Miller-Cushon]

On Thu, 14 Oct 2021 08:35:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I agree in general about using `inline` as a baseline, but `WellKnownTypes` doesn't currently check the output of string concatenation, it checks the signature of the `invokedynamic` it find in the test case.
>> 
>> What do you have in mind for `inline` here? Should I update the test to assert on the output of string concatenation (and tolerate not being able to find an `invokedynamic`, which could make the coverage for the indy strategies more fragile)? Or add a different test with similar inputs, and check the output of string concatenation on primitives and boxes?
>> 
>> I think it might make sense to rely on other tests to ensure `inline` and the `indy` strategies produce the same results, and use `WellKnownTypes` as a test just for `shouldConvertToStringEagerly`, which is only used by the `indy` strategies.
>
> Ah, I missed that `WellKnownTypes` does not verify concat output. Yes, that resolves my concern, we don't need to handle `inline` there. Maybe rename `WellKnownTypes` to `WellKnownTypeSignatures` or something?
> 
> But yes, I think adding another test that verifies the "special" input types produce consistent results across all strategies would be useful.

Sure, thanks--I renamed `WellKnownTypes` to `WellKnownTypeSignatures`, and added a new ` WellKnownTypes` that tests the actual concat behaviour on primitives for all of the strategies.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5844