On Thu, 6 Apr 2023 15:49:27 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The >> APIs that were preview APIs in Java 19/20 are changed to permanent and their >> `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The >> JNI and JVMTI versions are bumped as this is the first change in 21 to need >> the new version number. A lot of tests are updated to drop `@enablePreview` >> and --enable-preview. >> >> There is one API change from Java 19/20, the preview API >> Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an >> update to the JVMTI GetThreadInfo implementation to read the TCCL >> consistently. >> >> In addition, there are a small number of implementation changes to sync up >> from the loom fibers branch: >> >> - A number of stack frames are `@Hidden` to reduce noise in the stack >> traces. This exposed a few issues with the stack walker code. More >> specifically, the cases where end of a continuation falls precisely at the >> end of the batch, or where the remaining frames are hidden, weren't handled >> correctly. >> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in >> Thread rather than in two classes. >> - A few robustness improvements for OOME and SOE. There is more to do here, >> for future PRs. >> - New system property to print a stack trace when a virtual thread sets its >> own value of a TL. >> - ThreadPerTaskExecutor is changed to use FutureTask. >> >> Testing: tier1-6. > > Alan Bateman has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains 11 additional > commits since the last revision: > > - Test/comments updates > - Merge > - Expand tests for jdk.ThreadSleep event > - Review feedback > - Merge > - Fix ThreadSleepEvent again > - Test updates > - ThreadSleepEvent refactoring > - Merge > - Merge > - ... and 1 more: https://git.openjdk.org/jdk/compare/7adf8162...a5bb3fd9 src/java.base/share/classes/java/lang/ThreadLocal.java line 825: > 823: // switch to carrier thread to avoid recursive use of > thread-locals > 824: vthread.executeOnCarrierThread(() -> { > 825: System.out.println(vthread); Hello Alan, as far as I have seen, much of a our debug logs/stacktrace in the JDK uses `System.err` to write them out. For example, `Thread.dumpStack()`, then even `java.security.debug` logging and many such places. Is it intentional that this tracing here uses `System.out` instead? src/java.base/share/classes/java/lang/ThreadLocal.java line 832: > 830: }); > 831: } catch (Exception e) { > 832: throw new InternalError(e); Should inability to log/trace `ThreadLocal` creation or `set` lead to those operations failing? Or would it be OK, if we just ignored this exception that happened when tracing/logging? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160468749 PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160469548
