On Fri, 3 Jul 2026 02:28:06 GMT, David Holmes <[email protected]> wrote:
> Sorry Patricio but I found the refactoring completely obscured the fix for > me. There are too many closures and apparent handshakes that make the control > flow very difficult to see, and I can't see where the code in `StopThread` > went to - e.g. `get_threadOop_and_JavaThread` - is it hidden on one of the > existing handshake classes? Can we split this out to do the refactor first, > then apply the unsafe checks? > `StopThreadClosure` is the synchronous handshake that replaces `InstallAsyncExceptionHandshakeClosure`. `StopThreadAsyncClosure` is the async part executed by the target. It just subclasses `AsyncExceptionHandshakeClosure` to add extra logic specific for `StopThread` (currently only extra checks). These sync/async closures are the equivalent of `CloseScopedMemoryHandshakeClosure` and `ScopedAsyncExceptionHandshakeClosure` for the scoped memory usage of asynchronous exceptions. The call to `JvmtiHandshake::execute` contains the other logic you are looking for (`get_threadOop_and_JavaThread `, `MountUnmountDisabler`, etc). It is refactored there because it is shared with other JVMTI operations. Inside that method we call `Handshake::execute` to execute the synchronous handshake part (`StopThreadClosure`). I can file a new bug and separate this refactoring part first if you prefer though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31759#issuecomment-4872432075
