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

Roland Westrelin roland at openjdk.java.net
Tue Feb 23 16:37:40 UTC 2021


On Tue, 23 Feb 2021 16:29:59 GMT, Vladimir Kozlov <kvn at openjdk.org> 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


More information about the hotspot-compiler-dev mailing list