Existe-t-il un besoin de récupération de place dans un langage basé sur la pile?

16

Quel est le besoin de garbage collection (GC) dans un langage basé sur la pile? Dans une langue comme Forth ou RPL (sur les calculatrices HP ), y a-t-il un besoin de collecte des ordures?

Je pense, puisque la sortie est extraite de la pile, qu'il n'y aurait aucun besoin. Suis-je en train de manquer quelque chose?

garbage-collection stack-oriented

— Todd Moses
source

14

Le GC est normalement appliqué à la mémoire allouée sur le tas. Je ne connais pas Forth ou RPL, mais s'il n'y a pas de tas et que tout est stocké à la place sur une pile globale, alors il n'y a rien à faire pour GC.

— Mike Baranczak
source

2

Le modèle typique d'utilisation de la mémoire des programmes Forth que j'ai lus au début était qu'ils ressemblaient à des programmes d'assemblage, en ce sens qu'ils utilisaient des adresses de données globales statiques préarrangées. Cela fonctionne car Forth a la capacité de transférer des données entre la pile et des adresses spécifiques. De plus, il a la capacité de calculer des adresses. Ainsi, il serait possible de créer une bibliothèque d'allocateurs basée sur un concept de tas et la bibliothèque d'allocateurs aurait besoin d'un moyen de gérer la taille finie du tas. Si un utilisateur de Forth s'engageait dans cette voie, il pourrait imaginer vouloir et implémenter GC.

— Space Man à Cardiff le

13

Oui tu as raison. Mais le caractère basé sur la pile n'est qu'une partie de toute l'histoire. Par exemple, l'interpréteur de bytecode Java est également basé sur la pile (le code compilé fonctionne - pour des raisons d'efficacité - différemment). Cela nous dit que n'importe quel langage peut être transformé en langage de pile.

Ce qui compte, ce sont les objets en dehors de la pile, ceux qui peuvent survivre à l'exécution actuelle de la méthode. Tant que la langue n'a rien à voir avec mallocou new, il n'y a pas de tels objets et vous n'avez besoin deleteni de GC ni de GC.

Un langage dépourvu d'allocation de mémoire dynamique est assez limité dans son utilité.

— maaartinus
source

Je ne suis pas sûr d'être d'accord avec la dernière ligne, le bytecode java n'est-il pas utile?

— jk.

@jk., le bytecode java a l'allocation dynamique de mémoire.

— Peter Taylor,

1

En fait, il existe plusieurs langages à usage général basés sur la pile. Jetez un œil à factorcode.org

— Yam Marcovic

1

En fait, le facteur est la collecte des ordures

— Andrea

1

Le nettoyage de la mémoire est requis si le langage doit prendre en charge les structures de données dynamiques de manière inhérente. Ce qui est presque une nécessité si vous voulez faire quoi que ce soit au-delà du niveau de C. Sans cela, vous êtes coincé avec uniquement des structures de données de taille fixe et la gestion de la mémoire vous-même. C'est ce que Forth d'origine fait bien sûr, mais ce n'est probablement pas quelque chose que vous voudriez faire aujourd'hui, sauf si vous ne faites que du codage de systèmes de bas niveau.

— trans
source

1

La récupération de place n'est pas nécessaire si la langue utilise l'allocation statique au lieu de l'allocation de pile. Par exemple, Fortran 77 avec l' option -s (stockage statique) alloue toute la mémoire au démarrage du programme, donc aucune allocation de mémoire ne se produit au moment de l'exécution pour être libérée. Bien que cela demande un peu de discipline, il est possible d'écrire des programmes, en particulier des simulations pour utiliser l'allocation de mémoire statique. L'allocation statique supprime toutes les fuites de mémoire et conduit à des performances de cache formidables car le compilateur peut utiliser une analyse statique pour déterminer ce qu'il faut charger dans le cache.

— Michael Shopsin
source