Problem list the remaining 4 JDI tests that started to fail with the added support for more debuggee threads being created as vthreads. The failures are all well understood and documented in the problemlist comments.

Author: plummercj

test/hotspot/jtreg/ProblemList-vthread.txt

@@ -549,6 +549,25 @@ vmTestbase/nsk/jdi/stress/serial/forceEarlyReturn002/TestDescription.java
 
 vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java
 
+###
+# The test fails because it tries to call Thread.setDaemon(false) on a vthread, which is not
+# supported (vthreads are always daemon). It seems the only reason the test does this is because
+# it has a mix of what it refers to as "user and daemon threads", since it wants to test both.
+# It should be ok to just skip the setDaemon call for vthreads.
+vmTestbase/nsk/jdi/EventRequestManager/stepRequests/stepreq001/TestDescription.java
+
+###
+# These 2 tests try to create 10 vthreads and have them all block on a synchornized
+# method call, but on some hosts there are not enough cthreads to support pinning
+# all 10 vthreads, so the test deadlocks. -Djdk.defaultScheduler.parallelism=<n>
+# could be used with the debuggee to ensure there are enough vthreads.
+vmTestbase/nsk/jdi/EventRequestManager/stepRequests/stepreq002/TestDescription.java
+vmTestbase/nsk/jdi/EventRequestManager/deleteEventRequests/delevtreqs002/TestDescription.java
+
+###
+# The test relies on the underlying JVMTI GetObjectMonitorUsage() API, which currently
+# does not support vthreads, and will claim the cthread is owner of the monitor.
+vmTestbase/nsk/jdi/ObjectReference/owningThread/owningthread002/TestDescription.java
 
 ####
 ## NSK JMX Tests