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

Memory churn in jimage code affects startup after resource encapsulation changes

    Details

    • Subcomponent:
    • Resolved In Build:
      b160
    • Verification:
      Not verified

      Backports

        Description

        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.

          Attachments

            Issue Links

              Activity

                People

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

                  Dates

                  • Created:
                    Updated:
                    Resolved: