On 28/08/2019 10:57 pm, 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."
Yep it is allowed.
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.
Doesn't seem to reproduce on Linux.
At least, I can confirm that the following comment is true 😊
// FIXME: this is broken - raw_enter only accepts the VMThread
As I noted I had yet to reconcile the fact the outer raw monitor code
seems to allow non-JavaThreads while the inner code only allows the
VMThread! I'm quite surprised we have not encountered this bug before
now - unless there is some really subtle code difference I'm missing here.
Anyway this is an aside to the question of interrupt semantics that
needs to be addressed before this can proceed. :)
Thanks,
David
Best regards,
Martin
