On Wed, 23 Apr 2025 04:10:24 GMT, Chris Plummer <cjplum...@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
