As noted in JDK-8352088, JVMTI GetThreadGroupChildren does an upcall to java. This results in ClassPrepareEvents the first time it does this, and these events can cause problems for the debugger or debug agent.

The issue in JDK-8352088 is that while handling an event, the debugger is calling com.sun.jdi.ThreadGroupReference.threadGroups(), which results in the debug agent calling GetThreadGroupChildren. This can generate a ClassPrepareEvent, but since the debugger's event handler thread is currently blocked on the ThreadGroupReference.threadGroups(), it won't process the ClassPrepareEvent. This leaves the debuggee blocked (due to the event suspend policy), and it will never unblock.

JDK-8352088 is working around the problem modifying the java upcall so it no longer triggers class loading. However, it would be best if JVMTI didn't deliver events during upcalls to java, but there's more to it than that. The reality is that these upcalls shouldn't be generating events in the first place, unless it is due to some explicit request from the debugger, such as a breakpoint or method entry event.

The problem with turning off all events is that the debug agent and debugger rely on all ThreadStart and ClassPrepare events being delivered. If any are skipped, it can cause problems. At the same time, delivering them can also cause problems. So we need to make sure that these events are not triggered during java upcalls. What that probably means is adding an assert so we can catch instances where this does happen. This assert would only be for the events we really can't skip, like ThreadStart and ClassPrepare (there might be some others).