Java Bugs - Hard loops

The Java thread scheduler seems a little less than robust. It's easy to get bad things to happen by just running a tight infinite loop. Even some cases that play completely by the rules, calling yield() or sleep(), have problems. X11 versions of Netscape are especially vulnerable.

  1. The first example goes into a loop right in the paint() method. View the source code. Run the applet. Effects: Comment: if Java runs the paint() methods of all applets from the same thread (ScreenUpdater?), that explains the Win95 behavior. In Mesa we called this "Notifier lockup".
  2. Example two is just like the first except that the loop in the paint() method will exit if it sees a flag set by the stop() method. View the source code. Run the applet. Effects: Comment: apparently stop() is called from a different thread than paint().
  3. The next example creates a new thread for the loop. View the source code. Run the applet. Effects: Comment: tends to confirm the theory that all paint() methods are called from a single thread.
  4. Example four creates a new thread for the loop, and inside the loop calls repaint(). View the source code. Run the applet. Effects: Comment: this one plays completely by the rules and ought to work fine.
  5. Number five is just like four, except the loop has a yield() in it. View the source code. Run the applet. Effects: same as number four.
  6. Number six is just like four, except the loop has a sleep(1) in it. View the source code. Run the applet. Effects: same as number four.
  7. Number seven is just like four, except the loop has a sleep(5) in it. View the source code. Run the applet. Effects:

I also have reports that HotJava and at least some version of appletviewer undergo similar poor behavior.

Conclusions: I'd say there are really two separate problems here.

  1. The fact that Win95 Netscape can handle reasonable cases that X11 Netscape locks up on (#3 through #6) indicates a specific bug in X11 Netscape.
  2. Cases #1 and #2 demonstrate an annoying lack of robustness in the face of inadvertent or deliberate infinite loops. A recent message on comp.lang.java by Arthur van Hoff <31313027.5B1D@netcom.com> suggests this is something we just have to live with. I disagree. If my above theorizing about all paint() calls happening from a single thread is correct, then a simple solution would be to have an observer thread watching over the updater thread; if the updater fails to check in for too long, the observer starts up a new updater thread.

Back to bugs.
Back to ACME Java.
Back to ACME Labs.