RFR: 8256811: Delayed/missed jdwp class unloading events [v3]

[Coleen Phillimore]

On Thu, 23 Jun 2022 12:34:59 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.
>> 
>> **Update**
>> There are significant changes from early patch. 
>> 
>> The new approach:
>> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
>> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
>> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
>> 
>> The new solution breaks up into two steps:
>> - Collect all dead object tags with lock
>> - Transition to `_in_native` state and post object free events in one batch
>> 
>> This way, JDI event handler can process object free events upon arrivals without delay.
>
> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision:
> 
>  - Improve naming and cleanup
>  - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event
>  - v4
>  - v3
>  - v2
>  - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event
>  - Merge branch 'jdi_tmp' into JDK-8256811-jdi-missing-class-unloading-event
>  - v0
>  - v2
>  - v1
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/c4855a3d...559b4bf1

src/hotspot/share/prims/jvmtiTagMap.cpp line 1200:

> 1198: };
> 1199: 
> 1200: // PostObjectFree can't be called by JavaThread, so call it from the VM thread.

I wish I'd written why here.  I think it's because we can't hold a Mutex to do the callback, but now I don't remember. I need to spend some time to understand this.  Thanks @plummercj  for adding Kim and I.

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

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