JVM Language Summit 2019(JVMLS) day 2

JVMLSに来ています。2日目。
JVM Language Summit — July 29–31, 2019

初日はこちら
JVM Language Summit 2019(JVMLS) day 1 - きしだのHatena

今日はほぼ1日を通してコンパイラの話でした。
ちなみに、普通はJavaの文脈でコンパイラというとJavaソースコードをJavaバイトコードに変換するツールを指すと思いますが、このイベントではJavaバイトコードをネイティブコードに変換する仕組みを指します。

軽いまとめにしようと思ったけど、今日のWorkshopは結構おもしろかったのだけど資料も動画もなく、記憶だけが頼りなので、いまのうちにちゃんと書いておきます。

JIT and AOT in the JVM

JITとAOTの話。
このセッションはすごく面白かったので、ひとつ動画を見るならこれをおすすめします。

朝ごはんを食べながら聞いてます。

JITとAOTについて比較しながら話がすすみます。

JIT結果をキャッシュすることについてJ9だなーと思いながら見てました。

比較はこんな感じに。

そしてJITサーバー！！おもしろいことを考えるなーと思いました。

そこまで含めた結果はこんな感じ。

JIT and AOT in the JVM with Mark Stoodley

Improving GraalVM Native Image

GraalVMのNative Imageについてのセッション。
初期の想定と実際の利用が違う、という話と、今後どうするかという話でした。

いつものGraalVMの紹介

制約として、最適化するところを決めるのに全部のバイトコードを見る必要があるということなどがあります。

初期の想定ではOracleデータベースに様々な言語を埋め込むために使うということで、コードはひとつのチームで書かれて制約に従うことができるし、プラットフォームも絞れるし、リフレクションやJNIは不要だと考えたということです。なので最初はTruffle推しだったんだな。

けど実際にはマイクロサービスやコマンドラインで便利だった、と。そうすると初期の想定がくずれたということです。

対応のひとつとして、LLVMを使うといろんなプラットフォームに対応できてiOSでも動かせる、って話。

Improving GraalVM Native Image with Christian Wimmer

GraalVM Workshop

GraalVMのネイティブイメージ生成についてのWorkshopでした。

主な話題は実行時の話ではなくてコンパイルに時間がかかりすぎることでした。コード生成自体ではなく静的解析に時間がかかっているとのこと。
部分コンパイルはどうか、という話には、最適化が呼び出され方で決まるところから難しいということでした。(ここで部分コンパイルはコードの一部が変更されたときにその部分だけコンパイルしなおすことを指すと思います)
同じような理由で、Shared Libraryのようにjarライブラリを事前にコンパイルしておくというのも難しいとのこと。

というのを書きながら、gccのO2、O3みたいに最適化の深さを決めれるようにできないのかなと思った。機会があったら聞いてみよう。

次に、Static Initializerの設定を自動化できないのか、という質問がMark Reinhold氏からありました。

効率よく実行するためには、Static Initializeをビルド時に行うか実行時に行うかを設定で書く必要があります。ビルド時にできる初期化はビルド時に行うほうが効率がよくなる一方、たとえばstart=currentTimeMillisのような処理をビルド時に行ってビルド時刻を埋め込むのは無意味なので実行時に行う必要があるからです。現在は安全側に振って実行時に行う設定になってますがこれを自動判定できないのか、ということです。
やはり難しそうで、MicronautやQuarkusではフレームワークに設定が埋め込まれているという話をしていました。

あとは、Unsafeは特別対応が必要でたとえばNettyではDirectByteBufferを使っているとか、8バイトのオブジェクトハンドルが4バイトの圧縮ポインタになるのでヒープが圧縮できるとか、AppCDSはあまり助けにならないとか、コンパイルイメージのヒープは読み込み専用にできる(ので効率がよい)とか、マルチクラスローダーはIssueでモジュール構造が助けになるけどみんなモジュール使ってないとかいう話をしていました。
それと、LLVMをバックエンドとして導入することについて、マルチスレッドが弱いという話とGCの問題があって、コンセプト検証の段階だけどiOSで動かすには重要という話。

という感じで、結構おもしろい話が繰り広げられていました。

JIT and AOT in the CLR

CLRでのJITの話。
あまり興味ない人が多かったぽく、空席が結構できてました。

明確には書いてないけど、前提としてGUIアプリで使うというのがあるっぽい。なので、二回目の起動からはJIT結果を使いまわせるようにしてるという話。

いろいろ作ってて、いまは3世代目を作ってるということで、それぞれの世代の説明をしていました。

JIT and AOT in the CLR with Mei-Chin Tsai

Lunch

昨日のごはんが辛かったのだけど、今日は辛くなく、代わりにナスのようなものが辛かった。

デザートもありますが、だいたい取り損ねる。

jWarmUp

Alibabaで作ってるjWarmupの話。
JEP draft: JWarmup precompile java hot methods at application startup

どうやってウォームアップするかという話でした。

質疑も結構でてましたが、よく覚えてない・・・

プレゼン中は終始手元を見ながら話していましたが、質疑のときにようやく前を向いた写真がとれた。

動画は まだ公開されてませんが、そのうち見れるようになると思います。

TornadoVM

JavaコードをGPUやFPGAで動かすという話。
JEPもある！
JEP draft: Enable execution of Java methods on GPU

デモとしてKinectデータから3Dを作るコードをGPU化するとすごく速くなるというのを見せていました。

コードにはforループに@Parallelをつける感じ。

そうするとOpenCLに変換される。Aparapiを思い出す。

TwitterのChrisさんが、なんでSmatraを引き継がなかったの？って質問がでてました。あれはStreamの最適化だったからという答えだったけど、AMDがプロジェクトを止めているので引き継ぎにくいよねという話をskrbさんとしていました。

あと、話の中ででなかったので、FPGAのビルド時間は問題にならないのか聞いてみたら、やはりコンパイルには2時間くらいかかるらしく、コンパイルをどのタイミングでやるかというオプションがあるらしいです。飛ばした資料を見せてくれました。

しかし、あの場での質問、ドキドキした。

こちらも動画は非公開になってますが、そのうち見れるようになるはず。

Panama Update

Panamaの話。

資料に子どもの写真がはさまって、みんな笑顔だった。

内容としては、ポインタAPIとか、

構造体レイアウトとか。

Panama Update with Maurizio Cimadomore

Metropolis Workshop

MetropolisはJavaでJavaを実装するプロジェクトですが、Javaで実装したJITであるGraalの話で占められていました。

ちょっと遅れていったら、前に立つ人がボソボソ話してて、断片的に聞けて何の話をしてるかもなんとなくわかるんだけどどういう意図でその話をしているのかわからなくて、15分くらいして「This is my introduction」と言って、えー自己紹介かよーって思った。
そのあともいろいろ質問が出ていたりしたのだけど、席が遠いとよく聞こえなかったり、何の話をしてるのかよくわからなかった。
と思ったら、「それはGraalVM EEの話？」という質問があって、Graalの話だったはずなので関係ないのではと思ったら「OpenJDKの話」のような返事で、つまりみんなよくわかってないからよくわからない話が繰り広げられてたんだなーという理解。

そのあと、GraalにコントリビュートするならOpenJDKとGraalVMのどちらにすればいいの？という質問があって、これも結構ぐだぐだとしていたのですが、GraalVMのほうがupstreamであるということでした。そして、じゃあそれはどんな感じでsyncされるのという話になったのですが、どうもはっきり決まってない様子。だれかが、それを決めるのがWorkshopでは〜という発言をして、もっともだなと思いました。

あと、GCをJavaで書かないの？という話がでたときに、Mark Reinhold氏が全部書きなおせばいいよと男前なことをおっしゃっていました。

こんな感じで、ぐだぐだとした状況をぐだぐだと話していた感じですが、これこそWorkshopだなという感じでもありました。
しかし英語弱者には つらい。

Dinner

今日は公式ディナーの日。

もちろん無限ビール！

そして肉！

最初は店がさわがしくて向かいの人と話せず隣のjyukutyoと話してたのですが、人が減って静かになったときに、向かいに座ってたZuluでコンパイラを開発している人と話をしました。

ということで、今日もおつかれさまでした！

JVM Language Summit 2019(JVMLS) day 1

JVMLSに来ています。
JVM Language Summit — July 29–31, 2019

JVMLSはJava VM Language Summitの略で、JVMで動く言語に関するイベントだったのですけど、JVM言語の話はJavaも含めて減っていて、JVMの話がメインになっています。

場所はサンタクララのOracleキャンパスで、元はSunだったところ。
これは去年の写真ですが、普段は社員しか入れないところにSunの看板が、しかも初期のロゴのものです。

技術的な内容につっこんでいくとキリがないので、気になる人は動画を見てもらって、セッションの雰囲気のメモを。

Clojure Futures

まず最初はClojureの話

IFnというクラスを中心にいろんな実装の話をしていたのですが、最初なんでiPhoneの話をしてるんだろう？って思ってしまいました。

そんなかで、constantDynamicを使う話をしてたら、JVMアーキテクトのJohn Rose氏からツッコミが入るという、JVMLSの恐ろしさをいきなり見せられてしまった。

Clojure Futures with Ghadi Shayban

Loom Update

Project Loomの話。

まずはBatemanさんからAPI関係。
tryブロックによって構造的並行化を行い、キャンセルやデッドライン・タイムアウトの処理をやるのが難しい〜という話。

あと、ThreadとFiberが両方Strandを継承するという話になっていたのですが、継承関係のない独立したクラスになるようです。

それからThreadLocalなどの話。

実装状況として、すでにJDK11、12でもちょっとずつ変更が入ってて、13ではSocketが対応するなど準備は進んでるようです。

で、登壇者交代してBackmanさんがVMの話

frameをどう保持するかって話ですが、VMのことは ようわからん。

最後にJohn Roseさんが出てきて、Fiberを集めたThreadをLoomで編んだタペストリ作ったのであとでみんなに送るね！と。

Roseさんデザインですごくかわいい。

Project Loom Update with Alan Bateman and Rickard Bäckman

Amber Workshop

ここで1階と2階にわかれてワークショップです。というか、質疑応答の時間、という感じですね。
1階ではLoom、2階でAmberですが、2階のAmberのほうに来ました。

ホワイトボードに書いていくスタイル。Amberでの言語拡張をまず並べて。

Pattern Matchingのところで、Neal Gafterさんのツッコミ。NealさんはJava Puzzlerとかやってた人で、いまはMicrosoftで.NETやってます。

だいたいこんな感じの話。

if (!(s instanceof T1 x)) {
  return;
}
// ここでxは使える？

とか

switch (s) {
  case instanceof T1 x1:
  case instanceof T2 x2:
}

とか。

まあBike Shedの話だったねーとお昼ご飯のときに隣のグループの人が言ってました。だれか見てないけど、Javaのなにかを実装してる人じゃないかな。

Thread Sanitizing for Java

Thread Sanitizerの話。Googleの若手二人が登壇して、オレンジのBeylerさんは後ろから見てました。

Thread Sanitizer(TSan)はJavaのレースコンディションを見つけるものです。JEPのドラフトも出てますね。
JEP draft: Java Thread Sanitizer

デモとして、同じ変数を複数スレッドから1万回+1するコードを実行します。

TSanを有効にすると警告がたくさん。コードを修正してsynchronizedをつけると警告がなくなりました！

LLVMにはすでにTSanがあるということで、JavaのTSanもそれを利用するっぽい。

ただし、いまはまったくパフォーマンスを考えていないので、TSanを有効にすると3倍から9倍遅くなって、メモリも1.5倍から4倍使うそうな。

あと、JavaのプロダクトマネージャーのMark Reinholdさんからなんかツッコミが入ってましたね。やっぱり怖いイベントや。

Thread Sanitizing for Java with Jean Christophe Beyler, Arthur Eubanks, and Man Cao

Lunch

ランチはビュッフェです。

おいしい。

食べ終わって外にでてみると、日本ではあまり見ない雲がでてました。

Valhalla Update

Valhallaの話。

最近L2というプロトタイプが出ていろいろ試せるようになったんですが、L10でプレビューが出て、L100でSpecializationが入るのでは〜って言ってた。先の長い話や。

ベンチマークを出していたのですが、サンプルコードの最初のComplexクラスにinlineとついているのが見えます。Value Typeからinlineクラスに名前が変わったっぽい。

あとはデフォルト値の話とかNullilyの話とか。

あと、Objectクラスの下にRefObjectとValObjectが入って既存の参照型とinlineクラスがそれぞれその下に入るようなことを議論しているっぽい。

最後に、やっぱJohn Rose氏がツッコミをｗ。マイク係をMark Reinhold氏がやってて、時間単価高いマイク係だ！と思っていました。

Valhalla Update with Brian Goetz

Value Types in the CLR

.NETのCLRでのValuetypesの話。AgendaではValue Typesって書いてあったけど、.NETではValuetypesと空白なし小文字で書くのがただしいのかな。 最初はWrightonさん。

JavaのValue Type(いまはinlineクラス)との違いから。しかしこの人、紙を見ながら話していて、棒読みではないものの、資料繰りそこねて話してるところと表示してるものが違ってたり、どこ読んでるか見逃してしばらく止まってしまったり、プレゼン修行中ぽい感じでした。

最後にNeal Gafterさんが話を。

Value Types in the CLR with David Wrighton

Vectors and Numerics on the JVM

今日の最後のセッションはVector
最初はIvanovさんが「JohnがVector APIの話をするのでそのまえに会場をあっためておきます」とのことｗ
"I will warm the audience up before the John's part"

APIデザインについて、取らなかったものとそうした理由などを並べていました。

型をちゃんとつけるということで、「TypeNnnVector」という形のクラスができています。

とかやって、Roseさんのターン

デモをやってました。

あと、API一覧

そのまとめ

あとはパフォーマンスの落とし穴とかいろいろ話してたけど、あとでまとめる。。。
最後にQ&AをBrian Goetzさんと一緒にやって、そのままぐだぐだと終了。

ということで、Jyukutyoによる終わったのポーズで今日は終了です。

Vectors and the Numerics on the JVM with Vladimir Ivanov and John Rose

Dinner

参加している日本人5人で、チーズステーキバーガーが食べれるSt. John's Bar&Grillへ

こんな感じ。ジャンク感！

今回渡米したメインコンテンツである、skrbさんが写真を撮るところ、も撮れたので満足。

ということでJVMLS1日目おつかれさまでした。明日のブログはもっと適当に書きます・・・

Java最新フレームワーク、Helidon、Micronaut、Quarkusをnative-imageまでまとめて試す

最近でてきたフレームワーク、Helidon、Micronaut、Quarkusのクイックスタート、Native-Imageをまとめて試しましょう。

準備

SDKMANインストール

今回はSDKMANで環境を作っていきます。
https://sdkman.io/

コマンドラインで次のコマンドを実行します。Windowsの場合はCygwinかWSLで。

$ curl -s "https://get.sdkman.io" | bash

ターミナルを開きなおすか次のコマンドを実行するとSDKMANが有効になります。

$ source "$HOME/.sdkman/bin/sdkman-init.sh"

JDKインストール

今回はnative-imageまで使うのでGraalVMを使っておきましょう。

$ sdk use java 19.1.0-grl

native-imageの準備も行います。Cygwinではnative-imageはバンドルされているので不要ですが、いまのところ3つのフレームワークのネイティブ化ができてません。

$ gu install native-image

Mavenインストール

HelidonとQuarkusではMavenを使うのでインストールしておきます。

$ sdk install maven

Helidon

HelidonはOracleのWebLogicチームが開発しているフレームワークです。
https://helidon.io/

独自APIを使うSEとMicroProfileを使うMPがありますが、現時点でnative-imageに対応しているのはSEのみなので、ここではSEを使います。

プロジェクト作成

archetypeから作成しますが、いろいろ入力するのは面倒なので、候補から選択します。

$ mvn archetype:generate

たくさん候補がでるので、絞り込みます。

...
2450: remote -> xyz.luan.generator:xyz-gae-generator (-)
2451: remote -> xyz.luan.generator:xyz-generator (-)
Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): 1387:

ここでhelidonと入力すると２つに絞られます。

Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): 1387: helidon
Choose archetype:
1: remote -> io.helidon.archetypes:helidon-quickstart-mp (Quickstart archetype for Helidon MP)
2: remote -> io.helidon.archetypes:helidon-quickstart-se (Quickstart archetype for Helidon SE)
Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): :

2を入力してHelidon SEを選びます。

Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): : 2
Choose io.helidon.archetypes:helidon-quickstart-se version:
1: 0.9.0
...
16: 1.1.1
17: 1.1.2
Choose a number: 17:

そのままenterをおして最新を選びます。
その後、groupId、artifactId、version、packageを入力します。groupIdは組織名、artifactIdがプロジェクト名です。

Define value for property 'groupId': kis
Define value for property 'artifactId': start-helidon
Define value for property 'version' 1.0-SNAPSHOT: :
Define value for property 'package' kis: :
Confirm properties configuration:
groupId: kis
artifactId: start-helidon
version: 1.0-SNAPSHOT
package: kis
 Y: : y

artifactIdと同じ名前のディレクトリができているので移動しておきます。

$ cd start-helidon

ビルド

ビルドはMavenで。

$ mvn package

実行

targetにartifactIdと同じ名前のjarファイルができていて、このjarファイルを実行すればサーバーが起動します。

$ java -jar target/start-helidon.jar
[DEBUG] (main) Using Console logging
2019.07.15 07:35:48 INFO io.helidon.webserver.NettyWebServer Thread[main,5,main]: Version: 1.1.2
2019.07.15 07:35:48 INFO io.helidon.webserver.NettyWebServer Thread[nioEventLoopGroup-2-1,10,main]: Channel '@default' started: [id: 0x8985c83f, L:/0:0:0:0:0:0:0:0:8080]
WEB server is up! http://localhost:8080/greet

メッセージどおりhttp://localhost:8080/greetにアクセスするとJSONが返ってきます。

ネイティブ化

native-imageプロファイルでMavenビルドするとネイティブ化できます。

$ mvn -Pnative-image package

1分ほど待つと、targetディレクトリに実行ファイルができます。

$ target/start-helidon
2019.07.15 07:42:14 INFO io.helidon.webserver.NettyWebServer !thread!: Version: 1.1.2
2019.07.15 07:42:14 INFO io.helidon.webserver.NettyWebServer !thread!: Channel '@default' started: [id: 0xb59ae091, L:/0:0:0:0:0:0:0:0:8080]
WEB server is up! http://localhost:8080/greet

Micronaut

MicroanutはGrailsを作っていたObject Computing社が開発しているフレームワークです。独自APIを使っていて、APIの使いやすさやドキュメントのわかりやすさが魅力。KotlinやGroovyにも対応しています。
https://micronaut.io/

プロジェクト作成

プロジェクト作成にはMicornautのコマンドを使います。これもSDKMANでインストールできます。

$ sdk install micronaut

mnコマンドでプロジェクトを生成します。

$ mn create-app start-mn
Resolving dependencies..
| Generating Java project...
| Application created at /home/naoki/starts/start-mn

プロジェクト名のディレクトリに移動します。

$ cd start-mn

コントローラーは作成されないので、mnコマンドでコントローラーを作成します。

$ mn create-controller MyController

src/main/java/start/mn/MyController.javaが作成されるので少し編集します。

package start.mn;

import io.micronaut.http.annotation.Controller;
import io.micronaut.http.annotation.Get;

@Controller // パスを消しておく
public class MyController {
  @Get(produces="TEXT/PLAIN") // 出力メディアタイプを指定
  public String hello() { // 戻り値をStringに
    return "Hello"; // メッセージを返す
  }
}

ビルド

ビルドはGradleを使います。

$ ./gradlew build

> Task :compileJava
Note: Creating bean classes for 1 type elements

BUILD SUCCESSFUL in 8s
10 actionable tasks: 10 executed

実行

build/libsに実行可能jarが作成されているので実行するとサーバーが起動します。

$ java -jar build/libs/start-mn-0.1-all.jar
07:57:32.751 [main] INFO  io.micronaut.runtime.Micronaut - Startup completed in 1496ms. Server Running: http://localhost:8080

http://localhost:8080にアクセスするとメッセージが表示されます。

※ 8/13追記 1.2からstart-mn-0.1.jarじゃなくstart-mn-0.1-all.jarになった？

ネイティブ化

Micronautでは特別なネイティブ化コマンドは用意されていないので、native-imageコマンドを直接使います。

$ native-image -jar build/libs/start-mn-0.1-all.jar

カレントディレクトリに実行ファイルが作成されます。

$ ./start-mn-0.1-all
08:03:09.159 [main] INFO  io.micronaut.runtime.Micronaut - Startup completed in 131ms. Server Running: http://localhost:8080

Quarkus

QuarkusはRed Hatが開発しているフレームワークで、MicroProfileをベースにしています。
https://quarkus.io/

プロジェクト作成

プロジェクト作成にはMavenを使いますが、通常のarchetypeではなく独自プラグインを使います。

$ mvn io.quarkus:quarkus-maven-plugin::create

groupIdやartifactIdのほかにRESTリソースを作るかきかれるので、yにしておきます。

$ mvn io.quarkus:quarkus-maven-plugin::create
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------< org.apache.maven:standalone-pom >-------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] --------------------------------[ pom ]---------------------------------
[INFO]
[INFO] --- quarkus-maven-plugin:0.19.1:create (default-cli) @ standalone-pom ---
Set the project groupId [org.acme.quarkus.sample]: kis
Set the project artifactId [my-quarkus-project]: start-quarkus
Set the project version [1.0-SNAPSHOT]:
Do you want to create a REST resource? (y/n) [no]: y
Set the resource classname [kis.HelloResource]:
Set the resource path  [/hello]:
Creating a new project in /home/naoki/starts/start-quarkus
...

ビルド

ビルドはMavenでいつもどおり

$ mvn package

実行

targetディレクトリに実行ファイルができるので、javaコマンドで実行することができます。

$ java -jar target/start-quarkus-1.0-SNAPSHOT-runner.jar
2019-07-15 08:25:07,637 INFO  [io.quarkus] (main) Quarkus 0.19.1 started in 0.878s. Listening on: http://[::]:8080
2019-07-15 08:25:07,656 INFO  [io.quarkus] (main) Installed features: [cdi, resteasy]

http://localhost:8080/hello にアクセスするとメッセージが表示されます。

Quarkusの場合、Mavenで実行することでオートリローディングが有効になるので、開発時はこちらを使うほうが便利です。

$ mvn quarkus:dev

ネイティブ化

Quarkusのネイティブ化は、nativeプロファイルを指定してビルドします。

$ mvn -Pnative package

1分ちょい待つとtargetディレクトリに実行ファイルができるので、これを実行するとサーバーが起動します。

$ target/start-quarkus-1.0-SNAPSHOT-runner
2019-07-15 08:31:53,378 INFO  [io.quarkus] (main) Quarkus 0.19.1 started in 0.016s. Listening on: http://[::]:8080
2019-07-15 08:31:53,379 INFO  [io.quarkus] (main) Installed features: [cdi, resteasy]

起動時間やメモリの比較

今回はWSL上のUbuntuでの起動時間と利用メモリを比較してみます。
Helidonでは起動時間が表示されていないので、次のような表示コードを追加しておきます。

System.out.println(ManagementFactory.getRuntimeMXBean().getUptime());

起動時間は次のようになります。

	GraalVM JDK	OpenJDK 12.0.1	native-image
Helidon	864ms	715ms	16ms
Micronaut	1552ms	1387ms	109ms
Quarkus	819ms	720ms	15ms

ネイティブ化すると圧倒的に起動が速くなってますが、GraalVMよりもOpenJDK 12のほうがかなり速いですね。GraalとC2の違いだと思います。GraalではJavaで書かれているGraal自体をJITするのに時間がかかるので起動は遅くなりがちです。

メモリ使用量は次のような感じに。

	GraalVM JDK	OpenJDK 12.0.1	native-image
Helidon	233.7MB	64.9MB	7.4MB
Micronaut	344.6MB	95.2MB	15.0MB
Quarkus	246.6MB	81.3MB	6.9MB

これもネイティブ化するとメモリ使用量が激減してますが、GraalVMよりもOpenJDK 12のほうが少なくなってます。Graalがメモリを使ってるんですかね。

Javaスクリプト入門

みんなでJavaスクリプトに入門しましょう！

クラスをちゃんと定義する

それでは、まずはJavaっぽく書いてみましょう。

public class Main {
  public static void main(String[] args) {
    System.out.println("Hello!");
  }
}

これを、任意のファイル名で保存します。たとえばhello。
実行するにはJava 11以降が必要です。みなさんすでにSDKMANを入れてると思うのでOracle OpenJDKの12.0.1を使ってみましょう。

$ sdk use java 12.0.1-open

では実行します

$ java --source 12 hello
Hello!

実行できました！

これではちょっと面白くないので、先ほどのファイルの先頭にちょっとなにか追加しておきます。

#! /home/naoki/.sdkman/candidates/java/current/bin/java --source 12
public class Main {
  public static void main(String[] args) {
    System.out.println("Hello!");
  }
}

いわゆるShebangですね。

そして実行権限を付加

$ chmod +x hello

実行してみます。

$ ./hello
Hello!

やった！

これはJEP 330: Launch Single-File Source-Code Programsに基づくもので、Java 11から導入されています。
Java11ではjavacせずにJavaファイルが実行できるようになる - きしだのHatena

これを「スクリプト」と呼ばないとき、現代のスクリプト言語も実行時にネイティブコードになったりするので、どの時点でコンパイルされればスクリプトなのか(スクリプトではないのか)という話になっておもしろいですね。

もっとスクリプトっぽく書く

さっきのは あまりにもJavaだったので、もっとJavaっぽくなく書いてみます。

System.out.println("Hello2!")
/exit

このファイルを任意のファイル名で保存します。たとえばhello2。行末のセミコロンも不要です。

では実行します。実行するためにはJava 9以降が必要です。すでに先ほどJava 12を導入してますね。

$ jshell hello2
Hello2!

やった！

もうちょっと複雑なコードを書いてみましょう。

import java.time.*
var t = LocalDate.now()
System.out.println(t.minusMonths(1) + " to " + t)
System.out.println("Hello2!")
/exit

実行してみます。

$ jshell hello2
2019-05-29 to 2019-06-29
Hello2!

だいぶスクリプトっぽい！

注意が必要なのは、ブロックの中ではセミコロンが必要というところです。

import java.time.*
var t = LocalDate.now()
System.out.println(t.minusMonths(1) + " to " + t)
for (int i=0; i< 3; ++i) {
  System.out.println("Hello" + i);
}
/exit

実行してみます。

$ jshell hello2
2019-05-29 to 2019-06-29
Hello0
Hello1
Hello2

Shebangもやってみましょう。

#! /home/naoki/.sdkman/candidates/java/current/jshell
import java.time.*
var t = LocalDate.now()
System.out.println(t.minusMonths(1) + " to " + t)
for (int i=0; i< 3; ++i) {
  System.out.println("Hello" + i);
}
/exit

そして実行。

$ ./hello2
エラー:
'#'は不正な文字です
#! /home/naoki/.sdkman/candidates/java/current/bin/jshell
^
エラー:
式の開始が不正です
#! /home/naoki/.sdkman/candidates/java/current/bin/jshell
   ^
エラー:
式の開始が不正です
#! /home/naoki/.sdkman/candidates/java/current/bin/jshell
               ^
2019-05-29 to 2019-06-29
Hello0
Hello1
Hello2

がーん！！
実行されは するけど、#!の行もJavaとして解釈しようとするためにエラーになっちゃってますね。
これどうにかしないのかな？

7/1追記 BTSは立ってますね。 https://bugs.openjdk.java.net/browse/JDK-8167440

ちなみに、シェルスクリプトで1行目を無視するとかもありますが、OpenJDKソースを改変するなら、ここに

if (src.startsWith("#")) {
  return false;
}

を入れると#がコメントになってイケます。
https://github.com/openjdk/jdk/blob/master/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java#L1194

まとめ

Javaスクリプト最高！

GraalVMはどれだけ遅いか

GraalVM流行ってますね。
そして、多くの人はGraalをAOTとして使うnative-imageのことだけをGraalVMと言ってたりします。
ご安心を。このエントリではGraalをJITとして使うHotSpotモードとGraalをAOTとして使うnative-imageの両方が遅いという話です。

GraalVMは速い、と言われてますが、残念ながらHotSpotモードでC2より速い結果を手元では出せていません。
公式ブログでは1.7倍から5倍速くなると書いてますけど、手元では再現できてません。
Under the hood of GraalVM JIT optimizations - graalvm - Medium

native-imageは速い、というのはよくありますが、これはネイティブ化によりJVMの起動時間や最適化の時間、最適化されずに動く時間が省略されるので起動が速い、という話です。長く動くプロセスの場合、そういった起動にかかる時間というのは無視できるようになり、実行時に集めた情報を使って最適化するJITのほうが速いです。

用語について

ところでここで用語の確認を。
GraalVMというのは、Javaで書かれたJITコンパイラGraalを中心とした多言語環境です。
普通にGraalをJavaのJITコンパイラとして使うのがGraalVMのHotSpotモードです。ようするにjavaコマンドです。
Graalの最適化機構を一般のスクリプト言語から使えるようにしてJavaScriptやRubyのJITコンパイラにしてしまうのがTruffleです。
そして、Graalを事前にJavaコードに適用してネイティブ化するというのがnative-imageです。

計測

ということで、どのくらい遅いか比べてみます。
コードはこのレイトレ。
https://github.com/kishida/smallpt4j/blob/original/src/main/java/naoki/smallpt/SmallPT.java
commonsのFastMathを使っているので、通常のjava.lang.Mathに置き換えて実行します。また、ループ中のSystem.out.printlnはコメントアウトしました。
それはそうと、以前はこのコードはImageIOを使っているのでGraalVMでネイティブ化できなかったのですが、いまではできるようになってます。
実行するとこんな感じのPNG画像が出力されます。

GraalVM 19.0.2 CE

ここではWindowsで動かしてみました。GraalVMは19.0.2CEです。
まずはHotSpotモード。

C:\Users\naoki\Documents\prj>java -version
openjdk version "1.8.0_212"
OpenJDK Runtime Environment (build 1.8.0_212-20190603180034.buildslave.jdk8u-src-tar--b03)
OpenJDK 64-Bit GraalVM CE 19.0.2 (build 25.212-b03-jvmci-19-b04, mixed mode)

C:\Users\naoki\Documents\prj>java SmallPT
Samples:40 Type:master Time:PT9.713S

10秒弱。

ネイティブ化してみます。

C:\Users\naoki\Documents\prj>native-image SmallPT
[smallpt:21796]    classlist:   1,793.30 ms
...
[smallpt:21796]        write:     786.36 ms
[smallpt:21796]      [total]:  26,307.39 ms

C:\Users\naoki\Documents\prj>smallpt
Samples:40 Type:master Time:PT45.234S

45秒。だいぶ遅い！

GraalVM 19.0.2 EE

ついでにEEでも試してみます。

C:\Users\naoki\Documents\prj>java -version
java version "1.8.0_212"
Java(TM) SE Runtime Environment (build 1.8.0_212-b31)
Java HotSpot(TM) 64-Bit GraalVM EE 19.0.2 (build 25.212-b31-jvmci-19-b04, mixed mode)

C:\Users\naoki\Documents\prj>java SmallPT
Samples:40 Type:master Time:PT10.281S

10秒強。あんま変わらん。

ではネイティブ化。

C:\Users\naoki\Documents\prj>native-image SmallPT
[smallpt:43056]    classlist:   2,165.31 ms
...
[smallpt:43056]        image:     788.17 ms
Warning: Generating and stripping of debug info not supported on Windows[smallpt:43056]        write:     775.12 ms
[smallpt:43056]      [total]:  29,450.40 ms

C:\Users\naoki\Documents\prj>smallpt
Samples:40 Type:master Time:PT13.039S

13秒！CEに比べるとめっちゃ速い！

OpenJDK

それではC2版。つまりふつうのOpenJDK

$ java -version
openjdk version "1.8.0_212"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_212-b03)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.212-b03, mixed mode)

$ java SmallPT
Samples:40 Type:master Time:PT6.795S

6.8秒。GraalVMに比べるとだいぶ速いです。

OpenJDKの11でも試してみます。

$ java -version
openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)

$ java SmallPT
Samples:40 Type:master Time:PT5.8484946S

5.8秒。お、ちょっと速くなってる！

まとめ

ということで、まとめるとこう。
ついでにMacでも計測しています。Windowsが8コアでMacが4コアなので、ちょうど倍くらいの時間がかかってますね。CEのnative-imageがそれほど遅くないのだけど、コア数によるものかWindowsとMacの違いか気になるところ。

	GraalVM CE HotSpot	GraalVM CE Native	GraalVM EE HotSpot	GraalVM EE Native	OpenJDK 8	OpenJDK 11
Windows(i7-8Cores)	9.713	45.234	10.281	13.039	6.795	5.848
Mac(i7-4Cores)	20.966	47.069	18.797	19.135	16.783	12.594

グラフにするとこう。

ということで、GraalVMのネイティブイメージは起動以外は速くない むしろ遅い、GraalVM EEのネイティブイメージはCEに比べるとかなり速いけどHotSpotモードほどではない、JDKは8から11でも速くなってる、という結果になりました。
LinuxでやればGraalは速いという噂もあります。

7/4追記 19.1.0が出てたので試してみたけど、CEのnative-imageがちょっと速くなった？

	CE HotSpot	CE Native	EE HotSpot	EE Native
19.1.0 Win	10.676	43.419	10.787	12.972

NetBeansからHelidonを使う

Helidonです、Helidon。

プロジェクトの作成

HelidonはMavenプロジェクト的には素直なので、Mavenはバンドルの3.3.9で大丈夫です。 プロジェクト作成もNetBeansからできます。

新規作成でjava with MavenからProject from Archetypeを選びます。

Archetypeの検索でHelidonといれるとSEとMPが出るので、好きなほうを。
ここではSEにします。

あとは適当にプロジェクト名などを。

プロジェクトが作成されました。

ビルドや実行なども通常のプロジェクトどおりメニューから行えます。

Native Imageの作成

Helidon SEはGraalVMのNative Imageに対応していますが、単にjarファイルをnative-imageコマンドでコンパイルはできなかったので、Mavenからネイティブコンパイルを行う必要があります。
ネイティブコンパイルするときは、native-imageプロファイルをActivateする必要があります。

また、GraalVMのnative-imageコマンドにPATHが通ってる必要があります。バージョンはRC16ではダメでした。19.0.0以降が必要です。
ビルドするとネイティブコンパイルが始まります。

ただ、native-imageにパスを通したりプロファイルを切り替えたりは面倒なので、Quarkusの場合と同じようにGoalを設定するほうがよさそう。

この場合、Goalsにはpackage、Profilesにnative-image、PropertiesにEnv.PATHを設定します。
Env.PATHは${Env.PATH}:で始めて既存のパスを有効にする必要があるのと、パスなのでbinまでいれる必要があることに注意してください。Remember Asにnativeなどを設定しておくとメニューから選べるようになります。

これでプロファイル切り替えをせずにネイティブコンパイルできるようになります。

ということで、やはり1分20秒くらいかけてネイティブコンパイルできました。

NetBeansからQuarkusを使う

Quarkusです、Quarkus。

Mavenのアップデート

QuarkusのビルドにはMaven 3.5.3が必要ですが、NetBeans11にバンドルされているMavenは3.3.9なので、そのままではビルドなどができません。
ということで、Mavenの最新版をダウンロードしてどこかに解凍します。
Maven – Download Apache Maven

そしたら、PreferenceのJavaタブでMavenを選んでMavenを解凍したパスを設定します。

プロジェクトの作成

残念ながら、GUIからのプロジェクト作成は できなさそう。なので、ドキュメント通りにコマンドラインでプロジェクト生成します。

$ mvn io.quarkus:quarkus-maven-plugin::create

そうするとArtifact IDなどを聞かれてくるので、適当に入力していきます。 (もちろん空のMavenやGradleプロジェクトを作成してビルドファイルを編集すれば、プロジェクト作れます。)

※ 6/29追記
0.18.0でネイティブコンパイルがGraalVM 19に対応しました。プロジェクト作成時にバージョンを明示しておく必要があります。

$ mvn io.quarkus:quarkus-maven-plugin:0.18.0:create

実行用Goalの設定

開発時のプロジェクト実行にはquarkus:dev:というGoalを使う必要があります。そのままではNetBeansのメニューからのプロジェクト実行ができません。
なので、プロジェクト実行時に実行されるGoalを指定します。

プロジェクトのプロパティからActionsを選んでRun ProjectのExecute Goalsにquarkus:dev:を指定します。 またSet Propertiesのところにexec.argsでclasspathが指定してあるので、この行は削除しておきます。

そうすると[F6]などでプロジェクトが実行できるようになります。

Native Imageの作成

ついでにNative Imageを作れるようにしましょう。
現時点ではGraalVMの最新であるバージョン19ではなく、ひとつ前のRC16が必要です。
Release GraalVM Community Edition 1.0 RC16 · oracle/graal
※ 6/29追記 0.18.0からGraalVM 19に対応しています。

必須ではないですがJavaプラットフォームとして登録しておきましょう。

Build->Compileでプロジェクトのプラットフォームとして指定しておくのが無難です。

ActionsでAdd Customを選んでNativeを追加します。(別の名前でもいいです)

Execute Goalsにpackage -Pnativeを指定します。また、GRAALVM_HOMEを指定しておく必要があります。
※ 7/15追記 0.19ではGRAALVM_HOMEが不要になっています。

Use JDK for Maven Buildを使うとJAVA_HOMEが埋め込まれるので、それをGRAALVM_HOMEに書き換えるのが楽です。

そうするとプロジェクトメニューのRun MavenにNativeが追加されるので、ここからNative Imageが作成できるようになります。

1分ちょっとかかってNative Imageのビルドができました！