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