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

[Robin Stevens]

Hello Alexandr,

very valid remark.
Running that same test program on Linux with the metal look and feel
reveals no memory leak. I have no access to a Windows machine, so I
couldn't get the Windows specific look and feel.

The other ProgressBarUI implementations seem to extend from
BasicProgressBarUI, which has the same mechanism of an Animator which uses
a Timer.
However, in the test program the Timer does not get started on Linux (while
it gets started on OS X).

In the BasicProgressBarUI class, all calls to startAnimationTimer are
wrapped with an if check:

        if (progressBar.isDisplayable()) {
            startAnimationTimer();
        }

In the scenario from my test, the isDisplayable method returns false. On OS
X, this check is missing so the timer is started.

I assume adding that same check in the AquaProgressBarUI will fix the
problem as well. So that is a third approach to solve the issue.

Robin

On Tue, Jul 19, 2016 at 1:14 PM, Alexandr Scherbatiy <
alexandr.scherbatiy at oracle.com> wrote:

> On 7/19/2016 12:27 PM, Robin Stevens wrote:
>
>> 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.
>>
>    Does other L&Fs (for example Metal) have the same memory leak with the
> JProgressBar? If no, it would be interesting to know what is the difference
> between them and the AquaProgressBarUI.
>
>   Thanks,
>   Alexandr.
>
>>
>>
>> Robin
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160719/1b6f9941/attachment.html>