Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8128229

com.sun.glass.ui.mac.MacView are not garbage collected

    Details

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                anthony Anthony Petrov (Inactive)
                Reporter:
                epavlova Ekaterina Pavlova
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported: