RFR: 8355214: nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter001.java should use JDIBase superclass

[Leonid Mesnik]

On Wed, 23 Apr 2025 04:10:24 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> There is nsk/jdi superclass called JDIBase that many tests inherit from. It provides common functionality like log support, basic event handling, support for setting a breakpoint, and support for the communcation breakpoint that the debugger and debuggee used to synchronize with. addthreadfilter001 does not inherit from JDIBase and instead implements all this functionality in the test. The reason is because it provides a slightly modified version of the JDIBase.breakpointForCommunication() method.
> 
> 
>                 } else if (event instanceof ThreadStartEvent) {
>                     // It might be the case that while the thread start request was enabled
>                     // some threads not related to the test ( e.g. JVMCI threads) were started
>                     // and generated thread start events. We ignore these thread start events
>                     // and keep waiting for a breakpoint event.
>                     ThreadStartEvent tse = (ThreadStartEvent) event;
>                     log2("ThreadStartEvent is received while waiting for a breakpoint" +
>                             " event, thread: : " + tse.thread().name());
>                     continue;
>                 }
> 
> 
> However, this code seems to predate adding similar code to the JDIBase version of breakpointForCommunication():
> 
> 
>             if (EventFilters.filtered(event)) {
>                 // We filter out spurious ThreadStartEvents
>                 continue;
>             }
> 
> 
> The test now uses JDIBase and gets rid of the replicated code that is already in JDIBase. It is also updated to use the new JDIBase.breakpointForCommunication() method. 
> 
> Note: The code in the test mentions JVMCI and the CR mentions graal, so this test likely originally failed due to the creation of a graal compiler thread.  EventFilters.filtered() was not handling this thread name, which can have various names but always contains "Compiler", so I updated it the method to also filter out "Compiler" methods.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24812#pullrequestreview-2788308908