Discussion :

[Krustig]

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

[Pol63]

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 ^^

[Krustig]

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 ?

[Guulh]

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 !

[Pol63]

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

[Krustig]

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

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

[Guulh]

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

Citons encore 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 !