Hi,
I guess this issue was occurred on ObjectFree JVMTI event.
It is registered in a04t001.cpp [1]. I think it might be called on GC worker
because it relates to JvmtiExport::weak_oops_do().
In current code, JvmtiRawMonitor::_owner is handled with atomic operation.
However at JvmtiRawMonitor::quick_enter() in new webrev, it just referent
normally.
Should it be handled atomically?
At least, I think this assert might be failed in current code because raw monitor might
be handled on GC worker. So "FIXME" comment Martin found is valid...
Thanks,
Yasumasa
[1]
hg.openjdk.java.net/jdk/jdk/file/4f38fcd65577/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t001/ap04t001.cpp#l219
On 2019/08/28 21:57, Doerr, Martin wrote:
Hi David,
Now why would a GCTaskThread being executing code that accesses
JvmtiRawMonitors? Are we in some kind of event callback?
I believe so. The test registers the following callbacks:
callbacks.GarbageCollectionStart = &GarbageCollectionStart;
callbacks.GarbageCollectionFinish = &GarbageCollectionFinish;
And these callback functions use jvmti->RawMonitorEnter.
Note that the spec for "Raw Monitor Enter" allows this:
"This function may be called from the callbacks to the Heap iteration functions, or
from the event handlers for the GarbageCollectionStart, GarbageCollectionFinish, and
ObjectFree events."
Is there any more stack? What is that dll?
The dll belongs to the test. I guess it was built without debug info so there's
no native stack trace available.
Can you tell me what test this was and how to reproduce?
make run-test TEST="vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t001"
I haven't tried if it can be reproduced well. May be sporadic.
At least, I can confirm that the following comment is true 😊
// FIXME: this is broken - raw_enter only accepts the VMThread
Best regards,
Martin
