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

[David Holmes]

On Tue, 22 Sep 2020 03:13:04 GMT, Jamsheed Mohammed C M <jcm at openjdk.org> wrote:

>> 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.

Okay. I'm not familiar with that code at all so will leave this for compiler folk. Thanks.

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

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