[13] 8221592: C2 compilation failed with assert(!q->is_MergeMem())

[Vladimir Ivanov]

src/hotspot/share/opto/parse1.cpp:

+  _gvn.transform(_exits.merged_memory());

I'm curious why the node isn't put on worklist when it is 
created/modified. It seems it should have solved the problem.

Also, the code around usually does it a bit differently. For example, 
Parse::do_all_blocks():

         Node* result = _gvn.transform_no_reclaim(control());
	...
         if (result != top()) {
           record_for_igvn(result);

Best regards,
Vladimir Ivanov

On 26/04/2019 05:14, Tobias Hartmann wrote:
> Hi,
> 
> please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8221592
> http://cr.openjdk.java.net/~thartmann/8221592/webrev.00/
> 
> We hit an assert during parsing with incremental inlining when merging memory edges into a target
> block because of a MergeMem that has another MergeMem as input. I've traced the MergeMem back to
> this code:
> http://hg.openjdk.java.net/jdk/jdk/file/47a8fdf84424/src/hotspot/share/opto/parse1.cpp#l1028
> 
> The memory input of the _exit map is a MergeMem with a useless Phi input that has another MergeMem
> as input (see bug comments for details). After calling transform on this slice, the Phi is removed
> and we end up with a MergeMem that is then set as input to the original MergeMem. This later
> triggers the assert.
> 
> The proposed fix is to transform the original MergeMem after transforming the slices to get rid of
> MergeMem inputs.
> 
> The problem only shows up with the fix for JDK-8059241 [1] which reduced the number of times
> PhaseRemoveUseless is executed with incremental inlining. I don't think it's related though but just
> triggers the bug.
> 
> Tested with multiple runs of the microbenchmark that triggered the assert and
> hs-tier1,hs-tier2,hs-tier3,hs-precheckin-comp,jdk-tier1,jdk-tier2,jdk-tier3 (running).
> 
> Thanks,
> Tobias
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8059241
>