One of the really bad things in JavaFX 2.2 is that it has some serious memoryleaks in conjunction with TableViews.
I’ve filed a bug report against it (RT-32087) to it is fairly uncertain that there’s ever going to be a fix in 2.2 which is a real problem if you need to go GA before March 2014. So together with one of our customers we’ve studied heap dumps to find out where the strong references have been held so that we could go brute force way using reflection and clearing them up.
Daniel has posted our findings at http://www.modellwerkstatt.org/home/javafxtableviewmemoryleak
I hope this helps others having the same troubles
Tomsondev Blog 
Oracle totally dropped the ball on JavaFX2. It is riddled with bugs and memory leaks, code that is nowhere near production-worthy, none of which will get fixed (maybe) until FX8. Can you get it to work, yes, with reflection hacks remarkably similar to yours :). We have shipped a large, sophisticated trading platform using it, but if we had known what we were in for, there is a good chance we might have taken another route (maybe Swing even). Lets hope FX8 is better.
p.s. did you know TableCellSkin instances cost around 7K in memory? 14MB just for the cells in a 20 column 100 row table is insane. The real business data in our app comes to less than 70MB. The other 600MB is JavaFX.
Did you try my workaround, which I posted in Jira issue?
Although the problem there is in the same area the leak we fixed with this customer had nothing to do with graphics, I also think the sample I posted does not exhibit ALL memory leaks produced by the *View controls
Pingback: JavaFX links of the week, September 23 // JavaFX News, Demos and Insight // FX Experience
Pingback: Java desktop links of the week, September 23 « Jonathan Giles
what is your personal experience with FX8? Do you think the memory leak problems were solved? I installed the latest JDK ( build b108) and was surprised by the enormous initial memory consumption in the demo applications that rapidly grew when navigating back and forth in the UI a couple of times.
In the scenario we have FX8 fixed the problems. Generally speaking FX8 performs a lot better than FX2 and many problems have been fixed. Which demo app are you running? Might be worth to analyze it and see if there are other leaks. I’m sure when we bring them to the attention of the FX-Team we can get them fixed before FX8 goes GA, I’m always wondering – like with our problem – if this should be part of the SQE of such a library.
I just had a look at the Modena and Ensemble applications provided in the javafx samples. The memory usage was more than 1 GB after a few clicks. Too much for a simple UI demonstration.
Agreed! It would be interesting to see where the memory is going to. If i have time i give MAT a spin on them
Hi Tom, can you expound more on why we have to remove the actions and listeners (3), and also clear the columns (4)?
Those are just to make extra sure nothing is referenced even if it is a weak reference internally, on of the problems of inner-classes is that they hold a strong ref to the outer class, which means that the inner-class is only released once the outer class is gc’ed
Thanks for explaining. It would be great if you or Daniel could have another blog post explaining the reasons for the workarounds in detail.
Hi Tom,
I am stuck in the same issue. I had a look on your code but the problem is that i dont have reference of selection listener in my code. So can u pls modify the code to remove all selection listeners and callbacks using reflection.
Thanks,
Neo
I’m sorry but I’m not fixing your problems for free.
Thank you, very, very, VERY much.