[52] HTML や DOM は様々なオブジェクトやそれに類するもので構成されています。それらは文書 (Webアプリケーション) を構成する要素として存在していたり、スクリプトによって操作されたりします。どこからも参照されなくなり、スクリプト上も利用者界面上も意義を失ったオブジェクト等はごみ収集garbage collectionされ、破棄されます。それはすなわち Webブラウザー実行環境のメモリーから削除され、動作もアクセスもできなくなることを意味します。

仕様書

[2] HTML Standard (2012-11-16 20:26:18 +09:00 版) http://www.whatwg.org/specs/web-apps/current-work/#garbage-collection
[6] HTML Standard (2012-11-16 20:26:18 +09:00 版) http://www.whatwg.org/specs/web-apps/current-work/#playing-the-media-resource
[9] HTML Standard (2012-11-16 20:26:18 +09:00 版) http://www.whatwg.org/specs/web-apps/current-work/#best-practices-for-authors-using-media-elements
[11] HTML Standard (2012-11-16 20:26:18 +09:00 版) http://www.whatwg.org/specs/web-apps/current-work/#garbage-collection-and-browsing-contexts
[20] HTML Standard (2012-11-16 20:26:18 +09:00 版) http://www.whatwg.org/specs/web-apps/current-work/#dedicated-workers-and-the-dedicatedworkerglobalscope-interface
[24] HTML Standard (2012-11-16 20:26:18 +09:00 版) http://www.whatwg.org/specs/web-apps/current-work/#dedicated-workers-and-the-worker-interface
[22] HTML Standard (2012-11-16 20:26:18 +09:00 版) http://www.whatwg.org/specs/web-apps/current-work/#runtime-script-errors-0
[25] HTML Standard (2012-11-16 20:26:18 +09:00 版) http://www.whatwg.org/specs/web-apps/current-work/#garbage-collection-0
[31] HTML Standard (2012-11-16 20:26:18 +09:00 版) http://www.whatwg.org/specs/web-apps/current-work/#garbage-collection-1
[44] DOM Standard (2012-11-16 19:17:11 +09:00 版) http://dom.spec.whatwg.org/#garbage-collection
[46] HTML Standard (2012-11-16 20:26:18 +09:00 版) http://www.whatwg.org/specs/web-apps/current-work/#update-the-image-data
[49] HTML Standard (2012-11-16 20:26:18 +09:00 版) http://www.whatwg.org/specs/web-apps/current-work/#proxying-canvases-to-workers
[53] XMLHttpRequest Standard (2012-11-14 13:48:01 +09:00 版) http://xhr.spec.whatwg.org/#garbage-collection
[82] HTML Standard (2014-03-07 22:55:24 +09:00 版) http://www.whatwg.org/specs/web-apps/current-work/#garbage-collect-the-regions
[36] HTML Standard (2015-12-03 22:48:19 +09:00 版) https://html.spec.whatwg.org/#outstanding-rejected-promises-weak-set
[91] Notifications API Standard (2014-02-11 16:20:34 +09:00 版) http://notifications.spec.whatwg.org/#garbage-collection

ごみ収集アルゴリズム

[107] Webブラウザーはごみ収集を実装しなければなりません。

[108]

スクリプトをまったく実装しない Webブラウザーは、一般的に「ごみ収集」と呼ばれるものを実装せず、単に必要なくなった文書を解放するだけで済むかもしれません。

[109] 具体的な方法は規定されていません。実装は任意の方法を選択できます。

[42] 実際のところ、ごみ収集に関する規定はありますが、ごみ収集を実装しなければならないという規定はどの仕様書にもありません。しかしごみ収集しない場合、メモリー上の利用可能領域は徐々に減少し、いずれ Webブラウザー自体が動作しなくなります。動作しなくなった時点で Webブラウザーは仕様書上の各規定に従うことができませんから、 (無限に大きなメモリーを有さない限り) ごみ収集しない Webブラウザーは適合できません。

[110] 単なる参照カウンターでは、循環参照を持ち外部から参照されなくなったオブジェクト群を回収できません。著者のスクリプトが循環参照を破棄することは求められていませんから、メモリリークが発生してしまいます。仕様書のアルゴリズムも循環参照の破棄はしていませんから、実装時には注意が必要です。

[111]

メモリーリークを発生させること自体は仕様書の規定に不適合であるとは言い切れず、実装の品質の問題に過ぎないかもしれませんが、メモリーリークによりメモリー領域の確保ができず動作に支障が出るなら、仕様違反ということになりそうです。 (そもそも仕様に違反するかどうか以前に、プログラムの動作に対する一般的な期待として、メモリーリークは不具合とみなされるとは思いますが...)

観測可能性

[84] Web と JavaScript においてはごみ収集の具体的な手法は実装依存となっており、その挙動は著者から観測可能であるべきではないと考えられています。

[85] 言語によってはオブジェクトが破棄される直前に特定のメソッドが呼び出されるなどの仕組みがありますが、 Web にはそれに類するものはありません。

[96] この原則に反する新機能の導入は避けるべきだと考えられており、回避できないために断念された機能もあります。

[86] DOM3 には UserDataHandler を節点の破棄の直前に呼び出す仕組みがありましたが、削除されました。詳しくは UserDataHandler の項を参照してください。
[97] ポートの一端が閉じられたことを通知する仕組みが提案されましたが、実装されることはありませんでした (>>81)。
[35] PortCollection は実装されませんでした。

[98] ごみ収集の詳細を著者 (スクリプト) から観測可能にしてしまうと、 Webブラウザーの実装の進化を阻害してしまう危険性があります。

[99] 例えばごみ収集には様々な手法が存在しますが、特定のタイミングで特定の処理が実行されることを保証しようとすると、それを実現可能なごみ収集手法の実装を強制することになり、ごみ収集手法の改良を妨げてしまうおそれがあります。逆に当該処理の詳細な実行タイミングを定義しないと、ごみ収集その他の実装の差異によって、実装ごとに異なるタイミングで処理が実行され、相互運用性の問題が生じる可能性があります。

[100] live なコレクションは、対象となるDOM木の変更が反映されますが、実装上はリアルタイムで変更を反映させる必要はなく、スクリプトからアクセスがあった時まで変更の反映を遅延させることもできます。あるいは、節点のリストを途中までだけ作成したり、リストの一部だけ変更を反映させた状態にしたりと、色々な実装方針が考えられ、どれを採用するかは各実装の裁量です。

[101] さてDOM木から節点が削除され、スクリプトからも参照されなくなった時、その節点はおそらくコレクションからも削除されることになりますが、ごみ収集が実行可能になるタイミングは、コレクションの更新のタイミングに依存します。ごみ収集が観測可能になると、コレクションの実装方法にも制約が生じます。

[102] 多くの Webブラウザーでは console.log により、あるいは開発者ツールにより JavaScript オブジェクトにアクセスできます。つまり開発者ツールからオブジェクトへの参照が生じます。スクリプト側での GC のタイミングに制約があるとすると、開発者ツール側で参照が残っていてもスクリプト側では開放したことにしなければならず、より実装が複雑になるかもしれません。 (少なくても実装方法への制約は強くなると思われます。)

ごみ収集と参照

[51] HTML も DOM も、「ごみ収集ガーベージ・コレクションgarbage collection」、「強参照strong reference」、「弱参照weak reference」といった用語を定義なしで使っており、計算機科学分野での一般的な単語として用いていると思われます。 (なお HTML は「弱参照」という用語を使っていません。)

弱参照

[80] JavaScript には WeakMap と WeakSet があります。

[119] その他にいくつか仕様書上の概念が弱参照を使っています。

[70] 環境設定群オブジェクトの未決拒絶された約束弱集合は、そのメンバーに対して強参照を作ってはならない >>36 と規定されています。

[120] 変異オブザーバーは弱参照を持ちます。

暗示強参照

[3] 既存のオブジェクトを返すIDL属性からは、そのオブジェクトへの暗示強参照implied strong referenceがあります。 >>2

[4] 例えば、 window.document IDL属性により、 Window オブジェクトから Document オブジェクトは強い参照があることとなります。

[5] Document からその子孫節点へは (直接または間接の) 強い参照があります。

[112] 各節点から節点文書へは強い参照があります。

歴史

[67] Web Applications 1.0 r2529 MAJOR CHANGES: ... (2008-12-12 17:46:00 +09:00 版) http://html5.org/tools/web-apps-tracker?from=2528&to=2529
[113] Tie Location to the Window object · whatwg/html@fdd8216 (2016-02-04 20:54:13 +09:00 版) https://github.com/whatwg/html/commit/fdd8216a902a065dd3e205cbbc1b5a6b527970a2

内部的な属性値への参照

[79] オブジェクトには、しばしば IDL属性として直接外部から参照可能でなくとも、内部的な属性のようなものとして別のオブジェクトが関連付けられていることがあります。これも強参照が存在し、最初のオブジェクトが存在する限り関連付けられているオブジェクトも破棄されないものと思われます。

循環参照

[87] オブジェクト同士の参照は、直接または間接に循環していることがあります。例えば、親節点から子節点へは childNodes を通じて参照がありますし、子節点から親節点へは parentNode を通じて参照があり、循環しています。また JavaScript によって著者が容易に循環参照を作り出すことができます。

[88] 従って Web におけるごみ収集は、外部から参照されなくなった循環参照のあるオブジェクト群を回収できる手法を用いる必要があります。

ごみ収集による動作の停止

[93] ごみ収集の実装手法の中には、ごみ収集の処理のために本来のプログラムの動作をすべて停止する必要があるものもあります。

[94] 明示的な規定は存在していないものの、利用者に明確に判別可能なレベルで動作を停止させるような実装方法は、好ましくないと考えられます。

[95] Acid3 はそのアニメーションが滑らかであることを要求しており、この試験に通過するためには、実行途中でごみ収集によって速度が変化するような実装であってはいけません。

[40] ただしこれは実装の品質の問題と考える人もいます。

閲覧文脈

[13] 利用者エージェントは最上位閲覧文脈に対して強参照を持っています。 >>11

[18]

利用者エージェントから閲覧文脈への強参照は閲覧文脈を捨てる算法で削除されます。

[12] 閲覧文脈は、その Document 群とその WindowProxy に対して強参照を持っています。 >>11

[17]

閲覧文脈から Document への参照はDocumentを捨てる算法で削除されます。

[14] Document はその Window に対して強参照を持っています。逆に Window は document 属性を通じて暗示強参照を持っています。 >>11

[15] Window は window など、 Document は defaultView などを通じて WindowProxy への暗示強参照を持っています。 >>11

[16] スクリプトはスクリプト設定群オブジェクトへの強い参照を持っており、スクリプト設定群オブジェクトは大域オブジェクト、有責閲覧文脈、有責文書に対して強参照を持っています。 >>11

[19] 最上位閲覧文脈でない閲覧文脈の WindowProxy がごみ収集の対象になると、当該閲覧文脈は閲覧文脈を捨てる算法により処理されなければなりません。 >>11

歴史

[68] Web Applications 1.0 r2529 MAJOR CHANGES ... (2008-12-12 17:46:00 +09:00 版) http://html5.org/tools/web-apps-tracker?from=2528&to=2529

変異観察器

[45] 節点は、登録済み観察器のリストにある登録済み観察器に対する強参照を持ちます。逆方向には弱参照を持ちます。 >>44

ワーカー

[21] DedicatedWorkerGlobalScope/Worker は暗示的に関連付けられた MessagePort オブジェクトを有しますが、この MessagePort は DedicatedWorkerGlobalScope/Worker より先にごみ収集してはなりません。 >>20, >>24

[23] ワーカーの実行時誤りは error 事象として呼び出し元の Worker や Document へと伝達されていきますが、その伝達先が既にごみ収集されて消失している場合には onerror は null であるものとして (つまり何もしないで更に上位の呼び出し元へと伝達されるよう) 処理されます。 >>22

[90] ワーカーはスクリプト設定群オブジェクトを介してワーカーを起動した大域オブジェクトや Document への参照を保有しています。

[118]

ServiceWorker

`MessagePort`

[39] MessagePort についてはオブジェクト自身が著者のスクリプトから参照されなくなっても、相手方が存在する限り存続することがあります。

MessagePort 参照。

[81] MessagePort の一端が失われた場合に他方に通知する方法も検討されたものの、ごみ収集の挙動をスクリプトから観測できず、メモリーリークもさせず、 bfcache も実装可能であるような手法が見つからず、議論がまとまりませんでした。

[39] PortCollection は MessagePort を零個以上保有することができるオブジェクトですが、強参照ではないので MessagePort のごみ収集を防ぐ役割は持たず、ごみ収集された MessagePort は削除されていきます。しかしこれもごみ収集の実装の自由を損なうとして、実装されることはありませんでした。

`BroadcastChannel`

[38] BroadcastChannel 参照。

画像

[47] 画像データの更新update the image data算法の実行中は、その対象となっている img 要素の文書から当該要素への強参照があるとしなければなりません。 >>46

[48]

Document中にある要素なら自然に満たされますが、そうではなく単独で存在する img 要素であっても、画像の読み込みが終わるまでは破棄されないことになります。

[50] CanvasProxy は無効でなければ対応する画布要素への強参照があるとしなければなりません。 >>49

ヒット領域

[83] canvas のヒット領域は、削除されたり消去されて対応する画素がなくなり、他のヒット領域の子供でもないなら、領域をごみ収集するgarbage-collect the regions手順により削除されます >>82。

媒体要素

[7] 媒体要素は、それに対するすべての参照が削除されただけの理由で再生playingを停止してはなりません。それ以上音声audioを再生できない状態になった時、当該媒体要素はごみ収集して構いません。 >>6

[8] 要素に対して明示的に参照が存在しておらず、まだ活性的に再生actively playingされていなくとも、音声の再生のために存在し続けることがあります。例えばまだ参照されている現在媒体制御器があって再生再開unpauseできるかもしれませんし、あるいは再生再開されていてもバッファ待ちのため stall 中かもしれません。 >>6

[10] 環境によっては同時再生数の制限が厳しいかもしれませんから、再生が終わったらすべての参照を確実に削除するなど配慮することが特に好ましいとされています。

>>9

Blob

[74]

revokeObjectURL

WebRTC

[64]

WebRTC 1.0: Real-time Communication Between Browsers (2012-11-15 19:30:32 +09:00 版) http://dev.w3.org/2011/webrtc/editor/webrtc.html

[63]

Media Capture and Streams (2012-11-15 19:30:32 +09:00 版) http://dev.w3.org/2011/webrtc/editor/getusermedia.html#mediastreamtrack

XHR

[54] XMLHttpRequest オブジェクトは次の場合ごみ収集してはなりません。 >>53

[55] 次のいずれかが成立し、
- [56] 状態が OPENED であり send()フラグが設定されている
- [57] 状態が HEADERS_RECEIVED
- [58] 状態が LOADING
[59] かつ次のいずれかが成立する場合
- [60] readystatechange, progress, abort, error, load, timeout, loadend のいずれかの事象聴取器が登録されている場合
- [61] アップロード完了フラグが設定されておらず関連付けられた XMLHttpRequestUpload オブジェクトが progress, abort, error, load, timeout, loadend のいずれかの事象聴取器が登録されている場合

[62] XMLHttpRequest オブジェクトの接続が開いたままごみ収集される場合、 fetch をすべて取り消し、それらにより追加されたタスクをすべて破棄し、またそれらによりネットワークから受信しているデータがあれば破棄しなければなりません。 >>61

事象源

[26] EventSource については、

[28] readyState が CONNECTING であり、かつ open, message, error のいずれかの事象聴取器が登録されている場合
[27] EventSource の readyState が OPEN であり、かつ message, error のいずれかの事象聴取器が登録されている場合
[29] 遠隔事象タスク源にタスクが投入されている間

... には、 EventSource の構築子が呼び出された Window または WorkerUtils から EventSource への強参照がなければなりません。 >>26

[30] EventSource の接続が開いている間に同オブジェクトがごみ収集される場合、当該オブジェクトによって開かれた fetch は中断しなければなりません。 >>26

歴史

[69] Web Applications 1.0 r2870 Drop <eventsource>. Replace the API with an EventSource object. Rename onclosed to onclose on WebSocket. Remove the mostly worthless event definitions. I'll add more useful intro text to replace them later. Defined garbage collection specialness for WebSocket and EventSource. (2009-02-26 17:33:00 +09:00 版) http://html5.org/tools/web-apps-tracker?from=2869&to=2870

Web Sockets

[32] WebSocket オブジェクトは、イベントリスナーやバッファーの状況次第で、ごみ収集してはなりません >>31。

[37] また WebSocket オブジェクトが接続が開いたままごみ収集される場合は、接続を閉じる手順を実行しなければなりません >>31。

[106]

WebSocketのごみ収集を参照。

`Notification`

[92] Notification は、対応する通知が list of pending notifications か list of active notifications に含まれていて、 click, show, error, close のいずれかのイベントリスナーを持つ間は、これをごみ収集してはいけません >>91。

歴史

[1] Web におけるごみ収集 (garbage collection) は HTML Living Standard ではじめて明示的に規定され、その後他の仕様でも定義されるようになりました。

[71] Web Applications 1.0 r7573 Simplify the Blob release mechanism, at the cost of exposing the Web's innards a bit more to script authors. ( (2012-12-08 07:57:00 +09:00 版)) http://html5.org/tools/web-apps-tracker?from=7572&to=7573
[72] Navigation Timing ( (2012-12-13 06:51:35 +09:00 版)) http://www.w3.org/TR/2012/REC-navigation-timing-20121217/#garbage-collection

[66] Web Applications 1.0 r2357 Define MessagePort such that they won't be garbage collected while a message is outstanding. (credit: ap) (2008-10-21 04:18:00 +09:00 版) http://html5.org/tools/web-apps-tracker?from=2356&to=2357
[65] Web Applications 1.0 r2024 Simplify garbage collection for ports even further. Define dicarding of Document objects better for ports. Prevent inactive documents from receiving messages. (2008-08-06 16:57:00 +09:00 版) http://html5.org/tools/web-apps-tracker?from=2023&to=2024

メモ

[73] オブジェクトが著者がアクセスできる範囲の外から参照されることもあり得ます。例えば console.log メソッドにオブジェクトを渡すと、その環境のデバッガーが当該オブジェクトへの参照を保持し、スクリプト内から参照しなくなったとしてもごみ収集されずに残り続けることがあります。

[75] Incremental GC in Firefox 16! | JavaScript ( (2013-04-09 05:16:01 +09:00 版)) https://blog.mozilla.org/javascript/2012/08/28/incremental-gc-in-firefox-16/

[76] JavaScript:SpiderMonkey:GC Futures - MozillaWiki ( (2013-04-02 17:53:25 +09:00 版)) https://wiki.mozilla.org/JavaScript:SpiderMonkey:GC_Futures

[77] substructural: Programming, Entrepreneurship, and the Markets: Garbage Collection in JavaScript, Part 1 ( (2013-03-20 10:45:20 +09:00 版)) http://www.typedynamic.com/2012/03/garbage-collection-in-javascript.html

[78] Web Applications 1.0 r2529 MAJOR CHANGES: Revamp the way scripts are specified, along with their interaction with resolving relative URLs, etc. Give enough detail to justify objects in the DOM not being garbage collected randomly when still in use. Define script groups, to handle scripts going away during document.open() and session history navigation. Define why and how setTimeout(), database transactions, etc, handle page transitions. Drop the terms 'with' and 'without' script, use script is 'enabled'/'disabled' instead. Define 'unload' and 'beforeunload'. Rework how onfoo= and .onfoo event handler attributes are defined. Rework how the content model of <noscript> is defined. Reword the way javascript: is defined to use the new terminology. Add a few notes of things that came up while I was doing all that.]] ( (2008-12-12 17:46:00 +09:00 版)) http://html5.org/tools/web-apps-tracker?from=2528&to=2529

[89] エデンの園でおきたこと - steps to phantasien ( (Hajime Morrita 著, 2014-02-17 18:13:31 +09:00 版)) http://steps.dodgson.org/b/2012/12/19/dom-and-gc-or-what-happend-at-eden/

[103] Bug 25223 – IDB exposes GC behavior ( (2015-01-15 11:34:59 +09:00 版)) https://www.w3.org/Bugs/Public/show_bug.cgi?id=25223

[104] Bug 26515 – Change when media elements may be garbage collected ( (2015-01-16 12:37:52 +09:00 版)) https://www.w3.org/Bugs/Public/show_bug.cgi?id=26515

[105] Specify life time management · Issue #15 · yutakahirano/fetch-with-streams (2015-01-30 15:05:19 +09:00 版) https://github.com/yutakahirano/fetch-with-streams/issues/15#issuecomment-72119046

[33] Feature suggestion - event from the JS Garbage Collector · Issue #238 · WebAssembly/design (2015-07-14 08:38:23 +09:00 版) https://github.com/WebAssembly/design/issues/238

[34] Add description for suspension, resuming and garbage collection · whatwg/fetch@1dfbd1f (2015-09-16 11:35:14 +09:00 版) https://github.com/whatwg/fetch/commit/1dfbd1f6284e4cb0aae91a8b9db36a2dc11393b1

[114] Move structured cloning out from under Common DOM Interfaces · whatwg/html@e09b782 (2016-03-01 11:48:47 +09:00 版) https://github.com/whatwg/html/commit/e09b7824480ffc9df69b0d830c4b8adad3b000d1

[115] Clarify settings object, realm, and global relationships · whatwg/html@0866f1b (2016-03-27 23:19:37 +09:00 版) https://github.com/whatwg/html/commit/0866f1b3f4b4ea5a99a30909e9bbe557dea0b460

[116] Custom elements disconnected from a document should not be upgraded · Issue #419 · w3c/webcomponents ( (2016-05-16 00:20:22 +09:00)) https://github.com/w3c/webcomponents/issues/419

[117] Workers: Curtail the browser's license to kill · Issue #1004 · whatwg/html (2016-06-24 21:27:19 +09:00) https://github.com/whatwg/html/issues/1004

[41] GC / DOM / Web API Integration :unicorn: - WebAssembly (2017-01-14 05:40:46 +09:00) http://webassembly.org/docs/gc/

[43] Abortable fetch (jakearchibald著, 2017-09-20 21:59:57 +09:00) https://github.com/whatwg/fetch/commit/0bcd5dfc71ef44319873887f4b83119bd6d0b71d

[121] Sensor must not expose GC behavior (pozdnyakov著, 2017-12-14 20:24:36 +09:00) https://github.com/w3c/sensors/commit/9fd7eeb7a69635ea9e3b0f4eb0402c677bba19e5

[122] Must not expose GC behavior to the web · Issue #337 · w3c/sensors (2017-12-15 17:05:46 +09:00) https://github.com/w3c/sensors/issues/337

[123] Sensor must not expose GC behavior by pozdnyakov · Pull Request #338 · w3c/sensors (2017-12-15 17:06:04 +09:00) https://github.com/w3c/sensors/pull/338

[124] Permit freeing underlying source / sink / transformer after close · Issue #932 · whatwg/streams (2018-07-04 21:48:49 +09:00) https://github.com/whatwg/streams/issues/932