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

[David Holmes]

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