EcoConception Logicielle

The basic concept of PPAPI is the interface. In C, this is just a collection of function pointers associated with some similar concept. Interfaces are identified by a name, and should remain stable over time.

If additions are necessary in the future, they can be added by creating a "Interface2" with the additions.

This scheme allows the browser and the plugin to implement different capabilities and versions of interfaces over time.

For example, a plugin may want clipboard functionality provided on a Clipboard interface. If the browser supports working with the clipboard, it will return a pointer to the associated function pointers when queried with the interface name. If it doesn't support such operations, it will return NULL and the plugin will have to degrade. Likewise, a plugin may prefer a newer function on a Clipboard2 interface. When run under an older browser, only Clipboardmight be available and the plugin will have to make do.

Both the plugin and the browser expose a void* GetInterface(const char* name) function for the other to call to access functionality.

J’ai récemment fini un projet visant à améliorer la manière dont SpiderMonkey implémente les accès de variable, ainsi j’ai pensé qu’il était temps d’expliquer comment cela fonctionne désormais.

En m’inspirant dubillet de mraleph ainsi que du livre Structure et Interprétation de Programmes, je vais illustrer l’implémentation en utilisant JavaScript comme langage d’implémentation.

Par conséquent, je vais traduire du JavaScript qui utilise des accès de variable complexe en du JavaScript qui n’en utilise pas, un peu comme les premiers compilateurs C++ traduisaient le C++ vers du C.

asm.js code is packaged in specially marked functions (“asm.js modules”) that have the following structure:

Emscripten permet donc de "compiler" par exemple du C/C++ en JavaScript (je ne suis pas sur que l'utilisation du mot "compiler" soit la meilleure, mais vous comprenez l'idée...) et de l'exécuter dans n'importe quel navigateur. Et ça ne se limite pas au exécutions simple. Des projets comme Poppler, Python, Lua, FreeType, eSpeak, Ruby ou Bullet ont aussi été "traduits" en JavaScript.

To summarize: The JavaScript motto “source code is the new binary” and not minding the parsing is a surprising development. Source code minification is also interesting, but a logical consequence of this motto.

La spécification ne conserve qu’un sous-ensemble strict d’EcmaScript, respectant certaines règles. Ce n’est donc pas, à la différence de CoffeeScript ou TypeScript par exemple, un nouveau langage. Le code asm.js est du JavaScript valide qui peut s’exécuter dans tous les navigateurs récents.

Parmi les exemples d’optimisation, asm.js s’assure que les variables ne changent pas de type. Le code inclut des indications sur le type des variables, afin que l’interpréteur n’ait pas à le deviner. Le langage permet également une meilleure utilisation de la mémoire, limitant les ralentissements causés par le garbage collector (le code asm.js utilise des tableaux typés (_typed arrays_) comme pile pour certaines opérations).

Pour indiquer à l’interpréteur JS que le code respecte la spécification et peut être optimisé, il suffit d’ajouter une nouvelle directive "use asm" de syntaxe similaire au "use strict".

Si l’interpréteur ne reconnait pas cette directive, il l’ignorera et interprètera le code normalement. Sinon, il validera que le code respecte bien la norme, et si oui, l’exécutera de façon optimisée.

Pour le meilleur ou pour le pire, javascript est devenu incontournable. Néanmoins, malgré les efforts constants des navigateurs pour améliorer le moteur, il reste extrêmement lent dans certaines situations, et ce, à cause de certaines limitations intrinsèques au langage (comme le boxing, le garbages collector…). Jusqu’à présent, mozilla refusait un peu la réalité.

Lorsque dart est sortie, le seul argument qui me paraissait honnête était le coût de maintenance non négligeable à ajouter à l'existant.

Pour native client, l'argument était plus évident : les binaires ou bytecodes n'étaient pas l'idéal pour le web qui est supposé être ouvert tout en introduisant une nouvelle technologie à maintenir.

Ainsi, la réponse au problème de la part de mozilla a enfin était annoncé sous le nom d' asm.js:

un sous-ensemble de javascript qui permet enfin d'avoir des performances proches de native client (et aussi une protection mémoire similaire du code compilé à la volé dans certain cas…).

Cet exploit est réalisé grâce à quelques astuces syntaxiques qui permettent de donner des indices de typages des variables,des restrictions dans les fonctionnalités les plus coûteuses ainsi que l'utilisation d'un buffer (typeArray) comme heap dans le programme pour éviter tout problème de garbage collector…

J'avoue être très agréablement surpris par cette solution : ce n'est que du javascript, ainsi le fallback est évident à mettre en place car il sera exécuté par tout les navigateurs sans aucune modification. Pour toute personne intéressé par le sujet, je vous propose d'aller voir leblog suivant

Cependant, pour un développeur qui aime le bas niveau et le web, tout n'est pas parfait.

Tout d'abord, il n'existe que deux types classiques le int et le double. D'après moi, cette restriction provient du moteur même de firefox (spidermonkey/ionmonkey) qui est lui-même limité à ces types. Il existe d'autres raisons  plus obscures qui n'ont de sens que si vous pensez à l'implémentation (les type boolish/intish…). De mon point de vue, ce défaut mineur sera probablement corrigé lorsque les implémentations seront plus matures et que les interactions entre la partie codée en asm.js et javascript seront définies plus strictement.

En effet, asm.js permet d’interagir directement avec votre moteur javascript sans passer par des tableaux de bytes, provoquant un besoin de définir les interactions entre le code du js optimisé et le js interne (appelé ffi pour les plus curieux).