RFR: 8256811: Delayed/missed jdwp class unloading events

[Chris Plummer]

On Wed, 15 Jun 2022 12:53:40 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
> 
> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
> 
> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
> 
> It also performs `commonRef_compact()` only when there are classes unloaded.
> 
> New test failed about 20% without patch, none with patch.

One issue I have with this fix is that is doesn't fix the "delay" issue. It helps it, and ensures the CLASS_UNLOAD events are sent before the debuggee exits, but it doesn't guarantee that they are sent in a time manner.

Your test is somewhat contrived in that the debuggee only runs for as long as it takes to look up all the test classes. Then it exits, generating a VM_DEATH, and guaranteeing that by that point all CLASS_UNLOAD events have been sent (and without delay). However, we also have the issue of a [JDK-8257705](https://bugs.openjdk.org/browse/JDK-8257705), which is a test that times out waiting for a CLASS_UNLOAD event, because there isn't another event to trigger sending it. Since the debuggee does not exit until after the test is done (and has timed out), the VM_DEATH comes too late.

[JDK-8256811](https://bugs.openjdk.org/browse/JDK-8256811) offers other suggestions for the fix, albeit more complex than your. Please consider the one mentioned in the first comment, which is basically adding a watchdog thread.

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

PR: https://git.openjdk.org/jdk/pull/9168