<Swing Dev> javax.swing.RepaintManager volatileMap

[Artem Ananiev]

Hi, Vladimir,

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 
JDeveloper?

Thanks,

Artem

On 8/28/2013 3:00 PM, Vladimir Sitnikov wrote:
> Hi,
>
> 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.
>
> --
> Regards,
> Vladimir Sitnikov