最近ではクラウド環境やノートパソコンでも利用可能な ARM プロセッサへの Microsoft の熱狂は、さらに一歩進んだものとなっている。この夏、Microsoft は OpenJDK に初めて大きな貢献をした。Windows 10 ARM (AArch64) への OpenJDK の移植の第一段階だ。具体的には、Windows 10 ARM オペレーティング・マシン上で Java コードを開発して実行できることを意味する。
この移植作業は、OpenJDK の Windows on Arm64 の Monica Beckwith 氏が Microsoft に入社してから初めて主導したプロジェクトだ。InfoQ は、彼女とJava Engineering Group のプリンシパル SWE グループマネージャである Martijn Verburg 氏に連絡を取り、これがJava コミュニティにとって何を意味するのかを詳しく探った。Java 開発マシンとして Surface Pro に乗り換えることは、すでに可能なのでしょうか？Azure 上の ARM プロセッサの性能の恩恵を受けられるか？
InfoQ:読者の皆様のため、ご質問にお答えいただきありがとうございました。まずは自己紹介と、Microsoft での役割や日々の様子をお聞きしたいのですが、いかがでしょうか？
Verburg 氏:皆さんこんにちは、私は Martijn Verburg と申します。Microsoft の Java エンジニアリンググループのプリンシパル SWE グループマネージャをしています。以前から、jClarity （昨年 Microsoft が買収した）の CEO として、あるいは AdoptOpenJDK や Jakarta EE の運営委員会メンバーの一人として、私をご存知の方もいらっしゃるかもしれません。 私が「極悪非道の開発者」という噂もありますが、管理人なのでそんなことはありえません。 ;-)
Beckwith 氏:こんにちは、私は Monica です。OpenJDK の Windows on Arm64 プロジェクトのリーダーをしています。日々の仕事は、OpenJDK の Hotspot VM を改善することです。私は 2006 年に Sun がプロジェクトを開始して以来、OpenJDK で仕事をしてきました。私は主に、アプリ、JVM、GCヒューリスティックの最適化に取り組んでいます。そして、生成されたコードが基礎となるハードウェアの身になって考えることを確認します。Microsoft の前は、Arm でマネージドランタイムのパフォーマンスアーキテクトとして働いていました。
InfoQ:これは、MS から OpenJDK への最初の大きな貢献です。なぜ ARM を始めたのですか？一番難しい問題はどれだったのでしょうか？それはどうでしたか？他に何をしていたと思いますか？
Verburg 氏:Microsoft は ARM に関して2つの分野に関心を持っています。 当社の Surface X Pro ラインは ARM ハードウェアで動作しており、2017 年には当社のクラウドインフラストラクチャで ARM を試用する意向を発表しました。
移植への挑戦については、私の立場から見ると、チームが費やした時間と労力を見ることができて面白かったです。
- パッチは OpenJDK コミュニティで消化しやすい塊に分割しています（今回は4つのパッチセット）。
- テスト（機能、パフォーマンス、両方のリグレッション）。
新しい移植のサポートを追加する際には、新しいコードを追加し、（私の意見では）共有されているコードをより複雑に再構築します。すでに存在しているもの(Linux aarch64)に害を与えないことは、私たちにとって本当に重要なことでした。しかし、パッチを正しく適用し、両方のプラットフォームで徹底的なテストを行うためには、多くのエンジニアリングサイクルが必要でした。このグループの努力を特に誇りに思っているのは、このような仕事のために高いハードルを設定してくれているという配慮と注意のレベルです。 モニカのリーダーシップと彼女のチームの仕事に感謝します。彼らは最初から最後までこれを管理しており、非常に素晴らしい仕事をしてくれました。
Beckwith 氏:Windows (10) enablement on Arm (WoA) は Microsoft の大きな取り組みです。現代的なクラウドベースの環境を中心とした開発者向けの最初の WoA は、Surface Pro X デバイスです。
Arm64 には豊富なエコシステムがあります。Armサーバの導入に伴い、「データセンターで使用するためのARMサーバプロセッサによるイノベーションの推進」への投資をサポートするためにJava の移植が必要であることは明らかでした。
Red Hat はすでに OpenJDK を Arm64 上の Linux に移植するという素晴らしい仕事をしていました。Windows 開発者のベースを考えると、OpenJDK のエコシステムへの最初の大きな貢献として、Windows の移植を行うことは理にかなっていました。私たちは、OpenJDK コミュニティに対して、私たちが協力して Java プラットフォームを支援するためにここにいることを示したかったのです。
一番やりがいのある部分としては、移植作業を始めたときに、linux-arch64 のコードベースと windows-x86-64 のコードベースの共有コードに触れることに気がついたと思います。私たちは「波紋を最小限に抑える」ようにしたかったのです。私たちの目標は、新しいプラットフォームのサポートを押し出すことだけではなく、私たちが触れるすべてのものをサポート/クリーンアップ/融合させることでした。
Martijn さんが上で述べたように、私たちはテストとビルドのための堅牢なCIにも大きく投資しています。そして、すべてのプラットフォームの組み合わせで機能テストを実行できるようにしたかったのです。また、windows-aarch64、linux-aarch64、windows-x86-64 のテストプラットフォーム上でパフォーマンスの比較テストやリグレッションテストを実行しています。詳細は、JEP 388 の「テスト」の項を参照してください。
InfoQ:これらの貢献に対して、コミュニティはどのような反応を示したのでしょうか？AArch64 は開発者が使用する準備ができていますか？もしそうだとしたら、どのような制限があるのでしょうか？ AArch64 バージョンを使い始めようとしている開発者に何かアドバイスはありますか?
Verburg 氏:その反応には本当に満足しています。 Reddit、Hacker News、および様々な Java コミュニティの資産全体で、この移植は非常に好評を博しました。私が思うに、重要なコメントは、パッチの品質（Red Hat で Linux Aarch64 移植をリードしている Andrew Haley 氏が述べているように）と、ゲームの機会に興奮していた一般的なJava ユーザーの人々のことでした :-)。
Beckwith 氏:OpenJDK コミュニティからは手を広げて歓迎されていると感じました。また、パッチのレビューやフィードバックの面で提供されたサポートは驚異的なものでした！個人的には、賞賛や報道いただいたことに畏れ多く感じています。移植自体は完成しており、さらなる機能を有効化しているところです。Windows on Arm64 は比較的新しいプラットフォームなので、ネイティブコンポーネントや同様の依存関係を使用可能にすることも検討しています - 例えば、Minecraft が私たちの移植版で動作するためには、LWJGL が新しいプラットフォームで動作するようにする必要があります。
InfoQ:本番環境で使用しても問題ないと見なすのはいつになるのでしょうか？あなたたちの取り組みにもそのプラットフォームを利用していますか？だとしたら、どんな感じなのでしょうか？
Verburg 氏:私たちは本番に使うのを勧めるのはかなり保守的です。本番で使える準備が整ったと宣言する前に、いくつかの品質のマイルストーンをクリアする必要があります。
- そのコードは OpenJDK の jdk/jdk tip (つまりリポジトリの本流) に完全にマージする必要があります。
- 技術互換性キット（TCK）のテストを内部で完了させる必要があります。
- AdoptOpenJDK 品質保証スイートのすべてに合格していることを確認する必要があります。 私たちはここでは既にうまくいっています。
- 重要な業界の機能とパフォーマンスのベンチマークをすべて実行できるようにする必要があります。喜ばしいことに、ここでも Monica さん、Ludovic さん、Bernhard さん、チームがすばらしい進捗をしてくれました。
上記のすべては、非常に達成可能なものです。私たちは全体のために何をすべきかはわかっています。それは技術的な努力と、そこにたどり着くまでの経過時間に過ぎません。
いわば「自分たちのシャンパンを飲む」（訳注：開発中の自社製品を使う）ことはしています。とはいえ、今の段階ではそれ以上のコメントはできません。
Beckwith 氏:私の持説は「信頼はするが検証はする」です。私はそれを、目標とするパフォーマンスの改善や上流のパッチに適用しています。そこで、私の謙虚なアドバイスとしては、移植がみなさんの環境にどのように適しているかを検証し、フィードバックをお願いします。
今、私の開発者の帽子をかぶって、この移植の状態を判断するための簡単な基準を持っていることを強調したいと思います。ステージングリポジトリを本流に統合し、移植が TCK と AQA テストを通過するようにしました。
自分たちのドッグフードを食べること（訳注：開発中の自社製品を使うこと）に関しては、そうですね。私はそれがおいしいことを証明することができます。私の仕事やテストシステムの一つに、ノートパソコンの構成で Surface Pro X がありますが、これにはかなり感動しました。
InfoQ:OpenJDK のリリースプロセス中に実行されたベンチマークはありましたか？ARM アーキテクチャは、他と比較してどのように振る舞うのでしょうか？
Verburg 氏:たくさん実行されました。私は、チームがこれにどれだけ勤勉であったかを誇りに思っています。 Monica さんに比べて説明が下手くそなので、彼女に譲って！
Beckwith 氏:上記の名前付きのテストに加えて、私は openjdk-arch64 の GitHub のリポジトリにワークロード状況のページを管理しています。Arm64 サーバーは競争力が高く、大きな成果を上げています。
InfoQ:ARM プロセッサへのゴールドラッシュが起きてるように見えます。Apple は ARM をベースにした独自チップにシフトしており、AWS は少し前に ARM サーバをリリースしています。使うことでどんなメリットがあるのか？Azure もそろそろ ARM サーバーをサポートするのですか？
Verburg 氏:計算機あたりの消費電力を削減できる可能性があり、コスト削減につながります（COGS の削減につながる）。これは業界全体が注目しています。具体的な Azure 製品の方向性については現段階ではコメントできません。ですが、Microsoft が慎重に見ていると考えていいでしょう。
Beckwith 氏:Neoverse N1 コアの導入 (Arm 8.2 ISA) により、Arm はサーバ/クラウド市場に向けて順調に準備を進めています。Arm は伝統的に弱いメモリモデルをサポートしてきました。データアクセスが定義されたプログラムの実行順序に従う必要がある場合、マルチコア環境では、ソフトウェアはコードにガード/バリア/フェンスを含めることで、実行順序を保証する必要があります。
Arm 8.1+ ISA をサポートするプラットフォームでは、Arm 8.1+ ISA をサポートするプラットフォームでは、Neoverse ではバリアのスマートな発行（不要と判断された場合、完全にそれらを排除するように）も見られ、すでに新しいアトミック命令のおかげで改善が見られます。上記とは別に、7nm Fab のおかげで消費電力の削減と性能の向上が見られます。
InfoQ:Martijn さん、jClarity は約 1 年前に、Azure 上の Java ワークロードの最適化を支援するという宣言された目的で MS に買収されました。あなたや他の jClarity の皆さんにとって、この一年はいかがでしたか？
Verburg 氏:めちゃくちゃ楽しかったです。Google Docs や Slack から Office 365 や MS Teams への移行、新しい企業システムを学ぶという課題がありました。世界中から買い付けてきた他のJava VM やツール、インフラの専門家のホストと共通の文化を構築するのにも時間がかかりました。 6 つの異なるタイムゾーンでのチームビルディングは、それ自体に課題をもたらします。しかし、創造的な思考を持っていれば解決できます。
私たちは、ML主導のパフォーマンス診断という jClarity のビジョンを社内で推進し続けることができました。そして、完全な VM エンジニアリンググループで Java の心臓部にインパクトを与えることができるようになりました。だから、私たちのもっとも輝く点が継続して、影響する範囲が広がっているのはかなり嬉しいですね。
買収される他のスタートアップ企業へのアドバイスとしては、6 ～ 9 ヶ月かけて本当に落ち着き、それまでのペースで（そして最終的にはそれを上回るペースで）前進することを考えることができるようになるということです。
私たちは今、その段階に到達したのですが、また本当に速く動いていて、素晴らしいソフトウェアを生み出しています。そのため、今では個人的には、動きの速いスタートアップの舵取りに戻ってきたと感じています。しかし、企業のやり方を理解している非常に優秀なリソースを持った企業でもあります :-)。
InfoQ:Martijn さん、MS による jClarity の買収は AdoptOpenJDK の取り組みにとって何を意味するのでしょうか？それは時々企業に関連した面倒な意思決定プロセスをもたらしたのでしょうか。
Verburg 氏:Microsoft は、AdoptOpenJDK の対等なパートナーであり、その規模の大きさを知っているからといって不当な影響を与えないようにするという明確なポリシーを持っています。後方では、jClarity チーム全体が新しい役割の開始に巻き込まれ、混乱があったことは確かです。
しかし、インフラストラクチャー、ビルド、テスト、Azure のコンピュートパワーに加えて、より多くの人の力をプロジェクトにもたらすことができるようになったため、jClarityの時よりも状況は改善されました。 Adopt は、運営委員会の do-ocracy によって運営され続けています。そして、私は何も減速したり、大企業のお役所仕事に縛られたりしていないと言って良かったと思っています。結局のところ、Microsoft は最近オープンソースのやり方をよく知っています。ということで、今やっていることを続けていこうと推奨されています :-)。
InfoQ:OpenJDK のために MS が貢献したものは他にもたくさんありますが、技術的に一番苦労したのはどれでしょうか？
Verburg 氏:スタックアロケーションの提案と Windows ARM 64 移植は、労力/複雑さの面ではほぼ同等だと思います。 どちらも非常に深い Hotspot の仕事を代表しています。これは、回帰せずに新しい利益を提供するためには、非常に専門的な知識と注意が必要です。
Beckwith 氏:Martijn さんが既に指摘しているように、スタックアロケーションは私たちの大きな仕事の一つです。インライン化の改善など、JIT の最適化も視野に入れています。
InfoQ:ARM 移植の次のステップとして、グループ全体ではどうなのでしょうか？
Verburg 氏:ARM 移植については、最終的な洗練、TCK の通過、Java メジャーバージョンのリリースを対象とした JEP が必要になりました。 Monica さんはここでもっと面白い詳細を提供してくれるのではないかと疑っています！
グループ全体では、OpenJDK の改善に取り組んでいきます。これは、ファーストおよびサードパーティの Java ワークロードにプラスの影響を与えるでしょう。私たちは Azure や Minecraft などの子会社の社内や顧客のワークロードを見て、どこで最も価値を高めることができるかを見ています。この作業は今後もアップストリームの OpenJDK プロジェクトに提示されることを強調しておきます。Microsoft は OpenJDK で善良な市民になるためにここにいます。素晴らしいコミュニティに還元できることに興奮しています。
また、ML ベースのパフォーマンス診断を中心とした jClarity の知的財産を様々な Azure サービスに統合することも視野に入れています。ですが、そのあたりの具体的な製品発表はまだありません。
最後になりましたが、私たちからの地域社会へ積極的に働きかけていきます。これには、AdoptOpenJDK （Eclipse AdoptiumとしてEclipse Foundationに移行）の継続的な支援や、Java at Microsoft Blog と javaatmicrosoft の Twitter アカウントをを通じた記事、投稿、資料の継続的なストリームが含まれます。
Beckwith 氏:大きなマイルストーンには以下のようなものがあります。
- ステージングリポジトリのアップストリームへの統合
- ターゲットとするだけでなく、完全に統合するためのJDKリリースの特定。Windows on Arm64 移植をお届けしています。
- また、TCKコンプライアンスの実現にも期待しています。
個人的には、OpenJFX や Minecraft などのネイティブコンポーネントを中心に使用可能性を推進していきたいと思っています。
グループについては私たちは、JVMを最適化し続け、何よりも統合し、Java/JVMロードマップとうまく整合するようにしたいと考えています。特に、Panama、Metropolis、Valhalla 、有益なエコシステムのいくつかを思い描くことができます。