OmoikaneのDOMと例外通知を実装したら、コピーとGCの寿命まで調べることになった

Sat, 10 Oct 2026 17:42:29 +0900

Omoikaneに、before()やreplaceChildren()といったDOM操作と、window.onerror、未処理Promise rejectionの通知を追加した。PR #1322の話である。最初の入口は、ページが普通に呼ぶAPIが足りないという、分かりやすい問題だった。ところが実装と検証を進めると、HTMLテキスト挿入の兄弟一覧コピー、UTF-16追記の全文再構築、不要なiframe Realm生成、PromiseのGC root不足まで直すことになった。

名前の付いたAPIを増やすだけなら、記事ももう少し短くできる。しかし今回の差分は、APIが返す値だけでなく、その途中で走るユーザーコード、イベントの届く時刻、退役した文書の所有者、GCが見える参照までつながっている。replaceChildren()が新しい木を作る瞬間と、unhandledrejectionのコールバックがGCを起こす瞬間は、同じブラウザの同じオブジェクト群を別の方向から触る。そこを省いて「対応しました」と書いても、何を守って実装したのかが伝わらない。

今回はかなり長い記録にした。それぞれの機能について、何が足りなかったのか、入力をどの順番で処理するのか、どの観測結果をテストで固定したのかを説明する。性能の節では、処理時間の実測と、コピー量から分かることも分ける。個別の修正に興味があれば、次の入口から読める。

この記事で説明する実装の時点

説明の基準は、2026年10月10日にマージした994f17ccである。執筆時に確認したmainもこのコミットだった。PRの最終headは7ad562bf、比較元はe69ee73cで、APIに表示しきれなかった大きなファイルについても、両時点のソースを照合した。記事中のコードとテストのリンクは、基本的にマージ時点のコミットへ固定している。

計測値は、PR本文と調査経緯の最終コメント、関連Issueに保存した報告に基づく。この記事のためにブラウザの全テストや性能比較をもう一度実行した結果ではない。ソースから説明できる処理、報告された実測、まだ検証していない改善案を混ぜないようにする。

変更前に足りなかったDOM APIはIssue #1284、ページ内のエラー通知はIssue #1289で整理した。後者はCDPのRuntime.exceptionThrownとは別の経路である。外からブラウザを操作するクライアントが例外を知ることと、ページ自身のaddEventListener('error', ...)へ通知が来ることは同じではない。ページ内の監視処理が動くためには、ブラウザがそのページのglobalへイベントを届ける必要がある。

また、ここでいうBoaはOmoikaneのengine/boa/へ組み込んだ実装を指す。Omoikaneで加えた修正を、そのまま上流Boaの任意のリリースの状態として説明するつもりはない。以前のgetter返値のroot不足やephemeronと世代別GCの不具合とつながるところはあるが、今回のPromise.finallyの問題は、別の値、別の区間の保持漏れである。

APIの追加が下の層へ広がった理由

先に用語を揃えておく。Realmは、global objectやArray、Dateなどの組み込みオブジェクトを持つJavaScriptの実行環境の単位である。iframeの内外ではRealmが分かれ、同じ名前のconstructorでも別のオブジェクトになる。originは、その間でどの情報へアクセスできるかを判断する別の境界だ。今回のRealmの型には、この環境とhost側の所有情報を結び付ける入口がある。

wrapperは、Rust側のnative nodeをJavaScriptへ見せるオブジェクトを指す。identityを保つというのは、同じ内容の別objectを作るのでなく、===で同じものとして比較できるようにすることだ。GCのrootは、生存している値を探す起点である。Rustのローカルにhandleが残ることと、そのhandleがrootとして登録されていることは別なので、後半ではどの区間でrootを持つかを細かく見る。

ブラウザのDOMは、Rustの木構造だけで完結しない。ページのJavaScriptから見えるwrapper、native nodeのidentity、所有Document、Realm、イベントリスナー、Range、MutationObserver、custom elementのreactionが重なっている。木の中で同じnodeを動かしても、removeして別nodeを作った場合と同じ観測にはならない。逆に、同じwrapperが残っていても、その背後の所有Documentを新しいactive Documentへ勝手に付け替えてよいわけではない。

例外通知にも同じ事情がある。Rust側でエラーを受け取った時点で、元のscriptのRealmやsource位置がすでに復元されていることがある。そこで単に「現在の文書へエラーイベントを投げる」と、例外の発生元、cross-originのmuted errors、Workerのownerがずれる。Promise rejectionでは、rejectした瞬間と、未処理だと確定するcheckpointも違う。その間にhandlerが付けば、通知してはいけない場合がある。

性能修正は、その意味を保ったまま余分な仕事を消す変更になった。末尾の一件を得るために全childrenをcloneしなくてよい。履歴URLを読むためだけに子Realmを初期化しなくてよい。処理済みmoduleのASTを、評価可能な状態と一緒にいつまでも持たなくてよい。ただし、どれも本当に不要な保持や生成なのかを確かめる必要がある。コピーをなくした結果、GCから必要な値が消えたり、author getterを呼ぶ順番が変わったりすれば、別の不具合を作る。

以下では、まずページから見えるDOMとHTMLの機能を説明し、次に通知、GCとiframe、性能と検証の順に進む。途中に置く短いコードは、特に断らない限り、挙動を説明するための例である。実際に計測に使ったfixtureや回帰テストと同一だと扱う場合は、そのテストへ直接リンクする。

DOMの便利なメソッドにも、挿入の規則を全部通す

DOM側の出発点はIssue #1284だった。10月7日の確認ではChildNode・ParentNodeの操作、moveBefore、adoptNode、shadow treeを含むparse・serialize APIが足りなかった。名前を増やすだけなら簡単そうだが、文字列変換、例外、MutationObserver、live Range、custom element、iframeの寿命まで一緒に動く。 Issue #1284

まず公開先を整理した。prepend()、replaceChildren()、moveBefore()などのParentNodeのメソッドはElement、Document、DocumentFragmentへ置く。before()、after()、replaceWith()というChildNode側のメソッドはElement、CharacterData、DocumentTypeへ置く。全部を基底のNodeへ足すと、存在しないはずの場所でも呼べてしまう。今回のプロトタイプへの配置は、この区分をそのまま表している。

Nodeか文字列かを、木を動かす前に決める

before()などは、Nodeだけでなく文字列も複数受け取れる。次のコードは説明用の例だ。

const parent = document.createElement('div');
const marker = document.createElement('span');
parent.append(marker);
marker.before('head', null, undefined);

ここでは三つのTextノードがmarkerの前にできる。内容は順にhead、null、undefinedになる。nullを「何も挿入しない」と扱うAPIではない。一方、すでにNodeである値は新しいNodeへ変換せず、同じオブジェクトを移動する。marker.before(existing)の前後で、existingを変数に保持していたコードは同じNodeを指し続ける。

convertMutationArgumentsは、引数を正規のNodeとして識別できればそのまま残し、それ以外をDOMStringへ変換する。ここで公開のString()をそのまま使うだけだと、Symbolを文字列にできてしまう。DOMStringへの変換ではSymbolにTypeErrorを投げるため、toDOMStringでその条件を明示している。

変換のタイミングも意味がある。引数のオブジェクトにはtoString()があり、その中で任意のJavaScriptを実行できる。一つ目の引数Nodeを先に元の親から外し、二つ目の文字列変換が失敗すると、呼び出しは例外になったのに最初のNodeだけ動いた状態になる。今回の実装は、文字列への変換を先に一通り終えてから、Nodeを組み立てる処理へ進む。

親を持たない要素のbefore、after、replaceWithでも、挿入しないだけでDOMString変換は行う。detachedのテストはtoStringが一回呼ばれ、SymbolでTypeErrorになることを三つのAPIで確認する。 detachedのテスト

変換済みの引数をNodeへまとめるのはmutationArgumentsNodeだ。文字列を呼び出し先のDocumentでTextへ変換し、一つだけならそのNodeを返す。複数ならDocumentFragmentを作って順に入れる。ここで同じNodeを二度渡しても、同じNodeが二個の兄弟になれるわけではない。後の挿入で前の位置から動くため、最後の位置に一つだけ残る。

この点を兄弟操作のテストはa.replaceWith(a, 'replacement', a)で確認している。同じaをコピーして増やすのではなく、replacementのTextと、元のaのidentityを持つNodeが並ぶ。HTML文字列に直してからparseし直す実装では、このidentityは保てない。

beforeとafterは、参照兄弟を途中で失う

before()は自分の直前、after()は自分の直後へ挿入する。説明だけなら一行で済むが、引数に自分や隣の兄弟が入ると、その「直前」「直後」が動く。説明用に、親の子がa、b、cの順に並ぶ木を考える。

b.before(a, b, 'x');

複数引数をFragmentへまとめる間に、aもbも元の親から外れる。元のbを参照Nodeにしたまま最後にinsertBeforeすれば、もう親の子でなくなっているので失敗する。呼び出しが指定した位置を、引数をまとめる前の木から決めておく必要がある。

mutateSiblingは、変換済み引数に含まれるNodeのidを集める。beforeなら直前の兄弟から前へ、afterやreplaceWithなら直後の兄弟から後ろへ進み、引数に含まれない兄弟を探す。その兄弟は引数のFragment化で動かないので、挿入位置の目印として使える。

beforeの場合は、残る直前の兄弟の次を挿入先とする。残る兄弟がなければ親の先頭に入れる。afterの場合は、残る直後の兄弟をそのまま参照先とする。参照Node自身が挿入するNodeなら、その次の兄弟へずらす。これがないと、自分の前へ自分を入れる処理の扱いが崩れる。