Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Windows JVM scheduling bug?  (Read 1636 times)
0 Members and 1 Guest are viewing this topic.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Posted 2003-06-06 10:57:36 »

I've managed to narrow down a problem to the following:

  Whilst the AWT event thread is running, it often gets scheduled exclusively - ie. other threads get ZERO running time, for periods of up to 2 seconds. This is on a 1.5Ghz machine; on machines less than 1Ghz, it can get exclusive for tens of seconds.

Unless I'm mistaken, this is not a feature, it's a bug. I'm testing mainly on Windows XP, and since when did XP do 10 second long thread starvation? My other thread(s) (I can reproduce with either multiple specialized threads, or with all functions located in one thread) do everything from cpu-intensive calculations through to painting on Graphics. There is no reason why they should get starved for tens of seconds.

Note: I am doing almost NOTHING in the EventThread, during actionPerformed calls. On linux, I spend less than 30 millis in my code over the course of 30 seconds. On Windows XP, I spend over 1000 millis in my code during actionPerformed. The only method calls I'm making are constructors for Point objects.

Even if removing those constructors reduces the time spent in the AWT event thread, this surely does NOT justify thread starvation?

I have asked Sun about why they have a tutorial webpage that is completely wrong (the tutorial on threading, specifically the page talking about scheduling, which is directly conflicting with some of the things stated in the 1.4.x release notes, and perhaps others too), AND how they are actually implementing thread-scheduling under windows (is it native, or simulated?), but have had no response in 2 months. !?!?

I'm asking here in case I've done something stupid, or possibly made a silly mistake. Otherwise, this does appear to be a major bug in the windows JVM. Or do you disagree? What am I misunderstanding here?

malloc will be first against the wall when the revolution comes...
Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2003-06-06 22:21:41 »

Thread scheduling's pure native as the driven snow under all Windows platforms. So anything freaky going on is an AWT implementation quirk.

Got a profile of it? Just -Xprof will do.

Cas Smiley

Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #2 - Posted 2003-06-07 02:23:24 »

I haven't seen anything like that with my own multithreaded Java apps on XP.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline lilspikey

Senior Newbie




Computers Stole My Social Skills


« Reply #3 - Posted 2003-06-07 08:07:59 »

Sounds like a sychronization problem.  Perhaps the AWT thread is getting stuck on something, or entering a synchronized block that all other threads need access too (new'ing those points maybe?).

I guess try and reduce it to a test case and maybe something else will appear.  Or try and run thru jdb and see if you can work out what happens before/after actionPerformed is called.

Also maybe try putting the non-AWT threads on low priority.  Perversely I found this often helped with jitters and so on, as the AWT thread was hardly doing anything so normally doesn't mess with the other threads.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #4 - Posted 2003-06-07 08:37:20 »

Thanks for the suggestions; I'm willing to try all of them Smiley. Currently I'm majoring on reducing as much code as possible to make a lean test case, although since it appears CPU-speed / spare processing power / etc dependent, I'm not sure how lean I'll be able to go without ruining everything.

Cas: yes, that's what I thought from reading 1.4.x notes (and indeed is what I remember from 1.2.x days) - but, as I noted, the java tutorial boldly states this isn't true. Shrug.

swpalmer: I'd never seen it before either, and I've been doing multi-threaded java since 1.1.x on winNT. Interestingly, I've always used pure AWT (usually had to for speed reasons, and to avoid  "known bugs" in swing) until fairly recently, which might be significant.

Hmm. Actually, I DO have a similar problem with the AWT thread in an old tiny program, but it only occurs one time in 20. I got a test case to sun, and a bug report on 1.4.1 which they accepted, because it seemed the AWT thread was initiallising and displaying the window, but 1 time in 20 it wasn't creating the windowing-system resources, so getWidth etc returned -1, permanently. I had got as far as showing it was a race condition somewhere in the AWT startup code. I *think* I demonstrated it on both windows and linux, hence making it appear a fundamental design problem in some of the higher-level code, but I can't quite remember.

I'm also going to replace my (nice, easy, well-suited to a game) timing system with a Swing timer, so that there is only the AWT thread, and see what happens. I doubt it will tell us much, but worth a try.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #5 - Posted 2003-06-07 08:42:45 »

Quote
Sounds like a sychronization problem.  Perhaps the AWT thread is getting stuck on something, or entering a synchronized block that all other threads need access too (new'ing those points maybe?).


It's crazy, but it might just work. That's a very interesting thought. Whilst it would seem to me insane that Point manipulations could block the AWT thread - and ONLY on windows systems - my observed behaviour does tally with an "unexpected" synchronize bottleneck. But perhaps there's synchronization elsewhere, in some otherwise innocent-looking code...

I'm going to do a careful check to see if there might be some synchronization taking place I hadn't noticed.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #6 - Posted 2003-06-07 09:31:50 »

Quote
Thread scheduling's pure native as the driven snow under all Windows platforms. So anything freaky going on is an AWT implementation quirk.

Got a profile of it? Just -Xprof will do.


Yeah. On linux, 1Ghz machine, about 40% of time is spent in java.awt.EventDispatchThread.run(), about 40% in JComponent repaint's, and the rest spread about in lots of places.

On windows XP, 1.5 ghz machine, about 80% of time is spent in sun.awt.windows.WToolkit.eventLoop, but the JComponent paint's don't show up at all. Don't ask me why - same VM version, same profiling commandline (-Xrunhprof:cpu=samples,thread=y,depth=20) ?!?

However, I just noticed that I've got my image-preloading turned off, and so I've got ImageFetcher threads all over the place, with load taking place on first use. So i'll just go fix that... Smiley

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #7 - Posted 2003-06-07 10:56:29 »

Well, I've found the offending line:

1  
    repaint();


My game-loop triggers repaints as necessary, in preparation for moving to a full-screen implementation later. However, there was this extra repaint which had slipped in to the mouseMoved() method. Removing it has had two effects: firstly, there is no apparent mis-scheduling any more. Secondly, windows-JVM behaviour (i.e. user-perceived performance, delays, etc) is now identical to linux.

However, I still don't understand WHY this happened. I can guess that the reason for the system-dependent behaviour was that linux was choosing always to collapse that particular repaint(), and hence (effectively) ignore it.

My only guess for what was happening is that having a repaint() inside the EventThread on windows was either causing repaint()'s from other threads to block, or triggers some special behaviour causing the EventThread to rise in priority (?).

Note: the behaviour witnessed was that the game-loop thread actually froze; no processing took place in that loop at all whilst it was frozen; when it resumed, it carried on animating etc from the precise point where it left off. Hence, it is not simply that repaints from this other (non EventThread) thread were being ignored.

If my guesses are even slightly accurate, could this be a bug specific to "EventThread + repaint()-inside-a-MouseEvent-dispatch"? My main reason for thinking "bug, not feature" is the 100% repeatable platform-dependency here. And the fact that ommitting that one line causes the two platforms to behave identically.

Of course, if there's some documented reason for this behaviour in the API's, which I've failed to notice, feel free to slap me Smiley.

malloc will be first against the wall when the revolution comes...
Offline lilspikey

Senior Newbie




Computers Stole My Social Skills


« Reply #8 - Posted 2003-06-08 13:34:27 »

Perhaps it's something to do with accessing the event queue whilst running on the event thread.  Although that is pretty bad really.

Perhaps when dispatching on the AWT thread it actually does the event there and then, before waiting for more events.  e.g.

click on button
handle click
despatch paint event
finish handling click
handle paint event
wait for more events.

?  Only guessing but the java.awt.EventQueue javadoc does say it's implementation dependant.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #9 - Posted 2003-06-17 19:19:08 »

Quote
Perhaps it's something to do with accessing the event queue whilst running on the event thread.  Although that is pretty bad really.


Hmm. Yes. Any ideas on generating a SMALL test case? They won't let me log a bug otherwise... Sad. Thoughts on loading the system enough to make the bug show up?

Quote

Only guessing but the java.awt.EventQueue javadoc does say it's implementation dependant.


Famous last words for any java standard library...sigh.

malloc will be first against the wall when the revolution comes...
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (33 views)
2014-12-15 09:26:44

Mr.CodeIt (23 views)
2014-12-14 19:50:38

BurntPizza (51 views)
2014-12-09 22:41:13

BurntPizza (84 views)
2014-12-08 04:46:31

JscottyBieshaar (45 views)
2014-12-05 12:39:02

SHC (59 views)
2014-12-03 16:27:13

CopyableCougar4 (59 views)
2014-11-29 21:32:03

toopeicgaming1999 (123 views)
2014-11-26 15:22:04

toopeicgaming1999 (114 views)
2014-11-26 15:20:36

toopeicgaming1999 (32 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!