Discussion :

[splinternabs]

salut à tous.

je m'intéresse depuis quelques jours à ce sujet qu'est la mémoire managée, le garbage collector, fuites de mémoire etc.

en parrallèle on a aussi différents segments de données, qui sont d'après ce que j'ai pu lire sur des sujet concernant le C++ :

• la pile
• le tas
• le "free store"
• les données constantes
• les données globales ou statiques

La mémoire managée par le CLR va-t-elle inclure l'ensemble de ces segments ? j'ai cru comprendre que le GC n'avait pas besoin de toucher à la pile mais au segments dynamiques (qui sont le tas et le "free store"). les deux derniers segments cités sont-ils impactés par le GC ?
Aussi, en C++ on parle de tas lorsqu'il s'agit de faire un "malloc" et "free", ou de free store quand il s'agit d'un "new" et "delete" (respectivement pour l'allocation/désallocation mémoire, et instanciation/destruction d'objets).
qu'en est il en .Net ? est ce qu'il y a cette distinction entre ces 2 segments ?
si oui, sont ils gérés tous deux par le GC ? sont ils gérés de manière identique ?

Merci de vos réponses.

[Immobilis]

Salut

qu'en est il en .Net ? est ce qu'il y a cette distinction entre ces 2 segments ?
si oui, sont ils gérés tous deux par le GC ? sont ils gérés de manière identique ?

Amusant Ce sont des questions qui ne peuvent venir que d'une personne qui programme avec des langage du type C.

En .NET les occasions de se poser ce genre de questions sont très rares. Je ne me les suis jamais posées depuis que je fais du développement et je n'ai jamais eu de problèmes de fuites Le GC se charge de tout. Mettre en application les bonnes pratiques de développement (quelque soit le langage objet) suffit.

A+

[Graffito]

Le GC se charge de tout.

C'est vrai à 99.9%. Mais quand on tombe sur un OutOfMemory alors qu'il n'y a pas de fuite et qu'il reste encore plein de mémoire ...

[Immobilis]

OutOfMemory

Jamais eu le cas sur un projet .NET.

[ElTotor]

Bonjour,

Jamais eu le cas sur un projet .NET.

J'ai déjà eu le cas, et voici en gros le cas qui menait à cela. J'avais des icônes dans un fichier de ressources. Je les utilisais pour les afficher dans un TreeView.

Le TreeView était vivant et se mettant à jour durant la vie de l'application. Et parfois il était recréé entièrement.

Au bout d'un certain temps, le programme levait un OutOfMemory.

Le problème : les icônes implémentent l'interface IDisposable, et il faut donc veiller à bien les disposer lorsqu'on n'en a plus besoin. Et lorsque qu'on accède à une icône contenu dans un fichier de ressources, chaque accès créé une nouvelle instance de l'icône (ce que je ne savais pas à l'époque ^^).

L'empreinte mémoire du programme tournait autour de 200Mo (tout à fait normal, et je suis même monté plus haut sous forte charge, genre 500Mo sans problème) et pourtant j'avais ce OutOfMemory. Alors certes je ne "disposais" pas les icônes comme il le fallait, mais le GC est censé gérer la mémoire dans tous les cas (l'interface IDisposable étant normalement pour permettre la libération des ressources autre que la mémoire).

Quoiqu'il arrive donc, la mémoire est libérée lors de la destruction de l'objet par le GC même si celui-ci n'a pas été "disposé".

Et pourtant, dans mon exemple ci-dessus, sans fuite de mémoire, j'obtenais un OutOfMemory (mais sans doute provoqué par la fuite de ressources ^^)

[antoine.debyser]

Bonjour,

En .NET il y a aussi un tas et une pile. Les objets de type référence sont mis dans le tas, et les objets de type valeur sont mis dans la pile du thread.

Maintenant le .NET est aussi capable d'utiliser des ressources non-managé, il y a donc aussi un tas non-managé.

En ce qui concerne le GC, meme s'il n'est pas sencé traiter ce qui se passe dans la pile, il connait quand meme les objets qui sont dedans.
Pour le reste, le GC utilise un systeme de génération. En fonction de leur taille, de leur age, de leur activité, le GC déplace les objets d'une génération à une autre.

En fait, les génération ne sont que des zones mémoire pour stocker les objets.

Pour revenir sur le sujet des fuites mémoire, comme le GC connait tous les objets et qu'il compte les références à un objet. En théorie il n'y a pas de fuite mémoire, cette théorie n'est valable que dans un programme totalement managé.
Dès que le programme fait appele a des ressources non-managé, il va falloir gerer la libération de ces ressources, c'est à ça que sert l'implémentation de IDisposable (comme indiqué par ElTotor).
Il y a un deuxieme cas, ou on peut obtenir des fuites, celui des références circulaire. Cas qu'on produit assez facilement avec des deleguate/event.

[MABROUKI]

bonjour splinternabs

Le GC gere uniquement le tas manage "HeapManaged" et tout a ete resume par antoine.debyser..
La seule exception ou le programmeur peut intervenir sur le fonctionnement du "tas manage" qu'il faut peut etre signaler au passage c'est :
- "piner" un pointeur C# (code unsafe avec fixed) pour empecher le GC de deplacer la memoire pointe lors du compactage du tas memoire...
- un intpr GCHandle pointant vers une zone memoire non manage pour empecher le GC de le "garbager" lors de son passage imprevisible...

bon code............