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

[Tobias Hartmann]

Hi Roland,

as we've discussed off-thread, considering the CMove as unpinned seems reasonable because it does
not have any (side-)effects that would not be explicit in the graph.

Still wondering why the CMove then has a control input in the first place but your change looks good
to me. I'll run some testing.

Best regards,
Tobias

On 13.01.20 11:20, Roland Westrelin wrote:
> 
> http://cr.openjdk.java.net/~roland/8237007/webrev.00/
> 
> The assert fails because C2 expands a barrier between a membar and its
> control projection. That happens because the gc barrier is assigned the
> membar as control by loop optimizations (and not its control
> projection). The gc barrier has a load as input which itself depends on
> the memory state produced by the membar so the barrier has to be below
> the membar. The gc barrier has a CMove as use. That CMove has a control
> input that's above the membar and because it's considered pinned by loop
> opts, it's assigned earliest possible control: the membar. Considering
> the CMove as pinned is overly conservative AFAICT. My fix consists in
> excluding CMove nodes from being pinned.
> 
> Roland.
>