JDK-6482575 : Leak in ImageIcon
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-10-16
  • Updated: 2013-10-07
  • Resolved: 2011-05-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6 JDK 7
1.4.2_32Fixed 6u10Fixed 7 b22Fixed
Related Reports
Relates :  
JDK-6482571 - Leak in MetalLookAndFeel
Relates :  
JDK-6591450 - Plugin always sets the Swing LookAndFeel
Relates :  
JDK-7035495 - javax.swing.ImageIcon spec should be clarified
Relates :  
JDK-6641564 - Break dependence on javax.swing.ImageIcon in new plugin
Relates :  
JDK-6597821 - WWindowPeer leaks AppContexts
Description
ImageIcon creates a Component, which references the AppContext that created it. This results in pinning down the first AppContext that triggers loading of ImageIcon.
Comments
EVALUATION It turns out that AppContext can also get stuck in the MetalLookAndFeel.cachedAppContext static variable. This is addressed by 6482571. Between that fix and this fix, AppContexts should no longer leak for 6u5 (JDK7 requires further investigation). While profiling this, I noticed that AppContexts also appear to get stuck via JFrame in Java2D's BufferedContext.currentContext. This goes away once Java2D has drawn onto another surface, however it can take a few rounds of GCing for the JFrame/AppContext/WindowDisposerRecord to make it through the J2D Disposer's ReferenceQueue.
24-08-2007
EVALUATION BTW, I've been using Chris Oliver's JApplication (along w/ a test case which uses ImageIcon) to reproduce this bug. See his "Poor Man's Multi-VM" blog entry for details: http://blogs.sun.com/chrisoliver/entry/poor_man%27s_multi-vm
24-08-2007
EVALUATION This bug presents some interesting problems: * component and tracker are protected variables in ImageIcon. They are completely undocumented, so why anyone would use them is beyond me, but even so we can't just rip them out of ImageIcon * component and tracker are also final variables, so we can't, for instance, listen for AppContext disposal and recreate them on a different AppContext. * We can't sneakily unhook component's appContext reference, as it's package private to java.awt, and we'd be coming from javax.swing. ComponentAccessor might help with this, but that's only in JDK7. * The ImageIcon spec mentions in several places that it uses MediaTracker to track the loading of images, and in fact returns constants from the MediaTracker class from ImageIcon.getImageLoadStatus(). I don't see being able to move to something such as ImageIO (at least not until JDK 7). So, our two issues are: 1) Get rid of the ImageIcon->Component->AppContext leak 2) Still track image loading with MediaTracker (1): I think the path of least risk is to set component and tracker to null. The chances of someone subclassing ImageIcon *and* using these variables for anything seems extremely small. (2): We could create (and release) a new MediaTracker for every ImageIcon instance, but that could get expensive given that larger apps might load dozens or more ImageIcons. The next best thing is to have a MediaTracker per-AppContext. This cuts way down on the number of MediaTrackers created, and the MediaTracker (and it's Component) would be disposed along with the AppContext, instead of leaking it.
22-08-2007
EVALUATION Will investigate for JDK 7.
17-10-2006