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

[Patricio Chilano Mateo]

On Fri, 28 Jan 2022 05:51:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

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

I think that check was a side effect of using the wrapper. Otherwise why would it not be needed for the other cases when we don't hit that conditional path? We are always going back to Java.

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

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