原点
「仮想マシンの高度な設計と実装」を、ノートを読むという観点から体系的に研究していきます。この本は英語で書かれていて、すべてを注意深く徹底的に読むことは非常に困難です。以前は60％しか読んでいなかったので、後でもっと焦る。それについて考えた後、JVMがシステムレベルで特定のレベルに到達する必要がある場合でも、そのような本を1、2冊読む必要があるかもしれません。リーディングノートを取ることは、知識とスキルを学ぶためのより良い方法であり、少なくとも20年間私と一緒にいます。とりあえず、この読書ノートに「VMの理論」という名前を付けます。
この記事では、最後の2つの部分を紹介します。
この記事は、ADIVMに関する読書ノートの終わりです。今日の記事は少しおおざっぱです。結局のところ、これは高度な部分最適化に属します...私が要約できるいくつかの場所は、著者が話していることを知らせます（それを整理しないと、基本的にはわかりません）つまり、一種の完全に不明確な状況です）。
GC基本知識レビュー
最初にGCの基本を復習します。これは、本「Android JVM ARTの詳細な理解」の第14章からの抜粋でもあります。
原則として、4つの基本的なGCメソッドがあります。
マークスイープ
コレクションをコピーしています
コンパクトマーク
参照カウント
以下は、参照カウントを除く3つのGCメソッドの概略図です。
マークスイープの原理は上記の通りです。残っているオブジェクトを大まかに見つけて、その場でゴミのオブジェクトをクリーンアップします。この方法は比較的理解しやすく、追加の操作はありません。ただし、実際に使用すると、メモリの断片化が発生します。
コレクションのコピーとは、ライブオブジェクトを空き領域にコピーすることです。コピーするときに、全員が混雑するように位置を変更できます。このようにして、メモリの断片化の問題が解決されます。しかし、このコピーには間違いなくオーバーヘッドがあり、コピーの前後にオブジェクトが参照されるという問題もあります。また、メモリ空間は事前に空き領域として確保しておく必要があり、少し無駄です。
Mark Compactは実際にはコピーに似ています。別の空き領域が残らないだけです。それは動いています...いわゆるコンパクト（圧縮は実際に動いています）
上記は、3つの基本的なGCの図です。次に、本の中でGCを最適化する方法を見ていきます。
スループット（スループット）を改善するためのGC最適化
著者はまず、GCのスループットを改善する方法について説明します。この章では、たくさんの式を考えます。主な困難は、スループットの定義と計算方法にあると思います。まず、作者が気にしていることを見てみましょう。
GCスループットについて説明する場合、著者の最初の最適化設計の考慮事項は、部分ヒープと完全ヒープの回復のタイミングについて説明することです。つまり、マイナー/メジャーGCを照合する方法です。これは、ヒープ領域を分割するという主要な前提に基づいていることに注意してください。上図の左下がヒープの分割です。右側は分類です。
このような目的に基づいて、いくつかの数式が作成されました。以下は、元のテキストの非常に洗練されたコンテンツです。見えなくても大丈夫だと思います…ところで、この本の評価をメイヤで読んだのですが、本の巻末にはたくさんの引用があるとのことでした。しかし、本文では、特定のコンテンツがどのドキュメントからのものであるかについての言及はありません。正直なところ、以下のスループット計算については漠然と感じますが、著者自身がそれを思いついたのか、彼がどのような文献を参照したのかわかりません...
著者はまず、スループットの計算式、つまり、APP実行期間中の総再生メモリサイズ/総再生時間を定義します。しかし、これは計算が難しすぎるため、別の期間が定義されています。つまり、ある主要なgcの終わりから次の主要なgcの終わりまでです。このサイクルには、1つのメジャーGCといくつかのマイナーGCが含まれます。各マイナーgcの時間の消費が似ている（すべてTminor）と仮定すると、メジャーgcの時間の消費は似ています（すべてTmajor）。バラバラ....
めまいが来ます...
実際、上記の式では多くの仮定が行われています。たとえば、マイナーgcの後、アプリケーションはおそらくdSサイズの非ガベージメモリを割り当てます...しかし、これらの前提以外にもあると思うので、この章は実際には非常に困難です（Meiyaのコメントに具体化されている無力さを理解してください）。 。
最後に、著者はスループット計算式を得ました。Fmax / dS / Tmin / Tmaxを固定すると、微分方程式が解かれます。次に、Fmin = 16MBと仮定して、一連のスループットテストを実行します。このロジックはジャンプしすぎます（この図がどのように描かれるのか本当にわかりません）...
上の図の左下隅にある最適化の前提条件と最終的な結論（メジャーGCを先に開始）。
次に、スループットを改善するための2番目の設計上の考慮事項は、世代別GCまたは非世代別GCを使用することです。
上記はいくつかの重要な知識の抽出です。最終的な結論は次のとおりです。
著者のテスト結果によると、世代別GCのスループットは、最初は非世代別GCのスループットよりも低かったが、後で高くなった。したがって、著者が提供する最適化方法は、非世代別GCを高いスループットで開始することです。ある時点で、世代別GCに変更します...最適化の考え方は、シンプルで失礼です。もちろん、それを行う方法はかなりテストです。しかし、目標は確かにとても直接的です...
スループットを向上させるための最後の設計上の考慮事項は次のとおりです。これは、主に動作速度の向上の観点からです。
スケーラビリティを改善するためのGC最適化
GCのもう1つの最適化は、マルチコアを活用してスループットを向上させる方法です。この章はもっと退屈です。最初に何をすべきかを理解することをお勧めします。
上の図は、並行GCと並列GCの違いを説明しています。並行gcは、ミューテーターとコレクターの関係を強調し、並行して動作します。Parallel gcは、複数のコレクターの並列作業を強調しています。
この章で説明する内容については、1、2、3の紹介を参照してください。繰り返しますが、この本の非常に大きな特徴は、同じレベルの多くのコンテンツが並行関係にないことです。たとえば、上の図で言及した1と2です。オブジェクトトラバーサルには、オブジェクトマーキングが含まれます。また、マークスタックのデータ構造にもご注意ください。これは、ART本のGC部分でもよく使われる言葉です。また、本には、ルートオブジェクトの列挙はミューテーターの操作を一時停止する必要があるため、このシナリオではスケーラビリティは意味がないと述べています...
トラバーサルは実際にはマークのためです。しかし、マークだけについて話しましょう。しかし、マークに対して他のいくつかの最適化設計を行うことができます...
マルチコアの場合、最適化設計の考慮事項の1つは、並列オブジェクトトラバーサルです。スキャンしたオブジェクトをMarkStackに追加する必要があるため、これは典型的なマルチ書き込み/マルチ読み取りのプロデューサー/コンシューマーモデルになります。説明については、下の図を参照してください。
もちろん、負荷分散やその他の処理を追加したい場合は、状況はさらに複雑になります。つまり、この章で作成者が述べた3つの最適化方法は、複数の書き込み/読み取りの問題を解決するのに適しています。具体的な詳細については説明しません。この記事では何も言わないかもしれないと思う人もいます。実際、この記事を読む機会がない場合、90％の確率で、元のテキストが理解できない（または元のテキストが何を話しているのかわからない）可能性があります。
次に、パラレルオブジェクトマーキングについて説明します。
前述のように、上記の2ページの画像の内容は、元のテキストに並んでいるタイトルです。しかし、明らかにオブジェクトマーキングでは、トラバーサルのごく一部についてのみ説明しています...
最後に、この章では、最適化された設計ポイント-並列圧縮についても説明します。
とりあえず保管してください。元のテキストのこの部分を確認したら、戻ってきてください...
応答性を改善するためのGC最適化
応答速度を改善します。これはおそらく多くのキーボードの人が出てきて、いくつかの単語を言うことができる場所です。これも成熟した技術で、主な方法は並行処理だと思います...
最適化設計の考慮事項の1つである同時トレース。主な内容は次のとおりです。
3つの基本的な保証が重要です。著者が関連するGCメソッドについて説明するとき、結局はこれら3つの条件を満たすことになります。
ライブオブジェクトを見逃すことはできません
一部のガベージオブジェクトは保持できますが、最終的には収集する必要があります
トレースは、行き止まりに陥ったり、出たりしないように、終了できる必要があります。
並行トレースの全体的な状況を上の図に示します。まず、ルートルートオブジェクトが列挙された後、同時実行が存在することを明確にする必要があります。図3で述べた最後の問題に対応して、次の3つの方法が設計されています。
この記事では、最初のスナップショット方式のみを終了します。書き込みバリアを使用すると、オブジェクトのメンバー変数が変更されたときに記憶されます。上の図に注意してください。
A.f1、f2、f3はそれぞれ3つのオブジェクトB、C、Dを指します。
この時点で、A.f1がaに割り当てられ、次にA.f1がXを指します。次に、A.f1が指すBオブジェクトは記憶されません。それも見つかりません。Aはマークされているため、再度マークされることはありません。
したがって、書き込みバリアの助けを借りて、私たちは積極的にBを覚えています。Bに相当するものも、記憶されるオブジェクトです。Bを覚えておく必要がある理由は、Bがガベージオブジェクトである場合とそうでない場合があるためです。現在、それをガベージオブジェクトとして扱うことはできません（そうしないと、リサイクルされると問題が発生します。注意すべき点は、ミューテーターとコレクターが同時に動作していることです）。SATB（Snapshot-At-The-Beginning）メソッドはまさにそれです。いくつかの亜種もあります。
次の最適化設計の考慮点は、同時ルートセット列挙です。これは少し難しいです。この最適化ポイントの真の意味は、元のテキストを注意深く読む必要があります。つまり、複数のミューテーター間でルートセット列挙を同時に実行する方法について説明します。
ARTでは、「それほど高度な」（またはおそらく成熟していない実装）方法はないようです。ARTのスレッドスタックでのルートオブジェクトの訪問はNonCurrentRootに属します。これは、すべてのミューテーターが一時停止された後にのみアクセスできます...
並行移動衝突
この章の配置は、上で述べたサイドバイサイドのコンテンツの問題にも対処しています。最初の3つの章では、スループット、スケーラビリティ、応答性の3つの側面からGCを最適化する方法について説明します。この章は突然特定のGCメソッドになりました...
ARTで同時移動gc法が使用される場所もあります。以下の主要な手順に注意してください。
CMC（並行移動コレクションの略）最適化設計の考慮事項は、開始点です。ミューテーターが2つのObj Aを見るかどうかです（1つはFrom-Spaceの元のObj A、もう1つはTo-SpaceのコピーされたObj A 'です）。To-SpaceにObj Aのみが表示される場合、この設計はTo-Space Invariantと呼ばれます。この記事では主にこのデザインを紹介します
2.aの処理に注意してください。ルートセット列挙後、ルートセットのルートオブジェクトをTo-Spaceに移動する必要があります。次に、ミューテーターの操作を再開します。
2.bの処理に関しては、Read Barrierを使用しています。下記参照。
kUseBakerReadBarrierの定数は、ARTコードによく現れます。これは上の図に示されている読み取りバリアですが、厳密に言うと負荷バリアです。読み取りだけでなく、書き込み時にもいくつかの作業を行うためです。この方法は、ベーカーによって最初に提案されました...
上記はGCに関する最適化部分です。難易度はかなり大きいです。さらに、元のテキストと参照との関連性が明確ではないため、読むのがより困難になります。まだその目的と方法を理解していることをお勧めしますが、ARTのソースコードと組み合わせて詳細な調査を行うことができます。
ロックの実装とハードウェアベースのメモリトランザクション
この本の最後の2つの章では、ロックの最適化と、ハードウェアベースのメモリトランザクションテクノロジーがJVMにもたらす可能性のあるヘルプについて説明します。
最初にロックの概要を見てください
正直に言うと、ARTのセクション12.3を読むほうがいいと思います。ART's Lockは、上の図で言及されているいくつかのテクノロジーを組み合わせています。上記のディスカッションは実際にはレビューのようなものです（もちろん、ARTアプローチを理解していないと、この感覚はありません）。これらのテクニックは複雑ではありません。私の本（結合コード）を読むことをお勧めします。ここで説明したよりも強力です（著者は新しいものを提案するのではなく、これらの最適化手法を検討していると思います）
この本の最後の章では、JVM実装でのハードウェアベースのトランザクションメモリテクノロジーの可能な使用法を紹介しています。あまり話したくないので、下の図の左下にある簡単な紹介をご覧ください。
JVMリーディングノートの概要
この本は一般的にかなり内容が豊富です。JVM自体はプロジェクトです。エンジニアリングの面では、特定の領域での経験と最適化の蓄積が比較的多くなり、理論的な理論はあまり多くありません（GCは実際には最適化に近いものです）。ARTのソースコードを読むとき、あなたはこの本で言及されている内容に遭遇する運命にあります。したがって、この本は統合されてまとめられた本でなければなりません（さまざまな参考資料は、その後の詳細な調査のための宝庫でもあります）。
最後の最後
私が期待する結果は、私の友人が私の本、記事、ブログから学んだことや彼らが何をしたかではなく、むしろ、私はあなたの肩を踏みました。
私は学習の問題についての議論を終えました。次のパブリックアカウントは、いくつかの基本的な技術と新しい技術を学び、共有します。あなたの貢献も大歓迎です。しかし、私がパブリックアカウントの「連絡先情報」で述べたように、鄭元傑はおとぎ話の王「ウィズダムティース」に私に感銘を与えた文があります。「私は黙秘する権利がありますが、あなたが言うすべての言葉は私のインスピレーションの源になるかもしれません。」したがって、影響は一方向ではなく、あなたから多くを学んだ可能性があります。
シェノンと彼の友人によるエッセイ集
長押ししてQRコードを識別し、フォローしてください