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

[Vladimir Ivanov]

The fix looks good.

Does it worth to extract repetitive code [1] [2] into a helper method?

Best regards,
Vladimir Ivanov

[1]
      C->gvn_replace_by(callprojs.fallthrough_memproj,   final_mem);
+    if (final_mem->is_MergeMem()) {
+      // Keep track of MergeMems feeding into other MergeMems
+      for (SimpleDUIterator i(final_mem); i.has_next(); i.next()) {
+        Node* use = i.get();
+        if (use->is_MergeMem()) {
+          wl.push(use);
+        }
+      }
+    }

[2]
+      C->gvn_replace_by(callprojs.catchall_memproj,   ex_mem);
+      if (ex_mem->is_MergeMem()) {
+        // Keep track of MergeMems feeding into other MergeMems
+        for (SimpleDUIterator i(ex_mem); i.has_next(); i.next()) {
+          Node* use = i.get();
+          if (use->is_MergeMem()) {
+            wl.push(use);
+          }
+        }
+      }


On 22/05/2019 12:35, Tobias Hartmann wrote:
> Hi,
> 
> please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8223581
> http://cr.openjdk.java.net/~thartmann/8223581/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. The root cause is the same as with
> 8221592 [1]: After the fix for 8059241 [2], we don't always execute a round of PhaseRemoveUseless /
> IGVN after incremental inlining and as a result, MergeMems that feed into other MergeMems are not
> cleaned immediately (but they are on the IGVN worklist and will be cleaned up eventually).
> 
> To not confuse the parser, we need to remove them eagerly. This is already done in
> GraphKit::replace_call() for the non-exceptional memory edge but the implementation misses to also
> handle the exceptional case.
> 
> Instead of a Node_List, I'm now using a Unique_Node_List to avoid the costly contains() call that
> has O(n) complexity.
> 
> I've verified the fix by many runs of the api/java_lang JCK tests and testing on relevant tiers.
> 
> Thanks,
> Tobias
> 
> [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-April/033505.html
> [2] https://bugs.openjdk.java.net/browse/JDK-8059241
>