Results 1 to 9 of 9

Thread: Service Object Not GC'ed after undeploying the bundle ?

  1. #1
    Join Date
    Nov 2008
    Location
    London,UK
    Posts
    299

    Default 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. #2
    Join Date
    Oct 2008
    Posts
    493

    Default

    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?
    Andy Wilkinson
    SpringSource

  3. #3
    Join Date
    Nov 2008
    Location
    London,UK
    Posts
    299

    Default

    Hi Andy,

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

  4. #4
    Join Date
    Nov 2008
    Location
    London,UK
    Posts
    299

    Default

    Attaching image for better clarity
    Attached Images Attached Images

  5. #5
    Join Date
    Oct 2008
    Posts
    493

    Default

    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.
    Andy Wilkinson
    SpringSource

  6. #6
    Join Date
    Nov 2008
    Location
    London,UK
    Posts
    299

    Default

    Expanded view
    Attached Images Attached Images

  7. #7
    Join Date
    Oct 2008
    Posts
    493

    Default

    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.
    Andy Wilkinson
    SpringSource

  8. #8
    Join Date
    Nov 2008
    Location
    London,UK
    Posts
    299

    Default

    Where do i set this maxSize property ?

    Where can i find the corresponding property file for it ?

  9. #9
    Join Date
    Oct 2008
    Posts
    493

    Default

    According to the documentation, it's set using a system property.
    Andy Wilkinson
    SpringSource

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •