Hi Yasumasa,
On 29/08/2019 12:14 am, Yasumasa Suenaga wrote:
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?
No. In the new code "_owner" is only an informational field used by the
current thread to detect its own recursive lock usage. Actual ownership
is determined by the successful lock or tryLock of the underlying
PlatformMonitor.
However I had been thinking about memory ordering and there are missing
membars. We have to do:
lock(); _owner=THREAD;
_owner=NULL; unlock();
in the order specified so I need to insert storestore barriers.
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...
Yes. Though I'd still like to understand why we don't see the same
assertion failure in existing code.
But moving on ... what are your thoughts on the interrupt semantics?
Thanks,
David
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
