[14] RFR(S): 8228772: C2 compilation fails due to unschedulable graph if DominatorSearchLimit is reached

Tobias Hartmann tobias.hartmann at oracle.com
Mon Aug 5 07:25:50 UTC 2019

Hi Nils,

On 31.07.19 11:21, Nils Eliasson wrote:
> Your patch looks good, and I seek no change to the patch, but I would like to take the opportunity
> to gain some additional insight.

Thanks for the review!

> Doesn't the memory graph look a bit strange? If the load is control dependent on the membar, and the
> membar creates a new memory state, shouldn't the load actually use that state?

Yes, that's the case before EA:

But once EA figures out that the array allocation does not escape, it creates a memory Phi for that
slice (6006), and re-wires the load to use that memory:

I think the code that does this is ConnectionGraph::find_inst_mem which steps through membars.

> The basic assumption is that for all memory ops using the same memory state, all loads must precede
> any store. This case breaks that. We should investigate why the IR ends up like this and if it is
> actually correct.

Right. Semantically, the IR seems correct to me though.

Best regards,

More information about the hotspot-compiler-dev mailing list