RT-16630 "setStyle with lookup values is fixed in runtime" integrated into 2.0.2-controls-scrum build b10 introduced
memory leak in CSS. There are bunch of mam_memory_usage regressions in b10 comparing to b9. Memory usage growth on each
iteration which assumes there is a memory leak. Here are the regressions:
 Controls.CheckBox-adhoc-items300-toggle30: 48,196 ± 575.04 2% (929.33)
 Controls.CheckBox-adhoc-items300-toggleAll: 49,129.33 ± 1,631.61 4% (2,085.33)
 Controls.RadioButton-adhoc-items300-toggleAll: 47,769.33 ± 1,887.78 5% (2,481.33)
 Controls.TableView-Keyboard-adhoc-table30x150-press1: 66,605.33 ± 3,511.46 8% (5,008)
 Controls.TableView-Sort-adhoc-table30x150-sort1: 110,469.33 ± 5,330.83 5% (5,234.67)
 Controls.TreeView-Expand-adhoc-items100-depth: 68,706.67 ± 8,020.92 50% (22,758.67)
 Controls.TreeView-Expand-adhoc-items100-wide: 62,272 ± 4,537.72 37% (16,920)
 Controls.TreeView-Keyboard-adhoc-tree1000x50-press50: 146,865.33 ± 1,623.48 2% (2,286.67)

 There are also regressions in NodeMemory bechmarks:
  NodeMemory.TableView.rendering-on-48mb: 737,960 ± -1 -9% (-73,840)
  NodeMemory.TreeItem-rendering-on-48mn: 61,490 ± -1 -3% (-1,690)


 See all regressions in Aurora here:
 http://aurora.russia.sun.com/performance/faces/ChessBoard.xhtml?reportName=FX2-controls-scrum&parameters=%5Bshownbenchmarks%5D%281%3D1%29%5Brefrelease%5D2.0.2%5Brefbuild%5D%3D+%279%27%5Brefjdkrelease%5D1.7.0%5Brelease%5D%28pr.product.productRelease+%3D+%272.0.2%27%29%5Bbuild%5D%28pr.product.build+%3D+%279%27%29OR%28pr.product.build+%3D+%2710%27%29%5Bjdkrelease%5D%28jdk.product.productRelease+IS+NOT+NULL%29&splitting=%5BX+axis%5DfxConf%2C+metricName%5BComplement%5Dbenchmark%2C+jdkBuild%2C+jdk%5BZ+axis%5Dos%2C+hwclass%2C+jdkRelease%2C+benchmarkSuite%5BY+axis%5DbenchmarkName%2C+benchmarkConf%2C+fxRelease%2C+fxBuild&reference=%5BOthers%5DfxRelease%2C+fxBuild%2C+jdkRelease%2C+jdkBuild%2C+jdk%2C+benchmarkSuite%2C+benchmarkName%2C+metricName%5BReference+Set%5Dbenchmark%2C+os%2C+benchmarkConf%2C+fxConf%2C+hwclass&mixReference=false&flags=&significance=empty&hideDataConfiguration=false&calculateSummary=false&showSummaryExpanded=false&showSummaryContents=true&showComplementAttributes=false&compactTables=true&viewStyle=chessboard&filter=
 

I looked at TreeViewExpand test and run it with 16mb and 32mb of heap. In both cases the OOM occured pretty quickly.
The OOM occures because the number of StyleHelper$CacheEntry and StyleHelper$CalculatedValue constantly grows and
occupies almost all heap. Here is the diff between 16mb of heap and 32mb of heap:

com.sun.javafx.css.StyleHelper$CacheEntry 9,103 objects -> 19,780 objects
com.sun.javafx.css.StyleHelper$CalculatedValue 196,236 objects -> 427,768 objects

The standalone test TreeViewExpandPerfTest.java to reproduce the memory leak is attached.