On Wed, 31 Mar 2021 06:08:49 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> Robbin Ehn has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains two commits:
>>
>> - Merge branch 'master' into SuspendInHandshake
>> - 8257831: Suspend with handshake (review baseline)
>
> src/hotspot/share/runtime/objectMonitor.cpp line 411:
>
>> 409: OrderAccess::storestore();
>> 410: for (;;) {
>> 411: current->set_thread_state(_thread_blocked);
>
> So IIUC because ThreadblockInVM is now responsible for handling thread
> suspension checks, but those checks need to be done at a lower level, we can
> no longer use ThreadBlockInVM in some places. That both undermines the value
> of ThreadBlockInVM and make this manual management code much more complex.
> I agree with Richard that a TBIVM that took an unlock function would make
> this kind of code much clearer.
The problem is the we lock the OM from blocked state and then regret it.
Since we should not execute 'bytecode' during safe state but this
implementation does that we end up in this mess.
If this implementation did the correct thing we could use ThreadblockInVM
straight forward.
As I suggested if we are only blocked around parker it fixes it.
The reason for grabbing the lock is that we cannot call exit on the OM which
wakes next thread.
Only the owner may call exit, this makes succession more complicate because you
might wake a suspended thread.
Now the suspended thread needs to wake another thread without owning the lock.
And yes adding a method ThreadBlockInVM can help here.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3191
