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.
-
The first example goes into a loop right in the paint() method.
View the source code.
Run the applet.
Effects:
- Windows95 Netscape stops updating other applets, but is still otherwise ok.
The Back button gets you out of that page, but applets on other pages still
don't update.
You have to exit and restart the browser before Java will work again.
- X11 Netscape completely locks up and has to be killed.
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".
-
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:
- Windows95 Netscape stops updating other applets, but unlike example 1
hitting Back does fix things.
- X11 Netscape completely locks up and has to be killed.
Comment: apparently stop() is called from a different thread than paint().
-
The next example creates a new thread for the loop.
View the source code.
Run the applet.
Effects:
- Windows95 Netscape handles it without problem.
- X11 Netscape completely locks up and has to be killed.
Comment: tends to confirm the theory that all paint() methods are
called from a single thread.
-
Example four creates a new thread for the loop, and inside the loop
calls repaint().
View the source code.
Run the applet.
Effects:
- Windows95 Netscape handles it without problem.
- X11 Netscape completely locks up and has to be killed.
Comment: this one plays completely by the rules and ought to work fine.
-
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.
-
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.
-
Number seven is just like four, except the loop has a sleep(5) in it.
View the source code.
Run the applet.
Effects:
- Windows95 Netscape handles it without problem.
- X11 Netscape handles it without problem.
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.
-
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.
-
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.