On Tue, 1 Dec 2020 02:22:57 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> void JvmtiTagMap::flush_object_free_events() {
>> assert_not_at_safepoint();
>> if (env()->is_enabled(JVMTI_EVENT_OBJECT_FREE)) {
>>
>> Called by JVMTI to disable events and called by the service thread. And
>> here for get_objects_with_tags:
>>
>> if (collector.some_dead_found() &&
>> env()->is_enabled(JVMTI_EVENT_OBJECT_FREE)) {
>> post_dead_objects_on_vm_thread();
>> }
>
> That isn't quite what I asked. The claim is that `remove_dead_entries_locked`
> needs to recheck `is_enabled` if `post_object_free` is true in case the
> enabled state changed from true to false. But I can't see how such a
> situation can arise. In `flush_object_free_events` we only call
> `remove_dead_entries(false)` and that is when events were seen to be disabled.
I think you've missed the indirect remove_dead_entries(true) via
post_dead_objects_on_vm_thread() in the enabled case, over on the vmthread.
And that's exactly the case that shows up in the hs_err file. The assert
happens on the vmthread, in the VMOp used by post_dead_entries_xxx:
Stack: [0x00007f07456c6000,0x00007f07457c6000], sp=0x00007f07457c48c0, free
space=1018k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted,
Vv=VM code, C=native code)
V [libjvm.so+0x11e92fc] JvmtiExport::post_object_free(JvmtiEnv*, long)+0x8c
V [libjvm.so+0x12293b2] JvmtiTagMapTable::remove_dead_entries(JvmtiEnv*,
bool)+0x192
V [libjvm.so+0x12212cd] VM_JvmtiPostObjectFree::doit()+0x5d
V [libjvm.so+0x198469a] VM_Operation::evaluate()+0x18a
V [libjvm.so+0x19a7e7f] VMThread::evaluate_operation(VM_Operation*)+0x17f
V [libjvm.so+0x19a88cc] VMThread::inner_execute(VM_Operation*)+0x17c
V [libjvm.so+0x19a8b85] VMThread::loop()+0xb5
V [libjvm.so+0x19a8cba] VMThread::run()+0xca
V [libjvm.so+0x1893db0] Thread::call_run()+0x100
V [libjvm.so+0x1574796] thread_native_entry(Thread*)+0x116
-------------
PR: https://git.openjdk.java.net/jdk/pull/1439
