DOMのGCについて聞いてください!
DOMのGCについて聞いてください!
はじまるよ〜〜〜〜〜!!!!
自己紹介
趣味でやっていること
マイブーム
DOMのGC……?
思い浮かべてください……
DOMのGC……?
https://en.wikipedia.org/wiki/GameCube#/media/File:GameCube-Console-Set.png
https://commons.wikimedia.org/wiki/File:DOMDOM_Ibaraki_FC.JPG
DOMのGC……?
DOMのガベージコレクション
DOMのGC……?
DOMのガベージコレクション
ガベージコレクションってなんだっけ
👶「ガベージコレクションって?」
🧚「メモリに残ってる不要なデータを、自動で削除する仕組みです」
ガベージコレクションってなんだっけ
👶「メモリ!?そんなの気にしてない!」
ガベージコレクションってなんだっけ
👶「メモリ!?そんなの気にしてない!」
ふだんJSかいてる
メモリ管理の世界観は言語により異なる
メモリ管理の世界観は言語により異なる
メモリ管理の世界観は言語により異なる
メモリ管理の世界観は言語により異なる
JSエンジンはDOMのGCだってやってくれる
でもどうやって??
(今日のテーマ)
JSエンジンのGCのやり方
マークアンドスイープ
ルートセット=「絶対に残しておくオブジェクトたち」からたどれるものは残す。残りを消す
マークアンドスイープの流れ
マークアンドスイープの流れ
マークアンドスイープの流れ
マークアンドスイープの流れ
マークアンドスイープの流れ
マークアンドスイープの流れ
マークアンドスイープの流れ
JSエンジンは
マークアンドスイープしてるよ
(ルートはグローバルオブジェクトとか)
👶「DOMもマークアンドスイープすれば�よくない?」
👶「DOMだってたどれるんだからさ」
👶「ん?DOMってどこにあるんだっけ?」
DOMは誰が持っているんだ?
JSでDOMの操作
JSでDOMを操作して画面を変更するときのイメージ
DOMは誰が持っているんだ?
JSでDOMの操作
レンダリングエンジンにある?
でもJSエンジンにないとさわれない?
JSでDOMを操作して画面を変更するときのイメージ
DOMの本体はレンダリングエンジン側にあり、ラッパーを通じてJSに露出している
browser
rendering engine
JS engine
div
DOM
wrapper
DOM
JSでのDOMの操作
div
DOMの本体はレンダリングエンジン側にあり、ラッパーを通じてJSに露出している
browser
rendering engine
JS engine
div
DOM
wrapper
DOM
JSでのDOMの操作
div
なるほど……?
要するにどうなっているの??
例えばこんなDOMを作ってみる
ローディングのバーを出して
fetchできたらコンテンツに切りかえる
Ulan et al; Garbage Collection as a Joint Venture
https://queue.acm.org/detail.cfm?id=3325132
v8とblinkそれぞれでDOMが表現される
Ulan et al; Garbage Collection as a Joint Venture https://queue.acm.org/detail.cfm?id=3325132
実は……
Ulan et al; Garbage Collection as a Joint Venture https://queue.acm.org/detail.cfm?id=3325132
parentElement()なんかも、ブラウザががんばって取得して返してくれているだけ
parentElement()なんかも、ブラウザががんばって取得して返してくれているだけ
大事なこと
JSエンジンのなかでは
DOMノードはツリーになっていない!
👶「じゃあDOMはマークアンドスイープできないってこと?」
実際にやってみよう
これだけ消せれば良いね!
Ulan et al; Garbage Collection as a Joint Venture https://queue.acm.org/detail.cfm?id=3325132
V8は左しか見えない
これだけ消せれば良いね!
Ulan et al; Garbage Collection as a Joint Venture https://queue.acm.org/detail.cfm?id=3325132
ルートからたどってみると……
これだけ消せれば良いね!
何も考えずにやると
消えすぎちゃう
(blinkで使っているのに
消えちゃう)
Ulan et al; Garbage Collection as a Joint Venture https://queue.acm.org/detail.cfm?id=3325132
じゃあblinkから参照されてたら残す?
これだけ消せれば良いね!
blinkから参照されているなら必ず残すというルールはどうか??
👉それはそれで残りすぎてしまう
Ulan et al; Garbage Collection as a Joint Venture https://queue.acm.org/detail.cfm?id=3325132
👶「DOMもマークアンドスイープすれば�よくない?」
👶「DOMもマークアンドスイープすれば�よくない?」
object grouping (~2017/5, chrome56)
v8のGCに、blinkから「どのノードが同じツリーに属しているか」という情報を足し込む
object grouping (~2017/5, chrome56)
Ulan et al; Garbage Collection as a Joint Venture https://queue.acm.org/detail.cfm?id=3325132
object grouping (~2017/5, chrome56)
「DOMツリー同じやで」
「DOMツリー同じやで」
Ulan et al; Garbage Collection as a Joint Venture https://queue.acm.org/detail.cfm?id=3325132
object grouping (~2017/5, chrome56)
「DOMツリー同じやで」
「DOMツリー同じやで」
DOMツリーは相互に参照を持っているので
(i.e. parentElement/childNodes)
ツリー中のノードが1つでも生きていれば
全体が生きていると決めていい
object grouping (~2017/5, chrome56)
「DOMツリー同じやで」
「DOMツリー同じやで」
Ulan et al; Garbage Collection as a Joint Venture https://queue.acm.org/detail.cfm?id=3325132
object grouping (~2017/5, chrome56)
「DOMツリー同じやで」
マークされずに終わる
Ulan et al; Garbage Collection as a Joint Venture https://queue.acm.org/detail.cfm?id=3325132
object grouping (~2017/5, chrome56)
だめだった
object grouping (~2017/5, chrome56)
だめだった
cross-component tracing (~now)
v8がGCしててDOMに当たったら、blinkに「このDOMなにとつながってる!?」って聞く
cross-component tracing (~now)
Ulan et al; Garbage Collection as a Joint Venture https://queue.acm.org/detail.cfm?id=3325132
cross-component tracing (~now)
Ulan et al; Garbage Collection as a Joint Venture https://queue.acm.org/detail.cfm?id=3325132
cross-component tracing (~now)
Ulan et al; Garbage Collection as a Joint Venture https://queue.acm.org/detail.cfm?id=3325132
cross-component tracing (~now)
Ulan et al; Garbage Collection as a Joint Venture https://queue.acm.org/detail.cfm?id=3325132
cross-component tracing (~now)
Ulan et al; Garbage Collection as a Joint Venture https://queue.acm.org/detail.cfm?id=3325132
cross-component tracing (~now)
Ulan et al; Garbage Collection as a Joint Venture https://queue.acm.org/detail.cfm?id=3325132
cross-component tracing (~now)
Ulan et al; Garbage Collection as a Joint Venture https://queue.acm.org/detail.cfm?id=3325132
cross-component tracing (~now)
マークされずに終わる
Ulan et al; Garbage Collection as a Joint Venture https://queue.acm.org/detail.cfm?id=3325132
cross-component tracing (~now)
マークされずに終わる
Ulan et al; Garbage Collection as a Joint Venture https://queue.acm.org/detail.cfm?id=3325132
CCTによってDevToolsでの
メモリデバッグの精度があがった
左: object grouping
右: CCT
DevToolsで追えた度合いが異なる
左はDOMノード間の関係が見えない
Degenbaev, Ulan, et al. "Cross-component garbage collection."
結論
ふろく: すごくありがたかったソース