JDK-8234624 fixed an issue with missing mixed stack traces when using "jhsdb jstack --mixed" or the clhsdb pstack command. For example:

 "Service Thread" #5 daemon prio=9 tid=0x00007f17101b7800 nid=0x6dc3 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_blocked
0x00007f1716a1da35 __pthread_cond_wait + 0xc5

Instead of:

 "Service Thread" #5 daemon prio=9 tid=0x00007f56601d2800 nid=0x5ed2 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_blocked
0x00007f5668a7d63c __pthread_cond_wait + 0xcc
0x00007f56679bac7a Monitor::wait_without_safepoint_check(long) + 0xda
0x00007f5667bacb77 ServiceThread::service_thread_entry(JavaThread*, Thread*) + 0x2b7
0x00007f5667d47d16 JavaThread::thread_main_inner() + 0x226
0x00007f5667d4dbb0 Thread::call_run() + 0x100
0x00007f5667a55c26 thread_native_entry(Thread*) + 0x116

The cause was -fomit-frame-pointer being used to compile libc, so SA was unable to walk past the current frame when it was in libc (which is usually the case for any blocking thread). The fix was to look at the DWARF .eh_frame or .debug_frame records to get the needed stack walking information. This seemed to fix the issue in some cases, but apparently there are other causes of this bug besides -fomit-frame-pointer. I noted this in JDK-8234624, and Yasumasa responded that it is probably due to Language Specific Data Area (LSDA):

https://bugs.openjdk.java.net/browse/JDK-8234624?focusedCommentId=14338216&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14338216

His recommended solution is to use an unwind library (e.g. libunwind, binutils). It's unclear exactly what this entails and how disruptive it would be to existing SA stack unwinding code.