The number of com.sun.javafx.css.StyleHelper$CacheEntry objects grows over time and leads to OOM in css

Ensemble run with 128mb of heap failed with OOM after 1098 iterations
were passed (this means every sample was clicked on 1098 times).
Comparing this heap dump with heap dump gotten with 72mb of heap shows that there is
at least memory leak in CSS.
The number of com.sun.javafx.css.StyleHelper$CacheEntry objects grows from
3,514 to 12,495 and finally occupy about 20mb of heap.

All these com.sun.javafx.css.StyleHelper$CacheEntry objects are reachable from
valueCache attribute of com.sun.javafx.css.StyeleHelper objects.

The number of elements of valueCache is almost the same for 72mb and 128mb of heap:
 72mb: 1,771
128m: 1,790

The difference seems mostly comes from the fact that each valueCache entry (which is of type
List<CacheEntry>) has more CacheEntry objects for some reason. As I understand they correspond to different
states of the node. Perhaps the leak is because CacheEntry objects which correspond to obsolete states
are not removed.

I can't be sure in my observations and would suggest to look at heap dump files using Eclipse Memory Analyzer.
This tool allows to easy look at values of particular CacheEntry objects.
Heap dump files are located here:
 /net/jano1.us.oracle.com/export1/swing/fxperf/bugs/<this-bug-id>/heap_2854_72m.hprof
 /net/jano1.us.oracle.com/export1/swing/fxperf/bugs/<this-bug-id>/heap_2854_128m.hprof