Welcome To Headup – The semantic web – Blog

Abstract: Currently there’s no memory profiler for Silverlight

If you’ve ever programmed in Silverlight, you’ve probably wondered whether your objects in memory were collected by the GC (garbage collector) or not. What if the objects you create stay in the memory for the whole life-time of your application – will you know?
Regular .NET memory profilers don’t work with Silverlight applications and therefore, if we have a memory problem and want to examine it, the only way to approach the problem is to convert our project to a WPF application, which is difficult in the best of cases, and in my scenario was nearly impossible.

When should you use a memory leak detector?

The memory leak detector I wrote is meant for use in those cases where you have the feeling one of the objects you wrote isn’t being collected when it should be by the GC. You can use the memory leak detector to monitor this behavior.

How to use the Silverlight application memory leaks detector?

To use my memory leak detector first add the object you want to monitor by calling the detector’s ‘AddReference’ method in the object’s constructor. Next, at a point where the object should have been already collected by the GC call the ‘Check’ method to verify that it was indeed collected and is no longer in memory.

How is the GC duped into collecting objects despite the fact that the memory leak detector has references to them?

The trick behind this memory leak detector is the usage of the ‘WeakReference’ class. ‘WeakReference’ is a class that provides the ability to reference an existing object in memory, without preventing the object from being collected by the GC. For more information about the ‘WeakReference’ class visit: http://msdn.microsoft.com/en-us/library/system.weakreference.aspx

The Code – an overview

The memory leak detector manages a main list named ‘elementsList’ consisting of ‘ObjectStruct’ elements. Each element contains a ‘WeakReference’ to the monitored object and a few other debug values. You can use the ‘StackTrace()’ in order to identify the monitored object’s creator. This field can help finding the source of the memory leak. The code is divided into three main static public methods. The first two must be called while the last one, ‘SignalDisposed’, is for further debugging.

Main Methods:

• ‘AddReference’ – Adds the object you want to monitor to the memory detector. You can choose whether you want to create the ‘StackTrace’ upon creating the object or not. The object’s constructor is a good place to call this method.

        [Conditional("DEBUG")]

        public static void AddReference(object obj)

        {

            lock (lockObject)

            {

                // avoiding dups - can happen when adding an element
and its base-class to the profiler

                if (elementsList.Any(p => p.Reference.IsAlive &&
p.Reference.Target == obj))

                    return;

                elementsList.Add(new ObjectStruct(new WeakReference(obj),
generationCounter, new StackTrace().ToString()));

                //elementsList.Add(new ObjectStruct(new WeakReference(obj),
generationCounter, null));

            }

        }

-

• ‘Check’ – Use this method to check the memory condition. A good place for implementing this call would be an idle state of your application, where most of the objects already created can be disposed and collected. Each call to the ‘Check’ method increases the static generation counter by 1 providing us a method for following when the monitored objects where instantiated. The ‘Debugger.Break()’ command stops the application at a point allowing you to examine all objects alive in memory.

        [Conditional("DEBUG")]
        public static void Check()
        {
            lock (lockObject)
            {
                long memUsage = GC.GetTotalMemory(true);
                for (int i = 0; i < elementsList.Count; i++)
                    if (!elementsList[i].Reference.IsAlive)
                        elementsList.RemoveAt(i--);
            }
            generationCounter++;
            Debugger.Break();
        }

-

• ‘SignalDisposed’ – My experience hunting for memory leaks with this detector during my work on our semantic web Firefox add-on, led me to the conclusion that there is value in having a Boolean variable indicating whether or not the dispose method of the monitored objects was called. To debug your leak, call this method within the ‘Dispose()’ method to detect scenarios where the ‘Dispose()’ method was called but the object remains in memory.

        public static void SignalDisposed(object obj)
        {
            lock (lockObject)
            {
                var objectsToSignal = elementsList.Where(p =>
p.Reference.IsAlive && p.Reference.Target.Equals(obj));
                if (objectsToSignal.Any() && objectsToSignal.Count() == 1)
                {
                    var objectToSignal = objectsToSignal.First();
                    objectToSignal.DisposedSignaled = true;
                }
            }
        }

-

Notes:

1. All three functions have the ‘Conditional(“DEBUG”)’ attribute that allows using the memory leak detector freely in a project without worrying about performance in the release version of the application. For more information about the ‘Conditional’ attribute visit: http://msdn.microsoft.com/en-us/library/system.diagnostics.conditionalattribute.aspx
2. The class supports multi-threading.

Ideas for future development:

Knowing which object holds a reference to the in memory monitored objects would be great…

This post was written by Amit Kanfer.