On Wed, 24 Feb 2021 18:57:25 GMT, Sergey Bylokhov <s...@openjdk.org> 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