The JVM (and probably many other languages & runtimes as well) sorely misses three very useful serviceability features with regard to call execution stacks:
- ids: a stack frame is given a unique (within the thread context) identifier prior to being pushed onto the call execution stack
- marking: recording the number of mark operations performed since a frame was pushed onto the call execution stack
- tagging: a stack frame will take either a tag value set at the thread level or process level prior to being pushed onto the call execution stack
With identifying, marking and tagging the job of detecting hung or delayed threads (deadlocked, busy or spinning) is made far easier because it is possible to easily determine whether a repetitive call stack trace across multiple dumps is indeed the same execution call path instance or an entirely new execution (for the same thread). This is made all the more problematic with thread pools and workers (code blocks) that follow the same flow but which operate on different data types not discernible from the code itself.
Fortunately it is possible to enrich a Java runtime with these capabilities while we await JDK 99 ;-)