À quoi ressemblerait une langue dans laquelle le GC précis pourrait être implémenté en tant que bibliothèque?

Supposons que vous disposiez d'un langage de programmation avec gestion manuelle de la mémoire. De quelles fonctionnalités ce langage a-t-il besoin pour pouvoir implémenter un ramasse-miettes précis en tant que bibliothèque, et non en tant que construction de langage fondamentale?

Par un GC précis, je veux dire un où seuls les pointeurs vers le tas sont traversés pour déterminer quelles variables sont ou ne sont pas actives.

Quelques considérations supplémentaires:

• C et C ++ ont le ramasse-miettes Boehm, mais je ne compte pas car ce n'est pas un GC précis. Le collecteur Boehm suppose que tout élément de la pile qui pourrait être un pointeur, basé uniquement sur les exigences d'alignement de la mémoire, est un pointeur. Par exemple, tout entier kqui (k % 4) == 0ressemble à un niveau binaire comme un pointeur, car les pointeurs doivent être alignés sur 4 octets.
• magpie transforme le code C existant pour utiliser un ramasse-miettes précis. Le code C généré a beaucoup de stubs pour la récupération de place, c'est-à-dire des trucs pour enregistrer des pointeurs de pile dans le tas avec le collecteur. Je ne compte pas cela parce que personne ne pourrait jamais écrire du code de cette façon; c'est plus une cible de compilation pour d'autres langues.

J'imagine qu'une telle langue devrait avoir:

1. Macros ou une certaine forme de métaprogrammation, pour encapsuler tout le code supplémentaire nécessaire pour faire des choses comme enregistrer les racines GC.
2. Un mécanisme réfléchissant qui vous permet d'inspecter des structures ou des syndicats; vous devez déterminer quels membres sont des pointeurs.
3. Un mécanisme réfléchissant qui vous permet d'examiner la disposition du cadre de pile. Cela semble beaucoup plus difficile que 2.

J'espère que ce n'est pas trop vague ou basé sur l'opinion, mais je me pose des questions à ce sujet depuis un moment.

Je crois que cela est possible, ou du moins presque possible, dans une langue comme Rust, mais peut-être pas nécessairement dans le sens que vous pensez.

Rust a en fait une bibliothèque GC , mais je ne peux pas dire à quel point elle est précise. Mais l'idée est qu'il existe un type spécifique Gc<T>pour les pointeurs récupérés sur les valeurs de type T. Donc, la métaprogrammation dont vous parlez ne se produit pas

Ce qui permet que cela soit précis, c'est le système de propriété de Rust: en raison de la frappe linéaire affine, chaque emplacement en mémoire a au plus un pointeur vers lui, à moins qu'il ne soit déclaré en utilisant un unsafebloc (qui est utilisé pour implémenter des choses comme le garbage collector) . Donc, si vous avez un pointeur qui n'est pas encapsulé dans un Gctype, il est désalloué dès qu'il sort de la portée. Il n'est donc pas possible de considérer quelque chose comme un pointeur qui ne l'est pas: soit il est encapsulé dans le Gctype, soit il appartient à un seul utilisateur et est automatiquement désalloué.

Chaque type a une dropméthode implicite qui est appelée quand elle sort du domaine, qui désalloue les choses vers lesquelles elle pointe. Cette dropméthode est consciente de ce qui est et n'est pas un pointeur, ce qui contribue également à la précision.

Le langage est fortement typé statiquement, et à moins que vous ne soyez spécifiquement dans un unsafebloc, vous ne pouvez pas convertir les choses en d'autres types, il est donc possible de connaître statiquement le type d'un bloc de mémoire donné.

Ce n'est pas un transformateur intégré qui vous permet de traiter le code non-GC comme des ordures collectées. Le programmeur spécifie spécifiquement quelles valeurs sont collectées. Mais étant donné cela, je pense qu'il a le potentiel de répondre à vos critères.

Je pense qu'il est possible d'implémenter un garbage collector en C ++ sans changer le langage lui-même. Mais pour utiliser le garbage collector, il faut empêcher le programmeur d'utiliser des constructions de langage arbitraires. En particulier, toutes les demandes d'allocation de mémoire doivent être effectuées via les API d'allocation fournies par le garbage collector, et tous les accès doivent être effectués via des références gérées par le garbage collector.