The RepaintManager stores itself in the AppContext so it can be fetched later. However, the fact that it stores a strong reference causes it to hold on to storage for too long. The following reference trace from jhat shows that a destroyed applet (whose AppContext happens to occasionally take a long time to be disposed) is being referenced from the RepaintManager's entry in the AppContext, preventing the applet from being GCd properly and leading to an OutOfMemoryError on page reload. This is related to bug 6671092.

Static reference from java.awt.KeyboardFocusManager.activeWindow (from class java.awt.KeyboardFocusManager) :
--> sun.plugin2.main.client.PluginEmbeddedFrame@0x2f48340 (407 bytes) (field appContext:)
--> sun.awt.AppContext@0x2f48188 (49 bytes) (field table:)
--> java.util.HashMap@0x2f4b018 (40 bytes) (field table:)
--> [Ljava.util.HashMap$Entry;@0x2f53400 (136 bytes) (Element 20 of [Ljava.util.HashMap$Entry;@0x2f53400:)
--> java.util.HashMap$Entry@0x2f54b80 (24 bytes) (field value:)
--> javax.swing.RepaintManager@0x2f53490 (64 bytes) (field paintManager:)
--> javax.swing.BufferStrategyPaintManager@0x2f54c10 (64 bytes) (field root:)
--> MemoryTest@0x2f47da0 (280 bytes) (field testArray:)
--> [B@0x2f5bde0 (57671688 bytes) 

The RepaintManager should instead be referred to via a weak reference. I believe there should be no issue in doing this for normal applications since there should be other strong references which refer to the RepaintManager during typical execution which will prevent it from being GCd too eagerly and reallocated.
After discussion with the Swing team, changing the reference to the RepaintManager to be weak would be incorrect. Instead, the RepaintManager and subclasses should be changed to refer to their Components via weak references.

We have worked around this issue for the time being in the Java Plug-In under 6671092, though it would be desirable for the correct fix to be put into the RepaintManager.