Matériel Assisté Garbage Collection
Je pensais à la façon dont les langages fonctionnels pourraient être plus liés directement à leur matériel et je me demandais sur toutes les implémentations matérielles de garbage collection.
Cela accélérerait considérablement les choses car le matériel lui-même gérerait implicitement toute la collection, plutôt que l'exécution d'un environnement.
Est - ce ce que LISP Machines a fait? Y a-t-il eu d'autres recherches sur cette idée? Est-ce trop spécifique au domaine?
Pensées? Objections? Discuter.
11 réponses
En raison de la Collection générationnelle, je dois dire que le traçage et la copie sont pas d'énormes goulots d'étranglement vers GC.
Ce qui aiderait, ce sont les barrières de lecture assistées par le matériel qui éliminent la nécessité de faire des pauses "stop the world" lors des analyses de pile et du marquage du tas.
Azul Systems a fait ceci: http://www.azulsystems.com/products/compute_appliance.htm Ils ont donné une présentation à JavaOne sur la façon dont leurs modifications matérielles ont permis complètement pauseless GC.
Une autre amélioration serait les barrières d'écriture assistées par le matériel pour garder une trace des ensembles mémorisés.
GCS générationnel, et plus encore pour G1 ou Garbage First, réduisez la quantité de tas qu'ils doivent analyser en scannant uniquement une partition et en conservant une liste d'ensembles mémorisés pour les pointeurs de partition croisée.
Le problème est que cela signifie que chaque fois que le mutateur (mot de fantaisie pour le "programme réel") définit un pointeur, il doit également mettre une entrée dans le approprié rememered ensemble. Donc, vous avez (petit) frais généraux même lorsque vous n'êtes pas GCing. Si vous pouvez réduire cela, vous réduiriez à la fois les temps de pause nécessaires au GCing et les performances globales du programme.
Oui. Regardez les sections de travail connexes de ces 2 documents:
Https://research.microsoft.com/en-us/um/people/simonpj/papers/parallel-gc/index.htm http://www.filpizlo.com/papers/pizlo-ismm2007-stopless.pdf
Ou à celui-ci:
Http://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon12StallFree.pdf
Il y avait un article sur lambda the ultimate décrivant comment vous avez besoin d'un gestionnaire de mémoire virtuelle GC-aware pour avoir un GC vraiment efficace, et le mappage de VM est fait principalement par le matériel de nos jours. Vous êtes ici :)
Une solution évidente était d'avoir des pointeurs de mémoire plus grands que votre RAM disponible, par exemple des pointeurs 34 bits sur une machine 32 bits. Ou utilisez les 8 bits les plus élevés d'une machine 32 bits lorsque vous n'avez que 16 Mo de RAM (2 ^ 24). Les machines Oberon de L'ETH Zurich ont utilisé un tel système avec beaucoup de succès jusqu'à ce que RAM devienne trop bon marché. C'était autour de 1994, donc l'idée est assez ancienne.
Cela vous donne quelques bits où vous pouvez stocker l'état de l'objet (comme " ceci est un nouveau objet " et "je viens de toucher cet objet"). Lors de la GC, préférez les objets avec les "c'est nouveau" et d'éviter "effleuré".
Cela pourrait en fait voir une renaissance parce que personne n'a 2 ^ 64 octets de RAM (=2^67 bits; il y a environ 10^80 ~ 2^240 atomes dans l'univers, donc il pourrait ne pas être possible d'avoir autant de RAM jamais). Cela signifie que vous pouvez utiliser quelques bits dans les machines d'aujourd'hui Si la machine virtuelle peut indiquer au système d'exploitation comment mapper la mémoire.
Vous êtes un étudiant diplômé, semble être un bon sujet pour une bourse de recherche pour moi. Regardez dans la conception FPGA et l'architecture informatique il y a beaucoup de conception de processeur libre disponible sur http://www.opencores.org/
Garbage collection peut être implémentée en tant que tâche d'arrière-plan, elle est déjà destinée à un fonctionnement parallèle.
Pete
Je suis sûr que certains prototypes devraient exister. Mais développer et produire des fonctionnalités spécifiques au matériel est très coûteux. Il a fallu beaucoup de temps pour implémenter MMU ou TLB au niveau matériel, qui sont assez faciles à implémenter.
GC est trop grand pour être efficacement implémenté au niveau matériel.
Les anciens systèmes sparc avaient marqué la mémoire (33 bits) qui était utilisable pour marquer les adresses. Pas équipé aujourd'hui ?
Cela vient de leur patrimoine LISP IIRC.
Un de mes amis a construit un GC générationnel qui a été marqué en volant un peu de primitives. Il a mieux fonctionné.
Donc, oui, cela peut être fait, mais nodody dérange plus le marquage des choses.
Les commentaires de RunT1mes sur le GC générationnel assisté par le matériel valent la peine d'être lus.
Étant donné un tableau de portes suffisamment grand (vertex-III vient à l'esprit) une MMU améliorée qui a soutenu les activités du GC serait possible.
Probablement la donnée la plus pertinente nécessaire ici est, combien de temps (pourcentage de temps CPU) est actuellement consacré à la collecte des ordures? Il peut être un non-problème.
Si nous allons après cela, nous devons considérer que le matériel est en train de tromper avec la mémoire "derrière notre dos". Je suppose que ce serait "un autre fil", dans le langage moderne. Une certaine mémoire pourrait être indisponible si elle était en cours d'examen (peut-être résoluble avec la mémoire à double port), et certainement si le HWGC va se déplacer les choses autour, alors il faudrait verrouiller les autres processus pour ne pas interférer avec eux. Et de le faire d'une manière qui s'intègre dans l'architecture et le langage(s) en cours d'utilisation. Donc, oui, spécifique au domaine.
Regardez ce qui vient d'apparaître... dans un autre poste ... En regardant le journal GC de java.
Je suppose que le plus gros problème est les registres CPU et la pile. Une des choses que vous devez faire pendant GC est de parcourir tous les pointeurs de votre système, ce qui signifie savoir ce que sont ces pointeurs. Si l'un de ces pointeurs est actuellement dans un registre CPU, vous devez également le parcourir. De même si vous avez un pointeur sur la pile. Donc, chaque cadre de pile doit avoir une sorte de carte disant ce qui est un pointeur et ce qui ne l'est pas, et avant de faire une traversée GC, vous devez en obtenir pointeurs dans la mémoire.
Vous rencontrez également des problèmes avec les fermetures et les continuations, car soudainement votre pile cesse d'être une structure LIFO simple.
Le moyen évident est de ne jamais contenir de pointeurs sur la pile du processeur ou dans les registres. Au lieu de cela, vous avez chaque cadre de pile en tant qu'objet pointant vers son prédécesseur. Mais cela tue la performance.
Plusieurs grands esprits au MIT dans les années 80 ont créé la puce SCHEME-79 , qui interprétait directement un dialecte de Scheme, a été conçue avec LISP DSLs, et avait hardware-gc intégré.
Pourquoi "accélérer les choses"? Que devrait faire exactement le matériel? Il doit toujours traverser toutes les références entre les objets, ce qui signifie qu'il doit parcourir un gros morceau de données dans la mémoire principale, ce qui est la principale raison pour laquelle cela prend du temps. Qu'aimeriez-vous gagner par cela? Quelle opération particulière est-ce que vous pensez pourrait être fait plus rapidement avec le support matériel? La plupart du travail dans un garbage collector ne fait que suivre des pointeurs / références, et parfois copier des objets vivants à partir de un tas à l'autre. en quoi est-ce différent des instructions qu'un processeur prend déjà en charge?
Cela dit, Pourquoi pensez - vous que nous avons besoin de une collecte plus rapide des ordures? Moderne GC peut déjà être très rapide et efficace, au point où il s'agit essentiellement d'un problème résolu.