Fibers and stack traces

[Bela Ban]

Hi everyone (from a just-joined member)

quick introduction: Bela Ban, JGroups lead (jgroups.org), I work for Red 
Hat / IBM. My interest in Loom is to see how/whether fibers affect 
performance, e.g. for blocking RPCs across a cluster. Also, the wet 
dream of continuing down the road of blocking programming without the 
callback hell of async / reactive programming (but still reaping the 
benefits of fewer ctx switches) looks enticing!

Testing performance of fibers against JGroups looks good, besides the 
occasional JVM (16-ea29) crash :-)

The question I have is about stack traces, here's an email excerpt I 
sent to Alan earlier this week (I did read through some of the archives, 
but might have overseen this):

A big issue, however, is that stack dumps don't show anything 
meaningful. If a fiber is in BLOCKED or (TIME_)WAITING state, then its 
stack trace isn't visible.

If I keep track of all fibers I create, then I can provide a thread dump 
of them myself: see the attached (deadlocking) program.

But most customers will want to produce this via 
jstack/CTRL-kill/whatever, so the above is not feasible.

What have you guys planned to tackle this? I know I should probably be 
asking this on the ML...

I understand that a stack trace of millions of threads is cumbersome, but
* I assume most apps still use only a few or a few tens of threads, so 
this would still be useful
* Filtering could be used, e.g. only BLOCKED threads, or threads 
starting with "Invoker*"

Thoughts?


-- 
Bela Ban | http://www.jgroups.org