Name: dbT83986 Date: 03/29/99


I have found a slight inconsistency in the process of
adding/removing a RunnableCanvas from the static
Hashtable 'rootTable' of SystemEventQueueUtilities.

As i'm relative new to the Swing-Classes the description of the
following processes may be inaccurate or even wrong, but the Bug
i'm referring to is easy to see.

A RunnableCanvas is added by the RepaintManager to the static
Hashtable 'rootTable' of SystemEventQueueUtilities in the Method
'RepaintManager.addDirtyRegion' through the call to
'SystemEventQueueUtilities.queueComponentWorkRequest'.
The Key of the Hashtable-Entry is either an Applet or an Window (*)
of the Component given to 'RepaintManager.addDirtyRegion'.

A RunnableCanvas is removed from 'rootTable' through calls of
'removeNotify'-Methods ending in 'JRootPanel.removeNotify'. In
this Method the Key of the Component to be removed from 'rootTable' by the call
'SystemEventQueueUtilities.removeRunnableCanvas' is computed by a call
to 'SwingUtilities.getRoot'. Here comes the inconsistency: This method returns
the first ancestor of c that's a Window or the last Applet ancestor, if
there is no Window found ! Do you see the slight mismatch to (*) ?
If there is a hierarchy e.g. like Window->...->Applet->...->JPanel the
key for the addition to 'rootTable' in
'SystemEventQueueUtilities.queueComponentWorkRequest' is 'Applet'. To remove
the corresponding RunnableCanvas the Method SystemEventQueueUtilities.removeRunnableCanvas
is called with the Key 'Window' ! This results in the failing of
removal of reference to the the Applet-Class.

Sample code:

/*
A basic extension of the com.sun.java.swing.JApplet class
*/

import javax.swing.*;
import java.awt.*;

import javax.swing.JScrollPane;
import javax.swing.JTextArea;

public class JApplet1 extends JApplet
{
private JTextArea area;
private JButton button;

private byte[][] b = new byte[1500][1500];

public void init() {
getContentPane().setLayout(new BorderLayout(0,0));
area = new JTextArea();
getContentPane().add(area, BorderLayout.CENTER);
button = new JButton("Help !");
getContentPane().add(button, BorderLayout.NORTH);
}

public void start() {
area.append("started...\n");

// So that the Compiler doesn't removes the b-Array
// for optimization
for (int i=0; i<b.length; i++) {
b[i][i] = 1;
}

System.gc();

Runtime r = Runtime.getRuntime();
area.append("total memory: " + r.totalMemory() + "\n");
area.append("free memory: " + r.freeMemory() + "\n");

area.append("end\n");
}
}

You can see the behaviour if you start this Applet in Appletviewer.
Note that you have to click on the "Help !"-Button to get an RunnableCanvas
added for the Applet.
Procedure:
1. Start the AppletViewer
2. Click on the "Help !"-Button
3. Click on "Reload" in the "Applet"-Menu
4. Repeat steps 2. and 3. And see the memory-usage raising...

If you leave out step 2 there is no RunnableCanvas added and so the
garbagecollector can free all Objects...
(Review ID: 54146)
======================================================================