Memory leak seen in Nimbus L&F 

To reproduce 

run SwingSet2/SwingSet3 with Nimbus L&F  attach this process to a netbeans profiler as an external app. The memory use of different classes instantiated can be seen in the memory profiling. 

instances of the class com.sun.java.swing.plaf.nimbus.DuoDerivedColor$UIResource keeps increasing and never gets garbage collected  even if the user forces garbage collection. 


The  customer  of this particular class is around 50-60 bytes in size but if the app is run for a 4-5 hours continuosly with large no of repainting e.g. some Animation. the no of instances keeps going up... never comes down.

In this case i tried the following 
1) minimize/maximize app 
2) moving  anative window over the app 
3) keeping multiple native windows over the app and bringing the app to the foreground 

All this forces either complete repaint or partial repaint  - I could see the instances of the particular class going up for each repaint. (forcing a gc call didn't reduce even one instance) 

Have attached a screenshot of the profiling info with the particular instance count highlighted
Posted Date : 2008-06-24 09:03:17.0

N/A

The bug appears to be caused by the fact that DuoDerivedColor is created and added as a listener to DerivedColor, but never removed. Coupled with the fact the NimbusLookAndFee.getDerivedColor creates a new DuoDerivedColor on each call, and you have a classic property change listener based leak.

The fix is probably to alter DerivedColor such that:
	a) It doesn't use PropertyChangeSupport
	b) It handles all property change listeners as weak references

Since DerivedColor is package private, this is perfectly legitimate since only DuoDerivedColor ever listens to change events on DerivedColor, and we don't have to worry about other clients tripping over the addPropertyChangeListener method not working for anonymous inner classes.
Posted Date : 2008-06-27 00:00:01.0