RFR: 8260637: Shenandoah: assert(_base == Tuple) failure during C2 compilation

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

RFR: 8260637: Shenandoah: assert(_base == Tuple) failure during C2 compilation

Roland Westrelin-4
Another shenandoah bug with a fix in shared code.

LRBRightAfterMemBar.test2() has 2 allocations that are non escaping
but non scalarizable. As a result, the null check for a3.f is
optimized out but the CastPP is left in the graph. That CastPP becomes
control dependent on the o2 == null check which is later hoisted out
of the loop. The CastPP is then right after the membar of the barrier = 0x42
volatile access but with an out of loop control. Because the node is
considered pinned by loopopts, it is assigned the membar as
control. The input of the CastPP is a shenandoah barrier that's
sandwiched between the membar and the CastPP and so expanded right
after the membar (that is between the membar and its control
projection). That causes the crash. I don't think cast nodes need to
be pinned so I propose that as a fix.

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

Commit messages:
 - test & fix

Changes: https://git.openjdk.java.net/jdk/pull/2400/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2400&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260637
  Stats: 33 lines in 2 files changed: 27 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2400.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2400/head:pull/2400

PR: https://git.openjdk.java.net/jdk/pull/2400
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8260637: Shenandoah: assert(_base == Tuple) failure during C2 compilation

Roland Westrelin-4
On Thu, 4 Feb 2021 08:34:04 GMT, Roland Westrelin <[hidden email]> wrote:

> Another shenandoah bug with a fix in shared code.
>
> LRBRightAfterMemBar.test2() has 2 allocations that are non escaping
> but non scalarizable. As a result, the null check for a3.f is
> optimized out but the CastPP is left in the graph. That CastPP becomes
> control dependent on the o2 == null check which is later hoisted out
> of the loop. The CastPP is then right after the membar of the barrier = 0x42
> volatile access but with an out of loop control. Because the node is
> considered pinned by loopopts, it is assigned the membar as
> control. The input of the CastPP is a shenandoah barrier that's
> sandwiched between the membar and the CastPP and so expanded right
> after the membar (that is between the membar and its control
> projection). That causes the crash. I don't think cast nodes need to
> be pinned so I propose that as a fix.

Anyone for this (simple) change to shared c2 code?

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

PR: https://git.openjdk.java.net/jdk/pull/2400
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8260637: Shenandoah: assert(_base == Tuple) failure during C2 compilation

Christian Hagedorn-3
In reply to this post by Roland Westrelin-4
On Thu, 4 Feb 2021 08:34:04 GMT, Roland Westrelin <[hidden email]> wrote:

> Another shenandoah bug with a fix in shared code.
>
> LRBRightAfterMemBar.test2() has 2 allocations that are non escaping
> but non scalarizable. As a result, the null check for a3.f is
> optimized out but the CastPP is left in the graph. That CastPP becomes
> control dependent on the o2 == null check which is later hoisted out
> of the loop. The CastPP is then right after the membar of the barrier = 0x42
> volatile access but with an out of loop control. Because the node is
> considered pinned by loopopts, it is assigned the membar as
> control. The input of the CastPP is a shenandoah barrier that's
> sandwiched between the membar and the CastPP and so expanded right
> after the membar (that is between the membar and its control
> projection). That causes the crash. I don't think cast nodes need to
> be pinned so I propose that as a fix.

Looks reasonable to me!

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

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2400
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8260637: Shenandoah: assert(_base == Tuple) failure during C2 compilation

Vladimir Kozlov-2
In reply to this post by Roland Westrelin-4
On Thu, 4 Feb 2021 08:34:04 GMT, Roland Westrelin <[hidden email]> wrote:

> Another shenandoah bug with a fix in shared code.
>
> LRBRightAfterMemBar.test2() has 2 allocations that are non escaping
> but non scalarizable. As a result, the null check for a3.f is
> optimized out but the CastPP is left in the graph. That CastPP becomes
> control dependent on the o2 == null check which is later hoisted out
> of the loop. The CastPP is then right after the membar of the barrier = 0x42
> volatile access but with an out of loop control. Because the node is
> considered pinned by loopopts, it is assigned the membar as
> control. The input of the CastPP is a shenandoah barrier that's
> sandwiched between the membar and the CastPP and so expanded right
> after the membar (that is between the membar and its control
> projection). That causes the crash. I don't think cast nodes need to
> be pinned so I propose that as a fix.

Ok

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2400
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8260637: Shenandoah: assert(_base == Tuple) failure during C2 compilation

Roland Westrelin-4
On Tue, 23 Feb 2021 16:29:59 GMT, Vladimir Kozlov <[hidden email]> wrote:

>> Another shenandoah bug with a fix in shared code.
>>
>> LRBRightAfterMemBar.test2() has 2 allocations that are non escaping
>> but non scalarizable. As a result, the null check for a3.f is
>> optimized out but the CastPP is left in the graph. That CastPP becomes
>> control dependent on the o2 == null check which is later hoisted out
>> of the loop. The CastPP is then right after the membar of the barrier = 0x42
>> volatile access but with an out of loop control. Because the node is
>> considered pinned by loopopts, it is assigned the membar as
>> control. The input of the CastPP is a shenandoah barrier that's
>> sandwiched between the membar and the CastPP and so expanded right
>> after the membar (that is between the membar and its control
>> projection). That causes the crash. I don't think cast nodes need to
>> be pinned so I propose that as a fix.
>
> Ok

@vnkozlov @chhagedorn thanks for the reviews

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

PR: https://git.openjdk.java.net/jdk/pull/2400
Reply | Threaded
Open this post in threaded view
|

Integrated: 8260637: Shenandoah: assert(_base == Tuple) failure during C2 compilation

Roland Westrelin-4
In reply to this post by Roland Westrelin-4
On Thu, 4 Feb 2021 08:34:04 GMT, Roland Westrelin <[hidden email]> wrote:

> Another shenandoah bug with a fix in shared code.
>
> LRBRightAfterMemBar.test2() has 2 allocations that are non escaping
> but non scalarizable. As a result, the null check for a3.f is
> optimized out but the CastPP is left in the graph. That CastPP becomes
> control dependent on the o2 == null check which is later hoisted out
> of the loop. The CastPP is then right after the membar of the barrier = 0x42
> volatile access but with an out of loop control. Because the node is
> considered pinned by loopopts, it is assigned the membar as
> control. The input of the CastPP is a shenandoah barrier that's
> sandwiched between the membar and the CastPP and so expanded right
> after the membar (that is between the membar and its control
> projection). That causes the crash. I don't think cast nodes need to
> be pinned so I propose that as a fix.

This pull request has now been integrated.

Changeset: 8a2f5890
Author:    Roland Westrelin <[hidden email]>
URL:       https://git.openjdk.java.net/jdk/commit/8a2f5890
Stats:     33 lines in 2 files changed: 27 ins; 0 del; 6 mod

8260637: Shenandoah: assert(_base == Tuple) failure during C2 compilation

Reviewed-by: chagedorn, kvn

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

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