There is 75% regression in NodeMemory.ComboBox-rendering-on-64m occurred in build 8.0-controls-scrum-287.
NodeMemory.ComboBox benchmark measures how many ComboBox objects we are able to create till we reach
memory limit (64mb in our case). The results for builds 286 and 287 are:
 286: 1,030 objects
 287: 252 objects

Memory usage for Controls.Popup-ComboBox benchmark also increased up to 170%.

I have created heap dumps when there are only 100 ComboBox objects created for builds 286 and 287.
The difference is quite big, there are much more extra objects created in case build 287 is used.
See the whole difference in combobox_heap_diff_286vs287.txt attached


It looks like some related style data are not cleared.

According to Hudson 8.0-controls-scrum-287 contains the following ComboBox related changes:
  35. RT-27830: ComboBox sized and positioned incorrectly on first showing (detail)
  36. RT-21406: ComboBox do not show initial text value (detail)
  
Full list of changes:
 http://getjfx.us.oracle.com/hudson/view/8.0/job/8.0-controls-scrum/287/label=windows-i586-30/


Steps to reproduce:
> cd JFX_WS/tests/performance/NodeMemory/
 > ant
 > java -client -Xms64m -Xmx64m
       -cp "JFX_HOME/rt/lib/jfxrt.jar;./dist/NodeMemory.jar"
       nodememory.ComboBoxTest -render true -allocCnt 10