Dans les 24 dernières heures, j'ai eu des rencontres avec Luke (JS team), Shu, Étienne, Ariya Hidayat (du parseur JS Esprima) et Jandem/Djvj qui travaillent sur le baseline JIT.
J'ai une plus grande compréhension de l'analyse de types de Mozilla et de leur compilateur(s). Ils veulent se débarasser de JaegerMonkey et le replacer par un JIT très simple qui compile directement leur bytecode, sans même faire d'allocation de registre, et utilise des inline caches (ICs). J'ai eu une bonne explication de comment leur ICs fonctionnent, en gros, c'est simplement une linked liste de petits blocs de code machine qui testent des conditions (genre type des objets). Ils planifient utiliser les ICs pour faire du type feedback.
Ils planifient éventuellement remplacer leur inteprète bytecode par quelque chose d'encore plus simple: un AST walker. Dans les mots de Terrence ici: "interpreter performance doesn't matter at all". Leur interprète ne servira qu'à exécuter le code qui ne roule que quelques fois. IonMonkey sera en mesure de faire des bailouts vers leur JIT baseline (pour l'instant, Ion bail vers l'interprète).
Shu m'as fait un petit exposé sur l'analyse de types. Il y as certains aspects dont je pourrais m'inspirer, mais je ne sait pas si je peux améliorer beaucoup sur leur design. J'ai parlé de mes idées sur le tracing à Shu. Il semblait très sceptique au départ, mais plus intéressé vers la fin. Il me recommande de ne pas référer à mon approche comme un "tracing JIT" puisque ça n'en est pas un dans le sens classique, et de faire une recherche en littérature pour voir si je peux trouver des choses similaires.
Ce que j'ai trouvé de plus proche, c'est le "region-based compilation", venant du monde HPC. L'idée en gros: découper les programmes en unités de compilation autres que les fonctions, et repousser les chemins d'exécution moins chaud en dehors de ces régions. Les articles originaux parlaient de faire ça soit basé sur de l'information de profilage, soit par analyse statique. Ceci a été appliqué à des compilateurs Java, mais pas aux langages dynamiques, à ce que je vois (dans le monde dynamique, la compilation de boucle par trace c'est tout ce que je trouve).
Mon idée est similaire: essayer de faire grandir des extended basic blocks de façon dynamique et paresseuse pour éventuellement couvrir tous les chemins chauds. Faire grandir ces blocs en passant par les appels de fonction quand ça fait du sens, repousser le code mort ou "froid" hors des chemins critiques, dupliquer le code qui pourrait bénéficier de spécialisation. Shu semble croire que ce serait intéressant d'avoir des paramètres avec lesquels on peut jouer pour augmenter la croissance et le versionnement des blocs. Plusieurs métriques pourraient êtres produites pour différents paramètres. Peut-être serait-ce assez intéressant pour un premier article?
(J'ai attaché ma discussion en ligne avec ceux qui travaillent sur le compilateur baseline, si ça vous intéresse)