RFR: 8304919: Implementation of Virtual Threads [v6]

[Jaikiran Pai]

On Thu, 6 Apr 2023 15:49:27 GMT, Alan Bateman <alanb at 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/c2ee11c7...a5bb3fd9

test/jdk/java/lang/Thread/virtual/TraceVirtualThreadLocals.java line 52:

> 50:             name.get();
> 51:         });
> 52:         assertContains(output, "java.lang.ThreadLocal.get");

Should it also assert the presence of `ThreadLocal.setInitialValue` in the stacktrace?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160508153