Microsoft .NET - Définition
La liste des auteurs de cet article est disponible ici.
Architecture
CLI, CIL et CLR
Le framework .Net repose sur la Common Langage Infrastructure (ou CLI). Son but est de fournir un langage indépendant de la plate-forme, aussi bien pour le développement que pour l'exécution. Elle inclut des fonctions pour gérer les erreurs, le ramasse-miettes, la sécurité et l'interopérabilité avec les objets COM. L'implémentation de la CLI par Microsoft est appelée Common Language Runtime (ou CLR).
Voir aussi : Dynamic Language Runtime et Machine virtuelle applicative.
CLR et Sécurité
La sécurité est gérée par le CAS (Code Access Security). CAS est basé sur un système de preuves associées à une assembly particulière. La « preuve » est l'origine de l’assembly (Installation en local, téléchargement à partir d'Internet ou d'un Intranet, …). CAS utilise cette preuve pour déterminer les permissions données au code. Un code peut demander une autorisation pour le code qu'il appelle. La demande d'autorisation sait quand le CLR parcourt la pile d'appel : chaque assembly de chaque méthode dans la pile est vérifiée. Si au moins une de ces assembly n'est pas autorisée à avoir la permission demandée une exception est levée.
Quand une assembly est chargée, le CLR effectue divers tests dont la validation et la vérification. Pendant la validation, le CLR vérifie que l’assembly contient un code et des métadonnées valides. Après, il vérifie que les tables internes sont correctes. La vérification vérifie que le code ne fait rien de dangeureux. Le code non-sûr sera exécuté uniquement si l’assembly a la permission ‘skip verification’.
Le .NET Framework utilise des appdomains (domaine d'application) comme mécanisme pour isoler le code d'un processus. Un appdomain peut être créé et du code chargé ou déchargé d'un appdomain indépendamment des autres appdomain. Les appdomains peuvent aussi être configurés indépendamment avec différents privilèges de sécurité. Ceci peut aider à améliorer la sécurité d'une application en séparant le code potentiellement dangeureux du reste. Cependant, le développeur doit séparer l'application en plusieurs sous-domaines, ce qui n'est pas à la charge du CLR.
CLR et Gestion de la mémoire
Le CLR prend en charge la gestion de la mémoire (allocation et libération). L'allocation de la mémoire pour les instances des types .NET (objets) est effectuée de façon continue à partir du tas. Aussi longtemps qu'il existe une référence vers un objet (directe ou indirecte via un graphe), l'objet est considéré comme étant utilisé par le CLR. Dès qu'il n'y a plus de référence sur un objet (ie, il ne peut plus être ni atteint ni utilisé), le ramasse-miettes (en anglais : Garbage Collector), qui s'exécute périodiquement sur un processus léger différent de celui de l'application, passe libérer l'objet de la mémoire.
Le ramasse-miettes du .NET est non-déterministe : il s'exécute seulement après qu'une certaine quantité de mémoire a été allouée ou s'il y a un défaut de mémoire. Il n'y a pas moyen de déterminer quand les conditions de déclenchement du ramasse-miettes sont satisfaites. Chaque application .NET possède un ensemble d'éléments racines qui sont des pointeurs maintenus par le CLR et qui pointent sur les objets du tas gérés. Ceci inclut des références aux objets statiques, à ceux définis comme variables locales, aux paramètres définis dans la portée courante du code et enfin aux registres processeurs. Quand le ramasse-miettes s'exécute, il suspend l'application et, pour chaque objet référencé dans la racine, il énumère récursivement, grâce aux métadonnées .NET et à la réflexion, tous les objets qu'il peut atteindre et les marque. Il énumère ensuite tous les objets sur le tas (qui étaient initialement alloués de façon continue) en utilisant la réflexion ; tous les objets qui n'ont pas été marqués sont alors considérés comme des déchets. C'est la phase de marquage. Cependant, ce procédé laisse des morceaux de mémoire libre entre les objets encore référencés ; ces objets sont ensuite compactés en utilisant memcpy pour rendre l'espace mémoire utilisé à nouveau continu. Les adresses des pointeurs sont mises à jour en conséquence. Après ces opérations, l'application reprend son exécution.
En réalité, le ramasse-miettes est basé sur un système de génération. Chaque objet se voit affecté à une génération ; les objets nouvellement crées appartiennent à la génération 0. Les objets qui restent après la première passe du ramasse-miettes se voient promus à la génération 1 et les objets qui restent après une deuxième passe sont promus à la génération 2 (niveau maximum). Les objets ayant un niveau de génération élevé sont moins souvent analysés par le ramasse-miettes que les objets ayant un faible niveau de génération. Cet algorithme espère améliorer l'efficacité du ramasse-miettes, car les vieux objets ont tendance à avoir une durée de vie plus longue que les nouveaux objets.
