RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups() can lock up target VM [v2]

[Chris Plummer]

On Wed, 26 Mar 2025 19:11:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use explicit array copying code. Better comment.
>
> test/jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java line 83:
> 
>> 81:     public void classPrepared(ClassPrepareEvent event) {
>> 82:         try {
>> 83:             ++classPreparedCount;
> 
> It's a long time since I looked at at test based on TestScaffold. Would I be correct to say that it creates an event  handler thread to remove events from the event queue and dispatch them to the registered listeners? Only asking as it's not immediately clear if the increment of the event count is correct. I think TestScaffold uses one thread but would need to dig into the test infra to be sure.

Yes, one EventHandler thread dispatching to all listeners. More details below:

There is an interface called TargetListener which declares all the event callbacks. TargetAdapter implements TargetListener and provides and empty implementation for each callback. TestScaffold extends TargetAdapter, and each test extends TestScaffold. So every test has default empty implementations of all the callbacks, and can override some (there are a couple of overrides in this tests).

A TargetListener instance gets events by adding itself as a listener using TestScaffold.addListener(). You can see that this test is doing that early on so it gets events.

In addition, some of the TestScaffold APIs will create an instance of a TargetAdapter with one or more event callback overrides, and register that listener. For example, see waitForRequestedEvent(). So it is possible to have 2 or more listeners registered, although as I just pointed out in [JDK-8352759](https://bugs.openjdk.org/browse/JDK-8352759), that can be problematic at times.

TestScaffold always has an EventHandler thread active (and only one). It sits in a loop calling EventQueue.remove(). For any each EventSet received it will iterate over each Event in the EventSet, and for each registered listener, it will call the listener's event callback for that Event.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24236#discussion_r2014962541