Customer problem description:
------------------------------

The main thing we want is the ability to get a remote thread dump, as if you
typed Control-\ or Control-Break at the console.  What we've done today,
with JDK118 and JDK122 is the next best thing: a list of all the threads and
stack traces.  But what's missing even in those cases is: monitor locks,
thread state (waiting to enter, waiting for a notify, running).  APIs for
all those things would be fantastic.

With Java 1 we copied the part of the VM code that fills in the
stack trace, and we did it ourselves, filling in a Throwable ourselves ...
It didn't work with compiled methods (JIT methods) because following the
stack frame requires access to nonpublic methods that know how to walk JIT
stack frames.

Now with Java 2 that ability is no longer available. We have come
up with two suggested possibilities

*	Expose DumpThreads() and/or DumpMonitors() as routines we can call
from a JNI method.
*	Create a new, exposed method in JNI which takes a thread (possibly
suspended) and a Throwable, and it fills in the stack trace for that thread.


What I would like most is a method in class Thread which takes a Throwable
object and fills in its current stack trace into that throwable, so I can
then do whatever I need to do with the result.  

A method in Thread that takes a Throwable as an argument, and sticks
the thread's current stack trace into that throwable.

		Thread.fillInStackTrace(Throwable t)

OR

		Throwable.fillInStackTrace(Thread t);

If modifying the language spec to support these methods is not possible,
then I would settle quite happily for something in JNI land that I can call.

I heard that there will be something in 1.4 that will dump all stacks on demand. That's not really want we want, because we need better control over where the output is sent. A version of that which takes an output stream as an argument, something like:

	System.dumpAllStacks(OutputStream out)

would be perfect.

This would give us maximum flexibility to do what we would like to do, which
is look at all the running threads in a large, server-based Java
application.  We have diagnosed many MANY problems with this tool without
having to send engineers on site, and our customers realize it and are
reluctant to move to a platform that doesn't support this debugging tool.