RFR: 8253447: Remove buggy code introduced by 8249451 [v2]

[Erik Österlund]

On Tue, 22 Sep 2020 04:13:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Async-exception can be pending for Deoptimization::load_class_by_index(Java code executed case). This can happen for
>> C2/ and probably for JVMCI too.
>> https://github.com/openjdk/jdk/blob/d1f9b8a8b54843f06a93078c4a058af86fcc2aac/src/hotspot/share/runtime/deoptimization.cpp#L1964
>> In all cases deopt entries are equipped to handle pending exceptions.
>> In my previous code I incorrectly tried to handle it using Unpack_exception route. this can have implication that I am
>> at method entry and I don't handle locks properly.
>> now i simply leave it to the deopt entries to handle pending exceptions.
>
> Okay. I'm not familiar with that code at all so will leave this for compiler folk. Thanks.

So basically when you get here through the uncommon trap path, you have just called a JRT_ENTRY function and returned
from it by now. That means you can have an async exception installed as a pending exception. If you just leave it
there, the deopt entry of the interpreter will check for it and throw it. So we were already equipped to deal with
this, and that is what should happen. The code that clears the pending exception and sets the exception oop instead is
for when you are unwinding due to exception throwing into a deoptimized frame. The deopt handler is returned as
exception handler PC for such frames, and hence needs to quack like an exception handler. But that is not at all the
scenario we are in when we go through the uncommon trap; we are not in the middle of throwing an exception. Conversely,
we are just about to throw it - that difference is the crucial thing. So clearing the pending exception is likely to
just make it disappear (or crash later).

-------------

PR: https://git.openjdk.java.net/jdk/pull/292