On Wed, 5 Oct 2022 01:49:29 GMT, David Holmes <dhol...@openjdk.org> wrote:
> This is crude but probably sufficient - and I don't know if there is any way > to know for sure that it is okay to proceed. Yeah, it is. I decided to take a better look as to whether or not this could be handled in the debug agent. The first question I found myself asking is why is there a ClassPrepareEvent being generated? The test itself does not enable them. It turns out the JDI implementation enables them, and does so with SUSPEND_NONE. This SUSPEND_NONE suspension policy is part of the problem. It means that when the event is sent, the thread it was triggered on (the debuggee main thread) is not suspended. The event actually gets sent to the debugger from another thread (the "event helper thread"), and the class reference is freed after it is sent. But the main debugger thread considers itself "done" with the event once it gets enqueued for the event helper thread to handle, so the debugger main thread continues execution, and moves on to the full GC part of the test. Meanwhile the event helper thread is processing the event, and may take a while before it gets far enough along to free the class reference. If the suspension policy was SUSPEND_EVENT_THREAD or SUSPEND_ALL, then the debugger main thread would have suspended until after the debugger explicitly resumed its execution. This would have allowed the sending of the event and the freeing of the class reference to complete before the debugger main thread was resumed. I suppose another way to fix test issue would be to add an additional ClassPrepareRequest to the test, and have it use SUSPEND_EVENT_THREAD or SUSPEND_ALL. But in the end it's still just a workaround to the problem. ------------- PR: https://git.openjdk.org/jdk/pull/10519
