On Mon, 27 Jun 2022 17:49:25 GMT, Zhengyu Gu <[email protected]> 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
