Compte-Rendu #4 - Dlteam-list

7 Fév 2013


      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)