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

Memory churn in jimage code affects startup after resource encapsulation changes

XMLWordPrintable

    • b160
    • Not verified

        After 9+148 a number of startup and footprint benchmarks show significant, sometimes large regressions.

        Analysis shows this is due to the changes to resource encapsulation, which means that when calling ClassLoader::getResource with a resource name that's not encapsulated we will now scan every module for resources. What this means is that ImageReader code that was previously seldom seen during startup is exercised more often than not.

        Experimenting with the code that shows up in profiles has proven that by reducing memory churn in some places we can recuperate a significant portion (>50%) of the regression, showing that most of the measured footprint overheads comes from increased allocation and touching of memory pages early on in an application's lifecycle.

              redestad Claes Redestad
              redestad Claes Redestad
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: