Downloaded 118 times
Recommended
More Related Content
Similar to dalvikのGCをのぞいてみた
dalvikのGCをのぞいてみた
- 1.dalvik の GCをのぞいてみた @akachochin
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.おさらい1 - GCとヒープヒープとは、プログラムが動作中に必要に応じてメモリが欲しくなったときに使うためのメモリ領域である。
- 12.
- 13.
- 14.おさらい2 - もしGCがなかったらGCがない環境でヒープが欲しくなった場合、明示的にヒープ割り当て要求(Ex.malloc())を行い、ヒープが必要なくなった時点で明示的に解放(free())する。
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.ヒープ内で使われているオブジェクトを探して印をつけます。 ヒープ内のオブジェクトの参照を順番にたどって、印をつけていき (マークフェーズ ) ・・・ 印 印 印 印
- 23.前提1 -マーク＆スイープ- ヒープをサーチして、使われてないヒープを解放(スイープフェーズ)する。ヒープを先頭からサーチし、印のついてないヒープを解放していきます。 ※ サーチの過程で「印」は消しますが、図のわかりやすさのため、「印」を残しています。 印 印 印 印 解放 解放 解放
- 24.前提2 – ルート- 先の「マークフェーズ」で「使われているオブジェクトを順番にたどって」と書きました。
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.vm/alloc/HeapSource.c: dvmCollectGarbageInternal(false,GC_CONCURRENT);
- 31.GCをしているのはどこ? 見つけた箇所はstatic void*gcDaemonThread()という関数の中。
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.ソースを眺めてみると、 GC を呼び出した理由によって処理を変えている。今回はGC_CONCURRENT なケースにスポットを当てて説明します。
- 38.
- 39.
- 40.2.GC の処理中に VM内の他のスレッド ( ミューテータ ) が動けるようにする処理 (dvmResumeAllThreads(SUSPEND_FOR_GC);) がある。
- 41.-> 普通は GCを行う場合、 VM 内の他のスレッドがメモリの状態を変えて欲しくないので、 GC を行うスレッド以外の動きを止めたいはず。
- 42.dvmCollectGarbageInternal けれど、 13ページに書いた 2 つの処理によって他のスレッドが動けるようになるため、通常の VM の様に「処理が固まる」割合が減る。
- 43.
- 44.コンカレントな GC のイメージ通常処理 通常処理 GC 通常処理 通常処理 通常処理
- 45.ここで突然 ここで一旦 dvmCollectGarbageInternalを離れて、 メモリ割り当ての関数(dvmMalloc())を読んでみます。
- 46.
- 47.
- 48.
- 49.
- 50.dvmMalloc() dvmMalloc() ->tryMalloc() ->dvmHeapSourceAlloc()をコールします。
- 51.
- 52.
- 53.
- 54.
- 55.
- 56.
- 57.
- 58.GCに関係したデータ構造 GcHeap 構造体グローバルなヒープに関する情報 HeapSource MarkContext GcMarkContext 構造体 現在やっているGCの状態 HeapSource 構造体 ヒープ空間に関する情報 liveBits markBits liveBits MarkContext bitmap stack finger この2つのビット マップがとても重要
- 59.bitmap系データ構造 ビットマップ (liveBits,MarkBits)の各ビットと「ヒープ内を 8byte ごとに区切った空間」がそれぞれ図のように対応している。 これによって、 8byte ごとの各ヒープ空間の状況を記録する。 liveBits MarkBits ヒープ領域 ひとつのビットは ヒープ8byte領域に 対応している ・・・・ ・・・・
- 60.
- 61.例えば灰色のヒープ24byteを割り当てた場合はliveBitsは以下の様になる。 1 liveBitsヒープ領域 割り当てた領域の 先頭に対応した ビットを1にする ・・・・
- 62.
- 63.
- 64.とにかく、 ヒープを割り当てると、 liveBitsを立てる、というのが重要 。
- 65.再び dvmCollectGarbageInternal (処理概要 1) dvmCollectGarbageInternalはおおよそ、以下のことを行ってコンカレントGCを行っている。
- 66.
- 67.
- 68.
- 69.
- 70.
- 71.再び dvmCollectGarbageInternal (処理概要 2) 6.他スレッドを動けないようにする(suspend) 7.再度ルートをチェックして印をつける 8.再度マークのついたオブジェクトからたどって印をつける 9.不要なヒープを解放する。 10.他スレッドが動けるようにする(resume)
- 72.再び dvmCollectGarbageInternal (話の構成 ) これからは、以下の構成で話を進めてみます。
- 73.
- 74.
- 75.
- 76.
- 77.dvmCollectGarbageInternal ( ルートのみに印をつける) dvmHeapMarkRootSet()をコールして、ルートに印をつける。
- 78.
- 79.
- 80.dvmCollectGarbageInternal ( ルートのみに印をつける) markClassObject()はdvmMarkObjectNonNull - markObjectNonNullを呼び出す。 この中では、setAndReturnMarkBit()にmarkbitとobjを渡す。objのアドレスに対応したmarkbitに印をつける(1を立てる) 1 MarkBits ヒープ領域 使われている領域の 先頭に対応した ビットを 1 にする ・・・・
- 81.dvmCollectGarbageInternal ( ルートのみに印をつける) dvmCollectGarbageInternal() から dvmClearCardTable() を呼び出し、 CardTable を 0 クリアする。この時点では詳細は割愛しますが、押えてほしいポイントは二つ。 1. ひとつの cardTable はある特定のヒープメモリ 128byte に対応する。
- 82.2. ヒープメモリ上のオブジェクトが保持する他のオブジェクト参照の変更などの事象が発生すると、対応する cardTableは「 Darty 」な状態になる。
- 83.dvmCollectGarbageInternal ( ルートのみに印をつける) cardtable と livebit の関係 cardTable ・・・・ liveBits アドレス情報の変更 などでヒープ上の オブジェクトが変更 されると「Darty」 な状態になる ・・・・ livebit16個(ヒープ 128byte)が一つの CardTableに対応する
- 84.dvmCollectGarbageInternal ( 印のついたオブジェクトをたどる) dvmHeapScanMarkedObjects()を呼び出す。
- 85.
- 86.
- 87.
- 88.
- 89.
- 90.
- 91.dvmCollectGarbageInternal ( 印のついたオブジェクトをたどる) dvmHeapBitmapScanWalk()
- 92.まず最初にmarkBitをたどって印のついた箇所を見つけます。 1 markBitsヒープ領域 LiveBitをたどって 1を見つけた！ ・・・・
- 93.dvmCollectGarbageInternal ( 印のついたオブジェクトをたどる) 次にその領域の先頭をみます。例えばJavaオブジェクトの場合は以下のとおりです。 ヒープ領域 ・・・・ ヒープの 別領域 ヒープの 別領域 Javaオブジェクトの 場合、各メンバへの アドレスを保持して いる。
- 94.dvmCollectGarbageInternal ( 印のついたオブジェクトをたどる) 見つけたヒープアドレスが、現在探索対象のヒープアドレス (finger) よりも大きなアドレス値の場合、 markBits の対応ビットに 1 を立てる。 ヒープ領域 ・・・・ 1 markBits 現在検索対象の 次のビットは 「finger」という markBitsの該当 ビットに印 ・・・・ 1 参照
- 95.dvmCollectGarbageInternal ( 印のついたオブジェクトをたどる) 該当領域内で見つけたヒープアドレスが、 finger よりも小さなアドレス値の場合、 markbit のビットに 1 を立てないで、 stack というデータ構造内にアドレスを保存する。 ヒープ領域 ・・・・ markBits finger markBitsの該当 ビットに 印を つけない ・・・・ 1 参照
- 96.dvmCollectGarbageInternal ( 後回しにしたオブジェクトに印) Stackに貯めてあるアドレスに対応したmarkBitに印をつけていきます。
- 97.
- 98.
- 99.
- 100.
- 101.dvmCollectGarbageInternal ( 後回しにしたオブジェクトに印) stack データ構造 ヒープ領域 他のアドレスを 参照しているか 調べる 1 markBits アドレス値 他領域を参照する アドレス値 アドレス値をひとつ取り出す 見つけたアドレス値を突っ込む アドレス値を参照している場合
- 102.dvmCollectGarbageInternal ( 再度印をつける) 31ページから36ページの処理を行っている間はミューテータが動けるため、ヒープの状態が変わる可能性がある。
- 103.
- 104.dvmCollectGarbageInternal ( 再度印をつける) dvmHeapReMarkRootSet()を呼び出す。
- 105.
- 106.dvmCollectGarbageInternal ( 再度印をつける) dvmHeapReScanMarkedObjects()を呼び出し、ルート以外のヒープのうち、変更のあった箇所に印をつけます。
- 107.
- 108.
- 109.dvmCollectGarbageInternal ( 再度印をつける) 29ページ、30ページで説明したcardTableを覚えていますか？ 右の図のように、対応するヒープメモリ128byte上にあるオブジェクトのアドレス情報が変更されるなどすると、cardTableはDartyになります。 A B C 今までオブジェクトBを参照して いたが、今度はオブジェクトB でなくオブジェクトCを参照 するようになった。
- 110.dvmCollectGarbageInternal ( 再度印をつける) 以下の図のように変更された可能性の高いヒープ領域を見付だし、該当領域内の全てのオブジェクトに再度印をつけなおします。 ・・・・・・ ・・・ cardTable 変更された 領域発見！ ・・・ オブジェクト をサーチ markbits
- 111.dvmCollectGarbageInternal ( 再度印をつける) こうすることで、全てのmarkbitをたどらなくてもよくなるため、変更された可能性のあるオブジェクトをより少ない手間で絞り込めます。
- 112.dvmCollectGarbageInternal ( 不要なヒープを解放する) これでいよいよ不要なヒープを解放する準備ができました。
- 113.
- 114.
- 115.dvmCollectGarbageInternal ( 不要なヒープを解放する) ここでもう一度復習。 ・・・ markbits ・・・ livebits 割り当て済みメモリ の先頭アドレスにあたる ビットは1 GCの時点で使われている メモリ領域は1
- 116.dvmCollectGarbageInternal ( 不要なヒープを解放する) この二つのビットマップを使って「割り当てされたけど、今は使われていない」ヒープ位置を割り出します。そのために以下のようなビット演算を行います。
- 117.live & ~marklive ~mark & 意味 0 0 0 初めから割り当てられていない もしくは割り当てられた領域の途中 0 1 0 これはありえない 1 0 0 割り当てられて、今も使われている 1 1 1 割り当てられたけど、今は使われていない
- 118.dvmCollectGarbageInternal ( 不要なヒープを解放する) 46ページで新たに作成したビットマップで1が立っている箇所に対応したアドレスを求めて(DECODE_BITSマクロ)、ビットが立っている箇所に対して解放処理を呼び出す。
- 119.
- 120.
- 121.まとめ DalvikのGCはMark &Sweepでした。
- 122.
- 123.
- 124.
- 125.
- 126.