Est la pile de déchets collectées en Java?

Question

La mémoire de masse est le garbage collector de Java.

Est la pile de déchets collectés?

Comment est pile de la mémoire récupérée?

Answer 1

La mémoire sur la pile contient méthode-les paramètres et les variables locales (pour être précis: les références pour les objets et les variables de même pour les types primitifs). Qui sera automatiquement supprimé si vous laissez la méthode. Si les variables sont des références (pour les objets) les objets se trouvent sur le tas et traitées par le garbage collector.

Answer 2

La pile n'est pas le garbage collector de Java.

La pile allouée pour un appel de méthode est libéré lorsque le retour de la méthode. Puisque c'est un simple PRINCIPE de la structure, il n'est pas nécessaire pour la collecte des ordures.

Un endroit où la pile de collecte des déchets et interagissent est que les références sur la pile sont GC racines (ce qui signifie qu'ils sont à la base des références à partir de laquelle l'accessibilité est décidé).

Answer 3

La pile peut être nettoyée. Cependant, dans la plupart des JVM implémentations, il est traité comme de la "pile", qui par définition s'oppose à la collecte des ordures.

Ce que nous appelons la pile est l'accumulation de la méthode d'activation de contextes: pour chaque méthode invoquée, c'est la structure conceptuelle qui contient les arguments de la méthode, les variables locales, caché pointeur vers le contexte de l'appel de la méthode, et un emplacement pour enregistrer le pointeur d'instruction. Le contexte d'activation n'est pas accessible en tant que telle à partir de le langage Java lui-même. Un contexte devient inutile lors de la sortie de la méthode (avec un return ou en raison de la levée d'une exception). Il se trouve que lorsqu'une méthode d'Un appel d'une méthode B, il est garanti que lorsqu'Un reprend le contrôle, le contexte de B est devenu inutile. Cela implique que la durée de vie du contexte pour B est un sous-groupe de la durée de vie du contexte de A. par conséquent, l'activation des contextes (pour un sujet) peut être fourni avec un LIFO (Dernier entré, Premier Sorti") de la discipline. En termes plus simples, une pile: un nouveau contexte d'activation est poussé sur le dessus de la pile de contextes, et le contexte du haut sera le premier à être éliminé.

Dans la pratique, l'activation des contextes (également appelé stack frames) sont concaténés, dans l'ordre de la pile, dans un espace dédié. Cette zone est obtenue à partir du système d'exploitation lorsque le thread est démarré, et le système d'exploitation reçoit en retour lorsque le thread se termine. Le haut de la pile est désignée par un pointeur spécifiques, souvent contenue dans un PROCESSEUR inscrire (cela dépend si la JVM est de l'interprétation ou de compilation de code). Le "pointeur de l'appelant, du contexte" est virtuel; l'appelant contexte est nécessairement situé juste en dessous dans l'ordre de la pile. Le GC ne pas intervenir: la zone de la pile est créé et remis en état de façon synchrone, le fil de l'activité elle-même. C'est aussi la façon dont il fonctionne dans de nombreux langages tels que C, qui n'ont pas de GC à tous.

Maintenant, rien n'empêche une JVM de faire autrement, par exemple, l'allocation d'activation des contextes dans le tas et de les avoir recueillis par le GC. Ce n'est pas fait généralement dans des Machines Virtuelles Java depuis l'allocation de pile est plus rapide. Mais certains autres langues nécessité de faire de telles choses, et plus particulièrement de ceux qui jouent avec les continuations tout en continuant d'utiliser un GC (p. ex. Régime et de ses call-with-current-continuation de la fonction), car ces jeux de rompre le PRINCIPE de la règle expliqué ci-dessus.

Answer 4

La pile d'une partie de la mémoire de fonctions comme une "pile". Je sais que ça sonne mal, mais c'est exactement comment il fonctionne. Les données sont ajoutées en haut, sur le dessus les uns des autres (pushed onto the stack) et est automatiquement supprimé à partir du haut (popped off the stack) que votre programme fonctionne. Il n'est pas nettoyée et il n'a pas besoin d'être depuis que la mémoire est automatiquement récupéré une fois que les données ont sauté hors de la pile. Et quand je dis récupérée je ne veux pas dire qu'il obtient de-attribuées - c'est juste que l'emplacement de la pile de la mémoire où les données seront stockées est diminué, car les données sont détachés.

Bien sûr, cela ne veut pas dire que vous n'avez pas besoin de s'inquiéter à propos de la pile. Si vous exécutez une fonction récursive, à plusieurs reprises, il finira par utiliser tout l'espace de pile. Même si vous appelez de nombreuses fonctions, surtout si elles ont de nombreux paramètres et/ou des variables locales.

Mais la ligne de fond est que la mémoire de la pile est utilisée et récupérée comme des fonctions d'entrer et de sortir de la portée - automatiquement. Ainsi, à la fin de votre programme lors de l'exécution de la pile de la mémoire serait libre, puis remis en liberté sur le système d'exploitation.

Answer 5

Si vous vous référez à la mémoire utilisée sur la pile, il n'est pas nettoyée.
La machine virtuelle java utilise explicite bytecode instructions de réserve et de libérer de la mémoire sur la pile, ces instructions sont générés par le compilateur et de gérer la durée de vie primitives, comme int,boolean,double objet de références sur la pile.
Il y a eu des plans pour mettre en œuvre une sorte de queue d'appel d'optimisation, ce qui permettrait de supprimer certaines entrées de la pile une fois qu'il est connu qu'ils ne sont plus utilisés, mais je ne sais pas tout de la jvm qui prend déjà en charge cette.
Donc non il n'y a pas de collecte des ordures de la pile elle-même, seulement le compilateur a généré push et pop instructions pour gérer l'utilisation de la mémoire.

La pile elle-même fait partie d'un thread. La pile est allouée lorsque l'objet thread est créé et les ordures collectées après le thread s'est arrêté et le fil de l'objet n'est plus référencé.