On Wed, 25 Oct 2023 21:08:01 GMT, Leonid Mesnik <lmes...@openjdk.org> wrote:
> The jtreg starts the main thread in a separate ThreadGroup and checks > unhandled exceptions for this group. However, it doesn't catch all unhandled > exceptions. There is a jtreg issue for this > https://bugs.openjdk.org/browse/CODETOOLS-7903526. > Catching such issues for virtual threads is important because they are not > included in any groups. So this fix implements the handler for the test > thread factory. > > A few tests start failing. > > The test > serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorVMEventsTest.java > has testcases for platform and virtual threads. So, there is there's no need > to run it with the thread factory. > > The test > java/lang/Thread/virtual/ThreadAPI.java > tests UncaughtExceptionHandler and virtual threads. No need to run it with a > thread factory. > > Test > test/jdk/java/util/concurrent/tck/ThreadTest.java is updated to not check the > default empty handler. > > Probably, we need some common approach about dealing with the > UncaughtExceptionHandler in jtreg. Having a UHE invoke System.exit is surprising. Are you saying that this is only for cases where a test launches a child VM with the thread factory set? Stepping back a bit. ThreadGroup is legacy and we eventually want it to go away. We've been deprecating and degrading it very slowly over many releases. So I think jtreg will eventually need to change. Right now, it creates AgentVMThreadGroup for agent VM mode so it controls the UHE where it starts the "main thread". I think it will eventually need to change this to set the system-wide UHE but this means it would handling uncaught exception thrown by "system threads", we may have to audit some of the exception handling if things come out of the woodwork. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16369#issuecomment-1780660022
