Race Condition Inside the Microsoft JVM

Here’s a story about an unreported Internet Explorer Java bug. Anyone that creates applets is affected:

About two weeks ago, I got a message from FutureSource’s excellent Q. A. team informing me that an applet sometimes turns up blank on Windows NT 4. Just a gray rectangle. But as soon as the browser is resized, the applet repaints correctly. This was never happening for the first instance of the applet, but only when new windows containing applets were spawned or the window containing the applet was refreshed.

After installing NT4+SP4+IE5+JVM3802 on one of the boxes, I managed to reproduce the problem. This was good news. If you can reproduce it you can fix it.

By adding some traces and a timer to the applet, I found out that this was not a paint problem, nor a validation problem as I initially thought. Instead, my applet had a size of (0, 0) inside the Applet.init method, and that size stayed until the browser window was first resized.

Next, I overloaded the applet’s setSize() and setBounds() methods to trace the parameters they receive and then call the super’s implementation. What I found out is that on the runs when everything works, applet’s setBounds() is called just before a call to the init() method. On the runs when the applet failed to show, the setBounds() method was never called.

This was obviously a problem in IE’s JVM, not in my code. But I needed to fix it anyway because it would piss off the customers.

After unsuccessfully throwing a few wild guesses at the problem, I decided to take the time and solve it properly. I downloaded the NMI Java Decompiler and decompiled the classes that make up the com.ms.applet package. Now that I had the source code finding the problem was easy:

There is a race condition inside Microsoft’s code that happens on applet startup.

There are two threads working together on applet startup. One is the event queue thread, which controls the applet and its parent, BrowserAppletFrame, and another which calls the init, start, stop and destroy methods and which is represented by the AppletPanel runnable. Both of these classes are in the com.ms.applet package.

The event queue thread is responsible for processing an event that sets a Dimension object named objectSize to the desired size. The AppletPanel thread is responsible for using that object to set the applet’s size. If the event queue thread is faster, then all is well. But if the AppletPanel thread is faster, it will use the initial value of objectSize which is (0, 0) before the event queue thread has a chance to set it to the real size. The user will see only an ugly gray box.

The workaround is to add a component listener to the parent in the applet’s init method and then to set the applet size to the parent’s size when the parent’s size changes the first time.

This bug is not in the MS Knowledge Base. I tried to report it but found no way to do so on Microsoft’s website.

Microsoft JVM Bugs

So far Internet Explorer’s JVM has proven superior to the one in Netscape, but here are two instances where IE does a worse job than Netscape:

•  When an applet shows a popup menu in IE, the event queue is blocked.
• Applet’s init() and destroy() methods are called from a thread other than the event queue thread. Those unaware of that fact will suffer from a multitude of threading problems. Netscape, in contrast, calls these methods from the event queue thread.

Windows XP

I installed Windows XP RC2 yesterday. Coming from Windows 2000, here are impressions:

1. Everything still works. The upgrade was painless.
2. It’s pretty, but not cluttered.
3. When a window pops up a modal dialog, the background window changes color to let you know it’s disabled. Thus multiple stacked dialogs are not as visually confusing as they were under W2K.
4. ClearType is amazing! Text on LCD screens looks so good you’ll want to lick it.
5. The Remote Display Protocol now supports full color. Laptops in general don’t have the processor speed and memory capacity of desktops, but now I can work from my garden using my laptop while actually using my desktop computer. (Laptops do have good screens and keyboards. Dell Inspirons nowadays have a 1600×1200 displays and large keyboards.)
6. Some of the applications and drivers I use insist on putting an icon on the system tray although it’s not used for anything. Window XP will hide all unused icons after a while.
7. Icons on the desktop can automatically align to the grid. Great for anal retentive people like me who compulsively line up icons after they move them.
8. It has a built-in firewall, although it’s not as full-featured as ZoneAlarm.

Pointer Aliasing

If you are doing any array or matrix manipulation in C++, try to turn on the “assume no pointer aliasing” optimization selectively. I just did it for a function in a benchmark I was toying with, and the execution time dropped from 57 seconds to 47 seconds – a 21 percent increase in speed.

I just posted an article titled Java: Good and Bad which enumerates good and bad sides of Java for building large-scale programs.

Damn, this is cool! I just noticed that Microsoft FrontPage 2002 has an indicator, on the status bar, indicating how long the page on which you are currently working will take to download. You simply choose the download speed from a right-click menu, and FP takes care of the rest.