RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake()

Richard Reingruber rrich at openjdk.java.net
Mon Oct 12 17:23:17 UTC 2020


On Mon, 12 Oct 2020 16:28:17 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> I thought about removing that check, but right now it's also preventing an
> escape from a suspend. The issue is that when going back to java, we always
> check if we were suspended and call java_suspend_self_with_safepoint_check()
> if true. After the do-while(is_external_suspend()) loop we call again
> SafepointMechanism::process_if_requested(this) to see if we need to stop for a
> safepoint/handshake. If there is an actual safepoint pending because of a
> VM_ThreadSuspend() then unless we keep that check the thread will not notice
> it was suspended after the safepoint and will go back to java.

I meant the block could be removed if we put
ThreadInVMfromJava/ThreadInVMfromJava (TIVFJ) into
handle_polling_page_exception(). In that case the thread would notice and honor
the suspend when leaving the TIVFJ block. This would not be too late, would it?

> Now, I'm thinking the call to SafepointMechanism::process_if_requested(this)
> in java_suspend_self_with_safepoint_check() should be moved inside the the
> do-while(is_external_suspend()). That way we guarantee after returning from
> java_suspend_self_with_safepoint_check() that no one will be assuming the
> thread is suspended. And in that case I think that check in SS::block can be
> removed.

Yes I agree.

Well, I don't want to spam your PR with too many questions / comments. The
change still looks good to me.

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

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


More information about the hotspot-runtime-dev mailing list