On 6/19/19 9:59 PM, serguei.spit...@oracle.com wrote:
Sorry, forgot the bug title to add to the email subject.
Thanks,
Serguei
On 6/19/19 6:09 PM, serguei.spit...@oracle.com wrote:
Please review a fix for test bug:
https://bugs.openjdk.java.net/browse/JDK-8223736
Webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223736-mon-events-test.1/
test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC04/tc04t001.java
L164: if (enterEventsCount() == lastEnterEventsCount + 1) {
I wonder if '==' should be '>=' to more resilient against
multiple events. I tried to figure out the flow control
for the event posting, but I couldn't figure it out with
a quick look.
L170: if (enterEventsCount() != lastEnterEventsCount + 1) {
Similarly I wonder if this should be:
if (enterEventsCount() == lastEnterEventsCount) {
to simply detect that the count hasn't changed.
test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC04/tc04t001/tc04t001.cpp
No comments.
Thumbs up. My concerns above may not be correct depending on how the
test really works. Your call.
Dan
Summary:
It seems that waiting for 0.5 sec for a MonitorContendedEnter event
in the
increment() method sometime is not enough (especially when the JFR
is enabled).
The fix implement an approach to ensure the event has posted before
the worker
thread goes to the next iteration.
Also, another check is added to diagnose if any of two worker threads
(tc04t001Thread) has been interrupted by timeout.
In fact, we have many other tests which miss this kind of check and
diagnostics.
We may want to consider fixing other cases if we encounter this
eventually happens.
Testing:
A mach5 test submission is in progress.
Thanks,
Serguei
