On Thu, 17 Feb 2022 13:29:11 GMT, Zhengyu Gu <z...@openjdk.org> wrote:
> I suspect the issue with directly issuing the CLASS_UNLOAD event is due to > when, and on what thread, the OBJECT_FREE event is issued. Yes, I think there is an issue trying to send all the accumulated CLASS_UNLOAD events when the GC_FINISH arrives because it arrives on a VM thread, not a java thread. The debug agent may suspend whichever thread sent the JDWP event to the debugger, and it will stay suspended until the debugger tells the debug agent to resume the thread. I say "may suspend" because it depends on the suspend policy of the EventRequest. It will suspend if the policy is SUSPEND_THREAD or SUSPEND_ALL, but not for SUSPEND_NONE. So we have two problems then. The VM thread is suspended, and also the debugger sees the VM thread as the event thread (only java threads should be event threads). I assume OBJECT_FREE also arrives on a VM thread and would have the same issue if it triggered sending the CLASS_UNLOAD event right away. To fix the issue of having to wait for the next event before sending the CLASS_UNLOAD events (and it sometimes being a long time in coming), the debug agent could enable a JVMTI event it knows will be triggered right away, such as MethodEntry or MethodExit (these might be the only two candidates). This at least would ensure triggering the calling of processUnloads right way. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461
