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

[Daniel D. Daugherty]

Chris and Serguei,

Thanks for the fast reviews!!

I generated the webrev in my "mach5" directory and that was baselined
on the jdk-16+3 snapshot and that doesn't include the ProblemList change.
Sigh...  I have updated the repo to "current" and regenerated the webrev.

test/hotspot/jtreg/ProblemList.txt  now shows:

@@ -126,11 +126,10 @@
  vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/JavaDeadlock001/TestDescription.java 8060733 generic-all

  vmTestbase/nsk/jdi/ThreadReference/stop/stop001/TestDescription.java 
7034630 generic-all
  vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java 8065773 generic-all
  vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 8065773 generic-all
-vmTestbase/nsk/jdi/stress/serial/mixed002/TestDescription.java 8246493 
generic-all

  vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all

  vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 
generic-all
  vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 
generic-all

Thanks again for the fast reviews!!

Dan


On 6/29/20 3:41 PM, serguei.spitsyn at oracle.com wrote:
> Hi Dan,
>
> The same as from Chris.
> The ProblemList.txt has no changes.
> Otherwise, it looks good.
>
> Thanks,
> Serguei
>
>
>
> 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.
>>
>> 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.
>>
>>
>