Directions possibles pour le BBV

[feeley]

Directions possibles pour le BBV :

• Heuristique de merge non-locale. C’est l’idée d’accumuler des informations auxiliaires pour guider les merge (comme compter les tests faits sur chaque composante du contexte dans le passé, ou regarder l’impact futur d’un merge tel que l’élimination de contextes à cause du GC).
• Heuristique de merge optimisée par algo génétique. Ça pourrait s’appliquer à n’importe quelle heuristique. Donc je vois ça comme un outil essentiel pour trouver des bonnes heuristiques de merge.
• Étude de l’impact de la complexité de l’heuristique. Avec l’algo génétique d’optimisation on pourrait déterminer si les heuristiques non-locales donnent des merge de bien meilleure qualité que les heuristiques plus simples (comme choisir une paire de contextes purement sur la base des types dans ces contextes, comme une “distance”).
• Étendre les contextes de versionnement avec des types plus complexes, par exemple des structures ou classes définies dans le code compilé.
• Faire le versionnement du point de retour des fonctions. Par exemple, avoir plus d’un point de retour par site d’appel de fonction basé sur le type de la valeur de retour (un point de retour pour un résultat fixnum, un autre pour un résultat flonum, etc). On pourrait aussi propager des contextes qui nous donnent des propriétés des paramètres passés à la fonction appelée, par exemple si on a (define (f a b) (if (< a b) …)) et on fait l’appel (+ (f x 0) x) alors au point de retour de (f x 0) on pourrait connaître le type et signe de x car la fonction f contient le test (fixnum? a), et donc (fixnum? x), pour implémenter le (< a b). On pourrait appeler ça du “versionnement de la continuation”. Présentement les retours de fonction sont une barrière pour le versionnement.
• Versionner sur des propriétés globales du programme. Ceci serait utile pour Python pour traiter les modifications possibles des builtin (len, range, etc). Mais même en Scheme ça pourrait être utile pour avoir une version du code où la variable globale debug? est #t et une autre version où debug? est #f. Très probablement c’est lié au versionnement de continuation. (Exemple: variables globales de almabench)
• Faire de l’inlining partiel avec le BBV. Probablement aussi lié au versionnement de continuation.
• Approfondir le traitement des “vector length” et identité d’objet. En Gambit c’est un hack peu satisfaisant car pour éviter de boucler à l’infini il y a une limite arbitraire après laquelle l’algo de BBV ne “track” plus l’identité de l’objet (et donc ne peut plus optimiser les tests de borne).
• Améliorer le traitement des set! et des mutations aux box, vector, etc. Les contextes du BBV pourrait "tracker" l'état d'un objet mutable (box, vector, pair, etc) si on sait que l'objet n'a pas "échappé" au code.
• Retirer le test de borne sur binarysearch (étendre le système d'algèbre sur les longueur des vecteurs)
• Retirer le boxing/unboxing
• Versionnement selon l'échappement des valeurs.
• "BBV" sur le Call-Graph?