Javaパフォーマンス最後のフロンティア:ガベージコレクタの削除

RedHatでパフォーマンスとOpenJDK開発者であるAleksey Shipilëv氏は、新しいJEPドラフトでno-opガベージコレクタを作成した: つまり、実際にメモリを再利用しないGCである。このガベージコレクタは、JVMの実装者と研究者を支援することを目的にしており、広範囲ではないが、ガベージをほとんど生成しない非常にパフォーマンスの高いアプリケーションには広く興味をもつのではないだろうか。JEPが進めば、新しいGCは既存のものと一緒に利用できるようになり、明示的にアクティブ化しなければ効果がない。

ガベージコレクションとJavaパフォーマンスは処理が難しいトピックであり、InfoQは諸々を明確にするためにJava ChampionsとパフォーマンスエキスパートであるMartijn Verburg氏とKirk Pepperdine氏に連絡をした。私たちはまた、ガベージなしLog4jへの移行への目標がどう達成されたかを代表するRemko Popma氏とも話した。Martijn氏とRemko氏には、GC開発者とパフォーマンス研究者からはEpsilon GCと呼ばれるno-op GCの主な利益について彼らの視点を確認した。Epsilon GCは、他のガベージコレクターのパフォーマンスを計測する制御変数として機能する。単純化した例で言えば、私たちは（メモリの割り当てや変異の制御に関する考慮はなく）GCのオーバーヘッドを減らすためにno-op GCでアプリケーションを実行できる。たとえば異なるGCアルゴリズムが設定された同じアプリケーションは同じワークロードで実行されるが、アプリケーションのガベージコレクタの影響により異なるパフォーマンスが示されることになる。これによりGC開発者やパフォーマンス研究者は独立した形でガベージコレクタの振る舞いを理解できる。

"これはJVMの様々な部分（既存のJIT C1/C2コンパイラ、Graalへのシフトなど）のより正確なベンチマークを可能にすると考えています。これは実際にJVMの寿命を延ばすでしょう。" Martijn Verburg

もう一方で、超高性能アプリケーションはEpsilon GCからの利益を受けることができる。前述のLog4jのようにガベージを生成しないようにして、ガベージコレクターが必要ないように実装されている珍しいアプリケーションとライブラリがある。この種類のアプリケーションでは、コレクタのオーバーヘッドを取り除くことで、パフォーマンスを向上できる。しかしRemko氏が協調したように、Epsilon GCで実行できるライブラリを構築するには「アプリケーションのメモリがきちんと管理されているかを確認するには非常に多くの工数がかかり」、no-op GCを選択することによって得られる利益がガベージなし状態を達成することの難しさと一致するかを検証しなくてはならない。

ガベージを生成しないようにアプリケーションを書くことは難しいように思えるが、トピックはこの記事よりもはるかに複雑であり、以下の考慮点を考慮すれば理解しやすくなる:

• メモリはJVM内では2つの異なるメカニズムで管理される：ヒープとスタック; これが2つの異なるメモリ不足エラー(OutOfMemoryErrorとStackOverflowError)が存在する理由だ。スタックに配置されたメモリは現在のスレッドと現在のメソッドが実行されている間だけ表示されるため、現在のメソッドが現在のスレッドを終了すると、このメモリはガベージコレクタなしで自動的に解放される。ヒープ内のメモリは、アプリケーションのどこからでもアクセス可能である。つまり独立したガベージコレクタは、メモリが使用されなくなったら再利用可能かどうかを検証する必要がある。
• プリミティブの割り当ては常にスタック上にあり、ガベージコレクターに負担をかけない。主にプリミティブ型を使ってコードを書くと、ガベージコレクタが参照するオブジェクトは少なくなる。
• ガベージを生成しないことはオブジェクトを生成しないことではない; ガベージコレクタを必要としないオブジェクトは次のように生成できる:
  • アプリケーションやライブラリは、多数のオブジェクトを生成して、それらを再利用するようにできる; これは開発者がアプリケーションのメモリフットプリントを非常によく理解する必要がある。
  • コンパイラは特定のオブジェクトがメソッドの外でも使用されていないと理解できる場合がある;これはエスケープ解析として知られている。オブジェクトがメソッドをエスケープしていないことがわかると、ヒープではなくスタックに割り当てることが可能になり、現在のメソッドが終了すると自動的に削除される。

これらはすべて可能だが、Kirk氏は、これは非常に不自然なコードを記述しなくてはならなくなりJavaが提供する多くの利益を失うことになると指摘し、Martijn氏もメモリ管理が、Javaが業界で成功した主要な理由のひとつであると示した。これに加えて、ガベージコレクタはその名前にもかかわらず、未使用のメモリを再利用するタスクだけでなく、新しいブロックを生み出すことができるも必要になり、Epsilon GCもそれをする必要がある。Kirk氏は、少なくても理論的には、実際にはガベージコレクションを行わない点において、Epsilon GCと他のガベージコレクションアルゴリズムの間には、大きなパフォーマンスの違いがないことを示唆した。

しかしこれらの注意点を考慮しても、Kirk氏とMartijn氏はこの種の振る舞いが非常に有益な小さなオーディエンスが存在すると認識しているが、Kirk氏によるとこのオーディエンスは小さいという事実は、その有用性に疑問を投げかけている。大部分のアプリケーションはいくつかの時点で、メモリを再利用する必要があるため、機能的なガベージコレクションは必要になる。

「合理的なGC停止時間はほとんどのアプリケーションでは問題にならないため、疑問の残るパフォーマンスがJavaの利点をすべて放棄する理由にはなりません」 Kirk Pepperdine氏

Kirk氏はまた、OpenJDKへのすべての新機能を追加したときのメンテナンスコストを思い出させ、OpenJDK開発者はそれらを追加するときに大きなイメージを持って検討する必要がある。Oracleは利用可能なガベージコレクターを減らして保守コストを削減しているため、少数のユーザーにのみ有用なGCを追加することが適切な投資にならない可能性がある。Aleksey氏は、JEPドラフトを提出する際にこの点を考慮しているようで、予備分析においてこのケースによるオーバーヘッドは最小であると示しており、JEPドラフトのコンテンツとすでに提供されている プロトタイプから判断できる。 実際の所、Kirk氏とMartijn氏の両氏は、Aleksey氏の経験からこの構想を先導しているのは楽観的であると指摘している。

一方Kirk氏はまた、OpenJDKがJVMのリファレンス実装だが、ベンダーが独自のアルゴリズムで実装して、標準Javaと完全互換があるガベージコレクタの要件に準拠していないことも強調した。 これはパブリックの意見が分断してしまう可能性がある:ニッチな市場向けにアルゴリズムを実装することがJVMの商用バージョンにとってより適切であると考える人達がいれば、OpenJDKに追加することが非常に有益であると考えるかもしれない。

@shipilev Zingには実際にはGCオプションがない。これはテストに非常に便利だ。一部の人達はOpenJDKのオプションが大好きである。

— Nitsan Wakart (@nitsanw) 2017年2月12日

Remko氏はこれらの製品のライセンスコストは、エンジニアリングスタッフが特定のGCアルゴリズムを選択して、調整するコストと比較して低くなる可能性があるため、パフォーマンスが重要になった時には少なくても商用JVMsを検討することを推奨している。OpenJDK技術のみを使った修正として、非常に低い停止時間で(100GB以上の)非常に大きなヒープを目指しているRemko氏とMartijn氏は現在開発中のShenandoah GCについて言及した。どちらのケースにおいても、専門家達は、慎重に選択されたGCアルゴリズムは、GCがない場合よりもアプリケーションのパフォーマンスが常に優れていると考えられる。

この提案はまだ早期であり、正式なJEPになるためにはレビューと洗練が必要である。これが怒ると最終的にターゲットバージョンが追加される。現時点では、ターゲットバージョンがなにであるかを推測するしかできないが、Martijn氏はEpsilon GCがJava 10か11に準備できることが適切だと考えている。GCのインターフェイスがどんなものかを理解して、よりモジュール化されたJVMに貢献できる。