必要とされるスループットを実現するために、データベースからメモリへと処理を移行するJavaエンタープライズアプリケーションが増えている。この種のアプリケーションには、大量のライブ・ヒープデータと考慮すべきスレッドレベル並列性といった特徴があり、ハイエンドのマルチコアプロセッサ上で走らせることが多い。その結果、ヒープサイズとガベージコレクションの停止時間にある強い相関関係が、Javaアプリケーションのスケーラビリティを制限する大きな要因のひとつになっている。そして、こうした状況を改善しようと、研究開発にかなりの労力が費されている。
例えば、今年リリース予定のJava 7には、新しいガベージコレクタとしてGarbage-Firstが含まれている。これは、一貫性があり、停止時間が短く、低レイテンシ/高スループットのトレードオフを大幅に解消することを目指している。こうしたソフトウェアオンリーのアプローチとは対照的に、Azul Systemsハードウェアは独自カスタムの54コアプロセッサを中心に構築されており、要求に応じてJavaアプリケーションを実行するよう設計され、ライトバリアとリードバリアがプロセッサに組み込まれている。Azulのアプローチについて、現在、Azul SystemsのチーフJVMアーキテクトであり、以前、HotSpot Server Compilerのアーキテクト兼リード開発者であったCliff Click博士に話をうかがった。まず最初に、Azulのハードウェアが現在どこで使われているのか尋ねた。
ビジネスクリティカルなアプリや巨大なヒープのあるアプリで、確実に停止時間が短いことが要求されるところならどこでも使えます。巨大なヒープを使うアプリというのは、例えば、財務モデリングのようなアプリです。そこでは300GBもの財務データをヒープに入れて、数百ものCPUでそのデータを並列処理します。数十から数百GBもあるような、Java DBのキャッシュもうまく扱えます。低停止時間アプリというのは、例えば、みんながタイムリーにWebページを表示してほしいと思うようなアプリです。数秒以上の遅延があると、「Webサイトがダウンしている」と思って、みんな他のところへ行ってしまったり、苦情を訴えます。Azulを使ってWebサイトを提供している有名な企業もいくつかあります。Azulを使うと、高負荷でもすぐれた（均一の）レスポンスを提供できるためです。よくある用途としては、顧客向けポータルサイトや（パフォーマンスとスケーラビリティのための）巨大なキャッシュ、社内業務アプリ（在庫管理や休暇管理など）などですね。
InfoQ: Azulのハードウェアを使う最大の利点は、ライトバリアとリードバリアを直接サポートしていて、GCの停止時間を短くできることだと理解しているのですが、正しいでしょうか？
ええ、そうです。特にリードバリアのおかげで、単純なGCアルゴリズムに切り替えることができます。アルゴリズムが単純だと、並列化やスケーラビリティ、同時実行、ロバスト性を実現するのも簡単になります。アルゴリズムを切り替えて数年になりますが、私たちのGCは競合よりも一桁大きなヒープサイズ（そしてアロケーションレート）を軽々と扱えます。
InfoQ: 実際のところソフトウェアだけでもできますよね。これが意味のある状況はあるのでしょうか？
この分野はかなり研究が進んでいて、学術文献によると、そのペナルティは単一スレッドのパフォーマンスで10%から20%のスローダウンになるそうです。IBMのMetronomeハードリアルタイム向けガベージコレクタは、Brooksスタイルのリードバリアを使って、スローダウンを標準のガベージコレクタと比べて30%に抑えるという非常に困難な作業をしています。しかし、そのコストの一部は、ハードリアルタイムであることによるもので、単にリードバリアによるものだけではありません。IBMはMetronomeを実際に販売しています（ほとんどが軍事産業向けだと思いますが）。
InfoQ: AzulがGC停止に関してやっていることは、OracleのGarbage-FirstコレクタやJavaリアルタイム製品を使うのと比べてどうなんでしょう？
G1は興味深いですね。使えるようになればですが。私たちのGCは製品レベルで安定動作しており、もう4年もうまくいっています。G1と実績を比べるのは時期尚早でしょう。リアルタイムJava製品はたくさんの問題を抱えており、大規模なビジネスアプリには適さないことが多いです。そのGCは通常、ヒープが4GBまでに制限されているか、単一コレクタに制限されています（単一ミューテータスレッドの場合もあります）。RTSJ仕様によると、Scoped Memoryを使うようプログラムを書き直す必要があります。
InfoQ: GCの観点から、並列性の限界をどうお考えですか？ GCには効率的に並列化できない部分が必ずあるのでしょうか？
並列にガベージコレクトするのを難しくすることはできますが、実際のところ、大きなヒープのほとんどには、十分な並列性があります。GCにあるその他の問題も、ひとつずつうまく対処できます。私たちはこれに何年もかけて取り組み、極めてスケーラブルな（並列性のある）並行GCを手に入れました。100以上のGCスレッドを並列に走らせることもできます（実際、そうすることもあります）。
InfoQ: Azul VMをオープンソースにする（あるいは、OpenJDKプロジェクトに寄贈する）予定はありますか？
そうするのが相応しいときにはいつも成果物をオープンソースにしようとしてます。例えば、標準のロックのないCollectionsクラスを複数のスレッドで使っていて、あるスレッドが書き込もうとしてプログラミングエラーが発生することがよくありますが、私たちの CheckedCollections と LockedCollections を使うと、そうしたエラーを捕捉（あるいは、訂正）することができます。