[9] RFR (S): 8033626: assert(ex_map->jvms()->same_calls_as(_exceptions->jvms())) failed: all collected exceptions must come from the same place

[Vladimir Kozlov]

Looks good.

Essentially the fix does the same as for case Bytecodes::_athrow: in 
parse2.cpp.

Thanks,
Vladimir

On 6/9/14 9:58 AM, Vladimir Ivanov wrote:
> https://bugs.openjdk.java.net/browse/JDK-8033626
> http://cr.openjdk.java.net/~vlivanov/8033626/webrev.01/
>
> For polymorphic case of Object::clone call site, call generator of the
> following shape is used:
>    PredictedCallGenerator
>      _if_hit: LibraryIntrinsic (LibraryCallKit::inline_native_clone)
>      _if_missed: VirtualCallGenerator
>
> The problem is that Object::clone intrinsic is generated with
> reexecute=true, while the branch with virtual dispatch has reexecute=false.
>
> The fix is to bail out to interpreter if any exception is encountered.
> There's no need to update exception state. When reexecuting the call,
> native version of Object::clone (JVM_Clone) will be invoked.
>
> Controlling exception handling explicitly by passing
> deoptimize_on_exception parameters looks cleaner to me, than having a
> check (is_LibraryCallKit() or JVMS reexecute bit) burden in
> GraphKit::make_slow_call_ex.
>
> I fixed only Object::clone case, since I don't see other places where
> similar IR shape can be produced.
>
> Also, I didn't touch array cloning case because I don't see any
> possibility to have a polymorphic Object::clone call site for arrays
> (it's not the case for object arrays of different types and primitive
> arrays can't be intermixed with object arrays).
>
> Testing: regression tests, jprt, CTW, manual (instrumented JVM which
> always throws OOM from OptoRuntime::new_instance_C)
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov