ガベージコレクション

[アーティクル]
07/13/2023

Xamarin.Android では、Mono の Simple Generational ガベージコレクターが使用されます。これは、2 種類のコレクションを含む、2 つの世代と大きなオブジェクト空間を持つマークアンドスイープガベージコレクターです。

マイナーコレクション (Gen0 ヒープを収集)
メジャーコレクション (Gen1 と大きなオブジェクト領域ヒープを収集します)。

Note

GC による明示的なコレクションがない場合。Collect() コレクションは、 ヒープ割り当てに基づいてオンデマンドで実行されます。 これは参照カウントシステムではありません。未処理の参照がない場合、またはスコープが終了すると、オブジェクトは収集されません。新しい割り当てのためにマイナーヒープのメモリが不足すると、GC が実行されます。割り当てがない場合、実行されません。

マイナーコレクションは安価で頻繁であり、最近割り当てられたオブジェクトとデッドオブジェクトを収集するために使用されます。マイナーコレクションは、割り当てられたオブジェクトの数MB (メガバイト)ごとに実行されます。マイナーコレクションは、GC を呼び出すことによって手動で実行できます。収集 (0)

メジャーコレクションはコストが高く、頻度が低く、すべてのデッドオブジェクトを回収するために使用されます。メジャーコレクションは、(ヒープのサイズを変更する前に) 現在のヒープサイズに対してメモリが使い果たされると実行されます。メジャーコレクションは、GC を呼び出すことによって手動で実行できます。() を収集するか、GC を呼び出します。引数 GC を使用して (int) を収集します。MaxGeneration。

VM 間オブジェクトコレクション

オブジェクトの種類には 3 つのカテゴリがあります。

マネージドオブジェクト: Java.Lang.Object から継承されない型 (System.String など)。これらは通常、GC によって収集されます。
Java オブジェクト: Android ランタイム VM 内に存在するが Mono VM に公開されていない Java 型。これらは退屈であり、これ以上説明しません。これらは通常、Android ランタイム VM によって収集されます。
ピアオブジェクト: IJavaObject を実装する型 (すべての Java.Lang.Object サブクラスや Java.Lang.Throwable サブクラスなど)。これらの型のインスタンスには、マネージドピアとネイティブピアの "半分" が 2 つあります。マネージドピアは、C# クラスのインスタンスです。ネイティブピアは Android ランタイム VM 内の Java クラスのインスタンスであり、C# IJavaObject.Handle プロパティにはネイティブピアへの JNI グローバル参照が含まれています。

ネイティブピアには、次の 2 種類があります。

フレームワークピア: Xamarin.Android の何も認識しない "Normal" Java 型 (android.content.Context など)。
ユーザーピア : アプリケーション内に存在する Java.Lang.Object サブクラスごとにビルド時に生成される Android 呼び出し可能ラッパー。

Xamarin.Android プロセス内には 2 つの VM があるため、次の 2 種類のガベージコレクションがあります。

Android ランタイムコレクション
Mono コレクション

Android ランタイムコレクションは正常に動作しますが、注意が必要です。JNI グローバル参照は GC ルートとして扱われます。そのため、Android ランタイム VM オブジェクトを保持している JNI グローバル参照がある場合、コレクションの対象であっても、オブジェクト を収集することはできません 。

Mono コレクションは、楽しみが起こる場所です。マネージドオブジェクトは通常どおり収集されます。ピアオブジェクトは、次のプロセスを実行して収集されます。

Mono コレクションの対象となるすべてのピアオブジェクトには、JNI グローバル参照が JNI 弱いグローバル参照に置き換えられます。
Android ランタイム VM GC が呼び出されます。任意のネイティブピアインスタンスを収集できます。
(1) で作成された JNI 弱いグローバル参照はチェック。弱参照が収集されている場合は、Peer オブジェクトが収集されます。弱参照が 収集されていない 場合、弱参照は JNI グローバル参照に置き換えられ、Peer オブジェクトは収集されません。注: API 14 以降では、GC の後に返される IJavaObject.Handle 値が変更される可能性があることを意味します。

このすべての最終的な結果は、Peer オブジェクトのインスタンスが、マネージドコード (変数に格納されているなど) または Java コードによって参照されている static 限り存続します。さらに、ネイティブピアとマネージドピアの両方が収集可能になるまで、ネイティブピアは収集できないため、ネイティブピアの有効期間はそれ以外の場合の有効期間を超えて拡張されます。

オブジェクトサイクル

ピアオブジェクトは、Android ランタイムと Mono VM の両方に論理的に存在します。たとえば、 Android.App.Activity マネージドピアインスタンスには、対応する android.app.Activity Framework ピア Java インスタンスがあります。 Java.Lang.Object から継承するすべてのオブジェクトには、両方の VM 内に表現が含まれている必要があります。

両方の VM で表現を持つすべてのオブジェクトは、1 つの VM 内にのみ存在するオブジェクト (たとえば System.Collections.Generic.List<int>、 GC の呼び出し。 Xamarin.Android GC では、収集する前にオブジェクトがいずれかの VM によって参照されないようにする必要があるため、収集はこれらのオブジェクトを必ずしも収集する必要はありません。

オブジェクトの有効期間を短縮するには、 Java.Lang.Object.Dispose() を呼び出す必要があります。これにより、グローバル参照を解放することで、2 つの VM 間のオブジェクトの接続が手動で "切断" されるため、オブジェクトをより高速に収集できます。

自動コレクション

リリース 4.1.0 以降では、Gref しきい値を超えると、Xamarin.Android によって完全な GC が自動的に実行されます。このしきい値は、プラットフォームの既知の最大 grefs の 90% です。エミュレーターでは 1800 grefs (最大 2000)、ハードウェアでは 46800 grefs (最大 52000) です。注: Xamarin.Android では、Android.Runtime.JNIEnv によって作成された grefs のみがカウントされ、プロセスで作成された他の grefs については認識されません。これはヒューリスティック のみです。

自動収集が実行されると、次のようなメッセージがデバッグログに出力されます。

I/monodroid-gc(PID): 46800 outstanding GREFs. Performing a full GC!

この発生は非決定的であり、不都合な時間 (グラフィックスレンダリングの途中など) に発生する可能性があります。このメッセージが表示された場合は、他の場所で明示的なコレクションを実行するか、ピアオブジェクトの有効期間を短縮したい場合があります。

GC ブリッジオプション

Xamarin.Android では、Android と Android ランタイムを使用した透過的なメモリ管理が提供されます。これは、GC ブリッジと呼ばれる Mono ガベージコレクターの拡張機能として実装されます。

GC ブリッジは Mono ガベージコレクション中に機能し、Android ランタイムヒープで検証された "ライブ性" が必要なピアオブジェクトを確認します。 GC ブリッジは、次の手順 (順番に) を実行して、この決定を行います。

到達できないピアオブジェクトのモノラル参照グラフを、それらが表す Java オブジェクトに誘導します。
Java GC を実行します。
どのオブジェクトが本当に死んでいるかを確認します。

この複雑なプロセスは、サブクラスが任意の Java.Lang.Object オブジェクトを自由に参照できるようにするためです。Java オブジェクトを C# にバインドできる制限を取り除きます。この複雑さのため、ブリッジプロセスは非常にコストがかかり、アプリケーションで顕著な一時停止を引き起こす可能性があります。アプリケーションで大幅な一時停止が発生している場合は、次の 3 つの GC ブリッジ実装のいずれかを調査する価値があります。

Tarjan - Robert Tarjan のアルゴリズムと後方参照伝達に基づく GC ブリッジのまったく新しい設計。これは、シミュレートされたワークロードで最高のパフォーマンスを発揮しますが、実験用コードのシェアも大きくなります。
新規 - 元のコードを大幅に見直し、2 次的な動作の 2 つのインスタンスを修正しますが、コアアルゴリズムを維持します (厳密に接続されたコンポーネントを見つけるためのKosarajuのアルゴリズムに基づきます)。
古い - 元の実装 (3 つのうち最も安定と見なされます)。これは、一時停止が許容される場合にアプリケーションが GC_BRIDGE 使用する必要があるブリッジです。

どの GC ブリッジが最適かを判断する唯一の方法は、アプリケーションで実験し、出力を分析することです。ベンチマークのためにデータを収集するには、次の 2 つの方法があります。

ログ記録を有効にする - 各 GC ブリッジオプションのログ記録 (構成セクションで説明) を有効にしてから、各設定のログ出力をキャプチャして比較します。各オプション ( GC 特にメッセージ) のメッセージを GC_BRIDGE 調べます。非対話型アプリケーションの場合、最大 150 ミリ秒の一時停止は許容できますが、非常に対話型のアプリケーション (ゲームなど) では 60 ミリ秒を超える一時停止が問題になります。
ブリッジアカウンティング を有効にする - ブリッジ会計では、ブリッジプロセスに関係する各オブジェクトが指すオブジェクトの平均コストが表示されます。この情報をサイズで並べ替えることで、最大の量の余分なオブジェクトを保持しているものに関するヒントが提供されます。

既定の設定は Tarjan です。回帰が見つかると、このオプションを [古い] に設定する必要がある場合があります。また、Tarjanがパフォーマンスの向上を生み出さない場合は、より安定した古いオプションを使用することもできます。

アプリケーションで使用するGC_BRIDGEオプションを指定するには、環境変数を渡すか、bridge-implementation=new環境変数bridge-implementation=tarjanにMONO_GC_PARAMS渡bridge-implementation=oldします。これは、ビルドアクションAndroidEnvironmentを使用して新しいファイルをプロジェクトに追加することによって実現されます。次に例を示します。

MONO_GC_PARAMS=bridge-implementation=tarjan

詳細については、構成に関するページを参照してください。

GC の支援

GC を使用してメモリ使用量と収集時間を短縮するには、複数の方法があります。

ピアインスタンスの破棄

GC はプロセスの不完全なビューを持ち、メモリが少ない場合は実行されない可能性があります。これは、GC がメモリが不足していることを認識していないためです。

たとえば、Java.Lang.Object 型または派生型のインスタンスのサイズは 20 バイト以上です (予告なく変更される場合など)。マネージド呼び出し可能ラッパーは追加のインスタンスメンバーを追加しないため、メモリの 10 MB (メガバイト) BLOB を参照する Android.Graphics.Bitmap インスタンスがある場合、Xamarin.Android の GC では、20 バイトのオブジェクトが表示され、メモリが 10 MB (メガバイト)維持されている Android ランタイム割り当てオブジェクトにリンクされていることを判断できません。

多くの場合、GC を支援する必要があります。残念ながら、GC。AddMemoryPressure() と GC。RemoveMemoryPressure() はサポートされていないため、Java で割り当てられた大きなオブジェクトグラフを解放しただけのことがわかっている場合は、GC を手動で呼び出す必要があります。Gc に Java 側のメモリを解放するように求める Collect() か、Java.Lang.Object サブクラスを明示的に破棄して、マネージド呼び出し可能ラッパーと Java インスタンス間のマッピングを中断できます。

Note

サブクラスインスタンスを破棄Java.Lang.Objectする場合は、十分に注意する必要があります。

メモリ破損の可能性を最小限に抑えるには、呼び出 Dispose()すときに次のガイドラインに従います。

Java またはマネージドインスタンスを複数のスレッド間で共有できる場合は、d にすることはできません。Dispose() たとえば、のように指定します。Typeface.Create()は、キャッシュされたインスタンスを返す可能性があります。複数のスレッドが同じ引数を指定すると、同じインスタンスが取得されます。その結果、 Dispose()1 つのスレッドからインスタンスを削除すると、他の Typeface スレッドが無効になる可能性があります。その結果 ArgumentException、インスタンスが別の JNIEnv.CallVoidMethod() スレッドから破棄されたために、(特に) s が発生する可能性があります。

バインドされた Java 型の破棄

インスタンスがバインドされた Java 型の場合、インスタンスがマネージドコードから再利用されず、Java インスタンスをスレッド間で共有できない限り、インスタンスを破棄できます (前Typeface.Create()の説明を参照)。 (この決定を行うのは難しい場合があります。次に Java インスタンスがマネージドコードを入力すると、新しいラッパーが作成されます。

これは、Drawables やその他のリソース負荷の高いインスタンスに関しては、多くの場合に役立ちます。

using (var d = Drawable.CreateFromPath ("path/to/filename"))
    imageView.SetImageDrawable (d);

上記は安全です。Drawable.CreateFromPath() が返すピアは、ユーザーピアではなく Framework ピアを参照するためです。ブロックの最後の呼び出しによりDispose()、マネージド Drawable インスタンスとフレームワーク Drawable インスタンス間のusing関係が中断され、Android ランタイムが必要になるとすぐに Java インスタンスを収集できるようになります。 ピアインスタンスがユーザーピアを参照している場合、これは安全ではありません。ここでは、"外部" 情報を使用して、ユーザーピアを参照できないことを認識DrawableしているためDispose()、呼び出しは安全です。

他の型の破棄

インスタンスが Java 型 (カスタムなど) のバインドではない型を参照している場合は、そのインスタンスでオーバーライドされたメソッドを呼び出Dispose()す Java コードがないことがわかっている場合を除き、呼び出さないでください。Activity これを行わないと、s が発生 NotSupportedExceptionします。

たとえば、カスタムクリックリスナーがある場合は、次のようになります。

partial class MyClickListener : Java.Lang.Object, View.IOnClickListener {
    // ...
}

Java は後でメソッドを呼び出そうとするため、このインスタンスを破棄しないでください。

// BAD CODE; DO NOT USE
Button b = FindViewById<Button> (Resource.Id.myButton);
using (var listener = new MyClickListener ())
    b.SetOnClickListener (listener);

明示的なチェックを使用して例外を回避する

Java.Lang.Object.Dispose オーバーロードメソッドを実装した場合は、JNI を含むオブジェクトに触れないようにします。これにより、既にガベージコレクトされている基になる Java オブジェクトにコードが (致命的に) アクセスを試みることができる、二重破棄の状況が発生する可能性があります。これにより、次のような例外が生成されます。

System.ArgumentException: 'jobject' must not be IntPtr.Zero.
Parameter name: jobject
at Android.Runtime.JNIEnv.CallVoidMethod

この状況は、多くの場合、オブジェクトを最初に破棄するとメンバーが null になり、その後、この null メンバーに対して以降のアクセス試行によって例外がスローされた場合に発生します。具体的には、オブジェクト Handle (マネージドインスタンスを基になる Java インスタンスにリンクする) は最初の破棄時に無効になりますが、マネージドコードは、この基になる Java インスタンスにアクセスしようとします (Java インスタンスとマネージドインスタンス間のマッピングの詳細については、マネージド呼び出し可能ラッパーを参照してください)。

この例外を回避する良い方法は、マネージドインスタンスと基になる Java インスタンス間のマッピングがまだ有効であることをメソッドでDispose明示的に確認することです。つまり、オブジェクトのメンバーにアクセスする前に、オブジェクトHandleが null (IntPtr.Zero) であるかどうかを確認チェック。たとえば、次 Dispose のメソッドはオブジェクトに childViews アクセスします。

class MyClass : Java.Lang.Object, ISomeInterface 
{
    protected override void Dispose (bool disposing)
    {
        base.Dispose (disposing);
        for (int i = 0; i < this.childViews.Count; ++i)
        {
            // ...
        }
    }
}

最初の dispose パスが原因で childViews 無効 Handleな場合、 for ループアクセスは ArgumentException. 最初childViewsのアクセスの前に明示的Handleな null チェックを追加することで、次Disposeのメソッドによって例外が発生しないようにします。

class MyClass : Java.Lang.Object, ISomeInterface 
{
    protected override void Dispose (bool disposing)
    {
        base.Dispose (disposing);

        // Check for a null handle:
        if (this.childViews.Handle == IntPtr.Zero)
            return;

        for (int i = 0; i < this.childViews.Count; ++i)
        {
            // ...
        }
    }
}

参照されるインスタンスの削減

GC 中に型またはサブクラスのJava.Lang.Objectインスタンスがスキャンされるたびに、インスタンスが参照するオブジェクトグラフ全体もスキャンする必要があります。オブジェクトグラフは、"ルートインスタンス" が参照するオブジェクトインスタンスのセットと、ルートインスタンスが参照する内容によって参照されるすべてのものを再帰的に示します。

次のクラスがあるとします。

class BadActivity : Activity {

    private List<string> strings;

    protected override void OnCreate (Bundle bundle)
    {
        base.OnCreate (bundle);

        strings.Value = new List<string> (
                Enumerable.Range (0, 10000)
                .Select(v => new string ('x', v % 1000)));
    }
}

構築されるとBadActivity、オブジェクトグラフには 10004 インスタンス (1xBadActivity、1xstrings、1x、10000x string[] の文字列インスタンスによってstrings保持されます) が含まれ、インスタンスがスキャンされるたびにBadActivityすべてのインスタンスをスキャンする必要があります。

これにより、収集時間に悪影響が及び、GC の一時停止時間が増加する可能性があります。

ユーザーピアインスタンスによってルート化されるオブジェクトグラフのサイズを小さくすることで、GC を支援できます。上記の例では、Java.Lang.Object から継承されない別のクラスに移動 BadActivity.strings することで、これを行うことができます。

class HiddenReference<T> {

    static Dictionary<int, T> table = new Dictionary<int, T> ();
    static int idgen = 0;

    int id;

    public HiddenReference ()
    {
        lock (table) {
            id = idgen ++;
        }
    }

    ~HiddenReference ()
    {
        lock (table) {
            table.Remove (id);
        }
    }

    public T Value {
        get { lock (table) { return table [id]; } }
        set { lock (table) { table [id] = value; } }
    }
}

class BetterActivity : Activity {

    HiddenReference<List<string>> strings = new HiddenReference<List<string>>();

    protected override void OnCreate (Bundle bundle)
    {
        base.OnCreate (bundle);

        strings.Value = new List<string> (
                Enumerable.Range (0, 10000)
                .Select(v => new string ('x', v % 1000)));
    }
}

マイナーコレクション

マイナーコレクションは、GC を呼び出すことによって手動で実行できます。Collect(0)。マイナーコレクションは (メジャーコレクションと比較して) 安価ですが、固定コストが大きいため、あまり頻繁にトリガーしたくないので、数ミリ秒の一時停止時間が必要です。

アプリケーションに同じ処理が繰り返し実行される "デューティサイクル" がある場合は、デューティサイクルが終了したら、手動でマイナーコレクションを実行することをお勧めします。デューティサイクルの例を次に示します。

1 つのゲームフレームのレンダリングサイクル。
特定のアプリダイアログとの対話全体 (開く、入力する、閉じる)
アプリデータを更新/同期するためのネットワーク要求のグループ。

メジャーコレクション

メジャーコレクションは、GC を呼び出すことによって手動で実行できます。Collect() または GC.Collect(GC.MaxGeneration).

これらはまれに実行する必要があり、512 MB (メガバイト) ヒープを収集するときに Android スタイルのデバイスで 1 秒間の一時停止時間が発生する可能性があります。

メジャーコレクションは、次の場合にのみ手動で呼び出す必要があります。

長いデューティサイクルの終了時に、長い一時停止が発生してもユーザーに問題は発生しません。
オーバーライドされた Android.App.Activity.OnLowMemory() メソッド内。

診断

グローバル参照が作成および破棄されるタイミングを追跡するには、gref や gc を含むdebug.mono.logシステムプロパティを設定します。

構成

Xamarin.Android ガベージコレクターは、環境変数を MONO_GC_PARAMS 設定することで構成できます。環境変数は、AndroidEnvironment のビルドアクションで設定できます。

環境変数は MONO_GC_PARAMS 、次のパラメーターのコンマ区切りの一覧です。

nursery-size = size : 育苗のサイズを設定します。サイズはバイト単位で指定され、2 の累乗である必要があります。サフィックス kmg 。また、それぞれキロ、メガ、ギガバイトを指定するために使用できます。保育所は第一世代 (2 人) です。大規模な保育所は、通常、プログラムを高速化しますが、明らかにより多くのメモリを使用します。既定の保育サイズは 512 kb です。
soft-heap-limit = size : アプリのターゲットの最大マネージドメモリ消費量。メモリ使用量が指定した値を下回ると、GC は実行時間に合わせて最適化されます (コレクションの数が少なくなります)。この制限を超えて、GC はメモリ使用量 (より多くのコレクション) 用に最適化されています。
evacuation-threshold = しきい値 : 避難のしきい値をパーセントで設定します。値は、0 ~ 100 の範囲の整数である必要があります。既定値は 66 です。コレクションのスイープフェーズで、特定のヒープブロックの種類の占有率がこの割合より小さいことが判明した場合、次のメジャーコレクションでそのブロックの種類のコピーコレクションが実行され、占有率が 100% 近くに復元されます。値 0 を指定すると、退避がオフになります。
bridge-implementation = ブリッジの実装 : これにより、GC パフォーマンスの問題に対処するために GC ブリッジオプションが設定されます。古い値、新しい値、tarjan 値の 3 つを指定できます。
bridge-require-precise-merge:Tarjan ブリッジには最適化が含まれており、まれに、オブジェクトが最初にガベージになった後に 1 つの GC を収集する可能性があります。このオプションを含めると、その最適化が無効になり、PC の予測は可能になりますが、遅くなる可能性があります。

たとえば、ヒープサイズの制限が 128 に設定するように GC を構成するにはMB (メガバイト)コンテンツを含むビルドアクションAndroidEnvironmentを使用して新しいファイルをプロジェクトに追加します。

MONO_GC_PARAMS=soft-heap-limit=128m

次の方法で共有

ガベージ コレクション

VM 間オブジェクト コレクション

オブジェクト サイクル

自動コレクション

GC ブリッジ オプション