<AWT Dev> <Swing Dev> javax.swing.RepaintManager volatileMap
artem.ananiev at oracle.com
Wed Aug 28 06:52:48 PDT 2013
I agree that using a class with no equals/hashCode overridden as a key
for HashMap is not the best thing to do. However, in this case the
problem seems to be caused by something else.
I'm not an expert in RepaintManager, but here is what I observe:
1. When graphics environment changes, we get displayChanged()
notification (it's not a public API yet, unfortunately).
2. RepaintManager.displayChanged() clears all the volatile images, as
they depend on the GraphicsConfiguration objects and may be invalid
3. In clearImages(), we iterate through volatileMap and remove the
images. Note that despite GraphicsConfiguration doesn't override
equals/hashCode, iteration should still work.
Anyway, it indeed looks like a bug, no matter of what it's caused by. Do
you have a test case that can be used to reproduce it, other than to run
On 8/28/2013 3:00 PM, Vladimir Sitnikov wrote:
> In the heapdump of SQL Developer 4.0 I found that RepaintManager holds
> 23 items of sun.awt.image.BufImgVolatileSurfaceManager 5-10MiB each.
> All the images are contained in "volatileMap" HashMap.
> I identified that the key of the map is sun.awt.Win32GraphicsConfig and
> that class does not override equals/hashCode.
> Can you please tell me if "using GraphicsConfig as a key knowing the
> fact this key does not ovveride equals/hashCode" is intentional or not?
> I have checked several keys of the map (Win32GraphicsConfig) and they
> have identical value (even screen and sTypeOrig references point to the
> same objects), however as the Win32GraphicsConfig objects itself are
> different java objects they occupy different entries in valueMap.
> Vladimir Sitnikov
More information about the awt-dev