ORACLE.COM/JAVAMAGAZINE //////////////////// SEPTEMBER/OCTOBER 2018

43

//the leading edge/

現在、Armベースのプロセッサは、消費電力を低く抑えながら十分なパフォーマンスが提供されることか

ら、おもに組込み市場をターゲットにしていると考えられています。しかし、今や多くのハードウェア・ベン

ダーがArmアーキテクチャをサーバーCPUの構築に使用しており、クラウドや高パフォーマンス・コンピューティング

（HPC）市場でx86アーキテクチャとの競争が起こっています。このように展開プラットフォームの範囲が拡大する

ことで、Arm版Javaは複雑さを増しています。これは、さまざまなCPUベンダーやワークロードをサポートしなけれ

ばならないことが原因です。

本記事では、ArmアーキテクチャにおけるJavaおよびJavaエコシステムの進化と、その現状について説明しま

す。最近、Armプロセッサ向けのJavaの機能およびパフォーマンスは進展していますが、その点についても、サー

バー、IoT/組込みの両面から説明します。[編集注：Armプロセッサ事業を統括している会社Arm Limitedは、ブラン

ド名を頭字語のARMから、Armおよびarmに移行しています。本記事では、特定のプロセッサ・モデルを指す場合

は従来のように大文字でARMと表記し、それ以外の場合はArmと表記します。]

Armアーキテクチャの現状組込み市場やモバイル市場では、Armが32ビットARMv5、ARMv6、ARMv7、ARMv8命令セット・アーキテクチャ

（ISA）で圧倒的なシェアを誇っています。さらに、それらの市場を除いた、現在x86アーキテクチャが支配している

市場において、Armは1つの有望な選択肢を提供していると言ってももはや過言ではありません。プロセッサの販

売に重点を置いているインテルなどのマイクロプロセッサ・ベンダーとは異なり、Armはおもにアーキテクチャやコ

アのライセンスを顧客に販売するアーキテクチャ設計会社です。その知的財産を実際のシリコンに変えるのは顧客

です。このモデルによって、同じアーキテクチャで実装が異なる多種多様な製品が、さまざまなセグメントの市場で

共存し、競争することが可能になっています。

ArmプロセッサでのJavaすでにIoTおよび組込みプロセッサの主要アーキテクチャとなっているArm。最近の64ビット・リリースに伴い、サーバーにはJDKを完全サポートするArm CPUが搭載され始めている

ALEKSEI VOITYLOV

ORACLE.COM/JAVAMAGAZINE //////////////////// SEPTEMBER/OCTOBER 2018

44

//the leading edge/

Armアーキテクチャ自体の最近の進展を鑑みれば、競争力のあるArmベースのサーバーCPUを設計するこ

とに焦点が移っていることは明らかです。2016年、Armは組込み市場とサーバー市場の両方を狙って、64ビットお

よび32ビット対応のARMv8-A ISAを完成させました。このアーキテクチャには、Single Instruction, Multiple Data

（SIMD）命令セット（NEONと呼ばれています）が必要であり、AES暗号化と、SHA-1、SHA-256、CRC32の計算を行

うオプション命令も導入されました。これらの命令を使って、暗号化とチェックサムのパフォーマンスを増強してい

るベンダーもあります。

2017年、Armはこのアーキテクチャを拡張し、新しいアトミック命令を追加しました。その後、ARMv8.2-A ISAに

半精度浮動小数点データ処理と特殊なSIMD命令が追加され、機械学習計算のパフォーマンス向上が図られまし

た。さらに、ARMv8.2-A ISAでは、（NEON命令セットよりも）ベクトル化のサポートを強化するために、オプションの

Scalable Vector Extension（SVE）命令が導入さ

れました。この命令により、ARMv8アーキテク

チャは技術計算にいっそう適したものとなりま

した。最近では、ARMv8.3-A ISAにおいて、SIMD

で複素数がサポートされるようになりました。

ARMv8アーキテクチャには、ベンダーが設

計の選択によって、目指すパフォーマンス、複雑

性、消費電力を達成できる余地が残されてい

ます。また、x86プロセッサ（x86-TSOを使用しています）の緩やかなハードウェア・メモリ・モデルよりも弱いモデル

が採用されています。そのため、より多くのアウト・オブ・オーダーの効果を確認できます。このアーキテクチャには、

load-acquire命令やstore-release命令、弱いバリア命令などの、新しい同時実行プリミティブも追加されています。

しかし、こういった変更はJVMの実装によって隠蔽されているため、ほとんどのJava開発者は気づかないはずです。

中には、ARMv8ベースのプロセッサ設計を携えて、サーバー市場でインテルと競争しているハードウェア・ベン

ダーも複数あります。また、一部のハードウェア・ベンダーは、すでにArmベースのサーバー市場での地位を固めて

おり、データセンターで使われる64ビット本番システムをここ数年間提供しています。

技術計算の分野では、米国のサンディア国立研究所が2.3ペタフロップスを超える理論ピーク値を持つArm

ベースのスーパーコンピュータを導入中です。Debian、Oracle Linux、Red Hat Linux、SUSE、Ubuntuなど、主要な

LinuxディストリビューションはすべてArmをサポートしています。OSレベル、カーネル・レベルのツールはもれなく

安定しており、本番環境でそのまま使用できます。

現在x86アーキテクチャが支配している市場において、Armは有望な選択肢の1つを提供していると言ってももはや過言ではありません。

ORACLE.COM/JAVAMAGAZINE //////////////////// SEPTEMBER/OCTOBER 2018

45

//the leading edge/

Armアーキテクチャで利用できるJava多くのプロバイダがArmベースのアーキテクチャで使用できるJavaおよびOpenJDKバイナリを提供しているため、

エンドユーザーのニーズに合った選択肢が見つかります。ARMv7およびARMv8 ISA版のJavaは、いずれも完全な機

能を搭載しており、コードベースはOpenJDKから入手でき、そのライセンスはクラスパス例外付きGPLv2.1に基づい

ています。そのため、OpenJDKはほとんどのLinuxディストリビューションにバンドルすることができました。

必要なパッケージがお気に入りのLinuxディストリビューションに含まれていない場合や、商用サポートを求め

ている場合は、AdoptOpenJDK、Azul、BellSoft、オラクルが優れたJava/OpenJDKバイナリを提供しています。本

記事の執筆時点で、Azulとオラクルが提供しているのは、ARMv8およびARMv5/6/7 ISA向けのJDK 8バイナリのみ

です。一方、BellSoftはJDK 9および10のバイナリを提供しており、Raspberry Pi向けのバイナリには、OpenJFXおよ

びDevice I/O APIモジュールが含まれています。Azul、BellSoft、オラクルは、Java SE仕様に準拠したサポート付きの

バイナリを提供しており、Java Compatibility Kit（JCK）テスト・スイートによるバイナリ検証も行っています。

Armアーキテクチャ版Javaの特徴Java実装の互換性を保証することは非常に重要ですが、JCKテスト・スイートに合格することだけがJavaの移植を

成功させる要件というわけではありません。起動およびスループットのパフォーマンスに対する期待に応えるた

め、ARMv7およびARMv8 ISA版Javaは、いずれもC1およびC2 JITコンパイラを実装しています。そのため、最適化さ

れ、基盤となるアーキテクチャの特性を利用したコードを生成できます。さらに、サーバー仮想マシン（VM）では、

-XX:+TieredCompilationコマンドライン・オプションがサポートされ、有効になっているため、起動とC2スループットの高速化が可能となっています。ARMv7版およびARMv8版Javaでは、パラレルG1、シリアルGC、非推奨の

CMSを含め、すべてのガベージ・コレクタ（GC）が完全にサポートされています。

組込みでのユースケース向けに、最小限の軽量VMを含むARMv7版も存在します。JDK 9以降では、新しく

Javaモジュールが導入されたことにより、静的フットプリントの少ないJavaランタイム・イメージを構築できるよう

になっています。たとえば、BellSoft ARM JDK 10で次のコマンドを実行すると、静的フットプリントが16 MBほどの

java.baseモジュールを搭載したJavaランタイムが生成されます。驚くべきことに、リソースに制約のあるIoTゲートウェイ向けのJavaアプリケーションの大半は、java.baseがあるだけで（あるいはおそらく他のモジュールをいくつか追加すれば）十分動作します。たとえば、Apache FelixやJettyを実行できるランタイムは32 MBに収まります。

ORACLE.COM/JAVAMAGAZINE //////////////////// SEPTEMBER/OCTOBER 2018

46

//the leading edge/

OUTPUT=~/out bin/jlink --module-path jmods --compress=2 --add-modules java.base --output $OUTPUT rm -r $OUTPUT/lib/client $OUTPUT/lib/server echo "-minimal KNOWN" > $OUTPUT/lib/jvm.cfg

年を経るとともに、ARMv8版には、CPU負荷が高い演算に最適化されたアセンブリおよび組込み関数が搭載され

るようになりました。現在では、x86版に存在する組込み関数で、ARMv8版に存在しないものはわずかです。この

相違も、JEP 315によって近いうちに存在しなくなることでしょう。

Dockerサポートや、JEP 310で規定されているAppCDS（Application Class-Data Sharing）v2など、他の移植版

のJavaに見られる一般的な機能は、すべてArmでも動作します。

次のページの表1に、x86/64版、ARMv8 64ビット版、Arm 32ビット版のそれぞれで、JVMの主要機能を詳細に比較したものを示します。

Arm 64ビット版JVMのパフォーマンスサーバー市場ではパフォーマンスがもっとも重視されるため、ARMv8版のパフォーマンスに迫ってみます。正当な

比較を行うためには、同等の性能を持つx86ベースとArmベースのサーバーを見つけることが重要です。幸いにも、

SPECint2017レートによると、最近リリースされたCavium ThunderX2 ARMv8 CPUラインは、Intel Xeonプロセッサ

と同等のプロセッサを搭載しています。

そこで、Cavium ThunderX2 CN9975とIntel Xeon Gold 6140シングルソケット・システム（いずれもDDR4-2666

メモリを搭載し、Ubuntu 16.04を実行）を選択して比較しました（同じCPUを搭載したデュアルソケット・システム

も利用できます）。ThunderX2 CN9975 CPUは、112スレッド（4ウェイSMPの28コア・システム）であり、比較対象の

Intel Xeon Gold 6140 CPUは、36スレッド（ハイパースレッディング対応18コア・システム）です。

ORACLE.COM/JAVAMAGAZINE //////////////////// SEPTEMBER/OCTOBER 2018

47

//the leading edge/

ARMv8版とx86版のJVMのパフォーマンスを評価するため、OpenJDK 11 EAビルド18で、広く使われている

SPECjbb2015 1.01およびSPECjvm2008 1.01ベンチマークを実行しました。すべてのベンチマークを20回実施し、

平均値を収集しました。SPECjbb2015ベンチマークは、全体的なスコアを取得するために使用しました。一方、

SPECjvm2008ベンチマークでは、ARMv8 HotSpot版JVMのパフォーマンスに関して、より細かい洞察が得られまし

た。

表1：主要なx86版およびArm版JVMの機能比較

x86/64 ARMv8（64ビット） ARM（32ビット）VM クライアント ○ × ○

サーバー ○ ○ ○

最小構成 ○（32ビット） × ○

JIT C1コンパイラ ○ ○ ○

C2コンパイラ ○ ○ ○

階層的コンパイル ○ ○ ○

GRAAL JITコンパイラ （試験運用版）

○（JDK 10以降） ○（JDK 11以降） ×

GC シリアルGC ○ ○ ○

パラレルGC ○ ○ ○

CMS GC ○（非推奨） ○（非推奨） ○（非推奨）

G1 GC ○ ○ ○

Zガベージ・コレクタ（ZGC） 試験運用版 開発中 ×

ランタイム コンテナのサポート ○ ○ ○

APPCDS ○ ○（JDK 10以降） ○（JDK 10以降）

LINUX HUGEPAGE ○ ○ ○

NUMAサポート ○ ○ ×

保守性 FLIGHT RECORDER（JEP 328） ○ ○（JDK 11以降） ○（JDK 11以降）

ORACLE.COM/JAVAMAGAZINE //////////////////// SEPTEMBER/OCTOBER 2018

48

//the leading edge/

本記事の目的は、特定のハードウェア・システムで得られる最高のスコアを報告することではなく、典型的なエ

ンドユーザーにとってのパフォーマンスを調査することです。そのため、いずれのシステムでも、低レベルのJVMパラ

メータやカーネル設定の微調整はあえて行っていません。JVMオプションのチューニングによって実現し得る最高

値を比較する場合は、ハードウェア・ベンダーが公開している、プロセッサのSPECスコアを確認してください。

SPECjbb2015の結果：図1に、シングルソケットIntel Xeon Gold 6140システムとThunderX2 CN9975シングルソケット・システム（いずれもDDR4-2666メモリを搭載し、Ubuntu 16.04を実行）におけるSPECjbb2015 1.01-Composite

の結果（Critical-jOPSとMax-jOPS）を示します（スコアは、高いほど優れています）。

これらのベンチマークを実行するために使用したJVMコマンドライン・オプションは、SPECjbb2015を実行す

る際によく使われるものです。Armベースのシステムでは、次のオプションを使用しました。

-Xmx24G -Xms24G -Xmn16G -XX:+AlwaysPreTouch -XX:+UseParallelGC -XX:+UseTransparentHugePages -XX:-UseBiasedLocking

x86ベースのシステムでは、次のオプションを使用しました。

-Xmx24G -Xms24G -Xmn16G -XX:+AlwaysPreTouch -XX:+UseParallelGC -XX:+UseTransparentHugePages -XX:+UseBiasedLocking

図1：SPECjbb2015-Compositeのパフォーマンス計測結果

ORACLE.COM/JAVAMAGAZINE //////////////////// SEPTEMBER/OCTOBER 2018

49

//the leading edge/

（バイアス・ロックを、ARMv8アーキテクチャ

でオフにし、x86アーキテクチャでオンのままに

したところ、両方のプラットフォームで多少優れた結果が得られました）図1からわかるように、ThunderX2

CN9975システムで動作するARMv8版OpenJDK 11は、Intel Xeon Gold 6140システムで動作するx86版よりも、Max-jOPSスコアで33 %、Critical-jOPSスコアで16 %優れていました。この結果は、ARMv8版JVMを搭載したThunderX2システムが、SPECjbb2015ベンチマークで表されるエンタープライズ・ワークロードに非常に適していることを示しています。スレッドごとのパフォーマンスを評価するために、ThunderX2システムのCPUスレッド数を32 %に

制限し、Intel Xeon Gold 6140システムと同じ数にすることも行ってみました。予想どおり、この状態でのSPECjbb2015の結果は、Xeon Gold 6140システムが30 %上回りました。SPECjvm2008の結果：図2に、シングルソケットXeon Gold 6140システムとシングルソケットThunderX2 CN9975システム（いずれもDDR4-2666メモリを搭載し、Ubuntu 16.04を実行）におけるSPECjvm2008の個別ベンチマークのベース結果と、compositeベース結果を示します（スコアは、高いほど優れています）。SPECjvm2008の「compiler」サブベンチマークは、JDK 8以降のスイートでは機能しなくなっているため、compos-

iteの相乗平均ベース・スコアは、「compiler」ベンチマーク以外の結果で手動計算しました。

図2からわかるように、ThunderX2 CN9975システムで動作するARMv8版OpenJDK 11は、Xeon Gold 6140シ

ステムで動作するx86版よりも、SPECjvm2008ベンチマークのcompositeベース・スコアで28 %優れていました。

ARMv8ベースのシステムのスコアが全般的に優れている理由は、おもに2つあります。1つ目の理由は、システムのメ

モリ帯域幅が広いことです（Xeon Gold 6140システムが6チャネルであるのに対し、8チャネル）。2つ目の理由は、

ARMv8版Javaで行われた作業で、CPUの潜在能力と拡張機能を最大限に活用できるようになっていた点に関係し

ています。

ARMv7版およびARMv8版Javaでは、パラレルG1、シリアルGC、非推奨のCMSを含め、すべてのガベージ・コレクタが完全にサポートされています。

ORACLE.COM/JAVAMAGAZINE //////////////////// SEPTEMBER/OCTOBER 2018

50

//the leading edge/

さらに細かな洞察を得るため、個々のSPECjvm2008ワークロードのスコアに注目してみます。SPECjvm2008ベ

ンチマーク9つのうち8つで、ARMv8の結果がインテルのプロセッサを上回りました。インテルのプロセッサの方が

高速だったのは、1つだけでした。cryptoベンチマークの結果は、明らかにARMv8ベースのシステムが優れており、

62 %上回っています。ARMv8版がArmチップで利用できるAESおよびSHA拡張を完全に活用していなかったなら

ば、達成できなかった値です。

compressベンチマーク（ARMv8システムが12 %上回っています）では、CRC32C組込み機能が使用されてい

ます。XMLベンチマーク（ARMv8プロセッサが29 %上回っています）とmpegaudioベンチマーク（ARMv8が44 %

上回っています）では、java.lang.Stringおよびjava.lang.Arrays組込み機能が使用されています。このような組込み機能の中には、最近JDK 10および11でARMv8向けに改良されたものもあります。

図2：SPECjvm2008のパフォーマンス計測結果

ORACLE.COM/JAVAMAGAZINE //////////////////// SEPTEMBER/OCTOBER 2018

51

//the leading edge/

x86版OpenJDKが29 %上回ったscimark.smallベ

ンチマークの結果を理解することも重要です。その理

由は、ベンチマーク・コードにあります。scimarkのサブ

ベンチマークであるFFT、LU、SOR、SPARSEには、いず

れも重いループや行列計算コードが含まれています。

インテルは、長年にわたってループの展開とベクトル

化に多大な労力を費やしてきたため、このようなコー

ド・シーケンスをx86プロセッサ上のAVX命令にマッピングすることが可能となりました。この作業は、ARMv8 C2

版ではまだ完了していません。また、Intel AVX 512ビット命令セットに相当する優れた命令が存在しないことも作

業が未完了である一因です。

ARMv8版での科学計算ワークロードのパフォーマンスをx86実装でのものと同等にするために、まだ行わな

ければならない作業があることは明らかです。ただし、今のところ、通常のサーバー・サイドJavaビジネス・アプリ

ケーションのワークロード（データ処理、XML、暗号関連の操作など）の場合、Cavium ThunderX2ユニットで動作

するARMv8版OpenJDK 11は、同等のシステムで動作するx86版よりも優れたパフォーマンスを示しています。

パフォーマンスの診断パフォーマンス診断ツールは、開発中または本稼働中のJavaアプリケーションのボトルネックを理解するために不

可欠です。

Java Management Extensions（JMX）やJVMTI APIなどのJDKツールによる通常のパフォーマンス診断は、

Armベースのシステムでもx86システムと同様に動作します。さらに詳しくJavaパフォーマンスを分析するために、

筆者が所属するグループは、Async ProfilerとHonest ProfilerをARMv8向けに移植し、変更点をプロジェクトに反映

しました。これらの移植により、ARMv8システムでHadoopのような複雑なアプリケーションのパフォーマンス向上

が可能となりました。複雑なJavaアプリケーションを作成し、Armアーキテクチャ（または他のアーキテクチャ）で

JVMのボトルネックをプロファイリングしたい場合は、このようなオープンソース・ツールを使うとよいでしょう。

オラクルがオープンソース化してOpenJDK 11に寄贈したFlight Recorderも、Armベースの移植版で利用でき

ます。

Java Management Extensions（JMX）やJVMTI APIなどの JDKツールによるパフォーマンス診断は、Armベースのシステムでもx86システムと同様に動作します。

ORACLE.COM/JAVAMAGAZINE //////////////////// SEPTEMBER/OCTOBER 2018

52

//the leading edge/

ArmシステムでのJavaエコシステム理論的には、Javaで書かれたソフトウェアはすべて、Armベースのあらゆるシステムで動作するはずです。しかし、大

きなプロジェクトでは、プロジェクトが特定のアーキテクチャに限定されるような形で特殊な調整が行われる場合

もあります。たとえば、ネイティブにビルドしたライブラリを使う場合です。ARMv8 ISAを公式にサポートしている

とは述べていないものの、Armシステムにおいてテストされ、変更なしで動作することが確認された有名プロジェ

クトもあります。たとえば、Hadoop 3.1.0、Tomcat 9.0.8、Spark 2.3.0、Kafka 1.1.0、Cassandra 3.11.2、Lucene 7.3.0、

Flink 1.4.2です。

今後の発展Arm自身に加え、Azul、BellSoft、Cavium、Linaro、オラクル、Red Hatなど、複数の企業が協力してOpenJDKのコー

ドベースを管理しており、Armベースの移植版が今後も長い間使用できることを保証しています。この作業には、

パフォーマンスおよび安定性の段階的な改善だけでなく、完全サポートされたGraalVMに関する作業や、ARMv8プ

ロセッサのJITコンパイラをGraalとするための作業も含まれています。ValhallaやPanamaなど、未来を見据えたプロ

ジェクトもこの取組みの一部となるでしょう。

まとめ上流段階のArm 32ビット版およびARMv8版Javaは、本番環境ですぐに使用でき、関連するすべての機能はx86プ

ラットフォームと同等になっています。

32ビットArm版は、高速起動用のC1コンパイラ、小さな動的メモリ・フットプリント、最小限のVMなど、組込

みおよびIoT機器へのデプロイに必要なすべての機能を搭載しています。それにより、静的フットプリントの小さい

（16 MB未満）Javaランタイム・イメージを生成できます。32ビットArm版は、Raspberry Piなどの人気あるデバイス

で良好に動作します。デバイスおよびアプリケーションに固有の適切なチューニングを行い、GPLライセンスの下で

本番環境に使用することもできます。

ARMv8版はおもにサーバー市場向けで、同等の

ハードウェアにおけるx86版よりも優れたパフォーマ

ンス計測結果を示しています（SPECjbb2015 Critical-

jOPSベンチマークで16 %、SPECjbb2015 Max-

jOPSベンチマークで33 %上回っています。また、

組込みおよび IoTのユースケースにおいて、すでにArmは一番好まれるプラットフォームとなっています。

ORACLE.COM/JAVAMAGAZINE //////////////////// SEPTEMBER/OCTOBER 2018

53

//the leading edge/

SPECjvm2008のベースcompositeベンチマークで、28 %上回っています）。SPECjvm2008ベンチマークで確認した

ように、データの暗号化やXMLファイルの処理を行う典型的なサーバー・サイドJavaビジネス・アプリケーションの

場合、Cavium ThunderX2システムで動作するARMv8版OpenJDK 11は、インテルの同等のシステムで動作するx86

版より高速です。

Javaソフトウェアのエコシステムは、Armベースのシステムにおいて、本番環境にそのまま導入できます。組

込みおよびIoTのユースケースにおいて、すでにArmは一番好まれるプラットフォームとなっています。しかし、サー

バー・メーカーや主要クラウド・プロバイダは、パフォーマンスが数十パーセント優れているというだけで、別のアー

キテクチャに移行しようと考えるでしょうか。Armが一番好まれる理由は、価格とパフォーマンスの比率です。Arm

ベースのシステムにおけるJVMのパフォーマンスとCPUの価格を考えれば、納得できるでしょう。そして、既存の

Javaアプリケーションを新しいアーキテクチャに移行しても、必要な作業はほとんどないことを考慮すれば、Arm

はとても簡単に試せるようになっています。</article>

Aleksei Voitylov：BellSoftのCTO。Caviumシステム向けのOpenJDKの最適化など、同社の顧客のためにイノベーションを起こしている。BellSoftを共同設立する前は、オラクルとSun Microsystemsに在籍し、JDK 8および9リリースのさまざまなコンポーネント（HotSpot JVMなど）や、Java言語を開発するチームを率いた。サンクトペテルブルク国立大学で博士号を取得している。