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

[Jamsheed Mohammed C M]

On Tue, 22 Sep 2020 02:35:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jamsheed Mohammed C M has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing the assert message too
>
> src/hotspot/share/runtime/deoptimization.cpp line 531:
> 
>> 529: #endif
>> 530:
>> 531:   if (thread->frames_to_pop_failed_realloc() > 0 && exec_mode != Unpack_uncommon_trap) {
> 
> I'm not at all clear on whether an async-exception could be pending at this point. The original change indicated it
> could be, but now you are saying it can't. How is that known?

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.

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

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