RFR(S): 8246493: JDI stress/serial/mixed002 needs to use WhiteBox.deflateIdleMonitors support

[Daniel D. Daugherty]

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.