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

Chris Plummer cjplummer at openjdk.org
Fri Apr 25 16:34:03 UTC 2025


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.

This pull request has now been integrated.

Changeset: 77f5a246
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/77f5a24648758cb1adc74056ca58f880af4a8e84
Stats:     167 lines in 3 files changed: 5 ins; 157 del; 5 mod

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

Reviewed-by: lmesnik, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/24812


More information about the serviceability-dev mailing list