RFR(S): 8246493: JDI stress/serial/mixed002 needs to use WhiteBox.deflateIdleMonitors support
serguei.spitsyn at oracle.com
serguei.spitsyn at oracle.com
Mon Jun 29 19:41:46 UTC 2020
The same as from Chris.
The ProblemList.txt has no changes.
Otherwise, it looks good.
On 6/29/20 12:37, Chris Plummer wrote:
> 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.
> On 6/29/20 12:21 PM, Daniel D. Daugherty wrote:
>> I have a fix for the following bug:
>> JDK-8246493 JDI stress/serial/mixed002 needs to use
>> WhiteBox.deflateIdleMonitors support
>> Here's the webrev URL:
>> 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
>> I also did five 100 iteration runs of the failing mix002 test. Each
>> 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.
>> were no failures.
>> Thanks, in advance, for any comments, questions or suggestions.
>> Gory details:
>> The primary focus of the fix is in the first three files in the webrev:
>> nsk.share.jdi.SerialExecutionDebuggee is the class that used to serially
>> execute the debuggee portion of a specific list of tests. After this
>> 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
>> use StateTestThread expect there to be only one of these objects.
>> since we are running multiple debuggee classes serially *in the same
>> the StateTestThread object created in one debuggee can still be around
>> when the next debuggee runs.
>> The COMMAND_CLEAR_DEBUGGEE implementation clears the currentDebuggee
>> which permits the debuggee to be GC'ed and is modified by this fix to
>> WhiteBox.deflateIdleMonitors() to make sure that all inflated
>> are deflated after each debuggee has been run. This takes care of any
>> 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
>> *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
>> to execute deflation at the right time to prevent more than one
>> object from existing at the same time.
>> The additions to vmTestbase/nsk/jdi/stress/serial/mixed002 are the
>> 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
>> 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
>> 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.
More information about the hotspot-runtime-dev