RFR (11): 8205878: pthread_getcpuclockid is expected to return 0 code

[David Holmes]

On 5/07/2018 7:58 PM, David Holmes wrote:
> <sigh> Solaris compiler complains about doing a return from inside a 
> do-while loop. I'll have to rework part of the fix tomorrow.

Webrev updated in-place. The only change is to the makefile to disable a 
warning:

+ ifeq ($(TOOLCHAIN_TYPE), solstudio)
+   BUILD_HOTSPOT_JTREG_LIBRARIES_CFLAGS_libji06t001 += 
-erroff=E_END_OF_LOOP_CODE_NOT_REACHED
+ endif
+

David
-----

> David
> 
> On 5/07/2018 6:19 PM, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8205878
>> Webrev: http://cr.openjdk.java.net/~dholmes/8205878/webrev/
>>
>> Problem:
>>
>> The tests create native threads that attach to the VM through 
>> JNI_AttachCurrentThread but which then terminate without detaching 
>> themselves. When the VM exits and we're using Flight Recorder 
>> "dumponexit" this leads to a call to VM_PrintThreads that in part 
>> wants to print the per-thread CPU usage. When we encounter the threads 
>> that have terminated already the low level pthread_getcpuclockid calls 
>> returns ESRCH but the code doesn't expect that and so fails an assert 
>> in debug mode and can SEGV in product mode.
>>
>> Solution:
>>
>> Serviceability-side: fix the tests
>>
>> Change the tests so that the threads detach before terminating. The 
>> two tests are (surprisingly) written in completely different styles, 
>> so the solution also takes on two different styles.
>>
>> Runtime-side: make the VM more robust in the fact of JNI attached 
>> threads that terminate before detaching, and add a regression test
>>
>> I took a good look at the low-level code for interacting with 
>> arbitrary threads and as far as I can see the problem only exists for 
>> this one case of pthread_getcpuclockid on Linux. Elsewhere the 
>> potential for a library call failure just reports an error value (such 
>> as -1 for the cpu time used).
>>
>> So the fix is simply to allow for ESRCH when calling 
>> pthread_getcpuclockid and return -1 for the cpu usage in that case.
>>
>> I created a new regression test to create a new native thread, attach 
>> it and then let it terminate while still attached. The java code then 
>> calls various Thread and ThreadMXBean functions on it to ensure there 
>> are no crashes or unexpected exceptions.
>>
>> Testing:
>>   - old tests with fixed run-time
>>   - old run-time with fixed tests
>>   - mach tier4 (which exposed the problem - that's where we enable 
>> Flight recorder for the tests) [in progress]
>>   - mach5 tier 1-3 for good measure [in progress]
>>   - new regression test
>>
>> Thanks,
>> David