RFR (S): 8223736:jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events
Daniel D. Daugherty
daniel.daugherty at oracle.com
Thu Jun 20 23:17:36 UTC 2019
On 6/19/19 9:59 PM, serguei.spitsyn at oracle.com wrote:
> Sorry, forgot the bug title to add to the email subject.
>
> Thanks,
> Serguei
>
> On 6/19/19 6:09 PM, serguei.spitsyn at 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
>>
>
More information about the serviceability-dev
mailing list