RFR: 8257831: Suspend with handshakes [v10]

Robbin Ehn rehn at openjdk.java.net
Mon Apr 19 07:29:59 UTC 2021


On Mon, 19 Apr 2021 04:43:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed nits
>
> src/hotspot/share/runtime/handshake.hpp line 157:
> 
>> 155:   Thread* active_handshaker() const { return _active_handshaker; }
>> 156: 
>> 157:   // Suspend/resume support
> 
> Taking a step back I can't help but think that this is entirely the wrong place to have the suspend/resume API and supporting code. It is only here because we re-use the HandshakeState _lock monitor right? If we introduced a new thread-suspension monitor instead then this code would all reside somewhere else - probably in the JavaThread class.

When going to blocked inside the async handshake we **must** unlock the HandshakeState lock.
Thus _lock.wait() unlocks and gives us something to notify.
We could do:

_lock.unlock();
{
  MutexLocker(SomeOtherLock) ml;
  SomeOtherLock.wait();
}
_lock.lock();


Another alternative is to create a friend class which uses the HandshakeState lock and having the API there instead.

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

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


More information about the serviceability-dev mailing list