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