home‎ > ‎

JavaFx TableView Memory Leak

posted Sep 18, 2013, 1:24 AM by Daniel Stieger   [ updated Sep 18, 2013, 1:26 AM ]

Before going productive with some of our generated user-interfaces in java FX, we set up a
profiling session in MAT to spot potential memory leaks (jdk at hand was 1.7.0_u25). And indeed,
we found some leak suspects related to the java FX TableView control. Once a TableView control
was instantiated it was not collected any more, holding quite a lot of retained heap with all it s data
objects. More precisely, only after same interaction with the TableView took place (by selecting a
row), the TableView did not get garbage collected.

 

Although Tom Schindl from bestsolution.at already filed a bug report on the issue, a fix on jdk7
is not available. We met last week to devise a workaround - and we finally found one.

 

Our proposed workaround is not a single measure, but a whole series of steps to ensure the cleanup.
One major problem is related to the selection and the focus model behind TableViews. Therefore,
(1) we set the focus model to null. The Fx class TableCellBehavior holds a reference in a static map
to all TableViews loaded. This reference is not removed when the TableView is no longer in use. By
using reflection, (2) we call setAnchor() of TableCellBehavior to remove this reference manually.
(3) All actions and listeners are removed and (4) we clear the Columns. We also noted, that FX
keeps track of the last removed nodes from the scene graph. (5) We call setCenter() twice to get
the table removed for the current BorderPane. However, we did not investigate the importance of
this measure further. (6) Last but not least, we get rid of all the items displayed in the table - also
just a measure of safety.

 

 


(Pic 1: Cleanup code used)

 

After applying this workaround in our TableForm component, we recognize a total heap size of aprox.
12 MB after program start-up. Displaying various data in some tabs results in a 100MB heap, but
closing the tabs and issuing a "perform GC" brings the heap down to 12MB +/- again.

Comments