<Swing Dev> Input needed: JDK-8161664: Memory leak in com.apple.laf.AquaProgressBarUI: removed progress bar still referenced

[Robin Stevens]

Hello,

I wanted to discuss my approach for issue JDK-8161664 (
https://bugs.openjdk.java.net/browse/JDK-8161664) before I started working
on this issue.

In certain scenarios (see the JIRA issue for an example), the Timer in the
Animator inner class of the AquaProgressBarUI class remains running, even
when the JProgressBar has already been removed from the UI. This causes a
memory leak, as that running Timer avoids that the JProgressBar can be
GC-ed. As long as the Timer is running, the JProgressBar is referenced
through

Timer -> ActionListener (=Animator inner class) -> AquaProgressBarUI outer
class -> JProgressBar field



I see two possible approaches to fix this:

1) I carefully investigate the particular scenario I found, and try to
figure out why the Timer is not stopped and fix this particular scenario.
This offers of course no guarantees that there are no other scenarios which
keep the Timer running.

2) I replace one of the hard references with a weak reference, hence
avoiding the memory leak in all cases.
If I do not attach the Animator inner class directly as listener to the
timer, but use another ActionListener which only has a WeakReference to the
Animator class, the memory leak is solved.
The ActionListener could then stop the timer when the timer is fired and
the WeakReference#get returns null.



I prefer the second approach. By cutting the hard reference between the
Timer and the Animator + stopping the Timer when the Animator is GC-ed, I
ensure that the Timer cannot cause a memory leak anymore. This avoids
overlooking certain scenarios.

Any input on this ? Any preferences for a certain approach, or proposal for
another approach.


Robin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160719/382394ad/attachment.html>