I have discovered that we have continuous memory growth when running some of our performance benchmarks.
The memory grows from one iteration to another one.
Here is the example of charts.bm.BubbleBenchmark running with b44:
   MAX_MEMORY_USAGE 72980.000000
   MAX_MEMORY_USAGE 77320.000000
   MAX_MEMORY_USAGE 81224.000000
   MAX_MEMORY_USAGE 85208.000000
   MAX_MEMORY_USAGE 88724.000000
   MAX_MEMORY_USAGE 94628.000000
   MAX_MEMORY_USAGE 98556.000000
   MAX_MEMORY_USAGE 102552.000000
   MAX_MEMORY_USAGE 107340.000000
   MAX_MEMORY_USAGE 112172.000000
   MAX_MEMORY_USAGE 116296.000000
   MAX_MEMORY_USAGE 121072.000000
   MAX_MEMORY_USAGE 123080.000000
   MAX_MEMORY_USAGE 125248.000000
   MAX_MEMORY_USAGE 134020.000000
   MAX_MEMORY_USAGE 137360.000000
   MAX_MEMORY_USAGE 139788.000000
   MAX_MEMORY_USAGE 142780.000000
   MAX_MEMORY_USAGE 144400.000000
   MAX_MEMORY_USAGE 151288.000000
   MAX_MEMORY_USAGE 151288.000000


I have created 2 heap dump files: one after second test iteration, second one after 10 test iterations.
Note, full GC was done before heap dump was created.
Heap dump analysis shows that retained heap of com.sun.javafx.css.StyleManager is growing:
  after 2 iters: 2, 014,192
  after 10 iters: 25, 460,135

See also heap histograms attached.

The reason is because the number of com.sun.javafx.css.StyleManager$StylesheetContainer objects was increased
from 3 to 11. These objects are values of Map<Scene, StylesheetContainer> containerMap of class com.sun.javafx.css.StyleManager.
It looks like these entries are not deleted for some reason even in case there are no live scenes available any more.