RFR: 8273143: Transition to _thread_in_vm when handling a polling page exception [v2]

[David Holmes]

On Wed, 26 Jan 2022 15:07:47 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/safepoint.cpp line 973:
>> 
>>> 971:     // as otherwise we may never deliver it.
>>> 972:     if (self->has_async_exception_condition()) {
>>> 973:       ThreadInVMfromJava __tiv(self, false /* check asyncs */);
>> 
>> Hi Patricio,
>> The ThreadInVMfromJava destructor has some non-trivial actions that are now elided. It isn't obvious to me how we know they are not needed here. ??
>> 
>> Thanks,
>> David
>
> Hi David,
> 
>> Hi Patricio, The ThreadInVMfromJava destructor has some non-trivial actions that are now elided. It isn't obvious to me how we know they are not needed here. ??
>> 
> Sorry I was out on vacation. :)
> Since we are deoptimizing on the current thread we will call deoptimize_frame_internal() to patch the pc and there are no safepoint polls in that call so we don't need to check anything after it.
> Initially I thought this ThreadInVMfromJava wrapper was a left over from 6968367 which should have removed it after switching from using a VM op to deoptimizing the frame directly (https://github.com/openjdk/jdk/commit/1d8c677377bd6da16829de97ae2112279b70d93a#diff-688292e9695a95c2ac9a3228b2e946a3eba25fc08d893b733dfbfdf5840f9dd5). But biased locking code was still there at that time and I see the call to revoke_biases_of_monitors() in Deoptimization::deoptimize() could also issue a VM operation, so we still needed the wrapper to make sure we were in a thread_in_vm state and to check the special_runtime_exit_conditions after possibly being blocked during that call.

What about the stack_overflow_state check?

Thanks,
David

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

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