Discussion :

[François DORIN]

Bonjour à toutes et à tous,

Je vous propose une nouvelle série de tutoriels pour approfondir nos connaissances de l'environnement .Net. Ce premier opus est consacré à une rapide présentation et historique de cet écosystème.

Le prochain sera beaucoup plus technique et nous plongera au coeur d'un composant essentiel : le ramasse-miette !

Bonne lecture.



Retrouvez les meilleurs cours et tutoriels pour apprendre le .Net

[star]

Pourrait-on avoir un déroulé des 10 prochains chapitres de la série de tutoriels ?
Merci
.

[François DORIN]

Pour les 10 prochains, ça va être dur. Je ne vois pas aussi loin !

Les sujets que je compte aborder :

• le fonctionnement du ramasse-miette (implémentation du framework .Net) ;
• l'anatomie d'un assembly ;
• le CLS (Common Language Specification) qui permet une interopérabilité entre les différents langages ;
• l'interopérabilité avec du code natif (non managé) ;
• une introduction au CIL (quelques exemples d'instructions, comment voir le code généré, comment généré du code dynamiquement)

La liste n'est pas exhaustive, n'est pas ordonnée et est très certainement amenée à évoluer (en fonction de mes envies, des retours que j'aurais, etc...). Mais pour l'instant, c'est ce que j'envisage.

[François DORIN]

Bonjour à toutes et à tous,

Suite de la série de tutoriels pour approfondir nos connaissances de l'environnement .Net, où cette fois-ci nous nous plongeons dans les entrailles du fonctionnement du ramasse-miettes de la plateforme .Net.

Bonne lecture.

Retrouvez les meilleurs cours et tutoriels pour apprendre le .Net

[Pol63]

Très bon article.

Cependant une phrase me fait me poser quelques questions :

Pour cela, après la phase de marquage, le ramasse-miettes ausculte une de ses structures internes appelée « Finalization list ». Cette liste contient une référence pour chaque objet disposant d'un destructeur.

Je pensais que tous les objets étaient finalisables par défaut, d'une part parce que la classe object a un finaliseur, et en vb.net le destructeur s'écrit d'ailleurs par un Protected Overrides Sub Finalize.
via reflector sur la classe System.Object :

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
[ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success), NonVersionable, __DynamicallyInvokable]
protected virtual void Finalize()
{
}

D'autre part parce qu'à l'époque où je décompilais le Framework en 2008 j'étais tombé sur des classes qui appelait suppressfinalize(this) dans le constructeur.
Après recherche aujourd'hui je ne trouve que des classes implémentant IDisposable utilisant cette optimisation.

De plus en cas d'héritage une classe peut avoir une classe ayant un finaliseur et une classe enfant qui ne l'a pas, donc le GC ne pourrait pas se baser sur le fait qu'il y a un finaliseur sur le dernier niveau d'héritage, et trouverais celui de Object.
Ou alors il est codé spécifiquement pour ignorer celui d'Object ...

Mais en effet d'un autre côté ca ne serait pas logique d'être obligé de mettre des suppressfinalize dans tous les contructeurs de classes managées simples.
Si tu as des éclaircissements là dessus je suis preneur ^^

Merci.

[François DORIN]

Très bon article.

Merci

Je pensais que tous les objets étaient finalisables par défaut, d'une part parce que la classe object a un finaliseur, et en vb.net le destructeur s'écrit d'ailleurs par un Protected Overrides Sub Finalize.
via reflector sur la classe System.Object :

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
[ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success), NonVersionable, __DynamicallyInvokable]
protected virtual void Finalize()
{
}

En théorie, tu as raison. Tous les objets disposent d'une méthode Finalize dans la mesure où elle est définie au niveau de la classe Object. Mais cette classe en générale, et cette méthode en particulier, sont gérés de manière particulière. Ainsi, tant que cette méthode n'est pas redéfinie par une classe, les objets de cette classe ne sont pas marqués comme étant "finalisable". On peut retrouver cette information directement au sein de la MSDN :

The Object class provides no implementation for the Finalize method, and the garbage collector does not mark types derived from Object for finalization unless they override the Finalize method.

que l'on pourrait traduire

La classe Object ne fournit pas d'implémentation pour la méthode Finalize, et le ramasse-miettes ne marque pas les types dérivés de la classe Object pour finalisation sauf s'ils redéfinissent la méthode Finalize.

Petit point vocabulaire, que j'aurais dû préciser dans l'article (et je pense le modifier). Dans l'article je parle de destructeur, et là tu mentionnes la méthode Finalize. Il s'agit bien de la même chose. Quand j'ai écris l'article, j'ai été influencé par mon langage de prédilection : le C#.

En effet, en C#, il n'est pas possible de redéfinir la méthode Finalize, ni même de l'appeler. La seule possibilité pour le faire est de définir un destructeur au sein d'une classe, car lorsque le ramasse-miettes appelle le destructeur d'une classe, il appelle en réalité la méthode Finalize.

En VB.Net, l'approche est différente. Il n'y a pas de notion de destructeur, et la seule manière de procéder est donc de redéfinir cette méthode.

Les deux approches, bien qu'équivalentes dans leur finalité, sont légèrement différentes dans leur mise en oeuvre :

• le C# a une vision objet : lorsqu'on instancie une classe, toute la hiérarchie des constructeurs est appelée, de la classe de base (Object) à la classe finale. Il en est de même pour le destructeur, mais dans le sens inverse : de la classe finale, à la classe de base. C'est le comportement que l'on retrouve dans des langages sans ramasse-miettes comme le C++ ;
• le VB.Net a une vision polymorphique. On redéfinie une méthode, et charge au développeur d'appeler ou non la méthode Finalize de la classe parente.

En règle général, lorsqu'on redéfinie une méthode, il faut effectivement se poser la question de savoir si on doit appeler la méthode de la classe mère ou non. Il n'y a pas de réponse toute faite dans la mesure où cela dépend de la situation. Par contre, ici, on ne devrait pas avoir le choix. Une classe redéfinissant la méthode Finalize devrait toujours appeler la méthode de la classe mère. En effet, même avec une connaissance profonde de la manière dont est implémentée une classe, une classe fille ne peut pas accéder à tous les champs de la classe mère : ceux marqués comme private.

Il est donc de la responsabilité d'une classe de libérer correctement toutes les ressources qu'elle possède, c'est à dire :

• les champs privés ;
• les champs non privés, mais introduit par la classe. Par exemple, un attribut protégé hérité de la classe mère ne doit pas être géré dans la classe fille. Mais un attribut protégé introduit dans la classe fille doit être géré par cette même classe fille.

Je préfère l'approche du C#, car sur ce point précis, elle ne laisse pas le choix au programmeur pour un détail d'implémentation où il ne devrait de toutes les façons, pas avoir le choix.