RFR: 8353955: nsk/jdi tests should be fixed to not always require includevirtualthreads=y

[Alex Menkov]

On Fri, 11 Apr 2025 23:23:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This is just a preliminary review. I'd like to get some approval for the approach I'm taking. There are over 300 tests that need to be fixed. I've just fixed a handful in this PR to give a feel for the changes I plan on making. If they look ok to you, then I'll update this PR with the needed changes to the rest of the tests.
> 
> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n. There are nearly 1200 nsk/jdi tests. Only about 350 actually need includevirtualthreads=y. I plan making includevirtualthreads=n the default for nsk/jdi tests unless the test does something to override the default and request includevirtualthreads=y.
> 
> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).

Used approach (call a special method of Binder class) is different from standard way of nsk framework to customize test settings.
Standard way assumes settings like this are specified in "@run" as an option (like "-includevirtualthreads=y" or "-includevirtualthreads"),
ArgumentHandler parses it (in this case maybe it should be parsed by nsk/share/jpda/DebugeeArgumentHandler.java) and provides a method to get the value,
Binder calls the method and sets connector argument.
I'm not a fun of this approach, but I think that handling different settings in different ways would make the code even harder to understand

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

PR Comment: https://git.openjdk.org/jdk/pull/24606#issuecomment-2811367443