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

[Chris Plummer]

On Mon, 27 Jun 2022 17:49:25 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>>> This patch is intended to not post ObjectFree events on VMThread, so I am going to move this PR back to draft state and take another look.
>> 
>> I'm not so sure it matters to the debug agent. I thought the main change here was to not force posting of ObjectFree events to be deferred to the VMThread, and to change the debug agent to send the CLASS_UNLOAD events right away rather than accumulating them and waiting for a GCFinishEvent. Is there any issue if the posting of ObjectFree and sending of CLASS_UNLOAD is done on the VMThread?
>
> Hmm... I thought that is the whole purpose for delaying processing class unload events, because it can not be done on `VMThread`? Otherwise, we don't need all this complexity, just have `cbTrackingObjectFree()` calls `synthesizeUnloadEvent()` directly.

There were two delays. One was the debug agent waiting until the GCFinishEvent before sending out all the queued up CLASS_UNLOAD events. The other was JVMTI deferring the posting the ObjectFree events that arrive on a JavaThread, and instead using the VMThread:

1200 // PostObjectFree can't be called by JavaThread, so call it from the VM thread.
1201 void JvmtiTagMap::post_dead_objects_on_vm_thread() {
1202   VM_JvmtiPostObjectFree op(this);
1203   VMThread::execute(&op);

I think this was because the VM state was not consistent, and I believed you have resolved this so it should be ok to post from the JavaThread (which I think is actually the ServiceThread in this case, but I'm not certain).

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

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