Delayed/missed jdwp class unloading events

JDK-8212879 moved ObjectFree event posting out of the GC pause.

There is an "optimization" in jdwp that may cause some problems as a result. I think it may cause delays in jdwp ClassUnload events. Note that I've not seen any failures related to this; this is all based on code inspection.

The relevant code is in jdk.jdwp.agent/share/native/libjdwp:
eventHandler.c
classTrack.c

classTrack.c is where the ObjectFree handler resides. That handler records information which is made accessible by calling classTrack_processUnloads.

eventHandler.c has event_callback, which is the caller of classTrack_processUnloads. That call is conditional on garbageCollected > 0, and when that's true it clears the counter. event_callback is used as the core callback handler; many of its jvmti callback handlers use it.

garbageCollected is incremented by a jvmti GarbageCollectionFinish callback.

Garbage collectors post GarbageCollectionStart/Finish pairs at the start and end of garbage collection pauses.

If there is some jdwp event between the pause end and the ObjectFree postings, jdwp won't detect the unloading until after the next GC pause end.

I think this can be fixed by removing the conditionalization of the call to classTrack_processUnloads, and just do it unconditionally. There is a (somewhat confusing) comment saying that the conditionalization is there to avoid taking the handler lock when that isn't needed. But it's not clear why that lock is being taken on that code path at all, as classTrack_processUnloads contains it's own internal locking.

There is also a cache cleanup in the same conditional, as it is doing cleanup of possibly cleared weak references, so no point in doing it again unless there's been some GC activity.

The reason I think this is a problem is that if the new ServiceThread support for posting ObjectFree events is disabled then we get some consistent failures in jdi tests related to class unloading. So there may be a timing issue for those tests; even with the ServiceThread doing the ObjectFree posting, those tests might now have intermittent failures, though I've not seen any in the testing I've done.

With the ServiceThread not posting ObjectFree events, the failing jdi tests are:

vmTestbase/nsk/jdi/ClassUnloadEvent/className/classname001/TestDescription.java
vmTestbase/nsk/jdi/ClassUnloadEvent/classSignature/signature001/TestDescription.java
vmTestbase/nsk/jdi/HiddenClass/events/events001.java