On Mon, 28 Apr 2025 19:09:59 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> As part of the work for >> [JDK-8353955](https://bugs.openjdk.org/browse/JDK-8353955) I am reducing the >> number of tests that need to be run with includevirtualhreads=y due to using >> JDI to lookup threads in the debuggee. There are many tests that lookup the >> "main" thread. They can instead glean the "main" thread from the >> ClassPrepareEvent for the debuggee main class. Some tests already wait for >> this ClassPrepareEvent, and can take advantage of it. Most do not, but can >> be made to do so. The easiest way to do this for many of the tests is to >> wait for the event in Debuggee.prepareDebuggee() after having called >> Debuggee.bindToDebuggee(). For tests that don't call >> Debuggee.prepareDebuggee(), waiting for the ClassPrepareEvent was added >> after the bind. This doesn't seem to have any ill affect on the tests. >> >> Tested by running all nsk/jdi tests, including all tier2, tier3, and tier5 >> nsk/jdi testing. > > Chris Plummer has updated the pull request incrementally with one additional > commit since the last revision: > > found one more test to fix test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/hashCode/hashcode001.java line 121: > 119: > 120: case 0: > 121: ThreadReference thread = debuggee.mainThread(); This one is not so obvious until you look earlier in the file and see: ``` private final static String methodName = "main";``` So `methodName` is "main". Probably should have always explicitly used "main" here instead, but with this change it's gone anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24867#discussion_r2064350370
