RFR: 8355569: Some nsk/jdi tests can glean the "main" thread by using the ClassPrepareEvent for the debuggee main class [v3]

[Chris Plummer]

On Mon, 28 Apr 2025 19:09:59 GMT, Chris Plummer <cjplummer at 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