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

[Aleksey Shipilev]

On Tue, 12 Oct 2021 16:26:58 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> But still, we probably want to confirm that `inline` strategy yields the same answer in `WellKnownTypes`? That's my thinking why to test `inline`: that is a baseline.
>
> 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.

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

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