RFR: 8264663: Update test SuspendWithCurrentThread.java to verify that suspend doesn't exit until resumed

Serguei Spitsyn sspitsyn at openjdk.java.net
Fri Apr 23 22:27:36 UTC 2021


On Fri, 23 Apr 2021 21:26:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Test test/hotspot/jtreg/serviceability/jvmti/SuspendWithCurrentThread/SuspendWithCurrentThread.java
>> doesn't check that thread stops in SuspendThreadList(...).
>> 
>> Actually, before https://bugs.openjdk.java.net/browse/JDK-8257831 the thread didn't suspend itself but only get a request to be suspended.  So it continued to execute and stopped a little bit later.
>> 
>> Such behavior is a violation of spec which says " If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it."
>> 
>> While the bug is fixed it is still useful to verify correct behavior.  If the fix is backported without JDK-8257831 test should start failing.
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithCurrentThread/libSuspendWithCurrentThread.cpp line 33:
> 
>> 31: static jthread* threads = NULL;
>> 32: static jsize threads_count = 0;
>> 33: static std::atomic<bool> is_exited_from_suspend;
> 
> Is use of `std::atomic` permitted in tests?

I've never seen any such restrictions in our development guidelines.
In general, there are cases where using atomic vs raw monitors is desirable to avoid over sync in tests when there is a need to stress multi-threading.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3665


More information about the serviceability-dev mailing list