今年のJavaOneの発表の中で、Tony Printezis氏はもう少し詳しい内容を紹介した。続きのインタビュー(source)をJavaOneカンファレンスのサイトで見ることもできる。その中でPrintezis氏は、Garbage First (G1)の動作の仕組みの概要を説明している。
「ヒープは固定サイズの領域に分けられていて、２つの世代の区別は基本的に論理的なものです。つまり、若い世代になる領域もあれば、古い世代になるものもあるのです。G1での空間の再利用は全て、コピーを通して行われます。G1は一連の領域を選択し、生存しているオブジェクトをその空間から取り出し、それらを別の一連の領域にコピーします。G1での空間の再利用は全てこのように行われていますが、これはCMSが行っている、コピーとインプレイスな割り当て解除を組み合わせたものの代わりとなるものです。」
Printezis氏は、続けて新しいコレクタの３つの主な目標について述べている。
「１つめの目標は、長期にわたる一貫した低停止時間です。本質的に、G1は開始とともにコンパクションを行うので、オブジェクトはヒープのある領域から別の領域へとコピーされます。したがって、コンパクションによって、CMSが直面しているかもしれないフラグメンテーションの問題は起こらないでしょう。割り当てを行うための近接する空き空間が必ずあり、G1は長期にわたって停止時間を一貫したものにすることができるのです。２つめの目標は、できる限り完全なガーベジコレクションの実施を避けることです。G1は、ヒープ全体のオブジェクトの生存を調べて大域的なマーク付けを行うフェーズが終わると、ほぼ空の領域がヒープ内のどこにあるのかが、すぐにわかるでしょう。まずそうした領域を処理し、たくさんの利用可能な空間を作ります。このようにして、ガーベジコレクタはもっと十分な空間を得ることができ、完全なGCが行われる可能性は低くなります。これは、このガーベジコレクタが Garbage-Firstと呼ばれている理由でもあります。.
最後の目標は、十分なスループットです。私達の多くの顧客にとって、スループットは最も重要なことです。私達はG1が顧客の要求を満たすような十分なスループットを得て欲しいと思っています。」
Sun Researchは論文（PDF 文書）を発表(PDF・英語)し、Garbage-Firstに関するより詳しい情報や、どのようにしてこうした目標、特にリアルタイムの目標にを達成しているかについての情報を提供している。ほとんどのリアルタイムのコレクタが個々のオブジェクトの非常に粒度の細かいレベルで動いているのに対して、Garbage Firstは領域のレベルでコレクションを行っている。いずれかの領域に生存していないオブジェクトが含まれている場合、すぐに再利用される。ユーザは停止時間の目標を指定することが可能であり、G1は以前行ったコレクションをもとに、指定された時間内でどれだけの領域のコレクションができるかを見積もる。したがって、コレクタには領域のコレクションのコストに関する合理的に正確なモデルがある。そしてその結果、「コレクタは与えられた停止時間の制限内でコレクション可能な一連の領域を（高い確率で）選択することができる。」要するに、Garbage-Firstはハード・リアルタイムのコレクタではない－ソフト・リアルタイムの目標は高い確率で達成しているが、絶対的な確実さは無いのである。トレードオフは、Garbage-Firstでは、リアルタイムの制約がよりソフトになる（しかしそれでも非常に厳しい）代わりに、より高い水準のスループットを生み出すだろうことである。これは、生存しているヒープのデータが大抵の場合たくさんあり、スレッドレベルの並列処理がかなりあるような、大規模なサーバ・アプリケーションにぴったり合う。Garbage-Firstはさらに細かい制御も提供しており、ユーザはガーベジコレクションにかかる実行期間のわずかな時間－たとえば、次の１２０秒間はガーベジコレクションに２０秒以上かけないこと－を指定することができる。
Garbage FirstはJava SE 7に入るだろうし、数週間のうちにコミットされるだろう。また、Java 6のアップデートとしてもリリースされるだろう。
原文はこちらです：http://www.infoq.com/news/2008/05/g1