Community
Participate
Working Groups
This bug was reported in bug 402983 comment 21 https://bugs.eclipse.org/bugs/show_bug.cgi?id=402983#c21
From the bug: Investigating the duplicate package visible icons, I was able to reproduce with a fresh Eclipse 4.3.1 SDK, a new workspace and these steps: 1. In the workspace preferences, under General > Appearance > Label Decorations, enable "Java Type Indicator" 2. In the Package Explorer, enable "Link with Editor" 3. Create a new Plug-In Project, accepting all defaults 4. Open the newly created Activator.java 5. Open a package private class file, e.g. org.eclipse.core.internal.adapter.AdapterFactoryProxy 6. For good measure, switch a couple of times between the two editors 7. Take a snapshot in Sleak 8. Switch some more between the editors 9. Show the diff in Sleak You should see a number of images at the bottom of the list, all copies of the package local class file icon. I'm sure there's other leaks - or pathes to this one - though, because my Eclipse currently grows by about 1000 images per hour in my productive workspace. I'll keep looking.
That was a tricky one to debug! It turns out that the problem is a missing #equals and #hashCode in InterfaceIndicatorLabelDecorator.TypeIndicatorOverlay. As a result, the resource manager thinks he needs to create a new decorate image every time.
ImageDescriptor doesn't tell that implementations must override equals/hashCode. If all implementation are expected to do this, then this must be documented and added to the migration guide, so that existing implementations can be fixed. Probably affects all DeviceResourceDescriptors. You can also blame the DecoratorManager for holding on to so many images that are not in use any more -- however, that's hard to fix: DecorationResult#decorateWithOverlays(Image, ResourceManager) calls ResourceManager#createImage(ImageDescriptor), whose Javadoc tells that it leaks unless the resource manager is short-lived or the image is manually destroyed. Neither of these conditions can be satisfied, since the workbench window is long-lived and we have no clue how long the created images will be in use. Maybe the DecoratorManager could use a special 'lossy' ResourceManager that doesn't use reference counting but wraps the values (created Images) into a WeakReference and calls destroyImage(ImageDescriptor) when an Image becomes weakly reachable, i.e. right when it can be disposed. Though that would remove the 'caching' feature of DecoratorManager for images that are not always in use somewhere.
Same bug is in 3.x as well. I don't think we will make big changes to the decoration story at this point, so, just stating the expected behavior is the practical thing to do here.
Fixed with http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=a5ed672f97aee794e1e2512ad609484eb3b2409d Filed bug 420741 for updating the Javadoc.
Verified in I20131030-2000.
