15/07/13 23:57:19.86 .net
>>958,959
見る限りV8のDOMはおまけだ。ただ、そういう用途があるのかはよく分からない。
ブラウザから離れるのなら、最初からnative(exe)が使える。サーバーサイドは基本的にこれだ。
スクリプトの方が運用が楽だし、スレッド起動できるから今は速いわけだが、
exeをスレッド起動できる仕組みが出来ればスクリプトエンジンは全部抹殺されても不思議ではない。
(DLLの動的『指定』とか)
もちろん速いスクリプトエンジン自体は需要はあるし、JITならさほど遅くもないから、こちらに賭けるという選択だとも見える。
しかしNodeはC->JavaScriptは呼べるが、逆はできない。つまり本体はCで、JavaScriptをブラウザ/WEB用APIとして使う方向だ。
nativeが使える状況で速度至上主義なら、C系以外の選択肢は事実上無い。だからNodeの選択は妥当だ。
もちろんNode自体を動かすためにV8が必要だとしても、若干ここら辺に違和感を感じるのは事実だ。（統一感がない）
そもそも速い共通バイナリならJavaでよかったのだが、chromeはそれも外した。(NPAPIの廃止）
Javaについては他に問題がありすぎるようではあるが。
なお、密結合にはならない。
元々1つの物(DOM)を、2箇所(Blink/V8)から管理するからおかしいことになっている。
見る限りDOMとJSのオブジェクトは相似形だから、同じHeapで同居できるはず。
だから、Blink/V8/JSHeapと分離し、BlinkとV8内部には個別のHeapを持たず、全部JSHeapに突っ込めばいい。
wrapperというコピーが無くなるので、メモリ使用量は減る。
GCはすべてJSHeapに任せられる。単一で内部的にツリーを構成できているから、
「GCされないために云々」という無駄コードを全て捨てられ、プログラムとしては綺麗になる。
ただ、各エンジンとHeapが粗結合になるので、どうしても動作が遅くなる。
(Readはpublic（というか直接ポインタアクセスで動的保護無し）、
Writeはprivateという指定が出来ればいいのだが、これができる言語は多分無い）
だから高速エンジン制作者には不評だろうけど。
とはいえ、Mozillaがやろうとして失敗したようだから、何か他にも問題があるのだとは思う。