On Tue, 20 Oct 2020 02:28:35 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> The main point of this change-set is to make it easier to implement S/R on >> top of handshakes. >> Which is a prerequisite for removing _suspend_flag (which duplicates the >> handshake functionality). >> But we also remove some complicated S/R methods. >> >> We basically just put in everything in the handshake closure, so the diff >> just looks much worse than what it is. >> >> TraceSuspendDebugBits have an ifdef, but in both cases it now just returns. >> But I was unsure if I should remove now or when is_ext_suspend_completed() >> is removed. >> >> Passes multiple t1-5 runs, locally it passes many >> jck:vm/nsk_jvmti/nsk_jdi/jdk-jdi runs. > > Hi Robbin, > > IIUC the "waiting" part of `wait_for_ext_suspend_completion` is now > implicitly handled in the handshake - correct? > > Overall this seems like a great simplification. > > A few minor comments below. > > Thanks, > David Hi David, thanks for having a look. > Hi Robbin, > > IIUC the "waiting" part of `wait_for_ext_suspend_completion` is now > implicitly handled in the handshake - correct? A suspended Java thread may never transition back to java, never execute any more bytecodes. The old 'fully' suspended gives more guarantees which we need to do some operations. When we are in a handshake, the handshake gives us those guarantees, so it is enough that thread is considered suspended. So the answer is we wait until we are allowed to execute those operations (thread handshake safe), which is not identical with fully suspended. But fully suspended is an implementation detail, the agent only knows about suspended. > > Overall this seems like a great simplification. > > A few minor comments below. > > Thanks, > David ------------- PR: https://git.openjdk.java.net/jdk/pull/729
