MSIL Memory Leaks

Question

Nous utilisons une classe RuntimeDataBuilder personnalisée qui construit dynamiquement un type de mémoire .NET en utilisant Reflection.Emit pour créer des getters/setters de propriété simples pour les informations que nous recevons d'un DataService WCF générique. Le service expose une structure "DataSet like" constituée de 1..m DataTableDefinitions contenant chacune 1..m DataTableColumnDefinitions. Lorsque l'information est reçue côté client, nous générons le type avec ses setters/getters de propriété pour améliorer les performances et faciliter la liaison sur notre client Silverlight. Tout cela fonctionne bien.

Ma question est liée à la fuite de mémoire possible associée à la régénération du type. De temps en temps, l'utilisateur peut modifier les paramètres de la requête, ce qui peut entraîner plus ou moins d'informations sur le réseau. Il invalide donc le type précédent que nous avons créé et je veux m'assurer que nous sommes capables de libérer la mémoire utilisée par cette définition de type précédente. De this article on MSDN Je comprends que si vous utilisez la génération de code léger (LCG) le code est alloué sur le tas géré qui sera récupéré par le GC quand il n'y a rien qui contient une référence à celui-ci. Mais LCG ne semble s'appliquer qu'aux méthodes dynamiques. Mon souci est pour le Type avec tous ses getters/setters de propriété qui n'est plus maintenant requis. Si cela est alloué sur le tas non géré, notre seul espoir de récupérer la mémoire semble être de s'assurer que le type est chargé dans un AppDomain temporaire que nous pouvons décharger quand il n'est plus nécessaire. Est-ce que quelqu'un peut confirmer ou mettre en évidence une autre façon de récupérer la mémoire?

Thx

Answer 1

Vous avez raison de penser que les types dynamiques resteront dans la mémoire une fois qu'ils ont été chargés dans un AppDomain. Et comme vous le dites, la seule façon de pouvoir les décharger d'un Processus est de les héberger dans un AppDomain séparé que vous pouvez ensuite décharger dans son intégralité. Mais vous devez être prudent même là: assurez-vous que les références au Type ne fuient pas dans votre AppDomain principal, sinon elles le garderont en mémoire.

Il existe deux liens de l'aube du CLR que vous pourriez trouver utiles: Unloading an Assembly et Why isn't there an Assembly.Unload method?.

Avez-vous regardé le DLR? Il est peut-être que quelque chose comme ExpandoObject peut vous aider, même si elle ressemble à ce qui est actuellement pris en charge pour ne pas la liaison de données dans Silverlight 4 (in Silverlight 5 peut-être?)

Answer 2

.NET 4.0 introduit concept de collectible assemblies, qui sont admissibles à la collecte des ordures . L'échantillon d'utilisation peut être trouvé here.