I like to generate a thread dump programmatically. I've learned that there a basically two ways to do it:
Use the "Java Virtual Machine Tool Interface" JVM-TI
Use the higher abstracted "Java Debugger Interface" JDI
For the JVM-TI I was able to find some useful information, but I would have to write a JNI-DLL which, at least for the moment, I would like to avoid. With the JDI I can use Java and it seems I'm able to use it from within the application. But I wasn't able to find some kind of tutorial or HOWTO for it. The only documentation I could find, were the Java-Docs http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdi/ which isn't very helpful, because it doesn't show me how to use this classes.
So, does anybody know of a good tutorial/book I could read?
Thx for any help!
There is a third way: Thread.getAllStackTraces()
http://java.sun.com/javase/6/docs/api/java/lang/Thread.html#getAllStackTraces()
This is much easier than the debugger interface...
You can get just about all the Thread info you need including deadlocks from http://java.sun.com/javase/6/docs/api/java/lang/management/ThreadMXBean.html
Thread.getAllStackTraces() dumps only the execution trace of all the threads, but doesn't give the information of object locks that have been obtained by a particular thread or the lock on which a particular thread has been waiting. Basically, we'll not be able to nail down deadlocks with this.
Did you consider the remote alternative ? I.e. VisualVM
jps and jstack are also useful tools included in JDK 5, providing a quick command line method for obtaining stack traces of all current threads.
This article suggest JDI is also used as a remote tool.
So I am not sure you can triggers a thread dump within your own program, instead you find a way to send to yourself a SIGQUIT signal (kill -3) on Unix platforms, or press the Ctrl-\ key on Unix or Ctrl-Break on Windows platforms.
Plus, JDI wasn't intended to be used to debug the same process in which the JDI client is running. Still this thread I just linked to is the closest I have found to actually use JDI within the same program.
Related
I am using eclipse to write java code. If I'm debugging some code I can set a breakpoint and follow along as the code goes through each of the functions or I can backtrack. I can also look at the call hierarchy or the references to get an idea. But that's not enough.
I would like to have a some sort of time-based visualization of what each thread is doing along the process from ... let's say "point A" (pressing a button on the interface) to "point B" (getting the result). I want to see which classes/methods were called in what order. I want a good way to visualize what kind of output is coming from one method and going into another method which fires off a new process ...etc.
Is a profiler the only thing available for this type of visualization? Basically I want an action diagram or flow diagram created. Is there some plugin or app which can generate something like this?
Edit: Here is an example of what I'm thinking ... at least visually:
essmodel.sourceforge.net/index.html
It has some flow of where the code is leading. But I think this is just a static map of what classes lead to other classes and what inputs/output options are available. I would want to map the flow based on a specific case.
JProfiler offers such a view, it's called the "Call tracer":
It's important to restrict your filters very carefully in order not to record to much data.
Disclaimer: My company develops JProfiler.
I believe using a profiler is going to be your best option. Are you familiar with VisualVM? It comes with the JDK (look for "jvisualvm.exe" inside your JDK's bin directory) and is capable of profiling local virtual machines automatically as well as remote machines when configured properly. And it does give a pretty slick overview of what threads are running and the code they are spending time in, so I think you could easily do what you need from it. And best of all, it's free :)
As I said, local profiling is a breeze. You just run JVisualVM.exe standalone, and it will find any and all java processes running on the local machine automatically (you can just pick them out of a menu that VisualVM gives you upfront). If you want to profile remotely, set the following VM arguments for whatever it is that you're running:
-Dcom.sun.management.jmxremote.port=[0-65535]
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
Then within VisualVM, use the hostname of the machine your remote JVM is running on and the port you configured in the first VM argument above.
I am looking for any tool that allows me to see how objects are created on heap in run time.
I was using VisualVM - Profiles but was not able to find when a variable of specific type (the one I am looking for) is being created. Maybe I do something wrong...
I will be also thankful getting any hint how to get such information using any API.
Regards,
Marcin
Typically, profilers (such as JProfiler) will allow you to see this - see for example the Allocation recording explained screencast.
However, they achieve this by attaching an agent to the JVM that allows them to intercept the low-level operations - this information is not usually available to either users or Java programs. As such, you won't be able to see the heap via JMX apps such as JConsole or JVisualVM.
Inside VisualVM Profiler, select the Settings and specify the class you want to profile. May be you also need to look on the option which record allocation stacks.
It sounds like you are trying to debug a program and that using the debugger would be the best option. You should be able to add a conditional breakpoint to stop the program when a variable is assigned the value you are looking for. This will allow you to see all the values at that time and the call stack to see what was called to create it.
I've looked through couple of articles here such as:
java stack dump on windows
Thread dump programmatically /JDI (Java Debugger Interface)
But didnt catch the exact answer.
The problem:
There is a Java5 Application on Windows that's runs as a service (so we dont have a console where we are able to use Ctrl+Break for Dumping).
And sometimes Application hangs and we need a thread dump.
We've tried "jstack" but it doesnt work in our env (we found out that its Java6 only compatible).
So we made a C++ app that calls thread dump via .dll call method attaching to the Java app process, and because of this it needs Local Admin rights, that is not so good.
So we'd like other options that works without admin rights and works with Java 5 without lots of rework of existing code.
Method with Printing in LOOP thread dumps (Thread.getAllStackTraces()) is not an option because we need to refactor lots of applications in order to make it work.
So that just an util that works from "outside" of applications would be a best option.
Thanks in advance!
One option is to dump all the information using jmap, and then analyzing it using other tool.
jmap -dump:format=b,file=<filename>.hprof <jvm_pid>
I am not sure, buy I think it will work on Java 5.
References:
HPjmeter-like graphical tool to view -agentlib:hprof profiling output
You can attach to the process with JConsole to detect deadlocks and get stack traces of the threads. For more information, see here: http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html
I'm wondering if it's possible to get a handle on running instances of a given class. The particular issue that triggered this was an application that doesn't exit nicely because of a number of running threads.
Yes, I know you can daemonize the theads, and they won't then hold up the application exit. But it did get me to wondering if this was possible. The closest thing I can is the classloaders (protected!) findLoadedClass, although you'd have to run through your own classloader to do this.
On a related note, is this how profiling tools manage to track object handles? by running through their own custom classloaders? or is there some nice tricky way that I'm not seeing?
You can indeed get a stack trace of all running Threads dumped to the stdout by using kill -QUIT <pid> on a *NIX like OS, or by running the application in a Windows console and pressing Ctrl-Pause (as another poster notes.)
However, it seems like you're asking for programmatic ways to do it. So, assuming what you really want is the set of all Threads who's current call stacks include one or more methods from a given class...
The best thing I can find that doesn't involve calls into the JVMTI is to inspect the stacks of all running threads. I haven't tried this, but it should work in Java 1.5 and later. Keep in mind that this is, by definition, not AT ALL thread-safe (the list of running threads - and their current stack traces - are going to constantly change underneath you...lots of paranoid stuff would be necessary to actually make use of this list.)
public Set<Thread> findThreadsRunningClass(Class classToFindRunning) {
Set<Thread> runningThreads = new HashSet<Thread>();
String className = classToFindRunning.getName();
Map<Thread,StackTraceElement[]> stackTraces = Thread.getAllStackTraces();
for(Thread t : stackTraces.keySey()) {
StackTraceElement[] steArray = stackTraces.get(t);
for(int i = 0;i<steArray.size();i++) {
StackTraceElement ste = steArray[i];
if(ste.getClassName().equals(className)) {
runningThreads.add(t);
continue;
}
}
}
return runningThreads;
}
Let me know if this approach works out for you!
From this page,
A Java profiler uses a native interface to the JVM (the JVMPI for Java <=1.4.2 or the JVMTI for Java >=1.5.0) to get profiling information from a running Java application.
This amounts to some Sun supplied native code that gives a profiler hooks into the JVM.
If you only need a quick stack trace of your running application to find out which threads are blocking the JVM exit, you can send it the QUIT signal.
$ kill -QUIT <pid of java process>
Under Windows you need to run the application in a console window (using java.exe, not javaw.exe), then you can press Ctrl-Pause to generate the stack dump. In both cases it’s written to stdout.
I use Visual VM to monitor the JVM. Has lots of features, give it a try.
I think you need a Java thread dump. This should list all threads with what they are doing at the moment. I had a similar problem myself, which a thread dump helped solve (Quartz scheduler threads, which did not exit when Tomcat finished).
I just installed Java 1.6_07 so I could try profiling with VisualVM. It tells me that my app is spending 60% of its time in sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run
How do I find out what it was doing during that time? How much of the time was it waiting for something to call it, or doing something else? What was calling it and what was it calling? I just can't seem to find any way to drill down to deeper levels like there is in Quantify or the Perl profiler.
I don't have experience with VisualVM -- but JRockit's profiler does provide this information; you may consider using it instead.
Update: a question with a list of java profilers can be found here, for users with sufficient rep to view deleted questions.
Does your App use RMI over TCP? If not, is it possible that this is a heisenbug, caused by instrumenting the VM? I assume VisualVM must use RMI calls to figure out what's going on in the JVM....
I have started using the new VisualVM 1.2. It allows profiling CPU and drilling down using a call graph. Try it out.
Using 1.3.2 also seeing this being the reported hangup I am hitting. In 1.3.2 if you do a thread dump and look for this call you can see where it lands in the call chain for that thread. Not sure if Yuval F was referring to this or something else. Look up the call chain to see what it's calling and so on, look down to see what it's being called by and so on.