As most of the people doing XAML development already know Silverlight 4 shipped at Mix 10 this year. This official release contained a lot of issues (memory leaks included) and it was a reasonable decision for Microsoft to postpone their GDR (general distribution release – the one that comes with Windows Update) version. A few weeks ago, Microsoft finally shipped the GDR. One of the things all developers hoped for was a resolution to the known memory leaks. The GDR did fix a lot of memory leaks, however, it did not address all of them and there are still some with a severe impact.
Memory leaks in Silverlight 4 and their impact
We have identified and reported to Microsoft two major memory leaks in Silverlight 4 GDR:
- Template binding to a custom dependency property in a Popup’s Content.
- Inline DataTemplate, instantiated via DataTemplate.LoadContent() method.
Before answering how we have addressed these issues let’s look at what is the impact of each of them. The first issue’s impact was huge. A lot of our controls were using Popup’s including: RadComboBox, RadMenu, RadRibbonBar, many buttons and pickers. If you have just used any of these controls without even data-binding it is going to leak. Not only the control itself will leak, but the whole page that the control is used into will leak, because it has a strong reference to the control. Regarding the second issue the main control that was affected was RadGridView, because it allows users to customize each column’s appearance via data templates. Fortunately Microsoft have provided early on an “official workaround” to use Static Resources instead of inline data template definition. This will require a change on your side, but after all it is a doable operation.
Microsoft did acknowledge both problems (SL forums) and Tim Heuer said that they do have a fix but he could not commit to when an update (or another GDR) will be available. As customers were experiencing a lot of pain with this (TELERIK forums), and we were affected internally as a number of Telerik products such as TeamPulse heavily utilize Silverlight, we decided to take immediate action regardless of the enormous effort involved.
Fixing Silverlight 4 memory leaks or how to fix the unfixable
Luckily, our team has been successful in fixing both of the above runtime memory leaks in the Telerik code base:
- Fixing the Popup leak was not an easy task. We have developed a number of prototypes including custom attached dependency properties, attaching/detaching the Content of the Popup in code behind and even implementing our own Popup. Finally we have settled on the option with our own Popup, because it was the only one that was not leaking. We have changed all our controls to use this new Popup control in their Templates. We have modified all our themes to reflect this change as well. This means that if you have custom styled control from the above leaking list you will have to change your Templates as well to use the new Popup control. For example our online demos is using highly customized version of our controls and we have to modify its theme as well in order to avoid the leak. The end results is what drive us – memory leak free controls and online demos.
- Fixing the inline data template was easier. We have implemented the code based workaround proposed by Microsoft in our products. This ensures that if you are still using inline data templates the respective control will not leak. We still advice you to use StaticResource when applicable, but don’t worry if you are not. We have you covered.
Preventing future memory leaks
Memory leaks are one of the nastiest problems you can have in an application and we’d like to spare our customers. While we did save the day, the more important question is how do we ensure this does not happen again (or can we even make such a claim?). In order to prevent future memory leaks we have developed our own micro unit tests framework that covers all of the above leaking scenarios. We are going to expand these unit tests covering more and more use cases in the future.
What’s next – our 2010 Q2 Service Pack 2 release
We have always tried to stay close to our customer and address their problems early on. In this ongoing process we have introduced the concept of Latest Internal Build which allows you an early access to our internal continues integration builds containing fixes that you have reported.
We have pushed a new official service pack release which will have all known memory leak fixes packed. We know the high price for fixing a bug and this is the reason we have delayed this servicing release. Rushing to the first working solution and not evaluating other possible approaches that we might have taken is something that we will not do. As you know the only way to go fast is to go right. You can download the latest files under your accounts' Downloads - RadControls for Silverlight section
If any customer experiences further memory leak issues, please share your comment here or at the forum thread that I listed above.