with threads & swing, the event queue (event dispatch thread) is broadly presented & discussed.
However, when examining the thread states with a Swing application, there's also a thread named Swing-Shell. With brief googling I couldn't find much details, mostly thread stack traces with bug reports etc.
Can somebody describe shortly what that thread does. Or even better, does somebody have some link to some documentations
EDIT: I was asking too fast without enough details, sorry. I was going though various
JFileChooser issues and a thread named "Swing-Shell" occurs there, having
something to do with Windows COM services for file system.
A sample stack trace within a deadlock problem can be found at
Sun Bug #6741890.
(The thread stack trace starts with sun.awt.shell.Win32ShellFolderManager2$ComInvoker$3.run).
With closer inspection with jconsole, I noticed that the thread isn't present there until
I have used JFileChooser (JFileChooser for example; the Swing-Shell thread will probably be started
by any components using Win32ShellFolderManager)
The thread seems to exist also after the usage of JFileChooser.
So, answering to myself, the thread seems to be a separate thread used for COM services with
file-related operations (with Windows only? ). If somebody can provide more details, welcome =)
The number, purpose and naming of initial threads is implementation dependent. On my platform, the event dispatch thread (EDT) is named AWT-EventQueue-0.
Addendum: The only other reference I found says, "A Motif application uses a shell widget to communicate with the window manager." Are you using a Swing library of some kind?
As suggested above, a thread dump might be illuminating. Recent versions of NetBeans' profiler include a save button; I've attached a snapshot of the threads in a typical busy demo.
Related
I am facing this issue of JavaFx thread freezing randomly, found a solution online i.e
<jvmArgs>
<jvmArg>-Dprism.verbose=true</jvmArg>
<jvmArg>-Dprism.order=sw</jvmArg>
</jvmArgs>
Can anyone help me in where to implement this code?
In general without more information if a program hangs you can do a thread dump. Interpreting the result might be tricky, so this is something for advanced users. You could now see where the java fx UI thread(also called main thread or application thread) is and what it is doing. Maybe it is waiting or it is running in circles(would need several dumps to see that).
Tho given your description it sounds like a linux/javafx bug. I faced several of them lately. One example https://github.com/FAForever/downlords-faf-client/issues/1353 .
I've just started programming in Java, and I'm interested in how computers distribute their CPU load. I have made a very basic program that creates a window and makes a box and line move. While testing this, I looked at Task Manager; Task manager said I was using ~1% of my CPUs. however, when I ran my program, the CPU usage went up to ~36% (I only started the program, nothing else). Can anyone tell me what is going on here, please?
You think that your program has only one thread, but in reality every Java program has lots of threads. GUI apps have the Event Dispatch Thread, garbage collection has its own thread etc. You can use a profiler (like the VisualVM that is in the JDK) to see all the threads in your app.
Or you can see them programmatically, see Get a List of all Threads currently running in Java
I am working on a Java application which has a threading issue.
While using the applications for some time with Netbeans profiler attached, I can see several threads are created. Most of them finish in some .5 seconds. I could only find SwingWorkers used in the application.
Moreover, the majority of threads displayed by the profiler are normal threads and not SwingWorkers. Unless these threads were created by SwingWorker indirectly, I suspect, some library that the application uses is creating them.
Now I would like to remove this issue. But I could not find a way to determine the source of thread creation. If you can please suggest some other profiler/tool by means of which I can find the source(method) of thread creation.
If using Eclipse and its debugger is an option, you might try the following:
Import the code into a Java project.
Ctrl-Shift-T (Open Type), enter "Thread". The binary source editor for the Thread class opens.
Select all the Thread constructors in the Outline view, use context menu "Toggle Method Breakpoint". That creates breakpoints for the constructors.
Run and debug.
Alternatively
You could get the Yourkit Java profiler, which is also available for evaluation. It can show the threads created in an application including their stack traces (also after the thread finished). It does not show where the threads were created, but the stack trace of the threads might give you some clues about the involved libraries.
JProfiler can do that. The thread monitor view shows the stack trace where a thread was created - if CPU recording was active at that time:
Disclaimer: My company develops JProfiler
We are experiencing a bug we cannot track down where something is freezing up our swing thread (it's been almost 2 weeks now and no real results) - we are experienced Swing programmers but we have a huge program and believe it to be in some of the legacy code
I am wondering, is there any way outside of editing the actual EventQueue class in the JDK which will allow us to view all pieces of our code currently running on the Event Dispatch Thread - maybe some type of tool which will allow us to view things as they enter or leave the event dispatch thread?
One interesting approach is to extend EventQueue and push() it, as shown here.
Logging everything that passes through the Event Dispatch Thread seems a cumbersome way to diagnose a freeze. Wouldn't it be easier to wait until the problem occurs, and then ask the Event Dispatch Thread what it's doing now? One way to do this is to enable JMX monitoring, connect to your running process with a JMX client such a VisualVM (which ships with the JDK), wait for the problem to occur, and then take a thread dump.
In case you still wish to log everything the Event Dispatch Thread is doing, you can do this by:
In Eclipse, launch the application in debug mode.
Create a breakpoint on EventQueue.dispatchEvent, right-click it, select "properties", check "condition", and enter the following "condition":
System.out.println(arg0);
return false;
It might be good idea to try BTrace to instrument the EventQueue and capture stack traces each time something gets added. I think the latest VisualVM has plugins that will allow you to instrument a running JVM with a BTrace script.
If you're using the Oracle JRE, there is a TracedEventQueue included already. You can install it as mentioned before:
EventQueue eventQueue = Toolkit.getDefaultToolkit().getSystemEventQueue();
eventQueue.push(new TracedEventQueue());
Note, this will output a lot of output...
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.