On Wed, 15 Jun 2022 12:53:40 GMT, Zhengyu Gu <z...@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
