Groups > comp.lang.java.programmer > #31994 > unrolled thread

javax.swing.Timer blocking program termination

Started by	Knute Johnson <nospam@rabbitbrush.frazmtn.com>
First post	2015-07-13 16:03 -0700
Last post	2015-07-15 11:05 -0700
Articles	20 on this page of 41 — 7 participants

Back to article view | Back to comp.lang.java.programmer

  javax.swing.Timer blocking program termination Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2015-07-13 16:03 -0700
    Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-13 20:27 -0400
      Re: javax.swing.Timer blocking program termination Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2015-07-13 17:46 -0700
        Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-13 21:35 -0400
          Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-13 22:13 -0400
            Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-13 22:27 -0400
            Re: javax.swing.Timer blocking program termination e.d.programmer@gmail.com - 2015-07-14 06:31 -0700
              Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-14 10:15 -0400
                Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-14 10:22 -0400
                Re: javax.swing.Timer blocking program termination e.d.programmer@gmail.com - 2015-07-14 07:39 -0700
                  Re: javax.swing.Timer blocking program termination Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-07-14 10:53 -0400
                    Re: javax.swing.Timer blocking program termination e.d.programmer@gmail.com - 2015-07-14 10:16 -0700
                      Re: javax.swing.Timer blocking program termination Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-07-14 13:25 -0400
                        Re: javax.swing.Timer blocking program termination e.d.programmer@gmail.com - 2015-07-14 10:45 -0700
                          Re: javax.swing.Timer blocking program termination Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-07-14 14:16 -0400
                            Re: javax.swing.Timer blocking program termination Gene Wirchenko <genew@telus.net> - 2015-07-14 12:56 -0700
                              Re: javax.swing.Timer blocking program termination Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-07-14 16:14 -0400
                                Re: javax.swing.Timer blocking program termination e.d.programmer@gmail.com - 2015-07-15 05:11 -0700
                                Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-15 08:33 -0400
                                  Re: javax.swing.Timer blocking program termination Martin Gregorie <martin@address-in-sig.invalid> - 2015-07-15 18:46 +0000
                                    Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-15 21:18 -0400
                                      Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-15 22:13 -0400
                  Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-14 10:55 -0400
                    Re: javax.swing.Timer blocking program termination Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2015-07-14 08:17 -0700
                      Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-14 11:42 -0400
                    Re: javax.swing.Timer blocking program termination Martin Gregorie <martin@address-in-sig.invalid> - 2015-07-14 18:35 +0000
                      Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-14 15:17 -0400
                        Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-14 15:36 -0400
                      Re: javax.swing.Timer blocking program termination Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-07-14 15:51 -0400
                        Re: javax.swing.Timer blocking program termination Martin Gregorie <martin@address-in-sig.invalid> - 2015-07-14 21:51 +0000
                          Re: javax.swing.Timer blocking program termination Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2015-07-14 15:08 -0700
                            Re: javax.swing.Timer blocking program termination Martin Gregorie <martin@address-in-sig.invalid> - 2015-07-15 01:16 +0000
                      Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-14 16:09 -0400
                        Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-14 18:32 -0400
                          Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-14 18:34 -0400
                            Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-14 20:31 -0400
                  Re: javax.swing.Timer blocking program termination Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2015-07-14 08:16 -0700
    Re: javax.swing.Timer blocking program termination Joerg Meier <joergmmeier@arcor.de> - 2015-07-14 08:32 +0200
    Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-14 22:18 -0400
    Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-15 08:26 -0400
      Re: javax.swing.Timer blocking program termination Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2015-07-15 11:05 -0700

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

#32039

From	Jeff Higgins <jeff@invalid.invalid>
Date	2015-07-15 21:18 -0400
Message-ID	<mo70u0$7e1$1@dont-email.me>
In reply to	#32037

On 07/15/2015 02:46 PM, Martin Gregorie wrote:

> Thanks for posting that.

In turn I'm grateful to posters here and elsewhere for
providing me the impetus to discover neat stuff that I
wouldn't have otherwise.
Over this past weekend I enjoyed viewing a large "painting"
of a graph visualization of 20 years of the artists email contacts.
Now I consider the same type of visualization of data from
my usenet/other forum combined with my browser history.

[toc] | [prev] | [next] | [standalone]

#32040

From	Jeff Higgins <jeff@invalid.invalid>
Date	2015-07-15 22:13 -0400
Message-ID	<mo744j$66t$1@dont-email.me>
In reply to	#32039

On 07/15/2015 09:18 PM, Jeff Higgins wrote:
> my usenet/other forum combined with my browser history.
A recent post here concerning the standard streams and
a post in another group concerning linkers/loaders
led through all of:
XINU, OpenCores, VHDL, JHDL, with many hundreds of
tendrils one of which resulted in the arrival today of
a very nice copy of the out of print;
Vogt, R. C. (1989).
Automatic generation of morphological set recognition algorithms.
New York: Springer-Verlag.

[toc] | [prev] | [next] | [standalone]

#32010

From	Jeff Higgins <jeff@invalid.invalid>
Date	2015-07-14 10:55 -0400
Message-ID	<mo3810$c12$1@dont-email.me>
In reply to	#32008

On 07/14/2015 10:39 AM, e.d.programmer@gmail.com wrote:
>
> I don't use swing timers personally.  I embed my Java in BBj (http://www.basis.com/bbj) which did nothing when I tried to use a swing timer, so I still just use java.util.Timer.
>
> Closing a window should never terminate a JVM unless you flag it as EXIT_ON_CLOSE which is not recommended.

> You may want a timer to be able to do some cleanup after the window closes,
> so if the timer is running a process which doesn't need to finish if the
> window closes you want to manually stop it in the window close event process.

Makes perfect sense to me.
But I'm still not sure how a <1 sec timer keeps the EDT alive
while a >1 sec timer doesn't - barring explicit stops in windowClosing.

>
> A method to stop all timers could be useful.  It appears you currently have to store a reference to any timers you create if you need to be able to stop them.
>

[toc] | [prev] | [next] | [standalone]

#32012

From	Knute Johnson <nospam@rabbitbrush.frazmtn.com>
Date	2015-07-14 08:17 -0700
Message-ID	<mo393q$g46$2@dont-email.me>
In reply to	#32010

On 7/14/2015 07:55, Jeff Higgins wrote:
> Makes perfect sense to me.
> But I'm still not sure how a <1 sec timer keeps the EDT alive
> while a >1 sec timer doesn't - barring explicit stops in windowClosing.

Exactly!

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#32013

From	Jeff Higgins <jeff@invalid.invalid>
Date	2015-07-14 11:42 -0400
Message-ID	<mo3apu$nac$1@dont-email.me>
In reply to	#32012

On 07/14/2015 11:17 AM, Knute Johnson wrote:
> On 7/14/2015 07:55, Jeff Higgins wrote:
>> Makes perfect sense to me.
>> But I'm still not sure how a <1 sec timer keeps the EDT alive
>> while a >1 sec timer doesn't - barring explicit stops in windowClosing.
>
> Exactly!
>
Maybe posing the question at another forum with a wider readership;
<https://community.oracle.com/community/java/java_desktop> Swing or AWT
Stackoverflow
I'd be interested in hearing an explanation.
Please post back if you get it figured out.

[toc] | [prev] | [next] | [standalone]

#32018

From	Martin Gregorie <martin@address-in-sig.invalid>
Date	2015-07-14 18:35 +0000
Message-ID	<mo3kpq$oua$1@dont-email.me>
In reply to	#32010

On Tue, 14 Jul 2015 10:55:20 -0400, Jeff Higgins wrote:

> Makes perfect sense to me.
> But I'm still not sure how a <1 sec timer keeps the EDT alive while a >1
> sec timer doesn't - barring explicit stops in windowClosing.
>

It occurs to me that, the way Knute's original example works, that he 
might have inadvertently set up a race condition because all the heavy 
lifting involved in setting up the JFrame, i.e. loading a shedload of 
classes and constructing instances from them all happens on the EDT and 
that this might well take a second or so to complete and still be running 
when the timer gets started. IOW, could the timer have fired its event 
before the default close operation had been defined and would the timer 
event have been ignored if it fired its event before the JFrame had been 
completed and displayed?

Of course, this may be a stupid idea, but it does fit the test results 
which show a short timeout being ignored while a longer one does what 
you'd expect. 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#32019

From	Jeff Higgins <jeff@invalid.invalid>
Date	2015-07-14 15:17 -0400
Message-ID	<mo3ncn$ar8$1@dont-email.me>
In reply to	#32018

On 07/14/2015 02:35 PM, Martin Gregorie wrote:

> IOW, could the timer have fired its event
> before the default close operation had been defined and would the timer
> event have been ignored if it fired its event before the JFrame had been
> completed and displayed?
>

Well, in the code Knute supplied in his original post
the timer isn't started until after the call to setVisible(true).
The timer is a repeating timer - it continues to fire events
at the delay rate. I guess that at a rate of more than one per
second the ThreadQueue (or whatever the controlling mechanism)
thinks there is work remaining to be done and will not allow the
EDT to shut down. Conversely, at a rate less than one per second
this mechanism thinks all work is done and the EDT is allowed
to expire.

Shrug.

public class test extends JFrame {
   public test() {
     Timer timer = new Timer(1000,event -> {});
     setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
     setSize(400,300);
     setVisible(true);
     timer.start(); }

   public static void main(String... args) {
     EventQueue.invokeLater(() -> new test()); }}

[toc] | [prev] | [next] | [standalone]

#32020

From	Jeff Higgins <jeff@invalid.invalid>
Date	2015-07-14 15:36 -0400
Message-ID	<mo3ogc$fam$1@dont-email.me>
In reply to	#32019

s/ThreadQueue/TimerQueue/

[toc] | [prev] | [next] | [standalone]

#32021

From	Eric Sosman <esosman@comcast-dot-net.invalid>
Date	2015-07-14 15:51 -0400
Message-ID	<mo3p67$i12$1@dont-email.me>
In reply to	#32018

On 7/14/2015 2:35 PM, Martin Gregorie wrote:
> On Tue, 14 Jul 2015 10:55:20 -0400, Jeff Higgins wrote:
>
>> Makes perfect sense to me.
>> But I'm still not sure how a <1 sec timer keeps the EDT alive while a >1
>> sec timer doesn't - barring explicit stops in windowClosing.
>>
>
> It occurs to me that, the way Knute's original example works, that he
> might have inadvertently set up a race condition because all the heavy
> lifting involved in setting up the JFrame, i.e. loading a shedload of
> classes and constructing instances from them all happens on the EDT and
> that this might well take a second or so to complete and still be running
> when the timer gets started. IOW, could the timer have fired its event
> before the default close operation had been defined and would the timer
> event have been ignored if it fired its event before the JFrame had been
> completed and displayed?
>
> Of course, this may be a stupid idea, but it does fit the test results
> which show a short timeout being ignored while a longer one does what
> you'd expect.

     I don't *think* that's it, but like you I'm not sure.

     I've been experimenting with this modified version of Knute's code:

import java.awt.EventQueue;
import javax.swing.JFrame;
import javax.swing.Timer;

public class Test extends JFrame {

    public Test(int millis, boolean repeats) {
       Timer timer = new Timer(millis, event -> {
       });
       timer.setRepeats(repeats);
       System.out.printf("%s: delay %d ms, repeats %s%n",
             timer, timer.getDelay(), timer.isRepeats());
       setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
       setSize(400, 300);
       setVisible(true);
       timer.start();
    }

    public static void main(String... args) {
       int millis = (args.length > 0) ? Integer.parseInt(args[0]) : 1000;
       boolean repeats = (args.length > 1) ? 
Boolean.parseBoolean(args[1]) : true;
       EventQueue.invokeLater(() -> new Test(millis, repeats));
    }
}

On my system (Java 1.8.0_45-b14, Windows 7 64-bit), I observe:

     - With a repeating Timer and a delay > 1000 ms, the JVM exits
       1-2 seconds after the frame closes.

     - With a repeating Timer and a delay == 1000 ms, the JVM exits
       10-25 seconds after the frame closes.

     - With a repeating Timer and a delay < 1000 ms, the JVM keeps on
       running after the frame closes, until I lose patience (> 1 min)
       and kill it manually.

     - With a *non*-repeating timer, the JVM exits 1-2 seconds after
       the frame closes.

     Here's a possible explanation, entirely uncontaminated by actual
facts: Suppose there's a bit of Java somewhere that monitors the EDT's
health by polling at about 1 Hz.  It asks "Hey, EDT, are you doing
anything important?"  As long as the JFrame is open, the EDT replies
"Yeah, I've got windows open."  The monitor says "Okey-doke" and goes
about its other business.

     After the frame closes, the EDT's reply changes to "There's nothing
open, but events are still coming along and I'm processing them."  The
monitor says "Ho-kay, you're still doing work" and dozes off again.

     But with a > 1000 ms delay, the EDT replies to the next query with
"No windows, and no events since you last asked." The monitor then says
"Okay, time to call it a day" and tells the EDT to pack it in.  The EDT
stops, the JVM sees there are no non-daemons running, and shutdown
commences.  With a delay of exactly 1000 ms there's a bit of a race
between the monitor and the Timer, and several query-response cycles may
pass before it Just So Happens that two queries bracket zero Timer
events, hence the long and variable post-close shutdown time in this
case.  And with a delay < 1000 ms, the Timer *always* fires at least
once between each pair of the monitor's queries, so the EDT *always*
reports that it's still doing work.  And with a non-repeating Timer the
EDT reports right away that there's nothing afoot.

     That sort of mechanism would account for what we've seen so far --
but "would account for" doesn't imply "is True."  The ancients explained
that invisible gods and demons moved the planets by blowing on them, but
nowadays such notions aren't widely accepted (outside of Washington DC).

     Still not a confirmation, but highly suggestive: I added

       addWindowListener(new WindowAdapter() {
          @Override
          public void windowClosed(WindowEvent evt) {
             timer.stop();
          }
       });

in the constructor, and found that the JVM *always* exited promptly
after the frame closed, no matter the Timer's delay or repeatability.
It really, really looks like the endless train of Timer events is
what's keeping the EDT alive.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#32025

From	Martin Gregorie <martin@address-in-sig.invalid>
Date	2015-07-14 21:51 +0000
Message-ID	<mo4088$9ph$1@dont-email.me>
In reply to	#32021

On Tue, 14 Jul 2015 15:51:55 -0400, Eric Sosman wrote:

> On my system (Java 1.8.0_45-b14, Windows 7 64-bit), I observe:
> 
>      - With a repeating Timer and a delay > 1000 ms, the JVM exits
>        1-2 seconds after the frame closes.
> 
>      - With a repeating Timer and a delay == 1000 ms, the JVM exits
>        10-25 seconds after the frame closes.
> 
>      - With a repeating Timer and a delay < 1000 ms, the JVM keeps on
>        running after the frame closes, until I lose patience (> 1 min)
>        and kill it manually.
> 
>      - With a *non*-repeating timer, the JVM exits 1-2 seconds after
>        the frame closes.
> 
>      Here's a possible explanation, entirely uncontaminated by actual
> facts: Suppose there's a bit of Java somewhere that monitors the EDT's
> health by polling at about 1 Hz.  It asks "Hey, EDT, are you doing
> anything important?"  As long as the JFrame is open, the EDT replies
> "Yeah, I've got windows open."  The monitor says "Okey-doke" and goes
> about its other business.
> 
>      After the frame closes, the EDT's reply changes to "There's nothing
> open, but events are still coming along and I'm processing them."  The
> monitor says "Ho-kay, you're still doing work" and dozes off again.
> 
>      But with a > 1000 ms delay, the EDT replies to the next query with
> "No windows, and no events since you last asked." The monitor then says
> "Okay, time to call it a day" and tells the EDT to pack it in.  The EDT
> stops, the JVM sees there are no non-daemons running, and shutdown
> commences.  With a delay of exactly 1000 ms there's a bit of a race
> between the monitor and the Timer, and several query-response cycles may
> pass before it Just So Happens that two queries bracket zero Timer
> events, hence the long and variable post-close shutdown time in this
> case.  And with a delay < 1000 ms, the Timer *always* fires at least
> once between each pair of the monitor's queries, so the EDT *always*
> reports that it's still doing work.  And with a non-repeating Timer the
> EDT reports right away that there's nothing afoot.
> 
>      That sort of mechanism would account for what we've seen so far --
> but "would account for" doesn't imply "is True."  The ancients explained
> that invisible gods and demons moved the planets by blowing on them, but
> nowadays such notions aren't widely accepted (outside of Washington DC).
> 
>      Still not a confirmation, but highly suggestive: I added
> 
>        addWindowListener(new WindowAdapter() {
>           @Override public void windowClosed(WindowEvent evt) {
>              timer.stop();
>           }
>        });
> 
> in the constructor, and found that the JVM *always* exited promptly
> after the frame closed, no matter the Timer's delay or repeatability. It
> really, really looks like the endless train of Timer events is what's
> keeping the EDT alive.
>
That looks reasonable to me. Better than my supposition, certainly: I was 
speculating that, because there are two threads running you could get out 
of order execution between stuff passed to the EDT to initialise and 
stuff run directly by the 'main' (implied) thread. And, of course, I 
forgot that the timer is running on the EDT.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#32026

From	Knute Johnson <nospam@rabbitbrush.frazmtn.com>
Date	2015-07-14 15:08 -0700
Message-ID	<mo415j$j95$1@dont-email.me>
In reply to	#32025

On 7/14/2015 14:51, Martin Gregorie wrote:
> That looks reasonable to me. Better than my supposition, certainly: I was
> speculating that, because there are two threads running you could get out
> of order execution between stuff passed to the EDT to initialise and
> stuff run directly by the 'main' (implied) thread. And, of course, I
> forgot that the timer is running on the EDT.

That's one of the issues, the timer doesn't run on the EDT, it just 
schedules its work on the EDT.

"Although all Timers perform their waiting using a single, shared thread 
(created by the first Timer object that executes), the action event 
handlers for Timers execute on another thread -- the event-dispatching 
thread."

It's not clear to me what "executes" is either, does that mean start() 
is called on a timer or a timer has reached the initial delay and called 
one of the event handlers?

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#32030

From	Martin Gregorie <martin@address-in-sig.invalid>
Date	2015-07-15 01:16 +0000
Message-ID	<mo4c8p$er4$1@dont-email.me>
In reply to	#32026

On Tue, 14 Jul 2015 15:08:11 -0700, Knute Johnson wrote:

> That's one of the issues, the timer doesn't run on the EDT, it just
> schedules its work on the EDT.
>
Yes, I saw that from Jeff's dumps.
 
> "Although all Timers perform their waiting using a single, shared thread
> (created by the first Timer object that executes), the action event
> handlers for Timers execute on another thread -- the event-dispatching
> thread."
>
OK.
 
> It's not clear to me what "executes" is either, does that mean start()
> is called on a timer or a timer has reached the initial delay and called
> one of the event handlers?
>
'execute' could well mean that there's a single ticker loop that 
increments the counters in all running Timers. That would be fairly 
efficient with them all on the same thread. And with intervals specified 
in mS, there should typically be plenty of time within a tick to run the 
two threads (timer and action) one after the other, so there shouldn't be 
any locking or synchronising clashes between them. [*]

[*] However, the timer interval can be specified as < 1 mS, i.e. as fast 
as possible, so synchronization would be needed to handle that case, but 
even so it probably adds very little overhead in the general case where 
the timer interval is >= 1 and so the two sewquential thread invocations 
have completed before the tick interval expires.
  

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#32023

From	Jeff Higgins <jeff@invalid.invalid>
Date	2015-07-14 16:09 -0400
Message-ID	<mo3qej$mpf$1@dont-email.me>
In reply to	#32018

On 07/14/2015 02:35 PM, Martin Gregorie wrote:
> On Tue, 14 Jul 2015 10:55:20 -0400, Jeff Higgins wrote:
>
>> Makes perfect sense to me.
>> But I'm still not sure how a <1 sec timer keeps the EDT alive while a >1
>> sec timer doesn't - barring explicit stops in windowClosing.
>>
>
> It occurs to me that, the way Knute's original example works, that he
> might have inadvertently set up a race condition because all the heavy
> lifting involved in setting up the JFrame, i.e. loading a shedload of
> classes and constructing instances from them all happens on the EDT and
> that this might well take a second or so to complete and still be running
> when the timer gets started. IOW, could the timer have fired its event
> before the default close operation had been defined and would the timer
> event have been ignored if it fired its event before the JFrame had been
> completed and displayed?
>
> Of course, this may be a stupid idea, but it does fit the test results
> which show a short timeout being ignored while a longer one does what
> you'd expect.
>
>
Here's a thread dump. don't know what it means.

Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.40-b25 mixed mode):

"TimerQueue" #14 daemon prio=5 os_prio=0 tid=0x0000000001b55000 
nid=0x1159 runnable [0x00007fd462759000]
    java.lang.Thread.State: RUNNABLE
	at java.lang.Thread.currentThread(Native Method)
	at java.lang.Thread.interrupted(Thread.java:944)
	at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.checkInterruptWhileWaiting(AbstractQueuedSynchronizer.java:2002)
	at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2079)
	at java.util.concurrent.DelayQueue.take(DelayQueue.java:223)
	at javax.swing.TimerQueue.run(TimerQueue.java:171)
	at java.lang.Thread.run(Thread.java:745)

"DestroyJavaVM" #13 prio=5 os_prio=0 tid=0x00007fd4641e2000 nid=0x114a 
waiting on condition [0x0000000000000000]
    java.lang.Thread.State: RUNNABLE

"AWT-EventQueue-0" #11 prio=6 os_prio=0 tid=0x00007fd464214800 
nid=0x1158 waiting on condition [0x00007fd46285a000]
    java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000000f5b76630> (a 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
	at java.awt.EventQueue.getNextEvent(EventQueue.java:547)
	at 
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:170)
	at 
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

"AWT-Shutdown" #12 prio=5 os_prio=0 tid=0x00007fd464212800 nid=0x1157 in 
Object.wait() [0x00007fd46295b000]
    java.lang.Thread.State: TIMED_WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f5b76fe8> (a java.lang.Object)
	at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:314)
	- locked <0x00000000f5b76fe8> (a java.lang.Object)
	at java.lang.Thread.run(Thread.java:745)

"AWT-XAWT" #10 daemon prio=6 os_prio=0 tid=0x00007fd464210800 nid=0x1156 
runnable [0x00007fd462a5c000]
    java.lang.Thread.State: RUNNABLE
	at sun.awt.X11.XToolkit.waitForEvents(Native Method)
	at sun.awt.X11.XToolkit.run(XToolkit.java:568)
	at sun.awt.X11.XToolkit.run(XToolkit.java:532)
	at java.lang.Thread.run(Thread.java:745)

"Java2D Disposer" #8 daemon prio=10 os_prio=0 tid=0x00007fd4641eb000 
nid=0x1155 in Object.wait() [0x00007fd468111000]
    java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f5b5b918> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
	- locked <0x00000000f5b5b918> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
	at sun.java2d.Disposer.run(Disposer.java:148)
	at java.lang.Thread.run(Thread.java:745)

"Service Thread" #7 daemon prio=9 os_prio=0 tid=0x00007fd46400c000 
nid=0x1153 runnable [0x0000000000000000]
    java.lang.Thread.State: RUNNABLE

"C1 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x0000000001934800 
nid=0x1152 runnable [0x0000000000000000]
    java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x0000000001931800 
nid=0x1151 waiting on condition [0x0000000000000000]
    java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x0000000001930000 
nid=0x1150 waiting on condition [0x0000000000000000]
    java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00000000018f7800 nid=0x114f 
in Object.wait() [0x00007fd468db9000]
    java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f5906f58> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
	- locked <0x00000000f5906f58> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00000000018f0000 
nid=0x114e in Object.wait() [0x00007fd468eba000]
    java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f5906998> (a java.lang.ref.Reference$Lock)
	at java.lang.Object.wait(Object.java:502)
	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157)
	- locked <0x00000000f5906998> (a java.lang.ref.Reference$Lock)

"VM Thread" os_prio=0 tid=0x00000000018ea800 nid=0x114d runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x0000000001896000 
nid=0x114b runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x0000000001898000 
nid=0x114c runnable

"VM Periodic Task Thread" os_prio=0 tid=0x000000000198d800 nid=0x1154 
waiting on condition

JNI global references: 389

Heap
  PSYoungGen      total 9728K, used 4357K [0x00000000f5900000, 
0x00000000f6380000, 0x0000000100000000)
   eden space 8704K, 50% used 
[0x00000000f5900000,0x00000000f5d415a0,0x00000000f6180000)
   from space 1024K, 0% used 
[0x00000000f6280000,0x00000000f6280000,0x00000000f6380000)
   to   space 1024K, 0% used 
[0x00000000f6180000,0x00000000f6180000,0x00000000f6280000)
  ParOldGen       total 22016K, used 0K [0x00000000e0a00000, 
0x00000000e1f80000, 0x00000000f5900000)
   object space 22016K, 0% used 
[0x00000000e0a00000,0x00000000e0a00000,0x00000000e1f80000)
  Metaspace       used 8578K, capacity 8728K, committed 8832K, reserved 
1056768K
   class space    used 980K, capacity 1058K, committed 1152K, reserved 
1048576K

[toc] | [prev] | [next] | [standalone]

#32027

From	Jeff Higgins <jeff@invalid.invalid>
Date	2015-07-14 18:32 -0400
Message-ID	<mo42qp$p92$1@dont-email.me>
In reply to	#32023

On 07/14/2015 04:09 PM, Jeff Higgins wrote:

> Here's a thread dump. don't know what it means.
Here's a thread dumper. Still don't know.
When run in Eclipse even prints the source line numbers.

import java.awt.EventQueue;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import java.lang.management.ManagementFactory;
import java.lang.management.ThreadInfo;
import java.lang.management.ThreadMXBean;

import javax.swing.JFrame;
import javax.swing.Timer;

public class test extends JFrame {
   public test() {
     System.out.println("Start of test()");
     System.out.println(crunchifyGenerateThreadDump());
     Timer timer1 = new Timer(1000, event -> {});
     Timer timer2 = new Timer(1100, event -> {});

     Timer.setLogTimers(true);

     addWindowListener(new WindowAdapter() {
       @Override
       public void windowClosing(WindowEvent windowEvent) {
         System.out.println("Close");
         System.out.println(crunchifyGenerateThreadDump());
         timer1.stop();
         timer2.stop();
         System.out.println("Timers Stopped");
         System.out.println(crunchifyGenerateThreadDump());
       }
     });

     setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
     setSize(400, 300);
     setVisible(true);
     timer1.start();
     timer2.start();
     System.out.println(crunchifyGenerateThreadDump());
   }

   public static void main(String... args) {
     System.out.println("Before new test()");
     System.out.println(crunchifyGenerateThreadDump());
     EventQueue.invokeLater(() -> new test());
   }

   /**
    * 
<http://crunchify.com/how-to-generate-java-thread-dump-programmatically/>
    *
    * @return
    */
   public static String crunchifyGenerateThreadDump() {
     final StringBuilder dump = new StringBuilder();
     final ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean();
     final ThreadInfo[] threadInfos = 
threadMXBean.getThreadInfo(threadMXBean.getAllThreadIds(), 100);
     for (ThreadInfo threadInfo : threadInfos) {
       dump.append('"');
       dump.append(threadInfo.getThreadName());
       dump.append("\" ");
       final Thread.State state = threadInfo.getThreadState();
       dump.append("\n   java.lang.Thread.State: ");
       dump.append(state);
       final StackTraceElement[] stackTraceElements = 
threadInfo.getStackTrace();
       for (final StackTraceElement stackTraceElement : 
stackTraceElements) {
         dump.append("\n        at ");
         dump.append(stackTraceElement);
       }
       dump.append("\n\n");
     }
     return dump.toString();
   }
}

[toc] | [prev] | [next] | [standalone]

#32028

From	Jeff Higgins <jeff@invalid.invalid>
Date	2015-07-14 18:34 -0400
Message-ID	<mo42tr$p92$2@dont-email.me>
In reply to	#32027

Before new test()
"Signal Dispatcher"
    java.lang.Thread.State: RUNNABLE

"Finalizer"
    java.lang.Thread.State: WAITING
         at java.lang.Object.wait(Native Method)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
         at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler"
    java.lang.Thread.State: WAITING
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:502)
         at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157)

"main"
    java.lang.Thread.State: RUNNABLE
         at sun.management.ThreadImpl.getThreadInfo1(Native Method)
         at sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:174)
         at uni.test.crunchifyGenerateThreadDump(test.java:56)
         at uni.test.main(test.java:44)


Start of test()
"DestroyJavaVM"
    java.lang.Thread.State: RUNNABLE

"AWT-EventQueue-0"
    java.lang.Thread.State: RUNNABLE
         at sun.management.ThreadImpl.getThreadInfo1(Native Method)
         at sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:174)
         at uni.test.crunchifyGenerateThreadDump(test.java:56)
         at uni.test.<init>(test.java:16)
         at uni.test.lambda$2(test.java:45)
         at uni.test$$Lambda$1/1418481495.run(Unknown Source)
         at 
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
         at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:749)
         at java.awt.EventQueue.access$500(EventQueue.java:97)
         at java.awt.EventQueue$3.run(EventQueue.java:702)
         at java.awt.EventQueue$3.run(EventQueue.java:696)
         at java.security.AccessController.doPrivileged(Native Method)
         at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
         at java.awt.EventQueue.dispatchEvent(EventQueue.java:719)
         at 
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
         at 
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
         at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
         at 
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
         at 
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
         at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

"AWT-Shutdown"
    java.lang.Thread.State: WAITING
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:502)
         at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:295)
         at java.lang.Thread.run(Thread.java:745)

"AWT-XAWT"
    java.lang.Thread.State: RUNNABLE
         at sun.awt.X11.XToolkit.waitForEvents(Native Method)
         at sun.awt.X11.XToolkit.run(XToolkit.java:568)
         at sun.awt.X11.XToolkit.run(XToolkit.java:532)
         at java.lang.Thread.run(Thread.java:745)

"Java2D Disposer"
    java.lang.Thread.State: WAITING
         at java.lang.Object.wait(Native Method)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
         at sun.java2d.Disposer.run(Disposer.java:148)
         at java.lang.Thread.run(Thread.java:745)

"Signal Dispatcher"
    java.lang.Thread.State: RUNNABLE

"Finalizer"
    java.lang.Thread.State: WAITING
         at java.lang.Object.wait(Native Method)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
         at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler"
    java.lang.Thread.State: WAITING
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:502)
         at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157)


"TimerQueue"
    java.lang.Thread.State: RUNNABLE

"DestroyJavaVM"
    java.lang.Thread.State: RUNNABLE

"AWT-EventQueue-0"
    java.lang.Thread.State: RUNNABLE
         at sun.management.ThreadImpl.getThreadInfo1(Native Method)
         at sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:174)
         at uni.test.crunchifyGenerateThreadDump(test.java:56)
         at uni.test.<init>(test.java:39)
         at uni.test.lambda$2(test.java:45)
         at uni.test$$Lambda$1/1418481495.run(Unknown Source)
         at 
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
         at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:749)
         at java.awt.EventQueue.access$500(EventQueue.java:97)
         at java.awt.EventQueue$3.run(EventQueue.java:702)
         at java.awt.EventQueue$3.run(EventQueue.java:696)
         at java.security.AccessController.doPrivileged(Native Method)
         at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
         at java.awt.EventQueue.dispatchEvent(EventQueue.java:719)
         at 
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
         at 
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
         at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
         at 
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
         at 
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
         at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

"AWT-Shutdown"
    java.lang.Thread.State: WAITING
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:502)
         at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:295)
         at java.lang.Thread.run(Thread.java:745)

"AWT-XAWT"
    java.lang.Thread.State: RUNNABLE
         at sun.awt.X11.XlibUtil.translateCoordinates(XlibUtil.java:148)
         at sun.awt.X11.XWindowPeer.queryXLocation(XWindowPeer.java:745)
         at sun.awt.X11.XWindowPeer.getNewLocation(XWindowPeer.java:774)
         at 
sun.awt.X11.XDecoratedPeer.handleConfigureNotifyEvent(XDecoratedPeer.java:743)
         at sun.awt.X11.XBaseWindow.dispatchEvent(XBaseWindow.java:1135)
         at sun.awt.X11.XBaseWindow.dispatchToWindow(XBaseWindow.java:1090)
         at sun.awt.X11.XToolkit.dispatchEvent(XToolkit.java:502)
         at sun.awt.X11.XToolkit.run(XToolkit.java:611)
         at sun.awt.X11.XToolkit.run(XToolkit.java:532)
         at java.lang.Thread.run(Thread.java:745)

"Java2D Disposer"
    java.lang.Thread.State: WAITING
         at java.lang.Object.wait(Native Method)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
         at sun.java2d.Disposer.run(Disposer.java:148)
         at java.lang.Thread.run(Thread.java:745)

"Signal Dispatcher"
    java.lang.Thread.State: RUNNABLE

"Finalizer"
    java.lang.Thread.State: WAITING
         at java.lang.Object.wait(Native Method)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
         at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler"
    java.lang.Thread.State: WAITING
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:502)
         at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157)


Timer ringing: javax.swing.Timer@b52ebbf
Timer ringing: javax.swing.Timer@7a50dc07
Close
"TimerQueue"
    java.lang.Thread.State: TIMED_WAITING
         at sun.misc.Unsafe.park(Native Method)
         at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
         at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
         at java.util.concurrent.DelayQueue.take(DelayQueue.java:223)
         at javax.swing.TimerQueue.run(TimerQueue.java:171)
         at java.lang.Thread.run(Thread.java:745)

"DestroyJavaVM"
    java.lang.Thread.State: RUNNABLE

"AWT-EventQueue-0"
    java.lang.Thread.State: RUNNABLE
         at sun.management.ThreadImpl.getThreadInfo1(Native Method)
         at sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:174)
         at uni.test.crunchifyGenerateThreadDump(test.java:56)
         at uni.test$1.windowClosing(test.java:26)
         at 
java.awt.AWTEventMulticaster.windowClosing(AWTEventMulticaster.java:349)
         at 
java.awt.AWTEventMulticaster.windowClosing(AWTEventMulticaster.java:349)
         at java.awt.Window.processWindowEvent(Window.java:2058)
         at javax.swing.JFrame.processWindowEvent(JFrame.java:305)
         at java.awt.Window.processEvent(Window.java:2017)
         at java.awt.Component.dispatchEventImpl(Component.java:4881)
         at java.awt.Container.dispatchEventImpl(Container.java:2292)
         at java.awt.Window.dispatchEventImpl(Window.java:2750)
         at java.awt.Component.dispatchEvent(Component.java:4703)
         at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:751)
         at java.awt.EventQueue.access$500(EventQueue.java:97)
         at java.awt.EventQueue$3.run(EventQueue.java:702)
         at java.awt.EventQueue$3.run(EventQueue.java:696)
         at java.security.AccessController.doPrivileged(Native Method)
         at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
         at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:86)
         at java.awt.EventQueue$4.run(EventQueue.java:724)
         at java.awt.EventQueue$4.run(EventQueue.java:722)
         at java.security.AccessController.doPrivileged(Native Method)
         at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
         at java.awt.EventQueue.dispatchEvent(EventQueue.java:721)
         at 
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
         at 
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
         at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
         at 
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
         at 
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
         at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

"AWT-Shutdown"
    java.lang.Thread.State: WAITING
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:502)
         at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:295)
         at java.lang.Thread.run(Thread.java:745)

"AWT-XAWT"
    java.lang.Thread.State: RUNNABLE
         at sun.awt.X11.XToolkit.waitForEvents(Native Method)
         at sun.awt.X11.XToolkit.run(XToolkit.java:568)
         at sun.awt.X11.XToolkit.run(XToolkit.java:532)
         at java.lang.Thread.run(Thread.java:745)

"Java2D Disposer"
    java.lang.Thread.State: WAITING
         at java.lang.Object.wait(Native Method)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
         at sun.java2d.Disposer.run(Disposer.java:148)
         at java.lang.Thread.run(Thread.java:745)

"Signal Dispatcher"
    java.lang.Thread.State: RUNNABLE

"Finalizer"
    java.lang.Thread.State: WAITING
         at java.lang.Object.wait(Native Method)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
         at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler"
    java.lang.Thread.State: WAITING
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:502)
         at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157)


Timers Stopped
"TimerQueue"
    java.lang.Thread.State: TIMED_WAITING
         at sun.misc.Unsafe.park(Native Method)
         at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
         at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
         at java.util.concurrent.DelayQueue.take(DelayQueue.java:223)
         at javax.swing.TimerQueue.run(TimerQueue.java:171)
         at java.lang.Thread.run(Thread.java:745)

"DestroyJavaVM"
    java.lang.Thread.State: RUNNABLE

"AWT-EventQueue-0"
    java.lang.Thread.State: RUNNABLE
         at sun.management.ThreadImpl.getThreadInfo1(Native Method)
         at sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:174)
         at uni.test.crunchifyGenerateThreadDump(test.java:56)
         at uni.test$1.windowClosing(test.java:30)
         at 
java.awt.AWTEventMulticaster.windowClosing(AWTEventMulticaster.java:349)
         at 
java.awt.AWTEventMulticaster.windowClosing(AWTEventMulticaster.java:349)
         at java.awt.Window.processWindowEvent(Window.java:2058)
         at javax.swing.JFrame.processWindowEvent(JFrame.java:305)
         at java.awt.Window.processEvent(Window.java:2017)
         at java.awt.Component.dispatchEventImpl(Component.java:4881)
         at java.awt.Container.dispatchEventImpl(Container.java:2292)
         at java.awt.Window.dispatchEventImpl(Window.java:2750)
         at java.awt.Component.dispatchEvent(Component.java:4703)
         at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:751)
         at java.awt.EventQueue.access$500(EventQueue.java:97)
         at java.awt.EventQueue$3.run(EventQueue.java:702)
         at java.awt.EventQueue$3.run(EventQueue.java:696)
         at java.security.AccessController.doPrivileged(Native Method)
         at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
         at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:86)
         at java.awt.EventQueue$4.run(EventQueue.java:724)
         at java.awt.EventQueue$4.run(EventQueue.java:722)
         at java.security.AccessController.doPrivileged(Native Method)
         at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
         at java.awt.EventQueue.dispatchEvent(EventQueue.java:721)
         at 
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
         at 
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
         at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
         at 
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
         at 
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
         at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

"AWT-Shutdown"
    java.lang.Thread.State: WAITING
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:502)
         at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:295)
         at java.lang.Thread.run(Thread.java:745)

"AWT-XAWT"
    java.lang.Thread.State: RUNNABLE
         at sun.awt.X11.XToolkit.waitForEvents(Native Method)
         at sun.awt.X11.XToolkit.run(XToolkit.java:568)
         at sun.awt.X11.XToolkit.run(XToolkit.java:532)
         at java.lang.Thread.run(Thread.java:745)

"Java2D Disposer"
    java.lang.Thread.State: WAITING
         at java.lang.Object.wait(Native Method)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
         at sun.java2d.Disposer.run(Disposer.java:148)
         at java.lang.Thread.run(Thread.java:745)

"Signal Dispatcher"
    java.lang.Thread.State: RUNNABLE

"Finalizer"
    java.lang.Thread.State: WAITING
         at java.lang.Object.wait(Native Method)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
         at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler"
    java.lang.Thread.State: WAITING
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:502)
         at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157)

[toc] | [prev] | [next] | [standalone]

#32029

From	Jeff Higgins <jeff@invalid.invalid>
Date	2015-07-14 20:31 -0400
Message-ID	<mo49q5$c82$1@dont-email.me>
In reply to	#32028

Defined in AbstractQueuedSynchronizer:
/**
  * The number of nanoseconds for which it is faster to spin
  * rather than to use timed park. A rough estimate suffices
  * to improve responsiveness with very short timeouts.
  */
static final long spinForTimeoutThreshold = 1000L;



 From the method:
AbstractQueuedSynchronizer.awaitNanos

if (nanosTimeout >= spinForTimeoutThreshold)
   LockSupport.parkNanos(this, nanosTimeout);



 From thread dump after close:
Timer ringing: javax.swing.Timer@b52ebbf
Timer ringing: javax.swing.Timer@7a50dc07
Close
"TimerQueue"
    java.lang.Thread.State: TIMED_WAITING
         at sun.misc.Unsafe.park(Native Method)
         at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
         at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
         at java.util.concurrent.DelayQueue.take(DelayQueue.java:223)
         at javax.swing.TimerQueue.run(TimerQueue.java:171)
         at java.lang.Thread.run(Thread.java:745)

[toc] | [prev] | [next] | [standalone]

#32011

From	Knute Johnson <nospam@rabbitbrush.frazmtn.com>
Date	2015-07-14 08:16 -0700
Message-ID	<mo390r$g46$1@dont-email.me>
In reply to	#32008

On 7/14/2015 07:39, e.d.programmer@gmail.com wrote:
> Closing a window should never terminate a JVM unless you flag it as
> EXIT_ON_CLOSE which is not recommended.

Whether it should or shouldn't doesn't really matter, the JVM terminates 
when all the windows have been disposed and all the non-daemon threads 
have stopped.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#32000

From	Joerg Meier <joergmmeier@arcor.de>
Date	2015-07-14 08:32 +0200
Message-ID	<1et6b9nx8davi.1lttqcxuf5sn1.dlg@40tude.net>
In reply to	#31994

On Mon, 13 Jul 2015 16:03:53 -0700, Knute Johnson wrote:

> So I have this program that uses a couple of javax.swing.Timers.  I 
> forgot to put in code to stop one of the timers yet the program would 
> still terminate.  I have set the default close operation for the frame 
> to be DISPOSE_ON_CLOSE.

> What I found was that a timer of less the 1000ms would prevent an 
> application based on a JFrame from stopping but 1000ms or more and it 
> would stop just fine.

> I know that javax.swing.Timer uses a common thread for all timers but I 
> don't see anywhere that describes the stopping behavior.

The behaviour of javax.swing.TimerS is coupled to the Event Dispatch
Thread. If that goes away, so do timers. You are running into your
unexpected timing issues because that's how long it happens to take your
JVM to terminate the EDT after you dispose the last UI component.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#32031

From	Jeff Higgins <jeff@invalid.invalid>
Date	2015-07-14 22:18 -0400
Message-ID	<mo4g2p$ibt$1@dont-email.me>
In reply to	#31994

On 07/13/2015 07:03 PM, Knute Johnson wrote:
> So I have this program that uses a couple of javax.swing.Timers.  I
> forgot to put in code to stop one of the timers yet the program would
> still terminate.  I have set the default close operation for the frame
> to be DISPOSE_ON_CLOSE.
>
> What I found was that a timer of less the 1000ms would prevent an
> application based on a JFrame from stopping but 1000ms or more and it
> would stop just fine.
>
Maybe it's a feature.
Doctor, it hurts when I do this.

[toc] | [prev] | [next] | [standalone]

#32034

From	Jeff Higgins <jeff@invalid.invalid>
Date	2015-07-15 08:26 -0400
Message-ID	<mo5jlv$vtc$1@dont-email.me>
In reply to	#31994

On 07/13/2015 07:03 PM, Knute Johnson wrote:
> So I have this program ...

Found another article.

AWT shutdown and daemon threads
<http://www.pushing-pixels.org/2008/07/17/awt-shutdown-and-daemon-threads.html>

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

csiph-web

javax.swing.Timer blocking program termination

Contents

#32039

#32040

#32010

#32012

#32013

#32018

#32019

#32020

#32021

#32025

#32026

#32030

#32023

#32027

#32028

#32029

#32011

#32000

#32031

#32034