RFR (11): 8205878: pthread_getcpuclockid is expected to return 0 code
david.holmes at oracle.com
Thu Jul 5 22:18:52 UTC 2018
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
+ ifeq ($(TOOLCHAIN_TYPE), solstudio)
+ BUILD_HOTSPOT_JTREG_LIBRARIES_CFLAGS_libji06t001 +=
> 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/
>> 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.
>> 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.
>> - 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
More information about the hotspot-runtime-dev