Info gestion de la Stack

Bonjour,

Je me suis posé la question suivante : "Qui s'occupe de gérer la Stack" ?

Car j'ai lu sur le net que le GC ne s'occupe que de la Heap...

Je suis curieux de savoir comment cela fonctionne donc si vous avez une réponse, c'est avec plaisir que je vous écoute :)

Merci,
S

je dirais que c'est la clr qui s'occupe des 2
le gc n'est là que pour vider la mémoire, après est-ce que le gc ne vide la mémoire que du heap et la clr de la stack ? ...

je souligne que j'ai utilisé le conditionnel ^^

Je crois mais je ne suis pas du tout sûr que le GC ne gère que la heap.

Concernant la stack, les variables sont désalouées dès qu'on sort du bloc dans lequel elles ont été initialisées.

Oui ? Non ? ;)

Il est toujours bon de se poser les questions, mais en l'occurrence, .Net est conçu pour masquer tout ça. Comme le dit un des concepteurs du compilo C# (ici), c'est un détail d'implémentation.

Ceci étant, le GC ne s'occupe que des classes et non pas des structs (enfin il s'en occupe indirectement, puisque qu'une classe ayant un membre struct a la struct elle-même en mémoire, apr définition des structs) ; et après, toute classe est sujette à collectage par le GC, plus ou moins vite selon la façon dont il est conçu (éventuellement avant même la fin du bloc où la classe a été déclarée, ou même jamais si le GC ne collecte jamais rien, ce qu'il a le droit de faire).

Alors comme disent les moines zen : mu ! :)

Citation:

---

Envoyé par Krustig

Concernant la stack, les variables sont désalouées dès qu'on sort du bloc dans lequel elles ont été initialisées.

---

pour une variable de membre oui, mais il y a des variables de classes

Citation:

---

Envoyé par Pol63

pour une variable de membre oui, mais il y a des variables de classes

---

Elles doivent être gérées par la heap

Citation:

---

Envoyé par Krustig

Elles doivent être gérées par la heap

---

Citons encore ce cher Eric Lippert:

Citation:

---

Envoyé par Ce Cher Eric Lippert

But more generally, again we have an explanation that doesn’t actually explain anything. Leaving performance considerations aside, what possible difference does it make to the developer whether the CLR’s jitter happens to allocate memory for a particular local variable by adding some integer to the pointer that we call “the stack pointer” or adding the same integer to the pointer that we call “the top of the GC heap”? As long as the implementation maintains the semantics guaranteed by the specification, it can choose any strategy it likes for generating efficient code.

Heck, there’s no requirement that the operating system that the CLI is implemented on top of provide a per-thread one-meg array called “the stack”. That Windows typically does so, and that this one-meg array is an efficient place to store small amounts of short-lived data is great, but it’s not a requirement that an operating system provide such a structure, or that the jitter use it. The jitter could choose to put every local “on the heap” and live with the performance cost of doing so, as long as the value type semantics were maintained.

---

Mais en résumé, toutes les classes sont allouées sur la heap (même si un compilo peut faire autrement s'il le veut), et sont sujettes à collection quand le GC en a envie (et qu'elles ne sont plus référencées, bien sûr) ; et on peut raisonnablement penser que les structs et références de classes définies au sein d'une méthode sont dans la stack, et désallouées en fin de bloc / de méthode / autre chose, à la discrétion du compilo.

[Edit] message n°2000 ! C'est la fête ! :mrgreen:

Citation:

---

Envoyé par Krustig

Je crois mais je ne suis pas du tout sûr que le GC ne gère que la heap.

---

La stack se gère "toute seule", il n'y a pas besoin du GC pour ça... quand une méthode est appelée, l'adresse de retour est poussée sur la stack, et les variables locales sont allouées dessus. Quand on sort de la méthode, on dépile tout ça, et on réutilise l'espace libéré lors des prochains appels de méthode. Il n'y a pas besoin de faire un "suivi" des blocs de mémoire alloués, puisqu'ils sont tous empilés sur la stack

Citation:

---

Envoyé par Krustig

Concernant la stack, les variables sont désalouées dès qu'on sort du bloc dans lequel elles ont été initialisées.

Oui ? Non ? ;)

---

En gros c'est ça (pour les variables locales)

Mais il faut faire attention à ce qu'on entend par "désallouer" : pour une variable locale de type référence, la référence est allouée sur la pile, mais l'objet lui-même est alloué sur le tas, géré par le GC. Quand tu sors du bloc, la variable est désallouée, mais l'objet se trouve toujours sur le tas, et sera collecté par le GC s'il n'est plus accessible (s'il n'y a plus de référence qui pointe dessus)

c'est plus clair là merci pour ces infos

Je rajoute aussi le post suivant:
http://blogs.msdn.com/b/ericlippert/...lue-types.aspx