RFR: 8266130: convert Thread-SMR stress tests from counter based to time based [v2]
Daniel D.Daugherty
dcubed at openjdk.java.net
Mon Jun 7 23:53:16 UTC 2021
On Mon, 7 Jun 2021 22:09:51 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Apply @plummercj code review fix from JDK-8265153 to this review also.
>
> test/hotspot/jtreg/runtime/Thread/InterruptAtExit.java line 82:
>
>> 80: thread.exitSyncObj.countDown();
>> 81: while (true) {
>> 82: thread.interrupt();
>
> I just want to make sure I correctly understand the intent here. You call countDown() to unblock the thread's run() method, and then immediately interrupt the thread to create a race between the thread doing a normal exit and the thread being interrupted before or as it exits.
That is correct. The intention is to stress the Thread.interrupt() calls
on the exiting thread.
> test/hotspot/jtreg/runtime/Thread/StopAtExit.java line 88:
>
>> 86: thread.exitSyncObj.countDown();
>> 87: while (true) {
>> 88: thread.stop();
>
> It seems the main() method of these 6 or so thread tests are identical except for the one Thread API you call at this location. Have you considered refactoring so there is only one copy of all the common code?
Not really. It would be harder to use one of these tests in a standalone
fashion outside of JTREG runs if it depended on another .java file.
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003.java line 105:
>
>> 103: }
>> 104:
>> 105: System.out.println("Case 2: java.lang.Thread.interrupt()");
>
> Was Case 2 removed because it is covered by runtime/Thread/InterruptAtExit.java
Yes, it seemed like duplicated coverage to me.
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/suspendthrd003.cpp line 102:
>
>> 100: /*
>> 101: * Using printf() instead of NSK_DISPLAY1() in this loop
>> 102: * in order to slow down the rate of SuspendThread() calls.
>
> I don't understand the reason for wanting to slow down the rate, nor your reason for removing it.
I couldn't remember why I did that when I wrote the test so
I removed it.
-------------
PR: https://git.openjdk.java.net/jdk/pull/4237
More information about the serviceability-dev
mailing list