path: root/files/ja/mozilla/projects/spidermonkey/internals/garbage_collection/index.html

---
title: Garbage collection
slug: Mozilla/Projects/SpiderMonkey/Internals/Garbage_collection
translation_of: Mozilla/Projects/SpiderMonkey/Internals/Garbage_collection
---
<div class="note">
 <strong>この文書について: これはSpiderMonkeyのGC内部についての雑多な草案です。内容が古いまたは不正確な場合があります。</strong></div>
<div class="warning">
 <p><strong>警告:</strong>SpiderMonkey ガベージコレクションTipsは悲しいことに古い内容であり、完全に無視されるべきものとなってしまいました、</p>
</div>
<h2 id="デザインの概要">デザインの概要</h2>
<p>SpiderMonkeyは、オプションでインクリメンタルマーキングモード（<span style="line-height: 1.5;">incremental marking mode）を有効にされたマーク &amp; スイープ方式のガベージコレクション（GC）を持っています。マークフェイズでは、インクリメンタルマーキングに必要なマークスタックを用います。ファイナライザを伴わないオブジェクトのスイープは、バックグラウンドスレッドにて実行されます。</span></p>
<p>世代別GCおよびコンパクションGC（compacting GC）の実装に向けた作業が進行中です。</p>
<p> </p>
<h2 id="主要なデータ構造">主要なデータ構造</h2>
<h3 id="Cell">Cell</h3>
<p><strong>Cell</strong> は、外部からも使用される、GCによって割当と回収が行われるメモリーの単位です。つまり、GC以外から見れば、GCの仕事はCellの割当と自動的な回収ということになります。</p>
<p>例えばJSObjectのように、CellはGCによって割り当てられる全てのクラスの基底クラスとなります。</p>
<h3 id="Allocation_Kind">Allocation Kind</h3>
<p>Cellは、Allocation Kindにより分類されます。Allocation Kindはオブジェクトのサイズおよびファイナライズの振る舞いを定義します。Allocation Kindは<strong>AllocKind列挙型</strong>によって定義されます。</p>
<p>Arenas always hold objects of the same allocation kind. Thus, an arena holds objects all of the same size and finalization behavior.</p>
<h3 id="Compartment">Compartment</h3>
<p>JSヒープはCompartmentに分割されます。Compartmentの要点は以下になります：</p>
<ul>
 <li>あらゆるCell（JSヒープオブジェクト）は、Compartmentのどれか一つに属します（ヒープはCompartmentに分類されることを意味します）。</li>
 <li>オブジェクトは、別のCompartment内のオブジェクトに対する直接のポインタを保持することはできません。代わりに、他のオブジェクト用のラッパーを保持することになります。ラッパーは、Compartment間のセキュリティチェックに用いられます。同じCompartment内のオブジェクトは同じアクセス権限を持っているため、セキュリティチェックの必要はありませんが、cross-compartment wrapper（Compartment間ラッパー）のトラバース時にチェックが行われるかもしれません。</li>
 <li>エンジンは同時にひとつのCompartmentのGCが可能です。同様に、エンジンは他をGCしている場合を除いて、Compartmentの集合に対してGCが可能です。cross-compartment wrapperは、ひとつないし複数のCompartmentのGCのrootとして用いられます。</li>
</ul>
<p>Compartmentは、SpiderMonkeyにおける、GCを含む特にメモリに関連した事項の構造的かつ分野横断的なコンセプトになっています。詳細は<a href="“/ja/SpiderMonkey/SpiderMonkey_compartments" title="https://developer.mozilla.org/ja/SpiderMonkey/SpiderMonkey_compartments">Compartments</a>を参照してください。</p>
<p><strong>JSCompartment</strong>はGCに関連した重要なフィールドを保持しています：</p>
<dl>
 <dt style="margin-left: 40px;">
  ArenaLists型 arenas</dt>
 <dd style="margin-left: 40px;">
  この構造体は、それぞれのAllocation KindのArenaの2つのリストを記録しています。未使用のArenaのリストと、割当済みのArenaのリストです。</dd>
 <dt style="margin-left: 40px;">
  bool型 needsBarrier</dt>
 <dd style="margin-left: 40px;">
  このCompartmentにおけるGCが、インクリメンタルバリアの実行を必要とする場合にtrueとなります。すなわり、このCompartmentが現在インクリメンタルGCを実行しているかどうかを表します。</dd>
 <dt style="margin-left: 40px;">
  CompartmentGCState型 gcState</dt>
 <dd style="margin-left: 40px;">
  このCompartmentが現在GCを実行しているかどうかを表します。もし実行していなければ、GCの実行がスケジュールされているかを表します。</dd>
 <dt style="margin-left: 40px;">
  size_t型 gcBytes, gcTriggerBytes, gcMallocBytes, gcMaxMallocBytes</dt>
 <dd style="margin-left: 40px;">
  GCのスケジュールに使用される情報を表します</dd>
 <dt style="margin-left: 40px;">
  WrapperMap型 crossCompartmentWrappers</dt>
 <dd style="margin-left: 40px;">
  このCompartment内のオブジェクトのラッパーの集合です。Mapのキーはオブジェクト、値はラッパーです。同じオブジェクトに対するラッパーが複数回要求される場合、エンジンが同一のラッパーを毎回返せるようにするためにマッピングが必要とされます。ラッパーオブジェクトの集合は同様に、単一および複数のcompartmentの（non-globalな）GCにおいても必要となります</dd>
</dl>
<h3 id="Zone">Zone</h3>
<p>TODO（原文ママ）</p>
<h3 id="Chunk">Chunk</h3>
<p>Chunkはメモリの割当における最大の内部単位となります。</p>
<p>Chunkは1MBのサイズを持ち、内部にArena、パディング、Mark Bitmap（ChunkBitmap）、解放されたArenaのビットマップ、およびChunkヘッダ（ChunkInfo）を保持しています。</p>
<p>ChunkInfoは、ChunkInfo::freeArenasHeadから開始しており、ArenaHeader::nextを介してリンクしている未割当のArenaのリストを保持します。また、ChunkInfoは未割当のArenaの数の基本的な情報を保持しています。</p>
<p>TODO ChunkInfo next/prev（原文ママ）</p>
<h3 id="Arena">Arena</h3>
<p>Arenaはメモリ割当の内部単位です。</p>
<p>Arenaは1ページ（ほぼ全てのプラットフォームで4096バイト）の大きさであり、ArenaHeaderと、僅かなパディングとなるバイト領域と、整列された要素の配列を含みます。Arena内のすべての要素は、同じAllocation Kindとサイズを持ちます。</p>
<p>すべてのArenaは、ArenaHeader::firstFreeSpanOffetsから始まる自由なメモリ区間のリストを保持します。自由なメモリ区間の最後のCell（最後であるのが望ましい）は、次の自由なメモリ区間を表すFreeSpanを保持します。</p>
<h3 id="Free_Span">Free Span</h3>
<p><strong>構造体<code>FreeSpan</code></strong>は、Arena内の自由なCell <strong>[first, last]</strong>の連続を表します。FreeSpanは、自由なメモリ区間から割当を行うための関数を保持しています。</p>
<h3 id="Mark_Bitmap">Mark Bitmap</h3>
<p>マークビットマップは<strong>ChunkBitmap</strong>によって表されます。</p>
<p>マークビットマップはGC Cellごとのビットを持ちます。故に、複数のCellによって構成されているオブジェクトは、ビットマップ中の複数のビットを使います。</p>
<h2 id="Exact_Stack_Rooting_API">Exact Stack Rooting API</h2>
<div class="note">
 <p><strong>注</strong>:GC rootの実装とおよびSpiderMonkey内での使用についての情報となります。SpiderMonkeyを埋め込んで使う場合の、Rooting APIの使用方法については、<a href="“/ja/docs/SpiderMonkey/GC_Rooting_Guide" title='“/ja/docs/SpiderMonkey/GC_Rooting_Guide"'> GC Rooting Guide</a>を参照してください。</p>
</div>
<p>GC rootの実装とおよびSpiderMonkey内での使用についての情報となります。 <a href="/en-US/docs/SpiderMonkey/Internals/GC/Exact_Stack_Rooting" title="/en-US/docs/SpiderMonkey/Internals/GC/Exact_Stack_Rooting">Exact Stack Rooting</a>.</p>
<h2 id="マーキング">マーキング</h2>
<p>TODO（原文ママ）</p>
<h2 id="インクリメンタルマーキング">インクリメンタルマーキング</h2>
<p>インクリメンタルマーキングは、マーキングの最中に（JavaScriptプログラムによる）状態の変更が発生しても、他のマーキング作業の実行が可能であることを意味します。つまり、マーキングによる長時間のプログラムの実行の停止の代わりに、小さな停止の集まりがGCの実行となるのです。停止時間は10msもしくはそれ以下に抑えられます。</p>
<p>長時間の停止が必要となる可能性も常に存在します。インクリメンタルGCの間のメモリ割当の頻度が高い場合、エンジンはインクリメンタルGCの完了の前にout of memoryを実行するかもしれません。そのような場合、エンジンは幾つかのメモリーの返還とプログラムの実行の継続のために、非インクリメンタルな完全なGCを直ちに再実行しなくてはなりません。</p>
<h3 id="Incremental_write_barrier（インクリメンタル書き込みバリア）">Incremental write barrier（インクリメンタル書き込みバリア）</h3>
<h4 id="write_barrierを必要とする問題">write barrierを必要とする問題</h4>
<p>インクリメンタルGCは正確性の担保のためにwrite barrierを必要とします。</p>
<p>TODO（原文ママ）、基本的な問題を表す図を用意する<img alt="Very poor diagram showing IGC hazard that requires a write barrier" src="https://mdn.mozillademos.org/files/5187/IGC-hazard.png" style="width: 640px; height: 400px;"></p>
<p>基本的な問題は以下の通りです（色の説明については、辞書を参照）。オブジェクトAはblackかつポインタ領域を所持しています。オブジェクトBはwhiteとします。ここで、インクリメンタルなスライスが止まり、プログラムの実行による状態の変更が再開しました。プログラムがBをAに保存したことにより、AはBへのポインタを持つことになります。そして、Bへのすべての既存のポインタが削除されました。そのとき、</p>
<ul>
 <li>Bは生存している。なぜならAはblackであり、Bへのポインタを含んでいるから。</li>
 <li>Bはマーク作業が実行されない。なぜならBはAを介してのみ到達可能であり、Aがblackである故にAはすでにマーク作業が完了しているから。</li>
 <li>以上により、Bは生存しているが、GCの回収対象となってしまう。</li>
</ul>
<p>write barrierは、ポインタの保存の発生前に実行され、生存しているオブジェクトが回収されないようにするために情報を記録する機構の一つです。</p>
<h4 id="SpiderMonkeyのincremental_write_barrier">SpiderMonkeyのincremental write barrier</h4>
<p>SpiderMonkeyは、（相対的に）シンプルな、s<strong>snapshot-at-the-beginning allocate-black barrier</strong>と呼ばれる一般的なincremental write barrierを用いています。</p>
<p>このバリアの動作を理解するために、事象を単純にするために、新規にオブジェクトが割り当てられることの無いインクリメンタルGCを仮定します。生存しているオブジェクトを回収しないようにするためにはどうすればよいでしょうか？　一つの方法としては、インクリメンタルGCの最初の時点で生存していたすべてのオブジェクトをマークするという手法があります（これは、オブジェクトへの全ての参照が現在のインクリメンタルGC中に消えた場合は、次のインクリメンタルGC時にそのオブジェクトが回収されるということです）。この手法は、インクリメンタルGCの開始時に生存しているオブジェクトのスナップショットを保存し、それら全てをマークするのと<em>コンセプト上は</em>同義であるために、<strong>snapshot-at-the-beginning</strong>と呼ばれています。実際にはスナップショットを撮る訳ではありません。そのような場合は完全な非インクリメンタルなマーク作業が必要となります。</p>
<p style="">snapshot-at-the-beginningバリアの実装は単純です。GCポインタを保持する場所がプログラムによって上書きされたタイミングで、バリアは開始します。バリアは単純にポインタによって指し示されているオブジェクトをblackにします。鍵となるのは、オブジェクトへの全てのポインタが上書きされた場合にのみ、オブジェクトはマークされず”死んだもの”となりうるという点です。そのため、オブジェクトへのポインタが上書きされたタイミングでオブジェクトをblackにすれば、オブジェクトが”死ぬ”ということは発生し得ないのです。</p>
<p style="">FIXME（原文ママ）:指し示されたオブジェクトをblackにするだけは十分ではないと思います。マークされていない別のオブジェクトがあったら何がおこりますか？　マークスタックについても言及すべきです。「指し示されているオブジェクトをblackにする」というのは、「再帰的に指し示されたオブジェクトをblackにする」という意味で書かれていますか？</p>
<p>これで、メモリの割当の正確性についても話します。新規に割り当てられたオブジェクトはGCの開始時には存在していませんでした。snapshot-at-the-beginningバリアはこれについては巧くカバーしません。ですが、もし新規に割り当てられたオブジェクトが生存している場合は、それが回収されないようにする必要があります。これは簡単で、インクリメンタルGC中に新規にオブジェクトが割り当てられたら、それをマークすれば良いのです。これを名付けて<strong>allocate-black</strong>と言います。</p>
<h4 id="SpiderMonkeyの_incremental_read_barrier（インクリメンタル読み取りバリア）">SpiderMonkeyの incremental read barrier（インクリメンタル読み取りバリア）</h4>
<p>インクリメンタルGCの教科書的な実装では、write barrierしかありません。SpiderMonkeyでは、weak pointer（用語集参照）のためにread barrierも用意しています。</p>
<p>TODO（原文ママ）：解説の完成</p>
<h4 id="実装の詳細">実装の詳細</h4>
<p>write barrierは実行時のコストを伴うので、SpiderMonkeyはインクリメンタルGCの実行中以外ではスキップするようにしています。各compartmentの<code>needsBarrier()</code>フラグによって、バリアが必要かどうかを示しています。</p>
<p><code>T*</code>型のフィールドのように、全ての<code>T</code>型はwrite barrierを必要としており、<code>T::writeBarrierPre(old)</code>という関数が存在しています。たとえば、<code>JSObject*</code>がwrite barrierを必要とする場合、関数<code>ObjectImpl::writeBarrierPre(ObjectImpl *old)</code>が存在します（<code>JSObject</code>は<code>ObjectImpl</code>を継承しています。）。 <code><strong>zone-&gt;needsBarrier()</strong></code>がtrueである場合、<code>writeBarrierPre()</code>は<code>old</code>をマークする、ということです。</p>
<p>HeapPtr&lt;t&gt;クラスはwrite barrierの起動を簡単にするために提供されています。HeapPtr&lt;t&gt;は<strong><code>T*</code></strong>をカプセル化し、割当時にwrite barrierを起動します。これにより、GCポインタ型のオブジェクトの領域は、通常、HeapPtr&lt;T&gt;&lt;t&gt;として定義されています。<strong>HeapValue</strong>クラスはValueに対して同じことを行います。<strong>HeapSlot</strong>（および関連する<strong>HeapSlotArray</strong>）も同様に、オブジェクトスロットに対するものです。<strong>HeapId</strong>は、同じくjsidに対する物です。TODO（原文ママ）：なぜHeapValueとHeapSlotの2つが存在するのか&lt;/t&gt;&lt;/t&gt;&lt;/t&gt;</p>
<p>オブジェクトのプライベート領域は、特別に取り扱う必要があります。プライベート領域自体は、エンジンに対しては隠されていますが、マークされる必要があるものを指し示すかもしれません（例：JSObjectのポインタの配列）。この例では、プライベート領域が上書きされた場合、JSObjectのポインタは”死ぬ”ことになります。そのため、write barrierはそれらをマークしなければなりません。<strong>ObjectImpl::privateWriteBarrierPre</strong>はプライベート領域が上書きされる前にJSObjectクラスのトレースフックによって起動され、これに対処します。</p>
<p>他の詳細事項として、write barrierは新規に確保されたオブジェクトのフィールドの初期化時には、上書きされるポインタが存在しないことから、スキップすることができます。</p>
<h2 id="Sweeping（スイーピング）">Sweeping（スイーピング）</h2>
<p>TODO（原文ママ）</p>
<h2 id="世代別GC">世代別GC</h2>
<p>TODO（原文ママ）</p>
<h2 id="GC統計API">GC統計API</h2>
<p>実行時に<a href="“/ja/docs/SpiderMonkey/Internals/GC/Statistics_API" title='“/ja/docs/SpiderMonkey/Internals/GC/StatisticsAPI"'>GC統計API</a>.を通じて、GCが保持する明確な統計情報にアクセスする事ができます。</p>
<h2 id="ソースファイル">ソースファイル</h2>
<p><strong>jsgc{.h,inlines.h,.cpp}</strong> GCを起動するためのエントリーポイントを含む内部API関数群を定義します。</p>
<p><strong>jsgcstats.{h,cpp}</strong> 保守的なスタックスキャンに基づく情報収集のための構造体ConservativeGCStatsを定義します。TODO（原文ママ）：削除されたときに消す</p>
<p><strong>gc/Barrier[-inl].h</strong> インクリメンタルおよび世代別用のwrite barrierを実装しています。</p>
<p><strong>gc/Heap.h</strong> GCのヒープ構造の根幹を成す、<code>Chunk</code>, <code>ChunkInfo</code>, <code>ChunkBitmap</code>, <code>Arena</code>, <code>ArenaHeader</code>, <code>Cell</code>, <code>FreeSpan</code>といった一連の構造体を定義します。</p>
<p><strong>gc/Marking.{h,cpp}</strong> 多様なGC対象用のマーク作業関数の全てを定義します。</p>
<p><strong>gc/Memory.{h,cpp}</strong> ページの配置と解放（mapping and unmapping）のための僅かな関数に加えて、プラットフォーム固有の実装を保持しています。配置・解放（map/unmap）用の関数はチャンクの確保と解放（allocate and release ）用のために、 jsgc.cppによって使用されています。使用されておらずディスクに格納する代わりメモリ破棄が可能なページをOS伝えるなどに用いる、確保または解放（commit or decommit）のための関数もあります。</p>
<p><strong>gc/Root.h</strong> GCルートとして用いられる変数クラスを定義します。</p>
<p><strong>gc/Statistics.{h,cpp}</strong> SpiderMonkey GCのパフォーマンスカウンタとして保存される Statics構造体を定義しています。</p>
<h2 id="用語の解説">用語の解説</h2>
<p>TODO（原文ママ）: SpiderMonkeyの実装と色の名前が一致しているかを確認</p>
<p><strong>black（黒）</strong>一般的な計算機科学の文脈において、マークフェイズ中、マーク済かつ子供がgray（マークキューに積まれている）なオブジェクトをblackとします。SpiderMonkeyでは、マークビットが設定されたオブジェクトをblackと見なします。</p>
<p><strong>gray（灰色）</strong>：一般的な計算機科学の文脈において、マークフェイズ中、マークキューに積まれているオブジェクトをgrayとします。SpiderMonkeyでは、マークスタック内のオブジェクトの子孫かつblackで無いものはgrayとなります。つまり、状態が明白でないオブジェクトがgrayであるということです。</p>
<p><strong>Handle（ハンドル）</strong> 私たちのGCでは、Handleはルートによって登録されたどこかを指し示すポインタです。</p>
<p><strong>root</strong> TODO（原文ママ）: 上からコピーする</p>
<p><strong>weak pointer（弱参照ポインタ）</strong> 一般的な計算機科学の文脈において、weak pointerはGC目的で指し示された値が生存し続ける必要がなくなるポインタです。具体的には、既にポインタの指し示す対象が既にGCされている場合は、weak pointerのget()メソッドが返す値はnullポインタとなります。Gecko/SpiderMonkeyでは、weak pointerはマークされていないがGC対象となりうるオブジェクトへのポインタとなります。そのため、get()メソッドは存在せず、指し示す値がGCされたかどうかの保証も存在しません。プログラマは、指し示されたオブジェクトの生存時間が、weak pointerの生存時間よりも長いことを保証する必要があります。TODO（原文ママ） これが正しいか確認。</p>
<p><strong>white（白）</strong> 一般的な計算機科学の文脈において、マークフェイズ中、まだ辿れていないオブジェクトはwhiteとなります。マークされなかった場合、マークフェイズの後にオブジェクトはwhiteとなります。SpiderMonkeyでは、grayでもblackでもない（blackでもマークスタック内のオブジェクトの子でもない）オブジェクトがwhiteとなります。</p>
<h2 id="クリーンアップの可能性">クリーンアップの可能性</h2>
<p><strong>MarkPagesInUse</strong> はすべてのプラットフォームで何の操作も実施しません。</p>
<p>統計ファイルのマージ。</p>
<p><code>ArenaLists::refillFreeLists</code>は悪いネーミングです。それは、たとえ<code>Arena</code>の解放リストが完全ではなくても、<code>Cell</code>の確保を試みるように見えます。</p>