Slip Ahead Logging

It's not your fault at all.

JS > bytecode

「いまどきの JavaScript 処理系ってほとんど VM 型なんでしょ.で,中では JavaScript のコードが VM 命令列に変換されて,実行されてるんでしょ.ならその VM 命令を標準化しちゃえば良いのに.そうすれば CoffeeScript や HaXe や TypeScript みたいな Transpiler 型の言語も VM 命令を直接吐けて効率的になりそうだし」

そんな誰もが思ったことのありそうな(いくぶん聞き飽きた)疑問に対する Brendan Eich 御大のお答え*1

"JavaScript > bytecode"

  • Dynamic typing ⇒ no verification
  • Type inference ⇒ delayed optimization
  • Would bytecode compress as well?
  • Bytecode standardization would suck
  • Bytecode versioning would suck more
  • Low-level bytecode is future-hostile
  • Many humans like writing JavaScript
http://brendaneich.github.com/Strange-Loop-2012/#/27

バイトコードの Verification

(専門家ではないので,変なことを言っている可能性があります)

「これを実行してね」と与えられたバイト列をそのまま命令列として VM に流し込んで実行するわけにいかないのは当然.これは JavaScript のコードに構文エラーがあったら実行できないのと同じ.さらに,バイト列が一見きちんとした命令列になっていても,内部でのジャンプ命令がおかしなアドレスに飛んでいたりだとか,不正なメモリアクセスをしていたりだとかいう危険なことをおこなっている可能性があるので,結局は実行前にそれらをチェックしなければいけない.これがバイトコードの Verification と呼ばれているもの.言語機能と VM 命令のレベルによっては,変数の初期化がおこなわれているかだとか,型チェックだとか,private / protected をはじめとするアクセス範囲が守られているかだとか,そういったことまでしっかりチェックしてあげる必要がある.

いっぽう JavaScript 処理系はバイトコードを実行しているわけではなく JavaScript コードをパースして独自の VM 命令列に変換し,それを順に実行する.処理系が責任を持って内部的にバイト列をメモリ上に生成するので,おかしなものが混じっている心配もない.

JavaScript にはパース処理が必要なように,バイトコードには Verification が必要.で,最近の JavaScript 処理系のパース処理は頑張っているものだから,きちんと Verification をやるよりもよっぽど高速だったりするらしい.

*1:この人達があげつらうバイトコードというのが大抵は JVM のものであるところが,毎度ながら気になるところではある