com.sun.glass.ui.mac.MacView created by every new Stage/Scene
are not release. As result the references to Stage/Scene and their
objects are also kept alive.

This leads to constant memory usage growth in performance benchmark as they create
new Stage/Scene on every new iteration. You can see fx2.0.2-b02 memory usage results on mac here:
 http://aurora.russia.sun.com/performance/faces/ChessBoard.xhtml?reportName=FX2&parameters=%5Bshownbenchmarks%5D%281%3D1%29%5Brefrelease%5D2.0.2%5Brefbuild%5D%3D+-1%5Brefjdkrelease%5Dnone%5Bhwclassref%5Dhost.machine.additionalInfo+%3D+%27Mac-Mid-Range%27%5Brelease%5D%28pr.product.productRelease+%3D+%272.0.2%27%29%5Bbuild%5D%28pr.product.build+%3D+%2714%27%29%5Bjdkrelease%5D%28jdk.product.productRelease+%3D+%271.6.0_26%27%29%5Bhwclass%5Dhost.machine.additionalInfo+%3D+%27Mac-Mid-Range%27&splitting=%5BX+axis%5DfxConf%2C+metricName%5BComplement%5DfxRelease%2C+benchmark%2C+jdkBuild%2C+jdk%5BZ+axis%5Dhwclass%2C+os%2C+jdkRelease%2C+benchmarkSuite%5BY+axis%5DbenchmarkName%2C+benchmarkConf%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=

Note, there are no such problems on Windows. Stage/Scene objects are garbage collected by the end of each
performance test iteration. We also call System.gc() couple of times at the end of each iteration and as result
all unreachable objects (at least by strong references) are supposed to be collected. The fact MacView
objects are not collected means there are strong references to them. Memory heap analyzer doesn't allow
to see them as they are referenced from some native objects.

I used guimark2.BitmapBenchmark to reproduce the issue. I have stopped the benchmark after 3rd iteration,
created heap dump, then stopped after 10 iterations, created heap dump and did compare results.

This is quite important issue and would be nice to fix it soon.
This memory leak prevents or complicates finding other memory leaks
and also affect performance results. More memory to be analyzed on every new
iteration => could slow down the performance.