New Relicは、JVMを実システムで運用する世界中のユーザから収集したデータの分析に基いて、新たなJVMのレポートをリリースした。他の自己報告による調査と違うのは、使用されたデータが、運用システムで動作するJVMから収集したものである点だ。予想されるように、収集データはNew Relicのユーザからのデータセットで構成されているが、開発者の作業やテスト対象としてではなく、運用システムでJVMが使用されている方法の概要を知ることが可能になっている。
特に注目されるのは、運用システムで動作するJVMの大部分がJavaのLTSリリースを採用していることと、Java 11を運用しているのが11パーセント強に過ぎないという事実だ。JVMの大部分(85パーセント以上)がJava 8を運用しており、その次にはJava ７が数パーセント使用されている。非LTSリリースは、報告されたマシンの1パーセントを越える程度で運用されているに過ぎない。さらにレポートでは、JVMユーザのアップグレードが遅い傾向が明らかにされている。Java 9と10(いずれもEOL)、あるいは12と13(いずれもEOLないしEOLになる予定)よりも、7以前のバージョンの運用が多いのだ。さらに、相当数のJVMが古いJava 8のバージョンを運用しており、その中にはセキュリティ上の脆弱性が既知のものが含まれていることも明らかになった。
その他、データから見られる興味深い傾向としては、Oracleが依然として75パーセント近くを占める最大のJVMサプライヤである一方で、他の多くのプロバイダによるランタイム提供が増加している点がある。Adopt OpenJDKはOracleに次ぐ7パーセントを提供しており、以下はIced Teaの5パーセント強(GNUディストリビューションが使用)、Azul、IBM、Amazonがそれぞれ3パーセント弱、その他のプロバイダ、と続いている。
レポートでは、実システムで運用されているガベージくレクタについても報告されている。最も多いのは依然としてParallelで、57パーセント以上のJVMが選択しており、G1は25パーセント弱、CMSは17パーセント強となっている。この違いについては、JVMのバージョンからある程度説明することができる。Java 8でG1コレクタがデフォルトになって以来、完成度が高まっているからだ。例外的な結果もあるが — Java 8ではCMSが14パーセント以上使用されており、G1の13パーセントを上回っている — Javaのリリースを通じてこの変更がどのように進化しているかを見る上で、興味深い統計結果となっている。意外なことではないが、ShenandoahやZGCは重要な運用システムでは使われておらず、いずれも数パーセントの普及に留まっている。
最後に、JVMのメモリ構成は256Mbから16384Mbまでと、バラエティに富んでいることが分かる。その一方で、興味深いものとして、JVMの約2.5パーセントが819Mbという最大サイズを使用しているが、こちらの例で見るように、これは8192Mbのコピー・アンド・ペーストのエラーではないかと思われる。レポートでは3分の1以上のJVMが-Xmxと-Xmsフラグを同じ値で運用している。これは旧式のJVMでは必要なことだが、新しいガベージコレクタでの経験則からは、初期サイズと最大サイズは異なっている方がよい結果が得られる。
InfoQでは現在、データの匿名コピーの入手を打診しており、それがリリースされれば本記事を更新する予定である。