RFR: 8300575: JVMTI support when using alternative virtual thread implementation [v3]

[Serguei Spitsyn]

On Thu, 16 Feb 2023 17:03:32 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Yes, the elist comment was related to the other issue. The reason why I didn't explicitly added this check is because it will we done in the suspend/resume call already (while holding the handshake lock which serializes the suspend/resume requests). So inside the suspend handshake for example either the target is suspended, so nothing is done, or the target is not suspended and we suspend it. Is there an actual issue I'm missing or is this to make a fast check and avoid the call? In any case I added the check. Also I see the specs for the single suspend/resume functions say the same thing about not changing the state and, for example, in SuspendThreadList we are also not making an explicit check before the call to suspend_thread(). So if there is an actual issue here, don't we need to add that check for them too?

I agree with your analysis. And you are right on the `SuspendThreadList` as well.
The `SuspendThreadList` also return an error code of each suspend in the result array.
It'd be nice to add a check there as well to make it consistent but I'd suggest to be conservative here and leave it as it is now.

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

PR: https://git.openjdk.org/jdk/pull/12512