RFR: 8286830: ~HandshakeState should not touch oops

Patricio Chilano Mateo pchilanomate at openjdk.java.net
Mon May 23 15:31:41 UTC 2022


On Mon, 23 May 2022 02:37:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > But there could still be synchronous operations remaining or about to be added to the queue, again even though the closures won't be executed. In fact we could have some other async operation added to the queue after that
> 
> Sorry I'm not clear on the exact details. But a handshake requires the target thread to respond to the handshake request (that is afterall the "handshake" part of it). Once a thread starts to exit it will/should no longer respond to any handshake requests (sync or async) so the submitter of such a request must be polling for the target thread to either acknowledge the handshake or else indicate it is exiting; if the latter then the submitter abandons the handshake request because the target is considered dead. Are you saying that the submitter actually installs the op in the target's queue even if never acknowledged by the target (due to it exiting)?
>
Yes, the handshaker just checks if the target is included in the thread list it created. If it is included, it adds the operation to the queue. Then it will loop calling HandshakeState::try_process() until the operation is processed(which doesn't mean the closure will actually be executed). So until the target removes itself form the active threads list new operations could be added to the queue. If we want to avoid that and check the terminated status too then we would need to add extra locking to the add operation, but I don't think that's what we want.

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

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


More information about the hotspot-runtime-dev mailing list