On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman <al...@openjdk.org> wrote:
> Degrade Thread.suspend/resume to throw UOE unconditionally. > > Another step in the removal of this deadlock prone mis-feature from the > user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 > (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume > were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume > continues to work for platform threads but throws UOE for virtual threads. > The next step is to degrade both methods to throw UOE for all threads. A > corpus search of 19M classes in 113k JAR files found only 22 classes using > these methods so this change is unlikely to be disruptive. > > The change requires some minor adjustments to the JVM TI and JDWP > specifications, and a minor update to the JDI docs. > > Leonid Mesnik is working on > [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the > last few usages of Thread.suspend/resume from the hotspot tests (most of > these can use JVMTI SuspendThread/ResumeThread). Code changes look fine, though I didn't look too closely at the JDWP and JVMTI stuff. Nice use of JUnit. Not a big deal, but I could see leaving the links from `Thread::suspend` et. al. to the "Why deprecated?" doc, and then updating that doc to make it clear that the mechanisms have in fact been removed, but leaving the rationale that's there mostly in place. Might also be useful in the CSR to re-emphasize that this does not affect the ability to suspend and resume threads through the debugging interfaces. Of course the specs in those areas need to be updated so they no longer deal with the case of a thread that's been suspended through the API, but the debugging mechanisms' functions themselves are unchanged. ------------- PR: https://git.openjdk.org/jdk/pull/10324
