Announcement Announcement Module
Collapse
No announcement yet.
Service Object Not GC'ed after undeploying the bundle ? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Service Object Not GC'ed after undeploying the bundle ?

    I tried a small use case with the following

    Bundle A - service provider

    Bundle B - service consumer

    I used Yourkit to do the profiling.

    Now first i deploy Bundle A , and see teh your memory tab . I see a instance of my service object created.

    Now I undeploy the Bundle A . now i expect teh service object to be GC'ed.I tried forcing the GC using YourKit utility. Still GC doesnt happen ?

    I tried this in Dm 2.0. M4 version.

    Isnt it a BUG ? Is the Dm/Equinox code still holding some reference into service object ? Shouldnt it be freed ?

    In Dm 1.0.2 i see that it gets GC'ed, but when i deploy the Bundle B and then undeploy Bundle A , the instance does not get cleared . Is that expected ?
    IF so, y ?

  • #2
    This sounds a lot like a problem we encountered recently and tracked down to a bug in Equinox. We should be upgrading to the latest 3.5.x release of Equinox in our current sprint. DMS-1598 is tracking this.

    My guess is that this problem may well be solved once we've done this upgrade, although I can't be certain without some more details. Have you looked in YourKit at what's holding the service object in memory, i.e. what are the paths to GC roots for the service?

    Comment


    • #3
      Hi Andy,

      You could be right. I have attached the gc root obtained from yourkit.

      Comment


      • #4
        Attaching image for better clarity

        Comment


        • #5
          Thanks for the image. It shows that your service is being held in memory due to a ServiceReference instance that's being held by an org.apache.felix.log.LogNode instance. Unfortunately, I can't tell what's holding the LogNode in memory as its path isn't expanded in the image. If you fully expand the GC root path, we should be able to get a better idea of what's causing the problem.

          Comment


          • #6
            Expanded view

            Comment


            • #7
              The GC root shows that you service is being held in memory by the Felix LogService implementation. Looking at the code, Log (if configured with a maxSize > 0) maintains a fixed-size historic buffer. You service is being referenced by an entry in this buffer. Once a sufficient number of calls have been made to the log service this entry will be removed from the historic buffer and your service will be GCed. If you want your service to be available for garbage collection earlier, you can configure the log service with a maxSize of zero to disable the historic buffer.

              Comment


              • #8
                Where do i set this maxSize property ?

                Where can i find the corresponding property file for it ?

                Comment


                • #9
                  According to the documentation, it's set using a system property.

                  Comment

                  Working...
                  X