RFR: 8273143: Transition to _thread_in_vm when handling a polling page exception [v2]
Patricio Chilano Mateo
pchilanomate at openjdk.java.net
Wed Jan 26 15:10:35 UTC 2022
On Mon, 17 Jan 2022 05:32:02 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Fix copyrights to 2022
>
> 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.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7009
More information about the hotspot-runtime-dev
mailing list