RFR(S): 8200450: Analysis and fix for JDK-8200366 (SIGSEGV in print_names())

Schmidt, Lutz lutz.schmidt at sap.com
Tue Apr 17 15:49:12 UTC 2018

Dear all,

may I please request your comments on this topic. 

I have invested quite some time in testing, reproducing, analyzing, and fixing the effects that caused the CodeHeap State Analytics function print_names() to SIGSEGV (very rare, intermittent). Please refer to my description in the bug for the details (I did not want to duplicate it here). 

I have prepared an preliminary webrev as a basis for further discussions. The webrev is preliminary at least with respect to the debugging/tracing output which is still in there intentionally. I thought it might be helpful for you to see how I tested that the changes actually hardened the code. A potential push candidate would have all #ifdef JDK8200450_TRACE sections removed. All #ifndef JDK8200450_REMEDY sections would be gone as well.

As workload I ran SPECjvm2008. From a separate process, I hammered sets of
 - ${jcmd} ${testPID} Compiler.CodeHeap_Analytics discard
 - ${jcmd} ${testPID} Compiler.CodeHeap_Analytics aggregate
 - ${jcmd} ${testPID} Compiler.CodeHeap_Analytics MethodNames (50 repetitions)
 - start over
against the JVM. The pace was only limited by system capabilities. I scanned the output for marker strings to find handled issues which previously would have caused a SIGSEGV. Platforms tested are bsd_x86, linux_x86, linux_ppc, linux_s390. A handled issue was reported less frequently than 1 in 10,000. Unhandled issued were not encountered at all.

In addition, I cleaned the format strings a bit, replacing "%p" by INTPTR_FORMAT. 

Bug:    https://bugs.openjdk.java.net/browse/JDK-8200450 
Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8200450.00/ 

Thanks for having a look!

More information about the hotspot-compiler-dev mailing list