今年初め、Azul SystemsCTO代理のSimon Ritter氏が、Java 12の新機能に関するブログ投稿を公開した。Java 13のフィーチャーフリーズ入りを受けて、InfoQは、氏にコンタクトを取り、Java 12と13、最近Azulに起きたさまざまな事について話を聞いた。
InfoQ:Azulのプロダクトの話から始めましょう。OpenJDKディストリビューションのZuluと、高性能のプロプライエタリJVMであるZingという、2つのJDKを別々に提供していますね。これら2つのマーケットには、企業としてどのような違いがあるのですか？
Simon Ritter: ZingはコマーシャルなVMで、低レイテンシと高スループットを必要とするJavaアプリケーションのパフォーマンスを最適化するために設計されています。マーケットとするのは、非決定的な性質を持ったガベージコレクションでは対処できないような、厳しいワークロードを抱えたユーザです。
トレーディングシステムやWebページ広告インジェクションといったアプリケーションでは、ヒープサイズに比例するGC一時停止時間は許容されません。従って、異なるアプローチが必要なのです。Zingは完全にポーズレスのコレクタです。
ZuluはOpenJDKの当社版ビルドで、Oracle JDKの代替品を望む人たちを対象としています。 JDK 11になって、Oracleは、ディストリビューションのライセンスを変更しました。これにより、無償アップデートを頼ってきた多くの人たちが、Oracleにお金を払うか、別のディストリビューションを使用するか、という選択を迫られています。Zulu Enterprise Editionは、アップデートが利用可能になった時のSLAを含むフルサポートを、極めてリーズナブルな価格で提供することによって、サポートのない無償バージョンがニーズに適さないユーザにアピールします。
InfoQ: 明確にしておきたいのですが、御社が提供しているZuluバイナリはGPLライセンスで、自由に再配布可能なのでしょうか？サポートライセンスを購入しなくても、Azul Webサイトからダウンロードできますか？
Ritter: もちろんです。Zuluには2つのバージョンがあります。Zulu Community Editionは、当社のWebサイトから無料でダウンロードして、好きな場所で使用できます。Zulu Enterprise Editionは、アップデートの可用性に関するSLAと、問題解決のためのサポートチャネルが用意された、商用サポート付きのバージョンです。
InfoQ: 組み込みシステム用の製品もありますが、それは全体的な構想のどの部分に当てはまるのでしょうか？
Ritter: Zulu Embeddedはプロダクトラインの第３の部分にあたるもので、スマートメータ、車内インフォテインメントといった本当の組み込みシステムや、インストールを簡素化するためにアプリケーションコードにJDKをバンドルしたいユーザのための製品ラインです。
InfoQ: Zing(Azul独自のJVM)のロードマップについて説明して頂けますか？長年にわたって重要な差別化要因となっていたのは、C4ガベージコレクタでしたが、ZGCやShenandoahなど、OpenJDKの新しいコレクタは脅威になっているのでしょうか？JVMマーケットの変化には、どのように対応しますか？
Ritter: 基本的には、JVMに関わるパフォーマンスの問題を解消するために、新たな方法を常に模索しています。マネージランタイム環境であることは、開発やデプロイメントを簡素化する上では有利なのですが、GCによる停止や、JITコンパイラ動作時のアプリケーションのウォームアップ時間といった欠点があります。
当社が最初に行ったのは、C4(Continuously Concurrent Compacting Collector)の開発によるGC問題の解決でした。その後何年かの間にいくつか変更がありましたが、(負荷値バリアやLVBを使用するという)基本的なアプローチは変わっていません。
ShenandoahはC4とは異なるアプローチを採用していて、現時点では単一世代のヒープのみを使用しています。ZGCはアプローチの点ではZingによく似ていますが、完全なポーズレスではありません。これらのコレクタはいずれも実験段階ですので、多くのユーザ、特に要求の厳しいSLAを探しているユーザが近い将来、本番環境に導入するとは思いません。他社がどのような動きをするのか、興味を持って見ています。
InfoQ: その他のJVMサブシステムについてはどうですか？
Ritter:最近はJVM以外の部分に注意を向けていて、 C2 JITからLLVMコンパイラをベースにしたFalcon JITへのリプレースを行いました。これによって、特にベクトル処理をよりよい方法で活用するような領域では、優れたパフォーマンスが得られるようになります。ウォームアップ時間を短縮する目的では、ReadyNow！を開発しました。実行中のアプリケーションのスナップショットを取得し、クラスのロードと初期化にこれを使用することで、メインエントリポイントに達する前にメソッドをコンパイルするものです。
最も新しい開発成果はCompile Stashingです。これは、アプリケーション実行からコンパイルコードを保存し、キャッシュとして効果的に使用することで、ReadNow!を使用する時に必要なコンパイルの量を低減するものです。JVMの仕様は、起動時に実行可能なことと可能でないことを極めて詳細に定めているので、新たなアイデアを思いついた時には、TCK(当社が実施しています)をパスするのに苦労しています。
InfoQ: これらの技術はオープンソースなのでしょうか？将来的に公開される可能性はありますか？
Ritter: これは有償の製品なので、オープンソースライセンス下でコードを利用できるようにはしていません。これが将来的に変更されるかどうかは、今は何とも言えませんね！
InfoQ: Javaの非LTSリリースに対しては、どのような経験をしていますか？運用システムで実際に使用されているのでしょうか？
Ritter: 私は多くのカンファレンスで講演していますが、誰がどのJDKバージョンを実運用で使用しているか、参加者に必ず投票してもらうようにしています。ほとんどの人はまだJDK 8を使用します。11へ移行する人は増えていますが、実際に移行した割合は、挙手による確認では、まだ10～15パーセントといったところです。こういった非公式の調査で見る限り、非LTSバージョンを使用している人はほとんどいません。
InfoQ: Java 12、特に新しいswitch式機能について話を聞かせてください。どの程度便利だと思いますか？あなたの見た範囲で、開発者は採用していますか？
Ritter: Javaのラフな部分をひとつ排除するという意味で、便利な機能だと思います。Javaの構文の多くはCに基づいているので、開発作業を簡単にするためには、switchのように、別の方法で行うことのできる部分に対処していかなくてはなりません。
個々のcase文を分離しなければならないことと、breakがなければ次のcaseに流れ落ちてしまうことは、常に面倒の元になっていました。文と同じように式をスイッチできるようにすれば、割当を１回だけ行えばよく、潜在的なエラーの原因を排除できるため、非常によい方法です。
ラムダ式やストリームの時のように、この機能を絶賛している人は、これまで見たことがありません。JDK 12でしか利用できない(しかもプレビューとしてのみ)ので、次のLTSリリースに到達するまでは限定的な使用になると思います。
InfoQ: Preview Featuresメカニズム全体としてはどうですか？有用性が証明されていると思いますか？何らかの懸念をお持ちですか？
Ritter: うまく機能していると思います。switch式はプレビューとして追加された最初の機能ですが、この方法のメリットがすでに確認できています。JDK 12バージョンでは、古いスタイルのルックアンドフィールを維持するために、値を付けた`break`を使用します。
数値をラベルとして使用することはできませんが、ループからラベルへの抜け出しを行うコードがある場合、このswitch式は混乱を招く可能性があります。JDK 13では、より明確にするために、これを変更して、代わりに"yield"(JEP 354)を使用する、という決定が下されました。これがプレビュー機能でなければ、最初の構文がJava SEの言語仕様に含まれていたと思われるので、このような方法で変更することはできなかったかも知れません。
InfoQ: プレビュー言語機能は、インキュベータAPI(HTTP/2サポートのように、当初インキュベータとして提供されていたもの)と比較してどうでしょうか？あなたの意見としては、どのような違いがあるのでしょうか？
Ritter: 一方(インキュベータモジュール)がAPIに適用されて、もう一方(プレビュー機能)が言語構文を対象にしていることを除けば、事実上は同じです。いずれも仕様を修正せずに、新機能を追加することができます。その後、仕様を変更するか、あるいはフィードバックによって仕様変更が不要であることが正当化されれば、完全に削除される場合もあります。Javaのようなプラットフォームを十分な検討の下で進化させるには、これらのアプローチは極めて理にかなっています。
個人的には、これがもっと前に導入されていれば、いくつかの問題を回避できていたのではないか、と思っています。
InfoQ: Java 13は間もなくフィーチャーフリーズされます。これから9月のJava 13 GAまでに、大きな変更はないと思われますが、リリースの内容についてはどう思いますか？
Ritter: JDK 13は、多くの機能を含まないリリースのひとつになるでしょう。含まれる予定のJEPはたった5つです。開発者がこのリリースに慌てて移行するとは考えられません。新しいリリースケイデンスの考え方は、以前のリリーススケジュールで使用していたのと同じ程度の(あるいはもっと速い)更新ペースを提供可能な、新機能の安定した流れにあります。
現在進行中の大きなプロジェクトがいくつかあります(Valhalla、Loom、Panamaなどはその好例です)ので、これらがデリバリされれば、何回かのリリースにわたって、たくさんの新機能が提供されることになるでしょう。重要なのは、Javaが進化し続けること、停滞しないことです。
InfoQ: 特にText Block(以前は"複数行文字列"と呼ばれていた)に関しては、Wadlerの法則の実例と言っていいのではないでしょうか？
Ritter: そうですね、最も小さい機能が、最も議論を必要としているようなのは面白いことです。Javaにはこれまでにも、不毛な議論(bike shedding)が何度もありました。
複数行文字列によって構文が単純化するケースもありますが、Java 1.01の頃からプログラミングをしてきた私でさえ、そのような必要があったことは片手で数えるほどしかありません。
InfoQ: Azulのスタッフ(特にGil Tene氏)が参加しているメーリングリスト上では、先日から、Docker のOpenJDKイメージに関する領域と、Debianプロジェクトがソースを取得して自分たちのバイナリをリリースする方法に関して、活発な議論が行われています。問題の概要と、その問題が十分に解決されたと感じているか、説明して頂けますか？
Ritter: この問題は、Gilが"謎肉(mystery meat)JDK"と呼んでいるもので、JDKバイナリのバージョン文字列の誤用が関わっています。公開されているバイナリの一部にリリース前の、次期アップデート用のアップデート番号があった、というものです。
つまりこの問題は、JDK 8u212と呼ばれているものに、本当にそのアップデートからの変更が含まれているのか、という点に関する信頼性の問題なのです。JDKバイナリには多くのソースがありますから、ユーザとしては、自分が手にしているものが間違いなく自分の思っているものである、という確信が必要です。この問題が解決されたと確信するためには、今後のアップデートにおいて、これがどのように機能するかを確認する必要があるでしょう。
InfoQ: OpenJDK 8がOracleによって管理されなくなったことで、現在可能な取り組みのひとつとしてあるのが、機能やパッチのバックポートです。これはOracleが引き受けたくなかった作業です。この最も顕著な例のひとつは、Azulが深く関わっているJava Flight Recorder(JFR)からOpenJDK 8へのバックポートです。バックポートが重要である理由と、それにAzulがどのように関与したのか、パッチの現在の状況について説明してください。
Ritter: Flight Recorderは、JVMとアプリケーションのパフォーマンスに関する詳細なメトリックを収集するために、JVMに組み込む必要のある一連の機能です。このデータは、Oracle JDKとOpenJDKのコンバージェンスの一部として、Oracleがオープンソースとして公開したMission Controlアプリケーションによって使用されます。
Oracle JDKには、JDK 8に統合されたFlight Recorderがあります。当時はまだコマーシャル機能であったため、実運用環境で使用するには有償のライセンスが必要でした。Oracle JDK 8の無償公開アップデートが(少なくともコマーシャルユーザ向けには)終了したので、人々はFlight Recorderを持たないOpenJDK 8ビルドに移行しています。
確かにAzulでは、Flight RecorderのOpenJDK 8へのバックポートに取り組んでおり、Zulu 8バイナリに含めています。現在はこれをOpenJDKソースの一部にすべく、他のOpenJDKコントリビュータと協力しているところです。
InfoQ: Azulが関与する主要なOpenJDKイニシアチブは他にもありますか、あるいは立ち上げたいと思っていますか？
Ritter: Azulは、Javaエコシステムのあらゆる側面に深く関わっています。2011年からJCP Executive Committeeに、Java SE 9以後はJava SE Expert Groupに、それぞれ参加しています。当社のエンジニアであるAndrew Bryginは、OpenJDK 6のプロジェクトリーダであると同時に、JEP 285(Spin-Wait Hints)などでOpenJDKプロジェクトへの貢献を続けています。JUGへの参画やAdoptOpenJDKのスポンサといった活動を通じて、OpenJDKや、より広範なJavaコミュニティをこれからもサポートします。