RFR: 8256811: Delayed/missed jdwp class unloading events

Zhengyu Gu zgu at openjdk.java.net
Wed Jun 15 19:12:03 UTC 2022


On Wed, 15 Jun 2022 17:21:25 GMT, Chris Plummer <cjplummer 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.
>
> src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c line 637:
> 
>> 635:          * been collected.
>> 636:          */
>> 637:         commonRef_compact();
> 
> I think you want to be doing the `commonRef_compact()` after every gc, not just if some classes were unloaded. You may need to re-add the `garbageCollected` flag to accomplish this.

If so, should `cbGarbageCollectionFinish()` be a better place for the call?

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

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


More information about the serviceability-dev mailing list