Mozilla montre la puissance de asm.js en exécutant l'ensemble de la VM Lua dans une machine virtuelle JavaScript, avec la possibilité d'appeler du code JS.
lua.vm.js est un projet initié par Alon Zakai, un chercheur pour Mozilla travaillant sur Emscripten et asm.js, projets destinés à montrer la possibilité d'exécuter une machine virtuelle complète, y compris le garbage collector, ici la VM Lua, dans une machine virtuelle JavaScript . La VM Lua est écrite en ANSI C pur, devenu un bon candidat pour la compilation "out of the box" en asm.js avec Emscripten, "avec seulement quelques modifications mineures de Makefile", selon Zakai.
Il y a même un éditeur REPL pour tester le code Lua dans le navigateur. Outre la gestion du pur code Lua, l'éditeur REPL montre que l'on peut appeler du code JavaScript, en interaction avec le DOM, ou la mise en place de callbacks, en mettant la main sur l'objet js.global, comme indiqué dans l'exemple suivant :
print('hello' .. ' ' .. 'world!') -- This is Lua!
print(js.run('[0,1,2,3,4,5][3]')) -- Run JS from Lua
-- Interact with the page using Lua
local screen = js.global.screen
print("you haz " .. (screen.width*screen.height) .. " pixels")
local window = js.global -- global object in JS is the window
window.alert("hello from lua!")
window.setTimeout(function() print('hello from lua callback') end, 2500)
local document = js.global.document
print("this window has title '" .. document.title .. "'")
Un des aspects importants de la mise en place d'une machine virtuelle au sein d'une autre VM est la performance, et dans ce cas des tests indiquent des performances de l'ordre de 50% comparé à du code natif, ce qui va de pair avec du code C compilé avec asm.js, et ce qui est suffisant pour certains scénarios selon Zakai :
C'est trop [trop faible performance] pour certains cas d'utilisation, mais certainement acceptables pour d'autres. En particulier, n'oubliez pas que la VM Lua est souvent nettement plus rapide que les autres langages dynamiques comme Python et Ruby. Ces langages sont utiles dans de nombreux cas, même s'ils ne sont pas très rapides.
Un autre problème est la taille de la bibliothèque, qui dans ce cas est étonnamment petite, 200Ko g-zippé.
Il y a d'autres problèmes difficiles à traiter lors de l'exécution d'une machine virtuelle dans une autre machine virtuelle, comme mentionnés par Zakai :
Il y a cependant quelques questions délicates, par exemple, nous ne pouvons pas faire de cycles de collecte inter-VM - si un objet Lua et un objet JavaScript ne sont tous les deux pas référencés par d'autres objets, mais se référencent l'un et l'autre, pour être capable de les désallouer nous devons être capables de traverser toute la heap des deux côtés, et fondamentalement faire notre propre garbage collector à la place du navigateur - pour des objets JavaScript normaux, et pas seulement un nouveau type d'objets comme ceux de Lua. Les moteurs JavaScript ne nous permettent pas de faire cela, pour un ensemble de raisons de sécurité et de performance. Ce que nous pouvons faire est de permettre à Lua de maintenir des références fortes dans le monde JavaScript, et automatiquement libérer ceux-ci quand Lua collecte une telle référence. Cela limite les choses, mais il est important de se rappeler que les cycles de collecte inter-VM sont un problème difficile en informatique en général - le seul cas facile, c'est quand les objets d'une VM peuvent être implémentés entièrement dans l'autre, mais ce n'est pas possible dans la plupart des cas (et notamment pas dans celui-ci : par exemple, certains objets Lua peuvent avoir des "finalizers" qui ne peuvent être mis en œuvre en JavaScript) et même quand c'est le cas, la performance est un sujet de préoccupation. Mais il faut noter que ce type de problème pourrait également être présent si nous devions livrer deux machines virtuelles séparées dans les navigateurs Web.
Ce projet ne semble pas être une indication de la volonté de Mozilla d'exécuter d'autres machines virtuelles dans le navigateur, mais plutôt de montrer la puissance de Emscripten et asm.js, qui sont actuellement dans une course en tête-à-tête avec Google PNaCl, une autre tentative d'exécuter du code natif dans le navigateur. (des détails sur ceci peuvent être trouvés dans ce post InfoQ : Débat: Faut-il une Bytecode Web Universel ?)
Le problème avec asm.js et PNaCl est qu'aucun n'est pris en charge par d'autres navigateurs. Théoriquement, Chrome peut exécuter du code asm.js, mais la performance est plutôt faible. Par exemple, des benchmarks sur la VM Lua exécutés sur Chrome sont moins performants de 30% que ceux sur les builds "Nightly" de Firefox, ce qui représente 50% de l'équivalent natif. Dans l'état, personne ne va utiliser asm.js dans Chrome à moins que Google optimise son navigateur pour la solution de Firefox pour le code natif. Il est possible que tout se base sur la part de marché des navigateurs, et la capacité d'améliorer la performance de leurs solutions respectives.