最近、Goの新鮮なガベージコレクターが私にとって最も成功した方法を宣伝していないという記事をたくさん目にしました。 一部の記事は、言語自体の開発者によって書かれたものであり、その声明は、ガベージコレクションテクノロジーの根本的な進歩を示唆しています。



以下は、2015年8月付けの新しいコレクターの導入に関する最初の発表です。

ガベージコレクター（GC）は、2015年だけでなく、2025年以降も Goで作成されています... Go 1.5のコレクターは、アセンブリの一時停止が安全な言語への切り替えの障壁ではなくなった未来の到来を発表します。 これは、アプリケーションがハードウェアで簡単に拡張できる未来であり、ハードウェアが成長するにつれて、ガベージコレクターは、より優れた、よりスケーラブルなソフトウェアを作成する際の抑止力ではなくなります。 Goは、少なくとも今後10年間は​​使用するのに適した言語です。

作成者は、ガベージコレクションの一時停止の問題を解決しただけでなく、さらに進んだと主張しています。

パフォーマンスの問題を解決するための高度な方法の1つは、各問題に1つずつ、GC設定（ノブ）を追加することです。 プログラマは、アプリケーションに最適な組み合わせを選択して、それらを変更できます。 このアプローチの欠点は、毎年1つまたは2つの新しい設定が導入されると、10年後にこれらの設定を変更する人々の作業を法的に規制する必要があることです。 Goはこのルートに行きませんでした。 たくさんの設定の代わりに、設定をGOGCと名付けました。



さらに、開発者は多数の設定をサポートする負担から解放され、アプリケーションの実行時間の改善に集中できます。

多くのGoユーザーがGoのランタイムに対する新しいアプローチを喜んで受け入れたことは間違いありません。 しかし、私はこれらの主張について不満を持っています。それらは信頼できないマーケティングの弾丸のように見えます。 そして、それらはインターネット上で何度も繰り返し再生されているので、それらを詳細に扱う時が来ました。



現実には、Goのガベージコレクターには新しいアイデアや研究結果が実装されていません。 著者自身が認めているように、これは1970年代のアイデアに基づいた、並行マーキングとクリーニングを備えた単なるコレクターです。 コレクターは、コレクターの他のすべての重要な特性により、一時停止の期間を最適化するように設計されているため、これは注目に値します。 Goの技術資料およびマーケティング資料では、これらの副作用のすべてに言及しているわけではないため、多くのプログラマーはその存在を認識していません。 その結果、競合する言語はスラグの設計が不十分です。 そして、Goの著者はこれらの考えにのみ燃料を供給しています。

次の10年のコレクターを作成するために、過去数十年のアルゴリズムを使用しました。 コレクターは、1978年にダイクストラが提案した3色（3色）の並列マーキングおよびクリーニングアルゴリズムを実装しています。 これは、「企業」クラスのほとんどの最新コレクターとの意図的な違いであり、私たちの意見では、最新機器の機能と最新ソフトウェアの遅延レベルの要件に最適です。

これをすべて読んでください。過去40年にわたって、「企業」ガベージコレクターの分野でこれ以上良いものは提案されていません。

ガベージコレクション理論の概要

ガベージコレクションアルゴリズムを開発する場合、いくつかの要素を考慮する必要があります。

• プログラムのスループット：アルゴリズムはプログラムの速度をどれだけ遅くしますか？ これは、パーセンテージで表されることもあります。つまり、アセンブリに費やされるプロセッサ時間と有用な作業に費やされる時間の比率です。
• コレクターのスループット：コレクターは、特定のプロセッサー時間でどれくらいのガベージを消去できますか？
• ヒープの冗長性：コレクターが理論上の最小値を超えて必要とするメモリ量は？ アセンブリ中に一時構造をメモリに配置すると、プログラムによるメモリ消費が急激に増加することはありませんか？
• 一時停止の期間：コレクターがプログラムを停止する期間
• 一時停止の頻度：コレクターがプログラムを停止する頻度 。
• 一時停止の分散：ほとんどの一時停止は非常に短く、ごく少数の非常に長いですか？ それとも、ポーズの継続時間をより均一にしたいですか？
• メモリ割り当てのパフォーマンス：メモリ割り当ては高速、低速、または予測不能ですか？
• シーリング：コレクターは、要求を満たすのに十分なスペースがあっても、メモリー不足（OOM）メッセージを出しますが、小さなチャンクの形でヒープ全体に散らばっていますか？ そうでない場合は、作業を続行するのに十分なメモリがある場合でも、プログラムの速度が低下し始め、最終的には立ち上がります。
• マルチスレッド：コレクターはどのくらい効率的にマルチコアマシンを使用しますか？
• スケーリング：ヒープサイズが大きくなると、コレクターはどの程度効率的に機能しますか？
• チューニング：箱から出してすぐにコレクターをチューニングするのはどれくらい難しいですか？また、最適なパフォーマンスのために？
• ウォームアップ時間：アルゴリズムは、独自の動作の測定に基づいて自己調整されますか？ もしそうなら、どのくらいの期間最適な動作になっていますか？
• ページ空き：アルゴリズムは未使用のメモリをオペレーティングシステムに返しますか？ もしそうなら、いつ？
• 移植性：コレクターは、x86と比較してメモリーの一貫性の保証が弱いプロセッサーアーキテクチャで動作しますか？
• 互換性：コレクターはどの言語とコンパイラーで動作しますか？ アセンブラの使用を考慮せずに作成された言語、たとえばC ++で実行することは可能ですか？ コンパイラを変更する必要がありますか？ その場合、コレクターアルゴリズムを変更するときに、プログラム全体と依存関係を再コンパイルする必要がありますか？

ご覧のように、コレクターを設計する際に考慮すべき多くの異なる要因があり、それらのいくつかは、プラットフォームに関連するより広いエコシステムのアーキテクチャに影響を与えます。 そして、すべての要因をリストしたかどうかはわかりません。



設計パラメータのスペースが複雑であるため、ガベージコレクションはコンピューターサイエンスのサブエリアであり、研究論文で詳しく説明されています。 アカデミック環境と商用環境の両方で、新しいアルゴリズムが定期的に提案および実装されています。 しかし、残念ながら、すべての場面に適したアルゴリズムを作成した人はいません。

しっかりした妥協点があります

これについて詳しく説明します。



最初のガベージコレクションアルゴリズムは、シングルプロセッサコンピューターと小さなヒープを持つプログラム用に開発されました。 プロセッサとメモリのリソースは高価であり、ユーザーは要求が厳しくなかったため、プログラムの作業の一時停止は忠実でした。 当時作成されたアルゴリズムは、プロセッサの使用量を減らし、ヒープ上の過剰なメモリ消費を最小限にしようとしました。 これは、プログラムがデータをメモリに配置できるようになるまで、コレクターは何もしなかったことを意味します。 その後、ヒープが完全にタグ付けされてクリアされるまで一時停止し、できるだけ早くメモリの一部を解放しました。



古いコレクターには利点があります。シンプルです。 彼らが仕事をしていない場合、プログラムを遅くしないでください。 過度のメモリ消費につながらないでください。 Boehm GCなどの保守的なビルダーは、コンパイラーやプログラミング言語の変更さえ必要としません！ これにより、 AAAカテゴリのビデオゲームなど、デスクトップアプリケーション（通常は小さなヒープ）に適しています。 その中で、ほとんどのメモリはスキャンする必要のないデータファイルで占められています。



マーキングとクリーニングのフルストップポーズ（Stop-the-world、STW）を特徴とするアルゴリズムは、コンピューターサイエンスコースで最もよく研​​究されています。 インタビューの際に、候補者にガベージコレクションについて少し話すよう​​に頼むこともあります。 そしてほとんどの場合、彼らはコレクターをブラックボックスとして提示しますが、その内部では何が起こっているのかが分からないか、非常に古い技術を使用していると考えています。



問題は、そのような単純なマーキングとクリーニングの一時停止が非常に不十分にスケーリングされていることです。 カーネルを追加し、メモリ内のヒープボリュームと割り当ての比率を上げると、アルゴリズムはうまく機能しなくなります。 ただし、小さなヒープが使用されると、単純なアルゴリズムでさえも十分にタスクを実行できる場合があります！ このような状況では、同様のコレクターを使用して、メモリーのオーバーヘッドを最小限に抑えることができます。



もう1つの極端な例は、数十のコアを持つマシンで数百ギガバイトのサイズのヒープを使用することです。 たとえば、交換トランザクションまたは検索クエリを処理するサーバー上。 そのような状況では、できるだけ短く一時停止する必要があります。 そして、アルゴリズムが望ましい場合があります。これは、一般にバックグラウンドガベージコレクションのためにプログラムの動作を遅くしますが、非常に短い休止です。



強力なシステムでは、大規模なバッチジョブも実行できます。 彼らにとって、一時停止は重要ではなく、総実行時間のみが重要です。 そのような場合、 スループットを最大化するアルゴリズム、つまり、実行される有用な作業とガベージコレクションに費やされる時間の比率を使用することをお勧めします 。



残念ながら、完全に完璧な単一のアルゴリズムはありません。 また、言語のないランタイムは、プログラムがバッチジョブであるか、遅延の影響を受けやすい対話型プログラムであるかを判断できます。 これは、ランタイム開発者の愚かさではなく、「ガベージコレクター設定」の出現につながりました。 これは、コンピューターサイエンスの基本的な制限の結果です。

世代仮説

1984年に、メモリ内の配置のほとんどが「死んだ」、つまり配置後非常に短い時間でゴミになることがわかりました。 世代仮説と呼ばれるこの観察は、プログラミング言語の開発における最も強力な経験的観察の1つです。 この仮説は、数十年にわたり、関数型、命令型、データ型の有無にかかわらず、さまざまな言語で確認されています。



世代別仮説は、ガベージコレクションアルゴリズムがその利点を活用し始めたという意味で有益です。 そのため、古いストップティッククリアアルゴリズムと比較して多くの利点があった世代別コレクターがありました。

• コレクターのスループット：より多くのゴ​​ミを収集し、より高速に処理できます。
• メモリ割り当てパフォーマンス：新しいメモリを配置するときに、ヒープ上の空きスロットを探す必要がなくなりました。 実際、配置は無料になりました。
• プログラムのスループット：メモリフラグメントがきちんと隣り合わせに配置されるようになり、 キャッシュの使用率が大幅に向上しました 。 世代に基づいたジェネレーターは、プログラムが進行するにつれて何らかの作業を行う必要がありますが、実際には、これはキャッシュへの変更の利点よりも重要です。
• 一時停止の期間：ほとんどの一時停止（すべてではない）が短くなります。

しかし、そのようなコレクターには欠点もあります。

• 互換性：アルゴリズムはメモリ内のデータを移動し、プログラムがポインターに書き込む場合に追加の操作を行います。 これは、コレクターがコンパイラーと緊密に統合されている必要があることを意味します。 C ++の場合、世代ベースのコレクターはありません。
• ヒープの冗長性：このようなコレクターは、異なる「スペース」間でメモリーの一部をコピーします。 コピーするのに十分なスペースがあるはずなので、ヒープサイズにはある程度の冗長性があります。 さらに、このようなコレクターには、さまざまなポインターマップ（記憶されているセット）のサポートが必要です。これにより、冗長性がさらに向上します。
• 一時停止の分散：多くの一時停止は非常に短いですが、ヒープ全体をマークしてクリアするには完全な停止が必要になる場合があります。
• カスタマイズ：世代に基づくジェネレーターは、「若い世代」または「楽園空間」（エデンスペース）の概念を導入し、プログラムのパフォーマンスはそのサイズに大きく依存します。
• ウォームアップの期間：チューニングの問題に対応して、一部のコレクターは、実行中のプログラムの動作に関するデータに基づいて、若い世代のサイズを動的に調整します。 しかし今では、一時停止はプログラムの期間に依存し始めました。 通常、これはベンチマーク結果の場合にのみ重要です。

それにもかかわらず、世代ベースのコレクターを使用する利点は非常に大きいため、今日ではこのタイプが絶対的に支配的です。 あなたが欠点を受け入れる準備ができているなら、あなたは確かにそのようなコレクターを好きになるでしょう。 これらのアルゴリズムは、あらゆる種類の機能で拡張できます。典型的な最新のコレクターは、マルチスレッド化、並列化、圧縮、1人での世代の使用が可能です。

Goの並列コレクター

Goは、値型を持つかなり普通の命令型言語です。 おそらく、彼のメモリアクセスパターンは、生成仮説を使用するC＃と比較できるため、.NETコレクターが使用されます。



実際、Goプログラムには通常、HTTPサーバーのような要求/応答ハンドラーが必要です。 つまり、世代に強く結び付けられた動作を示しています。 Goのクリエーターは、「 リクエスト指向のコレクター 」など、これを将来どのように使用できるかを考えています。 既に述べたように、これは 、構成済みの保有ポリシーを持つ、 単に名前が変更された世代ベースのコレクターです。

このようなコレクターは、要求/応答ハンドラーの他のランタイムでエミュレートできます。 これを行うには、若い世代が、リクエストの処理中に生成されたすべてのガーベッジに適合するのに十分な大きさであることを確認する必要があります。



それにもかかわらず、Goで現在使用されているコレクターは世代別コレクターではありません 。 彼は、バックグラウンドで古き良きタグ付けとクリーニングの手順を実行するだけです。



このアプローチには1つの利点があります。非常に短い休止を得ることができます。 しかし、他のすべてのパラメーターは悪化します。 例：

• コレクターのスループット：デブリのヒープをクリアするのに必要な時間は、ヒープのサイズとともに増加します。 プログラムが使用するメモリが多いほど、このメモリの解放が遅くなり、有用な作業に比べてコンピュータがアセンブリに費やす時間が長くなります。 プログラムがその実行をまったく並列化しない場合にのみ、これをすべて回避できますが、制限なしでガベージコレクションにカーネルを使用し続けることができます。
• 統合：実行されていないため、プログラムは結果としてヒープ全体を断片化する場合があります。 これについては以下で説明します。 また、キャッシュを慎重に使用する利点は得られません。
• プログラムのスループット：各サイクルで、コレクターは多くの作業を行う必要があります。 これには、プログラム自体に与えられる可能性のある、より多くのプロセッサ時間がかかり、このため、実行が遅くなります。
• 配信の一時停止：プログラムと同時に実行されているコレクターは、Javaの世界ではコンカレントモード障害と呼ばれるものにつながる可能性があります。 この場合、ランタイムはプログラムを完全に停止し、クリーンアップサイクルが完了するまで待機する必要があります。 したがって、Goの作成者が一時停止が非常に短いと主張する場合、これはコレクターがプログラムに対応するのに十分なプロセッサー時間を持っている場合にのみ適用されます。 さらに、 Goコンパイラには、スレッドを確実かつ迅速に一時停止する機能がありません 。 つまり、一時停止の期間は実行中のコードに大きく依存します（たとえば、単一ゴルーチンで大きなblobをbase64でデコードすると、一時停止が増加する可能性があります）。
• ヒープの冗長性：マーキングとクリーニングの助けを借りてヒープ内のガベージコレクションの速度を考慮すると、ジョイント実行モードの障害に遭遇しないように、リザーブに多くのスペースが必要です。 デフォルトでは、Goは100％の冗長性を提供します。つまり、プログラムに必要なメモリ量が2倍になります。

上記の欠点について話している1つの投稿からの抜粋を次に示します。

サービス1はサービス2よりも多くのメモリを割り当てるため、完全停止の一時停止は長くなります。 ただし、両方のサービスについて、停止一時停止の絶対期間は桁違いに短縮されます。 両方のサービスをオンにした後、コレクターによるプロセッサー時間の消費が約20％増加するのを観察しました。

この場合、Goでの一時停止の長さは桁違いに減少しましたが、コレクターのスローダウンが原因です。 これは正当な妥協案と見なすことができますか、それとも一時停止期間はすでに非常に短かったのでしょうか？ 著者は言わなかった。



ただし、一時停止を減らすために鉄の能力を高めることはもはや意味をなさない点があります。 サーバーの一時停止が10ミリ秒から1ミリ秒に短縮された場合、ユーザーはこれに気付きますか？ そして、そのような削減のためにハードウェアリソースを2倍にする必要がある場合はどうなりますか？



Goは、帯域幅のために一時停止の期間を最適化します。そのため、一時停止を少し減らすために、プログラムを1桁遅くしたいように見えます。

Javaとの比較

HotSpot Java仮想マシンには、いくつかのガベージコレクションアルゴリズムがあります。 コマンドラインから選択できます。 バランスを維持しようとするため、Goほど休止時間を短くしようとするものはいません。 妥協の影響を感じるために、異なるコレクターを切り替えて、アルゴリズムを互いに比較できます。 どうやって？ コンパイルは実行時に実行されるため、プログラムの単純な再起動を使用します。これにより、さまざまなアルゴリズムに必要なさまざまな障壁をコンパイルし、必要に応じてコード内で最適化できます。



最新のコンピューターでは、デフォルトの世代ベースのコレクターが使用されます。 バッチタスク用に作成され、最初は一時停止の長さに注意を払っていません（コマンドラインで設定できます）。 デフォルトのコレクターを選択できるため、多くの人々はJavaを粗末なガベージコレクターだと考えています：Javaは、すぐに使用できるように、メモリの冗長性を最小限に抑えて、できるだけ速くアプリケーションを実行しようとし、一時停止について気にしません。



一時停止の期間を短縮する必要がある場合は、並行マーキングおよびクリーニングを使用するコレクター（同時マーク/スイープコレクター、CMS）に切り替えることができます。 これはGoが使用するものに最も近いものです。 ただし、これは世代ベースのアルゴリズムであるため、一時停止はGoよりも長くなります。オブジェクトが移動しているため、若い世代は一時停止中に圧縮されます。 CMSには2種類の一時停止があります：短い約2〜5ミリ秒と、より確実な約20ミリ秒です。 CMSは適応的に動作します。同時に（同時）実行されるため、（Goのように）いつ開始するかを想定する必要があります。 Goはヒープの冗長性を構成するように要求しますが、CMSは実行時に自己適応し、同時実行エラーを回避しようとします。 ヒープのほとんどは通常のタグ付けとクリーニングを使用して処理されるため、ヒープの断片化により問題とブレーキが発生する可能性があります。



Javaのコレクターの最新世代は、G1と呼ばれます（ガベージファーストから）。 デフォルトでは、Java 9以降で動作します。作成者は、できる限り汎用的にしようとしました。 ほとんどの場合、同時に実行され、世代に基づいて（世代別）束全体を圧縮します。 主に自己調整。 しかし、彼はあなたが望むもの（すべてのガベージコレクター）を知らないため、妥協点を調整することができます：割り当てるメモリの最大量と一時停止のサイズをミリ秒で指定するだけで、残りのアルゴリズムは要件に合わせて調整されます。 デフォルトでは、一時停止時間は約100ミリ秒です。したがって、一時停止時間を自分で削減しない場合、アルゴリズムがこれを行うことを期待しないでください。G1はアプリケーションの速度を優先します。



一時停止は完全に一貫しているわけではありません：ほとんどは非常に短い（1ミリ秒未満）が、ヒープの圧縮に関連するいくつかの長い（50ミリ秒以上）もあります。 G1は非常によくスケーリングします。 テラバイトサイズのヒープで使用した人のレビューがあります。 G1には、ヒープ上の文字列の重複排除などの優れた機能もあります。



最後に、Shenandoahと呼ばれる別の新しいアルゴリズムが開発されました。 OpenJDKに含まれていますが、Red Hat（プロジェクトスポンサー）からの特別なJavaビルドの使用を開始するまで、Java 9には表示されません。 このアルゴリズムは、ヒープのサイズに関係なく一時停止の期間を最小限に抑えるように設計されており、同時に圧縮されます。 短所には、高いヒープ冗長性といくつかの障壁があります。アプリケーションの実行中にオブジェクトを移動するには、ポインターを同時に読み取り、ガベージコレクターと対話する必要があります。 この意味で、アルゴリズムはAzulの「ノンストップ」コレクターに似ています。

おわりに

この記事の目的は、他の言語やツールを使用するように説得することではありません。 ガベージコレクションは、何十年も科学者やプログラマーの軍隊によって研究されてきた、 非常に難しい難しい問題です。 したがって、誰も気付いていない画期的な決定を疑ってください。 ほとんどの場合、これらは、後で明らかになる理由のために他人によって回避された、単に奇妙または異常な偽装妥協です。



また、他のすべてのパラメーターによる一時停止の期間を最小限に抑えたい場合は、Goのガベージコレクターに連絡してください。