Un très intéressant projet, connu sous le nom de SnowFlake vient d’être présenté par les chercheurs de 2 universités, Cambridge et Princeton, dans le cadre des programmes de recherche de Microsoft, qui permet de doter l’environnement .NET d’une double gestion d’objets, automatique et classique mais aussi désormais manuelle, si le programmeur tient à se charger de cette gestion dans ses applications.

Depuis que l’on programme avec des langages objet, se pose toujours le même problème : que faire des objets une fois qu’ils ont été instanciés en mémoire.

Assurer cette gestion de manière automatique, comme le fait le GC (Garbage Collector) est une solution, mais cela revient à fabriquer un aspirateur à qui on demanderait de nettoyer un espace, sans se préoccuper de ce qu’il y a dedans. Une tâche quasiment impossible, ce que démontrent les premiers GC du monde Java, par exemple, incapables d’assurer leur mission et à l’origine de foisonnements mémoire, qui ont fini par faire « planter » les machines.

Sans parler de la complexité du mécanisme, qui oblige à conserver pour chaque objet, sa classe d’instanciation, l’application dans laquelle il a été créé, les dépendances avec d’autres classes, un fichier sur la chronologie des objets, le langage et la version qui en est à l’origine, etc.

Le faire en manuel est évidemment plus souple et plus flexible, mais dans un monde urbanisé de réutilisation, on ne sait jamais si un objet présent en mémoire ne sera pas utilisé par un autre service et qu’il convient donc de le maintenir « vivant ». Certains langages, tels Java, ne permettent justement pas de « tuer » ces objets, de manière explicite, comme on le fait en C++, par exemple, les concepteurs estimant que l’affaire est trop dangereuse pour en laisser l’initiative aux programmeurs.

Ce que propose Microsoft Research, par l’intermédiaire des 2 universités, est de proposer les 2 solutions : soit un Garbage Collector automatique, comme on le fait aujourd’hui, soit de faire ce travail manuellement, sans compromettre (d’après les auteurs) la sécurité et les performances des applications. Ce qui se traduira par quelques modifications de fond du « run time ».

Toute la difficulté d’un GC (Garbage Collection) automatique est de lui laisser décider de l’opportunité à détruire un objet présent en mémoire. Transférer cette décision chez le développeur, n’est pas forcément la meilleure garantie de fiabilité des applications.

L’avantage du système manuel est qu’avec un grand nombre d’objets, ce qui est le cas pour des applications Big Data et si le développeur est pertinent, il saura éviter une surcharge opérationnelle, impossible à éviter avec le GC automatique. A l’inverse, les machines modernes disposent de grandes capacités mémoire et le risque de foisonnement est moins important qu’il ne l’était dans les années 90/2000 aux débuts de la grande saga .NET et Java.

L’inconvénient de la procédure manuelle est qu’elle beaucoup moins sûre, d’où d’ailleurs la création à l’origine d’un GC automatique et peut entraîner des « crash » applicatifs, difficiles à prévenir. Au fond c’est un peu la même problématique que pour la dépendance des objets : soit on la confie de manière automatique à un serveur d’application, soit on la gère manuellement dans nos programmes.

.NET Core doit être modifié

A priori le système de gestion manuelle des objets mémoire ne concerne que la version Open Source du « run time » : .NET Core 1.0. Dont il faudra modifier la plate-forme d’exécution CoreCLR, ainsi que les bibliothèques de composants standards et API qui exploitent ce mode manuel.

De manière à aboutir à un modèle de programmation homogène et qui ne dépendra plus des langages utilisés, susceptible de gérer l’allocation et la désallocation des objets de manière automatique ou manuelle. Le choix étant laissé au développeur.

Bien entendu, Microsoft se veut rassurant quant à la fiabilité des opérations, mais il conviendra néanmoins, si ce projet aboutit, ce qui n’est pas certain, d’exécuter quelques POCs, histoire de se faire une idée concrète des nouveaux processus. A suivre donc.