J'ai donné la présentation ce matin à l'atelier RESoLVE, après une présentation de Michael Petullo, dans laquelle il a expliqué comment son équipe a simplifié la construction d'un nouvel OS, Ethos, dans l'objectif d'explorer l'espace de design de l'API d'un OS pour faciliter la construction d'applications sécuritaires par design. Leur démarche est analogue à la mienne au sens ou leur design réutilise autant que possible des outils existants pour implémenter les services majeurs de l'OS pour focuser leur efforts sur le design de l'API, alors que je réutilise autant que possible les éléments existants du langage pour implémenter les fonctionalités que nous ne sommes pas intéressé à instrumenter.

L'atelier compte une dizaine de participants dont 2 organisateurs, le reste étant des présentateurs et une ou deux personnes ne présentant pas. Malheureusement VEE (Virtual Execution Environment) semble avoir attiré tous les autres participants à la conférence de la journée alors notre audience est limitée.

Pour ma présentation, j'ai mis l'emphase sur le contexte d'application du système (i.e. l'instrumentation dynamique pour la sécurité, la compréhension de programmes, le design d'optimizations, etc.) et une vision de haut-niveau de l'architecture du système et j'ai complètement omis l'explication des optimizations réalisées. Cela fut un bon choix car plusieurs personnes dans l'audience viennent du monde de l'OS et ont peu d'expérience avec JavaScript. Les gens ont vraiment apprécié le diagramme d'architecture explicitant l'interaction entre les composants à différentes couches du système et ont confirmé que cette représentation semble "nouvelle". J'ai également eu des questions de base sur le modèle d'exécution des VMs pour JavaScript (Utilisation de Bytecode?, usage de JIT, etc.), sur la définition de métacircularité et sur la façon dont l'évaluation en performance a été réalisée. Cependant, personne n'a critiqué les résultats actuels au sens d'invalider l'utilité du système car il serait trop lent. Alex Garthwaite, maintenant à CloudPhysics après avoir travaillé chez VMWare, m'a demandé si on avait essayé de rouler Photon par dessus lui-même pour déterminer son propre comportement en performance ;-). J'ai partagé l'idée de Paul Khuong de faire une analyse asymptotique de performance sur un nombre arbitrairement grand de MetaVM stackée les unes par dessus les autres et j'ai eu quelques sourires. Après Paul et un gars à ma présentation chez Mozilla c'est la troisième personne qui suggère l'idée!. Je lui ai dit qu'on a fait quelquechose d'équivalent avec le nouveau système de Bruno. J'ai l'impression que d'instrumenter Photon avec lui-même ferait un cas d'utilisation vraiment intéressant et convaincant pour l'article de OOPSLA, spécialement si on obtenait de l'information utile pour comprendre son comportement en performance. En passant, je pense que le sandboxing de Photon lui permet de s'appliquer à lui-même alors que le prototype de Bruno ne pourrait probablement s'instrumenter lui-même, à ce que j'en comprends.

Le plus enthousiaste à la présentation fut Antony Hosking de Purdue University, un des deux organisateurs de l'atelier. Il m'a dit qu'il allait définitivement prendre le temps de lire en détails l'article soumis pour comprendre le détail de l'implémentation et des optimisations réalisées. Son intérêt provient de son effort actuel, pendant sa sabbatique, pour implémenter un framework de création de VM qui résout les problèmes principaux derrière l'implémentation de VMs, soit la gestion mémoire, le scheduling de thread, la génération de code, la gestion de dépendances à l'exécution (et un 5e que je ne me rappelle pas). À terme, l'objectif est de battre CPython (et PyPy!) en performance et de montrer que Java peut être implémenté efficacement. Pour l'instant il ne pense pas implémenter JavaScript étant donné que l'effort industriel placé dans son optimisation rend plus difficile l'obtention de résultats de performance comparablement intéressants. Il ne semblait pas fermé à l'idée de le faire éventuellement mais sa réaction première était négative. Il était particulièrement intéressé à connaître les fonctionnalités dont j'aurais besoin de la part de la VM hôte sous-jacente pour optimiser les opérations de la MetaVM. Je lui ai partagé les efforts de Maxime dans la création d'une nouvelle VM JIT traçante pour JavaScript et l'opportunité qu'on aurait à travailler ensemble (Maxime et moi) pour faire le design des couches de façon à ce qu'elles interagissent de manière positive.

Il était intéressé à ton travail, Maxime, alors je vais vous mettre en contact dans un email séparé.

Après avoir appris que je commençais mon PhD il a confirmé que le problème de recherche que j'ai mentionné, soit "Comment réifier les éléments opaques de la sémantique de JavaScript pour permettre l'instrumentation dynamique à haut-niveau tout en minimisant son coût en performance?" semble prometteur et excitant. On a passé une partie du dîner à discuter de ses efforts actuels (non-reliés à mon projet) dans la formalisation d'un GC concurrent temps réel avec aucune pause pour les mutateurs (de ce que j'en ai compris). L'objectif est d'avoir à la fois une définition de l'algorithme qui se raffine à du C efficace et qui est également tractable pour être traduite à une logique formelle à partie de laquelle des preuves vont pouvoir être faites. La grosse limitation actuelle au niveau des formalismes existants est l'impossibilité d'exprimer la composition parallèle des opérations, reliée au comportement des caches modernes.

Son principal collaborateur actuel est Steve Blackburn, que je suspecte avoir été un des reviewers de mon article de OOPSLA l'an dernier. C'était d'ailleurs l'un des meilleurs reviews en terme de qualité. Il était assis à la même table que moi au dîner mais je n'ai pas eu l'occasion de lui parler encore.

Antony te connaît Marc, mais je n'ai pas trop compris dans quel contexte vous vous êtes connus. Ses explications furent brèves et je n'ai pas tenté de le faire répéter.

Je viens d'entendre que son article le plus cité est celui à propos de Remembered Sets dans un contexte de GC. Benjamin je t'invite à Googler son nom pour voir si ça devrait apparaître dans ta section related work de mémoire de maîtrise.

Ça va être ça pour aujourd'hui, je vous tiens au courant du reste de la conférence plus tard!

Erick