Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 3.1_dev
    • Fix Version/s: None
    • Component/s: performance
    • Labels:
      None

      Description

      The memory issues related to Weld/CDI reported in GLASSFISH-14419 seem to be gone with 3.1-b33. This is good news.

      However, repeating my tests I noticed a new issue. Deploying the same WAR (which does not use CDI at all) to different Glassfish versions and taking heap dumps with the Eclipse Memory Analyzer, I measured the following total heap sizes:

      GF 3.0.1 44.4 MB
      GF 3.1-b33 138.3 MB

      In 3.1b33, there are two instances of org.glassfish.hk2.classmodel.reflect.impl.TypesCtr with about 80 MB of retained heap. In 3.0.1, all of org.jvnet.hk2 only has a retained heap of 6.5 MB.

        Activity

        Hide
        dochez added a comment -

        I have traced down the problem to the deployment backend where any module data associated with the deployment context is added to the ApplicationInfo (which represents deployed applications in memory).

        ApplicationLifecycle : line 391

        for (Object m : context.getModuleMetadata())

        { tempAppInfo.addMetaData(m); }

        I thought only transient meta data was saved in application info but it seems everything is saved. I need some feedback from Hong why the deployment context module data is saved.

        Show
        dochez added a comment - I have traced down the problem to the deployment backend where any module data associated with the deployment context is added to the ApplicationInfo (which represents deployed applications in memory). ApplicationLifecycle : line 391 for (Object m : context.getModuleMetadata()) { tempAppInfo.addMetaData(m); } I thought only transient meta data was saved in application info but it seems everything is saved. I need some feedback from Hong why the deployment context module data is saved.
        Hide
        Hong Zhang added a comment -

        I have talked with Jerome later this afternoon on this:
        1. The module metadata need to be stored in the ApplicationInfo for the containers to access, mainly the DOL objects, so we need to continue to store them in the ApplicationInfo.
        2. The annotation processing result which is currently stored as module metadata should be stored as transient metadata and not tranferred to the ApplicationInfo.
        3. The ApplicationInfo currently transfers all the deployment context transient metadata to itself, we should no longer do that. Will find the code which relies on this and have that code explicitly add information to ApplicationInfo if it needs to access it.

        I will take care of 3) and then Jerome can take care of 2).

        Show
        Hong Zhang added a comment - I have talked with Jerome later this afternoon on this: 1. The module metadata need to be stored in the ApplicationInfo for the containers to access, mainly the DOL objects, so we need to continue to store them in the ApplicationInfo. 2. The annotation processing result which is currently stored as module metadata should be stored as transient metadata and not tranferred to the ApplicationInfo. 3. The ApplicationInfo currently transfers all the deployment context transient metadata to itself, we should no longer do that. Will find the code which relies on this and have that code explicitly add information to ApplicationInfo if it needs to access it. I will take care of 3) and then Jerome can take care of 2).
        Hide
        Hong Zhang added a comment -

        How bad is its impact? (Severity)
        Regression from previous release. Will hurt user experience, consumes un-necessary memory.

        How often does it happen? Will many users see this problem? (Frequency)
        Often. It will happen for any application which uses annotations (but the impact varies depending on the particular application).

        How much effort is required to fix it? (Cost)
        The fix is understood and under way.

        What is the risk of fixing it and how will the risk be mitigated? (Risk)
        Small to medium. Have involved relevant people in the discussions and will ask relevant people to review code and run the necessary tests.

        Show
        Hong Zhang added a comment - How bad is its impact? (Severity) Regression from previous release. Will hurt user experience, consumes un-necessary memory. How often does it happen? Will many users see this problem? (Frequency) Often. It will happen for any application which uses annotations (but the impact varies depending on the particular application). How much effort is required to fix it? (Cost) The fix is understood and under way. What is the risk of fixing it and how will the risk be mitigated? (Risk) Small to medium. Have involved relevant people in the discussions and will ask relevant people to review code and run the necessary tests.
        Hide
        Nazrul added a comment -

        Approved for checkin

        Show
        Nazrul added a comment - Approved for checkin
        Hide
        Hong Zhang added a comment -

        I have checked in my side of the changes to take care of 3). Will transfer the issue to Jerome to take care of 2) now.

        Show
        Hong Zhang added a comment - I have checked in my side of the changes to take care of 3). Will transfer the issue to Jerome to take care of 2) now.
        Hide
        dochez added a comment -

        checked in the code so the class-model Types instance is not stored in the ApplicationInfo instance

        Show
        dochez added a comment - checked in the code so the class-model Types instance is not stored in the ApplicationInfo instance

          People

          • Assignee:
            dochez
            Reporter:
            Harald Wellmann
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: