ProgressBar has significant leaks

Tomas Mikula tomas.mikula at
Fri Mar 27 19:21:23 UTC 2015

Looks like someone is adding weak listeners to ProgressBarSkin$1 in
the first case and to Node$NodeTransformation$2 in the second case,
but does not bother removing them, relying on the WeakReference to
enable their garbage collection. Well, the listeners themselves get
garbage collected, but the WeakReferences to them do not, until the
property is invalidated. Can you figure out what ProgressBarSkin$1 and
Node$NodeTransformation$2 are? These are probably properties that
don't change, thus WeakListeners fail to work well with them. You
could probably work around the problem by invalidating them

See also "Problem 2: Memory Leaks" in my post on "The Trouble with
Weak Listeners"


On Fri, Mar 27, 2015 at 2:36 PM, Scott Palmer <swpalmer at> wrote:
> Another chain to the GC root looks like:
> WeakReference
> BindingHelperObserver
> InvalidationListener[]
> ExpressionHelper$Generic
> Node$NodeTransformation$2
> Node$NodeTransformation
> StackPane
> ProgressBarSkin
> ProgressBar
> On Fri, Mar 27, 2015 at 2:28 PM, Scott Palmer <swpalmer at> wrote:
>> I searched the bug database and though ProgressBar leaks have been
>> reported before, they are supposed to be fixed in 8u40.  I'm seeing tons of
>> leaks in 8u40.
>> Comparing heap dumps with jvisualvm I see in three minutes that my app has
>> accumulated 11,000 WeakReference and BindingHelperObserver objects that
>> appear to be associated with the ProgressBarSkin.
>> The chain to the GC root looks like this:
>> WeakReference
>> BindingHelperObserver
>> InvalidationListener[]
>> ExpressionHelper$Generic
>> ProgressBarSkin$1
>> ProgressBarSkin
>> ProgressBar
>> My application needs to run for a long time.  (Streaming realtime video -
>> i.e. a TV station broadcast for hours if not weeks at a time...)
>> I suspect this may be a regression in 8u40.  I will try to get that
>> confirmed.
>> Scott

More information about the openjfx-dev mailing list