Regarding 8033626: C2: Merging exception state: reexecute=true vs reexecute=false

[Vladimir Ivanov]

Hi,

I'm looking at 8033626 [1]: 
"assert(ex_map->jvms()->same_calls_as(_exceptions->jvms())) failed: all 
collected exceptions must come from the same place".

8014447 [2] introduced new code shape for virtual intrinsifiable methods 
(Object::hashCode & Object::clone): "invokevirtual Object.clone()" can 
be represented as a PredictedCallGenerator with LibraryIntrinsic on fast 
path and VirtualCallGenerator on slow path.

The problem arises for Object::clone, because for OOM case intrinsified 
version requires reexecution (reexecute=true), but slow path (virtual 
dispatch) doesn't (reexecute=false). Further attempt to finish the 
diamond and merge 2 exception states fires the assertion.

So, I have 2 questions:
   (1) I don't see any way to merge reexecute=true & reexecute=false 
states, so both branches should have the same reexecute status. Am I 
missing something?

   (2) Does PredictedCallGenerator actually support such shape 
(intrinsic on fast path)? There are 2 call generators: 
PredictedIntrinsicGenerator & PredictedCallGenerator. What's the 
difference?

I see there's a way to customize predicate in 
LibraryCallKit::try_to_predicate() for PredictedIntrinsicGenerator, but 
is it the only reason why PredictedIntrinsicGenerator was introduced?

Best regards,
Vladimir Ivanov

[1] https://bugs.openjdk.java.net/browse/JDK-8033626

[2] https://bugs.openjdk.java.net/browse/JDK-8014447
     "Object.hashCode intrinsic breaks inline caches"