Servo Parallelism!

Tetsuharu OHZEKI

ABOUT ME

• Tetsuharu OHZEKI!

• @saneyuki_s!

• Mozilla Committer!

• Servo contributor (e.g. DOM binding)

モダンブラウザのアーキテクチャと抱える課題

現代的なエンジンの処理フロー

http://dbaron.org/talks/2014-06-04-cssday/master.xhtml

現代のエンジンの基本

•DOMの構築～レイアウト結果の描画（paint）ほぼシングルスレッド動作

•ネットワークは10年以上昔から非同期に動作している

現行エンジンの速度向上指針

•とりあえず頑張って最適化をする

•非同期に出来そうなところを頑張って非同期にする

•HTML5 parser

•描画のcomposition

•エンジン側で効率的に制御できるAPIを準備する

•Web Animations, CSS Transform

現行エンジンの抱える課題•レイアウトフローがシングルスレッド動作なので速度向上に限界がある

•ハードウェアはメニーコア志向なのでアーキテクチャ的に使い切れない

•安易に破壊的な変更ができない

•コードベースも巨大

•依存しているエコシステムも巨大

•Break the Webは何よりも忌避される

Servo

http://en.wikipedia.org/wiki/Tom_Servo

Servo•Mozillaによる、並列性にフォーカスしたブラウザエンジンの 試験実装

•Rustによって記述されている

•標準化されたspec通りに実装

• tableのlayout方法など、存在しないspecの再検証

•並列化に必要な機能の調査

•並列化に限らず、既存エンジンに投入しにくい（大きな変更を伴うがやっておきたい）アーキテクチャの変更も含む

Rust Language

•Mozilla製の新言語

•システムプログラミング

•並列性・安全性

•C++生まれHaskell育ちアクターモデルはだいたい友達

Servoのアーキテクチャ

Servoのアーキテクチャ

•可能な限り非同期動作にする

•役割に応じてタスクを分割

•スレッドではない（Rustのタスクモデル準拠）

•マルチコアの使用を狙う

•並列化・並行化をねらう

全体の関係図（→の方向にメッセージ送信可）

iframe (cross origin)

•Servoではクロスオリジンなiframeの中は非同期実行する

•タスクの分割によるセキュリティモデル

•根本的な影響の分離

iframe (cross origin)

Servoの並列化戦略

Copy-on-Write DOM

Copy-on-Write DOM

•DOMの変更点を接ぎ木し、スナップショットを構築する

•スクリプトの実行を妨げずにレイアウトを可能にする

•ただし、やるかは未定

• 実装の複雑さに反して、メリット薄いのでは？という話が出ている

セレクタマッチングの並列化

セレクタマッチングの並列化

• CSSセレクタのマッチング処理は非常にコストが高い

•全てのノードに対する総当たり

•レンダリング時間の約20%がこれに費やされているという調査報告も存在

•これの高速化は確実に高速化が見込める

• Other approach: CSS JIT

• Servoは、各ノード単位で並列してセレクタマッチングを行う

レイアウト処理の並列化

レイアウト処理の並列化

•何よりもこいつが遅い

•シーケンシャルに処理している

•既存実装では、並列化が困難

•そもそも並列化できるか不明？（e.g. float）

•設計的に困難なケースもある

レイアウト計算: 3-PASS•bubble-width (bottom up)

•好ましい幅の割当

•assign-width (top down)

•実際の幅を割当

•assign-height (bottom up)

•幅を元に高さを割当

•それぞれを混ぜる事はできないが、それぞれの中を並列化は可能

•Bottom up

•子の結果に親が依存する

•Top Down

•親の結果に子が依存する

依存先の計算が完了していれば並列化できる

並列化アプローチ

floatの計算をどうするか？

•floatの場合、回り込みが発生する

•floatの後続要素は、先行するfloatの結果を考慮する必要が有る

•先行するfloatの高さ次第で回り込みの有無が決まる

•floatの影響を受ける要素に「影響を受ける」とフラグを立てる

•影響を受けた要素（後続の要素）は,

floatの計算終了後に計算する

•=assign height phaseまで実際の計算タイミングを先延ばしする

block format context

•block format contextの場合, floatの幅計算の影響が減る（回り込む必要が無い）

•具体的にはoverflow:hiddenを用いてサイドバー的に使うレイアウトの場合

•その場合、assign-width時に、「親の幅」-「隣接するfloatの幅」により幅を仮定して処理を進行できる

•ただし、今のコードはバグッてるぽい……

その他

その他試したこと

•DOMのライフサイクル管理の一本化

•SpiderMonkey GCでRustオブジェクトの生存管理

•GPU上でのセレクタマッチ

•実験のみ。masterへのマージはしていない

TBD•インクリメンタルレイアウト

•CSS JIT

•実用的なエンジンへの一歩

•各プラットフォーム向けコードの開発

•未実装機能の実装

•現実的なベンチマークでの比較

•ファンタジーかどうかが未確認

現状

•全体のアーキテクチャは完成

•Acid 2は通った

•エッジケースの実装がまだまだ

•Web platform testを少しずつ走らせてる

•Samsungチーム最近見かけない……

•たまーにpull request出す人がいるけど？？？

Servoの将来

No Plan…?

将来

•繰り返しますが No Planな様子

•より正確には「メインラインへの統合・Geckoの置き換えなどは、まだ考えていない」が正しい

•bleeding edgeのためにembedding頑張ってる

•ChromiumのUI使うかも（Cで接合できるUIが欲しいので, Firefoxは不適）

•実用化にはやることがたくさん