- Really? How?
- I create and start the JME (lwjgl) thread, then in a SwingUtilities.invokeLater() I create the AWT panel and I start the EDT creating the Swing GUI. In order to draw the swing GUI I use JMEApp.enqueue() to get necessary data from the JME (lwjgl) thread. I don’t get why this is causing freezes (locks?) :S
@AXELTOPOLINO said: 1) Really? How? :D 2) I create and start the JME (lwjgl) thread, then in a SwingUtilities.invokeLater() I create the AWT panel and I start the EDT creating the Swing GUI. In order to draw the swing GUI I use JMEApp.enqueue() to get necessary data from the JME (lwjgl) thread. I don't get why this is causing freezes (locks?) :S
Well, we can’t see the code… so I guess you’ll have to sort it out yourself. For example, calling enqueue does no good if you then call get on it without checking to see if it’s done. We can assume probably 100 different things that “might” be wrong… only your code has the actual answer.
Yeah you are right, but the software is now pretty big so it will be difficult to post just the critical code. I’ll try anyway.
By the way, you said “calling enqueue does no good if you then call get on it without checking to see if it’s done”, so it’s like if the JME thread is still not ready (but I have started it…). So how do I check if the JME thread is ready? I thought it wasn’t necessary because enqueue() should wait until the JME thread is ready, or am I wrong? (With the Canvas, enqueue() was working, not with the AWTPanel).
Thanks for the patience you have 
UPDATE:
From what I see from the console output, it seems that the enqueue() is correctly done only if it is executed before this:
OGL: Enter showing state.
OGL: Visible. Create strategy.
If these 2 lines are in the console before the enqueue() is done, then the enqueue doesn’t work.
Does it have any sense?
@AXELTOPOLINO said: Yes, you're right, it must be for sure the right way. But I have 2 problems: 1. AWT panel is unloaded when I detach it (I need to reattach in another tab everytime the user changes tab)Not sure what you mean there. What is "unloaded"? You mean you cannot detach and reattach without it stopping rendering?
@AXELTOPOLINO said: 2. AWT panel seem to thread lock at the beginning: I create the AWT Panel (so the LWJGL thread) and start the JME app. Then I create my Swing GUI which requires some data from the JME thread (which is supposely the LWJGL thread) and the software just freezes.When you start an AWT panel context, it creates a fully functional OpenGL context so you can access it at that point. You do not need to have an AWT panel to access jME. You can wait for the context thread to initialize by using context.waitFor() call. After you do your stuff, you can then add the panel.
1 Like
@Momoko_Fan said: Not sure what you mean there. What is "unloaded"? You mean you cannot detach and reattach without it stopping rendering?When you start an AWT panel context, it creates a fully functional OpenGL context so you can access it at that point. You do not need to have an AWT panel to access jME. You can wait for the context thread to initialize by using context.waitFor() call. After you do your stuff, you can then add the panel.
For the first point, I have solved. I think I did some stupid mistakes initializing the awt panel 
Forgive my newbieness, could you explain or give any reference about what you tried to explain to me?
Because, from what I have understood, the AWT context is a fully functional OpenGL context and I must wait its initalization before starting asking JME data from the SWING thread (EDT). The problem is that I cannot find the context.waitFor() method and I feel so dumb ahah
Many thanks to both of you guys!
As always, UPDATE:
I simply used wait() and notify() on the 2 threads and everything works correctly until I enqueue JME data from the paintComponent() method of my custom JPanel. If I use enqueue() from other parts of the code, it works smoothly.
This is weird, because in the paintComponent() I’m in the EDT (Swing thread) and I should really enqueue JME data (and it should work correctly).
This is my custom JPanel:
public MyCustomPanel(int x, int y) {
super();
this.x = x;
this.y = y;
}
@Override
protected void paintComponent(Graphics g) {
System.out.println("PAINT COMPONENT CALLED "+Thread.currentThread().getName());
Main.enqueueCheck();
super.paintComponent(g);
}
So as you can see, I’m using enqueue() in the paintComponent method, but this causes the program to freeze. In fact the output console stops after writing “PAINT COMPONENT CALLED AWT-EventQueue-0” and no error is thrown.
Am I missing something about the paintComponent method? :S
@AXELTOPOLINO said: As always, UPDATE: I simply used wait() and notify() on the 2 threads and everything works correctly until I enqueue JME data from the paintComponent() method of my custom JPanel. If I use enqueue() from other parts of the code, it works smoothly. This is weird, because in the paintComponent() I'm in the EDT (Swing thread) and I should really enqueue JME data (and it should work correctly). This is my custom JPanel:public MyCustomPanel(int x, int y) { super(); this.x = x; this.y = y; }@Override protected void paintComponent(Graphics g) { System.out.println("PAINT COMPONENT CALLED "+Thread.currentThread().getName()); Main.enqueueCheck(); super.paintComponent(g); }
So as you can see, I’m using enqueue() in the paintComponent method, but this causes the program to freeze. In fact the output console stops after writing “PAINT COMPONENT CALLED AWT-EventQueue-0” and no error is thrown.
Am I missing something about the paintComponent method? :S
re: “So as you can see, I’m using enqueue() in the paintComponent method”
…no, we can’t see because you haven’t included that. You’ve only included a call to a custom method that might be doing something like that if we assume it from the name. If that method happens to block the EDT thread then anything trying to communicate similarly with the EDT thread will deadlock. A pure deadlock can even be detected if you run from the command line, get in the locked state, and then press Ctrl-Break on the command line window. (on windows)
Ok, so this is the enqueueCheck method. It’s in the Main class:
public static void staticCheck() {
try {
final ModelData modelData = (ModelData) Main.app.enqueue(new Callable() {
public ModelData call() throws Exception {
if (Main.app.modelNode == null) {
return null;
}
return Main.app.modelNode.getUserData("data");
}
}).get();
System.out.println("CHECK OUTSIDE ENQUEUE : " + modelData+ " | " + Thread.currentThread().getName());
} catch (Exception ex) {
Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
}
}
This doesn’t throw any exception but the console will never print the text as the software just blocks before.
This happens only if I call this method in the paintComponent(), but it works correctly if I call it from anywhere else in the EDT (Swing thread) and I don’t understand why.
Tell me if you need any other information and as always I really appreciate your support
Since that method blocks you are probably experiencing a deadlock of some kind.
@pspeed said: A pure deadlock can even be detected if you run from the command line, get in the locked state, and then press Ctrl-Break on the command line window. (on windows)
On other platforms there is a way to send a kill signal to Java to get it to do a thread dump. The thread dump will show any pure deadlocks.
@AXELTOPOLINO said: Forgive my newbieness, could you explain or give any reference about what you tried to explain to me? Because, from what I have understood, the AWT context is a fully functional OpenGL context and I must wait its initalization before starting asking JME data from the SWING thread (EDT). The problem is that I cannot find the context.waitFor() method and I feel so dumb ahahAh sorry... Looks like its an internal method which is called from JmeContext.create()... Regardless, you can always just wait for jME to initialize by calling obj.notifyAll() in your simpleInitApp() callback (where obj is your event / notification object). Then do your stuff.
Essentially, when you start a jME3 application which uses AWT panels, it creates an OpenGL context on another (separate) thread. This thread runs in parallel to the EDT and all other application threads. This thread runs at reduced FPS until you actually create and attach an AWT panel to your UI, then jME3 starts rendering at full speed.
@pspeed said: Since that method blocks you are probably experiencing a deadlock of some kind.On other platforms there is a way to send a kill signal to Java to get it to do a thread dump. The thread dump will show any pure deadlocks.
This is what I was trying to say, the program has a deadlock for an unknown reason, and this happen ONLY when I use enqueue() in the paintComponent() method of a Swing component.
And I cannot run from cmd line the code (I followed this: https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:simpleapplication_from_the_commandline ) as it doesn’t find my Main class…
I also tried to detect the deadlock programmatically using the following code, but it doesn’t find any deadlock (could it not be a deadlock?!):
ThreadMXBean bean = ManagementFactory.getThreadMXBean();
long[] threadIds = bean.findDeadlockedThreads(); // Returns null if no threads are deadlocked.
if (threadIds != null) {
ThreadInfo[] infos = bean.getThreadInfo(threadIds);
for (ThreadInfo info : infos) {
StackTraceElement[] stack = info.getStackTrace();
// Log or store stack trace information.
}
}
Seriously swimming in a sea of desperation now, I thought I knew how Swing works 
@Momoko_Fan said: Ah sorry... Looks like its an internal method which is called from JmeContext.create()... Regardless, you can always just wait for jME to initialize by calling obj.notifyAll() in your simpleInitApp() callback (where obj is your event / notification object). Then do your stuff.Essentially, when you start a jME3 application which uses AWT panels, it creates an OpenGL context on another (separate) thread. This thread runs in parallel to the EDT and all other application threads. This thread runs at reduced FPS until you actually create and attach an AWT panel to your UI, then jME3 starts rendering at full speed.
I’m already doing it. This is in the main() of the Main class:
SwingUtilities.invokeLater(new Runnable() {
@Override
public void run() {
createAWTPanel();
synchronized (JMEapp) {
try {
System.out.println("Waiting for JME to complete...");
app.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("JME should have started");
}
JPopupMenu.setDefaultLightWeightPopupEnabled(false);
createFrame();
frame.pack();
frame.setLocationRelativeTo(null);
frame.setVisible(true);
}
});
And then in my JMEapp, at the very end of the simpleInitApp() method:
synchronized (this) {
System.out.println("JME COMPLETE!");
notify();
}And the prints are correctly called, in fact I can enqueue data from any part of the Swing thread (EDT) except from the paintComponent() method.
Seems I still have to learn these basics :S
Here is how you start a JME app from the command line:
java -jar myAppsJar.jar
…from the directory where the jar is and where there is a ./lib subdirectory with all of the jars.
Anyway, I guess you don’t have a class deadlock. Just something is waiting for something to happen but it never will because the EDT thread is blocked… and that something is blocking the JME render thread.
Personally, I can’t see any reason to block at all if you’d just make everything asynchronous. You will save yourself a lifetime of pain as a software developer if you avoid blocking whenever possible.
`@Override
public void run() {
createAWTPanel();
synchronized (JMEapp) {
try {
System.out.println("Waiting for JME to complete...");
app.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("JME should have started");
}
JPopupMenu.setDefaultLightWeightPopupEnabled(false);
createFrame();
frame.pack();
frame.setLocationRelativeTo(null);
frame.setVisible(true);
}
});`
Move the createAWTPanel() part until after the wait.
@pspeed: Which other deadlock types exist?
@Momoko: Thanks for the tip, but I already tried that with no success.
I’ve created a very small and simple app that reproduces the problem. It has only 3 small classes (one of them is the custom panel that is causing this crazy mess). Would you be so kind to just check it and confirm that I haven’t done anything weird?
I’ve uploaded it on mediafire: https://www.mediafire.com/?4dnxojzci64v798
Many thanks!
@AXELTOPOLINO said: @pspeed: Which other deadlock types exist?
All kinds of types of deadlocks exist any time you have synchronous message passing. For example, let’s say you have the EDT blocked because you are waiting for the JME thread to process your enqueued() callable. Meanwhile, some JME process is waiting on the result of a SwingUtilities.inokeAndWait() (hypothetically). You then have a deadlock that is not one that the JVM will detect because no one is holding out of order locks… they are simply waiting for code to execute that never will. The JME thread will never pop off that Callable and run it… but there is no deadlock contention on the callable itself.
The same thing happens in networking all the time if you aren’t careful. This is largely why SpiderMonkey forces an asynchronous model… though even then you can manage to get in trouble if you are overly crafty (by effectively implementing synchronous behaviors). (For example, only accepting messages of type X while waiting for a response… if the other end does the same then you have a deadlock across the network completely undetectable by JVM means.)
@pspeed said: All kinds of types of deadlocks exist any time you have synchronous message passing. For example, let's say you have the EDT blocked because you are waiting for the JME thread to process your enqueued() callable. Meanwhile, some JME process is waiting on the result of a SwingUtilities.inokeAndWait() (hypothetically). You then have a deadlock that is not one that the JVM will detect because no one is holding out of order locks... they are simply waiting for code to execute that never will. The JME thread will never pop off that Callable and run it... but there is no deadlock contention on the callable itself.The same thing happens in networking all the time if you aren’t careful. This is largely why SpiderMonkey forces an asynchronous model… though even then you can manage to get in trouble if you are overly crafty (by effectively implementing synchronous behaviors). (For example, only accepting messages of type X while waiting for a response… if the other end does the same then you have a deadlock across the network completely undetectable by JVM means.)
I see, thanks for the useful info! Excluding the network deadlock, the first one could, as you said, hypothetically happen in my software, but still I haven’t detected it.
Has anyone tried my simple test code? It’s really small and it’s already set as JME project
I’ve also semplified more the test code: https://www.mediafire.com/?4dnxojzci64v798
Please give me any feedback about this very basic code…
UPDATE:
I’ve used CTRL+BREAK to check the threads and I see one of them in the BLOCKED state, but I don’t understand much here, any guess?
C:\Users\user\Coding\Projects\JMonkeyEngine\SwingDeadLock\dist>java -jar MyGame. jar CREATING APP AND STARTING IT. THREAD IS: main INVOKELATER Waiting for JME to complete... nov 22, 2014 10:52:20 AM com.jme3.asset.AssetConfig loadText AVVERTENZA: Cannot find loader com.jme3.scene.plugins.blender.BlenderModelLoaderJMEAPP INIT. THREAD IS: LWJGL Renderer Thread
JME COMPLETE! SO NOTIFYING THE THREAD
OGL: Throttling update loop.
JME should have started (I guess…)
AWT Panel created and attached to app.viewPort
EDT: addNotify
PAINT COMPONENT CALLED. THREAD IS: AWT-EventQueue-0
OGL: Enter showing state.
OGL: Visible. Create strategy.
2014-11-22 10:52:43
Full thread dump Java HotSpot™ 64-Bit Server VM (24.60-b09 mixed mode):“D3D Screen Updater” daemon prio=8 tid=0x0000000010b16000 nid=0xc9c in Object.wa
it() [0x000000001300f000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000e1224280> (a java.lang.Object)
at sun.java2d.d3d.D3DScreenUpdateManager.run(Unknown Source)
- locked <0x00000000e1224280> (a java.lang.Object)
at java.lang.Thread.run(Unknown Source)“jME3 Audio Thread” daemon prio=6 tid=0x000000000b976800 nid=0x36dc waiting on c
ondition [0x000000000fb7f000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at com.jme3.audio.lwjgl.LwjglAudioRenderer.run(LwjglAudioRenderer.java:1
24)
at java.lang.Thread.run(Unknown Source)“DestroyJavaVM” prio=6 tid=0x000000000036d800 nid=0x6b1c waiting on condition [0
x0000000000000000]
java.lang.Thread.State: RUNNABLE“AWT-EventQueue-0” prio=6 tid=0x000000000b8d3000 nid=0x7b70 waiting on condition
[0x000000000ec5c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000e1280218> (a java.util.concurrent.lock
s.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject
.await(Unknown Source)
at com.jme3.app.AppTask.get(AppTask.java:89)
at mygame.Main.staticCheck(Main.java:114)
at mygame.CustomPanel.paintComponent(CustomPanel.java:18)
at javax.swing.JComponent.paint(Unknown Source)
at javax.swing.JComponent.paintChildren(Unknown Source)
- locked <0x00000000e0616770> (a java.awt.Component$AWTTreeLock)
at javax.swing.JComponent.paint(Unknown Source)
at javax.swing.JComponent.paintChildren(Unknown Source)
- locked <0x00000000e0616770> (a java.awt.Component$AWTTreeLock)
at javax.swing.JComponent.paint(Unknown Source)
at javax.swing.JLayeredPane.paint(Unknown Source)
at javax.swing.JComponent.paintChildren(Unknown Source)
- locked <0x00000000e0616770> (a java.awt.Component$AWTTreeLock)
at javax.swing.JComponent.paintToOffscreen(Unknown Source)
at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(Unknown S
ource)
at javax.swing.RepaintManager$PaintManager.paint(Unknown Source)
at javax.swing.RepaintManager.paint(Unknown Source)
at javax.swing.JComponent.paint(Unknown Source)
at java.awt.GraphicsCallback$PaintCallback.run(Unknown Source)
at sun.awt.SunGraphicsCallback.runOneComponent(Unknown Source)
at sun.awt.SunGraphicsCallback.runComponents(Unknown Source)
at java.awt.Container.paint(Unknown Source)
at java.awt.Window.paint(Unknown Source)
at javax.swing.RepaintManager$3.run(Unknown Source)
at javax.swing.RepaintManager$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Sour
ce)
at javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
at javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
at javax.swing.RepaintManager.prePaintDirtyRegions(Unknown Source)
at javax.swing.RepaintManager.access$1100(Unknown Source)
at javax.swing.RepaintManager$ProcessingRunnable.run(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$200(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Sour
ce)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)“LWJGL Renderer Thread” prio=6 tid=0x000000000b8d5800 nid=0x7f78 waiting for mon
itor entry [0x000000000eb3e000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.awt.Window.getOpacity(Unknown Source)
- waiting to lock <0x00000000e0616770> (a java.awt.Component$AWTTreeLock
)
at sun.awt.SunToolkit.isContainingTopLevelTranslucent(Unknown Source)
at sun.awt.windows.WComponentPeer.isAccelCapable(Unknown Source)
at sun.java2d.d3d.D3DSurfaceData$D3DWindowSurfaceData.restoreSurface(Unk
nown Source)
at sun.java2d.d3d.D3DScreenUpdateManager.validate(Unknown Source)
at sun.java2d.d3d.D3DScreenUpdateManager.createGraphics(Unknown Source)
at sun.awt.windows.WComponentPeer.getGraphics(Unknown Source)
at java.awt.Component.getGraphics(Unknown Source)
at java.awt.Component$SingleBufferStrategy.getDrawGraphics(Unknown Sourc
e)
at com.jme3.system.awt.AwtPanel.drawFrameInThread(AwtPanel.java:194)
- locked <0x00000000e0855fe0> (a java.lang.Object)
at com.jme3.system.awt.AwtPanel.postFrame(AwtPanel.java:305)
at com.jme3.renderer.RenderManager.renderViewPort(RenderManager.java:987
)
at com.jme3.renderer.RenderManager.render(RenderManager.java:1029)
at com.jme3.app.SimpleApplication.update(SimpleApplication.java:252)
at com.jme3.system.awt.AwtPanelsContext.updateInThread(AwtPanelsContext.
java:188)
at com.jme3.system.awt.AwtPanelsContext.access$100(AwtPanelsContext.java
:44)
at com.jme3.system.awt.AwtPanelsContext$AwtPanelsListener.update(AwtPane
lsContext.java:68)
at com.jme3.system.lwjgl.LwjglOffscreenBuffer.runLoop(LwjglOffscreenBuff
er.java:125)
at com.jme3.system.lwjgl.LwjglOffscreenBuffer.run(LwjglOffscreenBuffer.j
ava:151)
at java.lang.Thread.run(Unknown Source)“AWT-Windows” daemon prio=6 tid=0x000000000b8df000 nid=0x7f28 runnable [0x000000
000c25f000]
java.lang.Thread.State: RUNNABLE
at sun.awt.windows.WToolkit.eventLoop(Native Method)
at sun.awt.windows.WToolkit.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)“AWT-Shutdown” prio=6 tid=0x000000000b8da800 nid=0x7f14 in Object.wait() [0x0000
00000c09e000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000e0626c20> (a java.lang.Object)
at java.lang.Object.wait(Object.java:503)
at sun.awt.AWTAutoShutdown.run(Unknown Source)
- locked <0x00000000e0626c20> (a java.lang.Object)
at java.lang.Thread.run(Unknown Source)“Java2D Disposer” daemon prio=10 tid=0x000000000b8c9800 nid=0x7c9c in Object.wai
t() [0x000000000be7f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000e0626660> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
- locked <0x00000000e0626660> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
at sun.java2d.Disposer.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)“Service Thread” daemon prio=6 tid=0x0000000009b2d000 nid=0x7674 runnable [0x000
0000000000000]
java.lang.Thread.State: RUNNABLE“C2 CompilerThread1” daemon prio=10 tid=0x0000000009b2c800 nid=0x3510 waiting on
condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE“C2 CompilerThread0” daemon prio=10 tid=0x0000000009b1f000 nid=0x2fe4 waiting on
condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE“Attach Listener” daemon prio=10 tid=0x0000000009b1e800 nid=0x67d0 runnable [0x0
000000000000000]
java.lang.Thread.State: RUNNABLE“Signal Dispatcher” daemon prio=10 tid=0x0000000009b16800 nid=0x1e60 waiting on
condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE“Finalizer” daemon prio=8 tid=0x0000000009ac6000 nid=0x6dd4 in Object.wait() [0x
000000000ac4f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000e0305630> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
- locked <0x00000000e0305630> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)“Reference Handler” daemon prio=10 tid=0x0000000009abf000 nid=0x60fc in Object.w
ait() [0x000000000a8ff000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000e03051b8> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:503)
at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)
- locked <0x00000000e03051b8> (a java.lang.ref.Reference$Lock)“VM Thread” prio=10 tid=0x0000000009ab9800 nid=0x75c8 runnable
“GC task thread#0 (ParallelGC)” prio=6 tid=0x000000000223c000 nid=0x75fc runnabl
e“GC task thread#1 (ParallelGC)” prio=6 tid=0x000000000223d800 nid=0x6b00 runnabl
e“GC task thread#2 (ParallelGC)” prio=6 tid=0x000000000223f800 nid=0x7d9c runnabl
e“GC task thread#3 (ParallelGC)” prio=6 tid=0x0000000002241000 nid=0x64c0 runnabl
e“VM Periodic Task Thread” prio=10 tid=0x0000000009b37800 nid=0x6ee4 waiting on c
onditionJNI global references: 453
Heap
PSYoungGen total 28672K, used 18618K [0x00000000e0300000, 0x00000000e23000
00, 0x0000000100000000)
eden space 24576K, 75% used [0x00000000e0300000,0x00000000e152eb90,0x00000000e
1b00000)
from space 4096K, 0% used [0x00000000e1f00000,0x00000000e1f00000,0x00000000e23
00000)
to space 4096K, 0% used [0x00000000e1b00000,0x00000000e1b00000,0x00000000e1f
00000)
ParOldGen total 65024K, used 0K [0x00000000a0a00000, 0x00000000a4980000,
0x00000000e0300000)
object space 65024K, 0% used [0x00000000a0a00000,0x00000000a0a00000,0x00000000
a4980000)
PSPermGen total 21504K, used 12873K [0x000000009b800000, 0x000000009cd000
00, 0x00000000a0a00000)
object space 21504K, 59% used [0x000000009b800000,0x000000009c4926f0,0x0000000
09cd00000)