RFR: 8255936: "parsing found no loops but there are some" assertion failure with Shenandoah [v2]
Tobias Hartmann
thartmann at openjdk.java.net
Thu Nov 12 15:00:01 UTC 2020
On Fri, 6 Nov 2020 11:13:04 GMT, Roland Westrelin <roland at openjdk.org> wrote:
>> This is a Shenandoah bug but the proposed fix is in shared code.
>>
>> In an infinite loop, a barrier is located right after the loop head
>> and above the never branch. When the barrier is expanded, control flow
>> is added between the loop and the never branch. During loop
>> verification the assert fires because it doesn't expect any control
>> flow between the never branch and the loop head.
>>
>> While it would have been nice to fix this Shenandoah issue in
>> Shenandoah code, I think the cleaner fix is to preserve the invariant
>> that the never branch is always right after the loop head in an
>> infinite loop. In the proposed patch, this is achieved by moving all
>> uses of the loop head to the never branch when it's constructed.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>
> fix & test
Otherwise looks good to me.
src/hotspot/share/opto/loopnode.cpp line 4569:
> 4567: set_loop(if_t, l);
> 4568:
> 4569: Node* cfg = NULL; // Find the One True Control User of m
Should be removed.
src/hotspot/share/opto/loopnode.cpp line 4576:
> 4574: int nb = x->replace_edge(m, if_t);
> 4575: assert(nb > 0, "use should have been updated");
> 4576: --j, jmax -= nb;
Indentation is wrong.
-------------
Marked as reviewed by thartmann (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/1073
More information about the shenandoah-dev
mailing list