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 occasionally.
See also "Problem 2: Memory Leaks" in my post on "The Trouble with Weak Listeners" http://tomasmikula.github.io/blog/2015/02/10/the-trouble-with-weak-listeners.html Tomas On Fri, Mar 27, 2015 at 2:36 PM, Scott Palmer <swpal...@gmail.com> 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 <swpal...@gmail.com> 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 >>
