Distance from GC root: No GC roots

steven

in my profiling results I get a bunch of objects for which

• GC root object = No
• Distance from GC root = No GC roots

These objects are not being garbage collected, and I have no idea why. What can be the cause of such a situation?

Jessica R

Hi there,

I believe you have a support ticket opened for this issue with my colleague, Alex. Please continue bearing with us as our developers look into this!

haraldsteinlechner

I have the same problem. No matter how often i call GC or take a snapshot i still have those objects. Unfortunately, this is exactly the object which i am debugging. On thing to note here is that i make heavy use of conditionalweaktables and weakreferences.
Which brings me to a follow up question: is it possible to prune away things which are only alive (and have strong references) because of weak references or conditional weak tables?

haraldsteinlechner

I have the same problem. No matter how often i call GC or take a snapshot i still have those objects. Unfortunately, this is exactly the object which i am debugging. On thing to note here is that i make heavy use of conditionalweaktables and weakreferences.
Which brings me to a follow up question: is it possible to prune away things which are only alive (and have strong references) because of weak references or conditional weak tables?

Jessica R

Hi haraldsteinlechner,

I've checked on the support ticket that steven had open and it looks like the last response from my colleague Alex had helped with the memory issues he was seeing. I just wanted to copy it over to you in case it may (hopefully) apply to your situation as well!

---

The objects that we don’t find a path to, are all dependent handles which are typically objects that are in a conditional weak table. For such a table, if the key is referenced, the value field is strongly rooted. ANTS is currently not tracking these references – so we don’t draw a link between key and value for items in such a table.

// A dependent handle is conceputally a tuple containing two object reference
//
// * A Primary object (think key)
// * A Secondary Object (think value)
//
// The reference to both the primary object is (long) weak (will not keep the object alive). However the
// reference to the secondary object is (long) weak if the primary object is dead, and strong if the primary
// object is alive. (Hence it is a 'Dependent' handle since the strength of the secondary reference depends
// on the primary).

From the point of view of your example, all of the items without a GC root seem to be held in this way. That means in turn that there is a strong referenced object that is a key in such a table, so concentrating on the objects that do have roots should still allow you to investigate your issue.

You should definitely look at having less finalization happening, by disposing things (instead of letting the finalizer do this) and making sure that when things are disposed they are unmarked for finalisation. For example your Dispose method on BindingMethod could call SuppressFinalize so that it is removed from the finalizer queue.