Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。原文(投稿日:2018/07/23)へのリンクオラクルのJava実装はオープンソースのOpenJDKプロジェクトがベースである。1.3からHotSpot仮想マシンがある。("クライアント"と"サーバ"と呼ばれることもある)。現代的なJava環境では標準的なプログラムの実行中にJITコンパイラを2つとも使う。Javaプログラムはインタプリタモードで動き始める。実行が少し進むと、頻繁に呼び出されるメソッドが特定されコンパイルされる。初めはC1を使い、HotSpotがさらに多くの呼び出しを検知するとメソッドはC2を使って再度コンパイルされる。この戦略は"階層型コンパイル"として知られ、HotSpotのデフォルトの処理である。関連スポンサーコンテンツほとんどのJavaアプリケーションにとって、C2コンパイラが環境のもっとも重要なパーツの1つであるということになる。これがプログラムのもっとも重要な部分に対し、高度に最適化されたマシンコードを生成するからである。コンパイラでは利用できない実行時最適化のおかげだ。C2は近年成果が落ちてきており、ここ数年コンパイラに大幅な改善は実装されていない。それだけでなく、C2のコードは維持拡張がとても難しくなっており、新しく関わるエンジニアがC++の方言で書かれたコードベースが持つスピードに追いつくのは非常に困難である。Clickのようなエキスパートからだ)。C2に残っている改善点はすべて、やや取るに足らないものだけとなるだろう。(@HotSpotIntrinsicCandidateアノテーション)。これは次のようなものだ。VMがアノテーションを付与されたメソッドを手書きのアセンブリや手書きのコンパイラIR、すなわちパフォーマンス改善用のコンパイラ組み込み関数で置き換える場合、メソッドは強化されます。JVMを起動すると、実行しているプロセッサが精査される。これによりJVMはそのCPUで利用可能な機能を正確に把握できるようになる。使用中のプロセッサ特有の組み込み関数テーブルを構築する。JVMはハードウェアの能力を十分に活用できるということだ。これはAOTコンパイルと異なる。AOTコンパイルは一般的なチップ向けにコンパイルし、利用できる機能について仮説を慎重に立てなければならない。AOTコンパイルされたライブラリは実行時に現在のCPUでサポートされていない命令を実行しようとするとクラッシュするからだ。HotSpotはすでにかなりの数の組み込み関数をサポートしている。命令がよく知られている。integerといった機能を実装している。現代的なプロセッサはほぼすべて、単一のハードウェア命令を使ってこれを実装している。組み込み関数はJVMに事前に知らされるもので、OSやCPUアーキテクチャでの特定の機能のサポート内容に依存する。これにより組み込み関数はプラットフォーム特有となり、全プラットフォームですべての組み込み関数がサポートされるわけではない。一般的に組み込み関数は全般的な技術ではなく、ポイント修正として認識されるべきだ。パワフルで軽量、柔軟という利点はあるが、複数のアーキテクチャにまたがってサポートしなければならないため開発と維持のコストが潜在的に高い。ゆえに、組み込み関数で進展があったにもかかわらず、あらゆる意味でC2はそのライフサイクルの終焉にたどり着き、置き換えられなければならないものとなった。オラクルは最近GraalVMの最初のリリースを発表している。研究プロジェクトであり、いつかはHotSpotを完全に置き換えることになるかもしれない。Java開発者にとって、Graalはいくつか別々の、しかし関連のある複数のプロジェクトとみなせる。HotSpotの新しいJITコンパイラであり、また新しいpolyglotな仮想マシンである。以降JITコンパイラはGraal、新しいVMはGraalVMとして言及する。(そしてGraalVMの場合他言語にも同様のことをする)。Graalの基本的な見解はとても単純だ。コンパイラは、バイトコードをマシンコードに変換するものだ。Javaの用語では単にbyte[]を別のbyte[]に変換するということだ。この変換コードをJavaで書くと何が起こるだろう?Javaでコンパイラを書くと大きな利点がいくつかあるとわかる。コンパイラエンジニアが新規に加わる際のハードルが非常に低くなる。コンパイラにおいてメモリ安全になる。コンパイラ開発で成熟したJavaのツール群を活用できる。新しいコンパイラ機能のプロトタイプをより早く作れる。コンパイラがHotSpotから独立したものとなる。コンパイラが自分自身をコンパイルでき、自分自身のより速いJITコンパイルされたバージョンを生成できる。243として提供されているが、GraalVMの主要な部分としても使われている。10ではまだかなり実験的な技術である。次のようにすると新しいJITコンパイラを使える。-XX:+UseJVMCICompiler単純なプログラムを実行するのにも異なる3つの方法があるということになる。通常の階層型となるコンパイラで、もしくはGraalのJVMCIバージョンで、そしてGraalVM自身で、である。単純な例を使ってGraalの効果をを見てみよう。これでもコンパイラの起動を見るには十分な実行時間だ。単純な文字列のハッシュ化をする。}}このコードをPrintCompilationフラグを通常の方法でセットして実行する。(またGraalの実行と比較する際のベースラインとなる)。10で実行しコンパイラとしてのGraalの効果を見てみる。out-jvmci.txtそしてGraalVMでも実行する。out-graal.txt出力としてファイルが3つ生成される。生成される出力をtimeHashing()の実行200回分で切り詰めた場合、次のようになるだろう。out-jvmci.txt予想どおり、Graalを使った実行では出力をより多く生成している。これはPrintCompilationの出力の違いによるものだ。これはまったく驚くべきことではない。Graalの大事なポイントはJITコンパイラが最初にコンパイルされるものの1つとなるということだ。VM起動後の最初の数秒間はJITコンパイラのウォームアップが多くあるだろう。(通常のPrintCompilationフォーマットだ)。bytes)こうした小さな実験は少し注意深く扱うべきである。初期の大量のコンパイルがスクリーンI/Oに影響しウォームアップのパフォーマンスがゆがめられるかもしれない。アロケートしなければならないほど大きくなるだろう。10もGraalVMもともにデフォルトでG1コレクタを使う。するとG1ガベージコレクションのプロファイルはG1のHumongousコレクションによって特色づけられる。これはまったく普通の状況ではない。GraalVMについて議論する前に、注目に値することがある。10でGraalコンパイラを使う、もう1つ別の方法だ。AOTコンパイラモードである。従った、まったく新しいコンパイラとしてゼロから書かれている。この設計によりGraalはHotSpotと統合できるが、HotSpotに固定されてはいない。ホットなメソッドだけをコンパイルするプロファイル駆動のアプローチを使うのではなく、我々はコードを実行することなくオフラインモードですべてのメソッドを完全にコンパイルするためにGraalを使うことも考えられる。295の"AOTコンパイル"で言及されている機能だ。(Linuxの.soやMacの.dylib)。kathik/StringHash.class以降の実行ではコンパイルしたコードが使える。kathik.StringHashここでGraalを使うのは、たった1つの目的のためだ。スタートアップ時間のスピードを速くするためである。HotSpotにおける通常の階層型コンパイルのアプローチが引き継ぐまでの時間だ。絶対的には、フルサイズのアプリケーションにおいてJITコンパイルは実際のベンチマークでAOTコンパイルされたコードより効率がよいと考えられる。詳細はワークロードに依存する。(.dylibはそれでも生成されるが)。java.base@10/sun.reflect.misc.Trampoline.<clinit>(MethodUtil.java:50)こうしたエラーは特定のメソッドをAOTコンパイルから除外するよう制御できる。295のページを参照してほしい)。コンパイラのエラーにもかかわらず、このAOTコンパイルしたbaseモジュールはユーザコードと一緒に実行できる。kathik.StringHashPrintCompilationをセットしてJITコンパイルがどのくらい動作したのかを見る。今度はほぼないに等しい。初期のブートストラップで必要となる本当にコアなメソッドのいくつかだけが今回JITコンパイルされる。(static)結果として、この単純なJavaアプリケーションはほぼ100%AOTコンパイルの形式で実行していると判断できる。GraalVMに戻って、このプラットフォームが提供する機能で核となるものを1つ見てみよう。GraalVMで実行するJavaアプリケーションに他言語を完全に組み込めるという機能だ。対応するもの、もしくは置換するものとして考えられる。GraalのアプローチはHotSpotにあった以前の機能の技術と比較するとより先を行っている。SDKはGraalVMのデフォルトのクラスパスの一部として提供されているが、IDEのプロジェクトで明示的に含めるべきだ。