RFR: 8341696: C2: Non-fluid StringBuilder pattern bails out in OptoStringConcat [v4]
Theo Weidmann
tweidmann at openjdk.org
Wed Jan 8 14:04:49 UTC 2025
On Wed, 8 Jan 2025 13:58:02 GMT, Theo Weidmann <tweidmann at openjdk.org> wrote:
>> src/hotspot/share/opto/stringopts.cpp line 613:
>>
>>> 611: } else if (use != nullptr &&
>>> 612: check_append_candidate(use, sc, m, string_sig, int_sig, char_sig) == CheckAppendResult::GiveUp) {
>>> 613: return nullptr;
>>
>> What happens here in the two other cases `GoodAppend` and `NotAppend`?
>
> We don't really care here if it was an append or not. The only important thing is to exit this algorithm if the processing of the append candidate detected a reason to definitely give up.
If we had exceptions, the method could just return true and false, and throw to abort the optimization...
>> src/hotspot/share/opto/stringopts.cpp line 643:
>>
>>> 641:
>>> 642: if (result == CheckAppendResult::GiveUp) {
>>> 643: break;
>>
>> Can you put a comment here where this is supposed to jump, and why?
>
> I was already considering to replace all the `break` with `return nullptr` here before, because all of them just exit from the entire algorithm because we detected something that completely prevents this optimization. But then I thought I will rather stick with the existing pattern and not change code that does not really need to be changed.
Of course the way this entire loop works is a little confusing, but I didn't want to really refactor/rewrite all of this as it seems quite delicate and not trivial to test.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/22537#discussion_r1907233513
PR Review Comment: https://git.openjdk.org/jdk/pull/22537#discussion_r1907232574
More information about the hotspot-compiler-dev
mailing list