Hi Dan,
Something is wrong with ProblemList.txt. It doesn't show any changes,
but I also don't see mixed002 in the file anymore.
Otherwise the changes look good.
thanks,
Chris
On 6/29/20 12:21 PM, Daniel D. Daugherty wrote:
Greetings,
I have a fix for the following bug:
JDK-8246493 JDI stress/serial/mixed002 needs to use
WhiteBox.deflateIdleMonitors support
https://bugs.openjdk.java.net/browse/JDK-8246493
Here's the webrev URL:
http://cr.openjdk.java.net/~dcubed/8246493-webrev/0_for_jdk16/
The test bug that's being fixed:
vmTestbase/nsk/jdi/stress/serial/mixed002/TestDescription.java fails
intermittently with the following message:
nsk.share.TestBug: There are more than one(2) instance of
'nsk.share.jpda.StateTestThread in debuggee
Summary of the fix:
Use WhiteBox.deflateIdleMonitors() to make sure that all inflated
ObjectMonitors are deflated after each debuggee has been run.
This fix has been tested with a Mach5 Tier5 test run that executes all
of the JDI tests (along with JDWP, JVM/TI and other Serviceability
tests).
I also did five 100 iteration runs of the failing mix002 test. Each Mach5
job set ran the test 100 times on Linux-X64, macOSX, and Win-X64 for a
total of (5 * 100 * 3) iterations of nsk/jdi/stress/serial/mixed002.
There
were no failures.
Thanks, in advance, for any comments, questions or suggestions.
Dan
Gory details:
The primary focus of the fix is in the first three files in the webrev:
test/hotspot/jtreg/vmTestbase/nsk/share/jdi/SerialExecutionDebuggee.java
test/hotspot/jtreg/vmTestbase/nsk/jdi/stress/serial/mixed002/TestDescription.java
test/hotspot/jtreg/ProblemList.txt
nsk.share.jdi.SerialExecutionDebuggee is the class that used to serially
execute the debuggee portion of a specific list of tests. After this
class
is done executing a debuggee class, it needs to deflate idle monitors in
order to prevent a StateTestThread object created by one debuggee class
from confusing the next debuggee class. Each of the debuggee classes that
use StateTestThread expect there to be only one of these objects.
However,
since we are running multiple debuggee classes serially *in the same VM*,
the StateTestThread object created in one debuggee can still be around
when the next debuggee runs.
The COMMAND_CLEAR_DEBUGGEE implementation clears the currentDebuggee
variable
which permits the debuggee to be GC'ed and is modified by this fix to
call
WhiteBox.deflateIdleMonitors() to make sure that all inflated
ObjectMonitors
are deflated after each debuggee has been run. This takes care of any
pinned
StateTestThread objects (and any other inflated ObjectMonitors).
vmTestbase/nsk/jdi/stress/serial/mixed002 is a wrapper style stress
test that
executes the debugger and debuggee parts of a specific list of tests
serially
*in the same VM*. Several of the tests executed by mixed002 make use
of the
StateTestThread class. The failure is intermittent because the order
of test
execution is shuffled automatically and sometimes the ServiceThread
manages
to execute deflation at the right time to prevent more than one
StateTestThread
object from existing at the same time.
The additions to vmTestbase/nsk/jdi/stress/serial/mixed002 are the
standard
boilerplate needed to call WhiteBox functions from test code. The
actual call
to WhiteBox.deflateIdleMonitors() is made in SerialExecutionDebuggee.
I did
attempt a fix where I modified the StateTestThread class to make the
call to
WhiteBox.deflateIdleMonitors() after the internal waitOnObject is no
longer
contended or waited on. That fix reduced the frequency of the failures by
about half, but it didn't solve the test bug entirely. So I had to
make the
fix in SerialExecutionDebuggee instead.
test/hotspot/jtreg/ProblemList.txt is modified to re-enable the mix002
test.
The remaining nine files are also wrapper style stress tests that execute
the debugger and debuggee parts of a specific list of tests serially *in
the same VM*. Because these tests also use SerialExecutionDebuggee, they
also need the boilerplate changes so that WhiteBox.deflateIdleMonitors()
can be called.
