RFR: JDK-8273914: Indy string concat changes order of operations [v5]
cushon at openjdk.java.net
Thu Oct 14 17:14:43 UTC 2021
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.
More information about the hotspot-runtime-dev