RFR: 8336254: Virtual thread implementation + test updates

[Serguei Spitsyn]

On Tue, 16 Jul 2024 05:58:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Bringover some of the changes accumulated in the loom repo to the main line, most of these changes are test updates and have been baking in the loom repo for several months. The motive is partly to reduce the large set of changes that have accumulated in the loom repo, and partly to improve robustness and test coverage in the main line. The changes don't include any of the larger changes in the loom repo that are part of future JEPs.
>> 
>> Implementation:
>> - Robustness improvements to not throw OOME when unparking a virtual thread.
>> - Robustness improvements to reduce class loading when a virtual thread parks or parks when pinned (jdk.internal.misc.VirtualThreads is removed, jdk.internal.event.VirtualThreadPinnedEvent is eagerly loaded)
>> - VirtualThread changes to reduce contention on timer queues when doing timed-park
>> 
>> Tests:
>> - New tests for monitor enter/exit/wait/notify (this is a subset of the tests in the loom repo, we can't move many tests because they depend on on the changes to the object monitor implementation)
>> - New test infrastructure to allow tests use a custom scheduler. This updates many tests to make use of this infrastructure, the "local" ThreadBuidlers is removed.
>> - More test scenarios added to ThreadAPI and JVMTI GetThreadStateTest.java 
>> - New test for ThreadMXBean.getLockedMonitor with synchronized native methods
>> - Reimplement of JVMTI VThreadEvent test to improve reliability
>> - Rename some tests to get consistent naming
>> - Diagnostic output in several stress tests to help trace progress in the event of a timeout
>> 
>> Testing: tier1-6
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 273:
> 
>> 271:                 // current thread is a ForkJoinWorkerThread so the task will be pushed
>> 272:                 // to the local queue. For other schedulers, it avoids deadlock that
>> 273:                 // would arise due to platform and virtual threads contenting for a
> 
> s/contenting/contending/

Also noticed this typo. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20143#discussion_r1682450204