Hi, Vladimir,
have you received this reply, or it was lost for some reason?
Thanks,
Artem
On 8/28/2013 5:52 PM, Artem Ananiev wrote:
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
