RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v5]

[Robbin Ehn]

On Thu, 5 Nov 2020 23:48:19 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Thanks for the updates! All LGTM.
>> 
>> David
>
>> Thanks for the updates! All LGTM.
>> 
>> David
> Great, thanks David!
> 
> Patricio

> {
> ThreadInVMfromJava tivm;
> }
> 
> which transitions from Java to VM and back, for absolutely no reason
> other than to get the side-effects of doing those transitions.

As I see it, if you have an oop map and are executing in VM, you are technically in VM.
But here we skip going to VM since SS:block used to need to know where you are going back to due to suspend flag is handle inside SS:block().
And the safepoint synchronizer will treat java/vm the same thus we can cheat.

If the thread is in Java it is not guaranteed that it will have an oop map and it's not certain that it can be made walkable.
Being blocked requires you to be walkable, thus going from java->blocked cannot be done as general rule.
Instead of having a ton of special rules which no one can remember, the rule is you can only block in VM where we know you can be made walkable.

Polling page exception handling can thus been seen as a cheat avoiding setting in vm since it will actually have no effect on the safepoint synchronizer.

So no we are not looking for side-effects, we need to be in VM (at minimum technically) to become blocked.
Thus the rules for going from VM to Java applies, and we should deliver e.g. async exceptions.

{
  ThreadInVMfromJava tivm;
  SS:block()
}

Would be the preferred way of doing it.

> 
> David
> -----

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

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