5

objective c ARCメカニズムに関するSOには多くの質問があります。多くの人が、ARCを置き換えるかどうかなどを尋ねています。 Mac アプリ用にからGCに移行することが合理的かどうかについての議論さえあります (一部のデータ型で複雑な参照を処理する作業があまり必要ない場合など)。ARCGC

の明らかな欠点は、ARC循環参照を消去するためのメカニズムがまったくないことです (編集: 循環強参照)。これは、メモリ リークに関する非常に適切で簡単な説明ARC です。

また、AppleARCのGC. http://lists.apple.com/archives/objc-language/2011/Jun/msg00013.html

どのように機能し、どのような問題があるかについてはよく理解していますが、世界からGC移動して何かを読んでも、アプリケーションで循環参照を消去するバックグラウンドメカニズムがなぜないのかという単純なことはまだわかりません。C#/.NETobjective c / CocoaARCARC

スレッドを中断する必要はありませんね。そのため、比較的安価に入手できます。実装するのは問題ですか？スタックをスキャンし、登録し、グラフを作成し、循環参照を検出し、アプリケーション スレッドを中断することなくメモリを解放するGCのライト バージョンは、クールに聞こえますよね?

深刻な計算やその他のリソースが必要ですか? すべてのオブジェクト グラフを構築せずに循環参照を見つける方法を想像するのは難しいですが、このプロセスがバックグラウンドで継続的であると仮定すると、そのようにしても問題ないはずです。

.NET 4.5 GC ( http://blogs.msdn.com/b/dotnet/archive/2012/07/20/the-net-framework-4-5-includes-new-garbage-collector-enhancements-for-client -and-server-apps.aspx ) はパフォーマンスが大幅に向上していますが、ARC システムに循環参照コレクターがあると 2 番目に勝者になりますか? ARCシステム進化の次のステップは何ですか? それが可能であり、いつかARC循環参照コレクターが発生する場合、完全に置き換えることができますGCか、または次世代GC(さらに優れたパフォーマンスを持つ) がARCシステムを排除しますか?

UPD:参照について投稿しないでください。weak私は ARC で循環参照を処理する方法を知っています。それは明らかです。質問は、循環参照コレクターを既存の ARC メカニズムに追加する可能性についてです。これは、最新の GC と同じくらい強力で汎用的であるためです。それは

4

2 に答える 2

8

C ベースの環境でのサイクル検出には、次の 2 つのいずれかが必要です。

  • オブジェクトのすべての割り当ては、常に書き込みバリアを通過します (コレクターの機能によっては、読み取りバリアも通過する可能性があります)。

  • スキャナーは、サイクルをスキャンするときにメモリを一貫した状態に保持するために「世界を止める」必要があります

前者はユニファイド メモリ モデルであり、単純な C に比べて大量のオーバーヘッドが発生します (ただし、純粋な手動の保持/解放よりも効率的にすることができます)。実際には、通常、ある種の手動参照カウントを使用して、バリアのある世界からバリアのない場所にオブジェクトを「エスケープ」します (これは、ARC コンパイラのブリッジメカニズムとほぼ同じです; CFBridgingRetain() など)。 ...)

後者は開発者にとってははるかに簡単ですが、特定のスレッドがいつ、またはどのくらいの間停止するかを知ることができないため、パフォーマンスは完全に予測できなくなります。バリアがなければ、一度に 1 つのスレッドだけを停止することはできません。

これらは両方とも、C ベースの環境の相対的な「アット ザ メタル」の性質と比較して、かなりのオーバーヘッドを追加します。VM ベースの環境では、オブジェクト グラフ接続の仮想化と、C などの事前コンパイル済み環境 (事前コンパイル済みの静的実行可能ファイル...プリコンパイラ自体ではありません）。

于 2012-12-13T18:44:05.143 に答える
0

あなたの質問は次のとおりです: ARC の循環参照の問題を解決するメカニズムは何ですか?

それに対する答えは、弱いポインターです。

于 2012-12-13T17:35:18.023 に答える