J'essaie d'écrire quelques fixations au GC Boehm pour Rust.
Un peu d'histoire : Rust est conçu pour être un langage à fort courant, et un résultat de cette conception est d'avoir la capacité de restreindre statiquement les pointeurs GC au sein des threads dans lesquels ils ont été alloués (c'est-à-dire qu'un pointeur GC alloué dans le thread x ne peut jamais être maintenu en vie (ou même référencé du tout) par un autre fil).
C'est pourquoi je souhaite inciter Boehm à en tirer le meilleur parti possible pour ses performances :
- thread-safe, donc je peux allouer et collecter à partir de plusieurs threads
- arrêter les collections les plus petites possibles (c'est-à-dire juste le thread actuel), les autres threads peuvent continuer à fonctionner car ils ne peuvent pas interférer avec quoi que ce soit de pertinent pour les pointeurs GC en dehors d'eux-mêmes.
- de préférence, entièrement en mode thread-local, sans synchronisation entre les "instances" GC de différents threads.
Le 1 est facile, mais je ne trouve aucune facilité pour les 2 et 3. Les points 1 et 2 sont les plus importants car je veux pouvoir faire tourner des threads en arrière-plan, indépendamment de ce que font les autres threads (même s'ils allouent et récupèrent tous des gigaoctets de mémoire).
(Je fais savoir THREAD_LOCAL_ALLOC & gc_thread_local.h mais cela ne satisfait pas complètement le point 3, cela le rend juste plus efficace, mais il est toujours valable de transférer les pointeurs alloués thread-locally entre les threads, alors que je n'ai pas besoin de cette garantie).
3 votes
Êtes-vous déterminé à utiliser Boehm, ou êtes-vous prêt à considérer d'autres GC conservateurs open-source sur le marché ? Par exemple, vous pourriez être en mesure de pirater le MMgc de Tamarin pour en faire quelque chose qui convienne à vos besoins. (Mon souvenir est que MMgc permet des objets GC per-thread, chacun avec ses propres racines et son propre graphe d'objets).
3 votes
(En guise de suivi sur MMgc : il y a toujours un état global cross-thread dans une classe GCHeap et aussi un pagemap global ; je ne suis pas sûr de savoir jusqu'où vous voulez aller avec votre troisième critère. il y a aussi le problème qu'adobe ne fournira probablement pas beaucoup de support pour ce projet).
2 votes
@pnkfelix Je ne suis engagé dans rien, je ne fais qu'expérimenter des GC "faciles" (et je pourrais aussi bien le faire dans le contexte de Rust, même si des gens comme vous en savent beaucoup plus que moi :) ). Cela semble être faisable, mais je ne suis pas très intéressé par l'écriture d'une interface C à utiliser via FFI (cependant, je vais certainement le garder à l'esprit comme une possibilité à étudier, merci). Quoi qu'il en soit, je suis maintenant en train de bricoler un pur GC Rust ; plus facile d'obtenir toutes les exigences ci-dessus et plus amusant de toute façon : mais beaucoup plus difficile à obtenir d'être aussi rapide, donc je suis toujours intéressé par toute réponse à cette question.
0 votes
Au cas où ce serait nouveau depuis la question, juste pour les adeptes :
-DPARALLEL_MARKgithub.com/ivmai/bdwgc/blob/master/doc/scale.md il y a aussi l'incrémental avec limite de temps (au détriment de la marque parallèle) github.com/ivmai/bdwgc/commit/