On Wed, 24 Feb 2021 18:57:25 GMT, Sergey Bylokhov <[email protected]> wrote:
> This bug was reported as a leak of the ImageObserver when the user draws a
> multiresolution image.
>
> The multiresolution image is an image that contains a few images inside, when
> the app uses the observer to get notifications about image loading we create
> a special internal observer and use it to track loading resolution-variants.
> This internal observer forwards notification from the resolution variant to
> the application observer.
>
> The mapping from the application observer to the internal observer is done
> via "SoftCache" which is a kind of HashMap that uses soft references to the
> key and value.
>
> Here the bug comes, the soft references are cleared only under memory
> pressure, and unused objects may sit hours in memory before being cleaned.
> Moreover, the internal observer was implemented using a strong reference to
> the application observer(it is not obvious since the lambda is used). So the
> key object refers to the application's observer cannot be clear fast. This
> causes an even longer delay of the memory cleanup, which was considered by
> the use as a "leak".
>
> The fix changes the usage of SoftCache to the WeakHashMap, so the key(the
> application observer) will be cleared when the application lost the reference
> to it.
src/java.desktop/share/classes/sun/awt/image/MultiResolutionToolkitImage.java
line 130:
> 128:
> 129: if (observer == null || image == null) {
> 130: return false;
How about a case when `ObserverCache`'s class instance is not collected by GC,
but its `observerRef` or `imageRef` is collected. Is it possible?
If so this class instance will permanently return false on `imageUpdate()` call.
-------------
PR: https://git.openjdk.java.net/jdk/pull/2711
