Devoxx Belgium 2019 - Day 4

LINEでは年に1回の海外カンファレンス補助があるので、ベルギーのDevoxxに来てます。

今日はConference Daysの2日目。しかし寝坊・・・
ところで会場の向こうには風力発電が見えます。
f:id:nowokay:20191108093958j:plain

今日聞いたセッションはこんな感じ。Ask the Java Architectが一番おもしろかった。

Optimizing the Performance of Machine Learning in Enterprise Java SaaS with GraalVM, Python and CUDA

GraalVMといってもNative Imageは関係なくて、PythonなどTruffleベースの言語からCUDAが使えるようにするという話です。
f:id:nowokay:20191108101255j:plain

grCUDAという、Truffleベースの言語からCUDAが使える仕組みをNVIDIAとGraalVMチームが一緒に開発しているらしく、そうするといろんな言語から同じようにCUDAが使えるというのを目指してるっぽい。
これは楽しそう。
f:id:nowokay:20191108102159j:plain

あと、なんかNetSuiteというのを紹介してたけどなんだったんだろう?ERPパッケージらしい

The past, present and future of the Java type system

Javaの型を紹介するショートセッション
f:id:nowokay:20191108102615j:plain

Oakからenumジェネリクス、Lambda、varなど型の扱いの拡張の歴史を紹介して、Valhallaのinline classやAmberのrecordにつなげるというセッションでした。

Ask the Java Architect

Javaアーキテクトに話を聞いてみようというセッション
f:id:nowokay:20191108104420j:plain

主にBrian Goetzが話をしていました。
会場での質問や、Twitterで #askarch タグをつけた質問に答えるセッションです。 とりあえず、話題にでたもののまとめ

  • Alpine Linux対応について。Project Portola
  • 検査例外について。検査例外自体は失敗ではなく、その使い方に問題があったという話。
  • Deprecationについて。LinkedListをDeprecatedにする?という冗談が共通の話題っぽい
  • Project Loom。非同期はデバッグとかプロファイルとか大変
    構造化並列という新しいプログラムモデルが導入できるとか言ってたかな。
  • GraalVM native imageについて
  • 14で正式化されるswitch式について。13と一緒
  • 3項演算子の話?(ternary operatorと聞こえた)
  • Reflection。Valhallaで変える必要がある?specialized genericsとか。
  • モジュールシステム。Genericsが最初は複雑といわれてたけど今は当たり前になっていて、そんな感じで時間がたつと当たり前になるんでは
    JDK自身については絶対に必要

ぼくも質問してみました。

ちゃんと答えてもらえて、エスケープシーケンスや改行の扱いなどで再考する必要があるということでした。
そこからPreview featureの話になって、6ヶ月だけのpreview期間はフィードバックを集めて作業するのに必ずしも十分ではないという話をしていました。
それから、ぜひフィードバックをくれ、と。
フィードバックについては、ドキュメントをちょっと眺めて文句をつけるんではなくて、使ってみてどういう場合にどういう不具合があったかという形で報告してもらえると役立つとのこと。

Java. Migrating to 11 in real app

Java 11への移行のやりかたについて f:id:nowokay:20191108110254j:plain

リリースサイクルの変更やライセンスの変更の話をしていたのだけど、Repeat after me・・・Java・・・Eleven・・is NOT・・・PAIDってみんなやってたのおもしろかった。
f:id:nowokay:20191108110343j:plain

Bootiful Kotlin

おもしろプレゼンをするJosh Longさんです。
f:id:nowokay:20191108110519j:plain

会場のみんながたぶん(cがかぶってる・・・)ってつっこんでたと思うんだけど
f:id:nowokay:20191108110609j:plain

流れでカーソルを先頭にもっていったときに何事もなかったかのようにc消してて、すげー場慣れしてるなーと思いました。
f:id:nowokay:20191108110629j:plain

おもしろかった。

Java Packaging Tool: Create Native Packages to Deploy Java Applications

インストーラーを作るツールの話
f:id:nowokay:20191108111027j:plain

14以降でIncubatorとして入って、16で正式版になるだろうとのこと。
コマンドライン引数やAPIは確定ではないので、たくさんフィードバックが欲しいらしいです。
f:id:nowokay:20191108110944j:plain

帰りの電車とアントワープ

帰りは電車で 。 f:id:nowokay:20191108094035j:plain

アントワープ駅につくのだけど、めちゃかっこいいです。プラットフォームは4階層あるのかな。
f:id:nowokay:20191108094141j:plain

プラットフォームから外にでてもかっこいい
f:id:nowokay:20191108094236j:plain

今日のビール

結局ホテルの近くでごはん食べつつビール飲めるところというと、Bier Central一択みたいな感じでした。
まずLambicus Blanche Timmermans
ランビックでありブランシェ。すっぱくてさわやか。
f:id:nowokay:20191108095353j:plain

そしてDelirium Tremens
f:id:nowokay:20191108095440j:plain

それと、ハンバーガー食べました。 いままで食べたことがあるハンバーガーで一番おいしい。そこらで食べるパンがすごくおいしいし、チーズもおいしいし、そうするとハンバーガーもおいしいって感じです。
f:id:nowokay:20191108095520j:plain

最後はBlanche de Bruxelles
日本で飲んだのよりホップの味がする気が。
f:id:nowokay:20191108095704j:plain

そして、今日はちゃんとノンアルのヒューガルデンを買って帰りました。
f:id:nowokay:20191108095808j:plain

おやすみなさい

聞きたかったけど聞いてないセッション

Why We Hate Java Serialization And What We're Doing About It
Brianのセッションは、寝坊で・・・
Javaシリアライズについて問題意識があって、改善していくって話のようです。
http://cr.openjdk.java.net/~briangoetz/amber/serialization.html

Beyond Jakarta EE 8, by and for the Jakarta community

Back to the Future: How 80s Arcade Games Taught me Clojure
ハイヒールのヒールがかわいすぎる

Play an acoustic guitar with a Raspberry Pi

How to Build A Decompiler

Devoxx Belgium 2019 - Day 3

LINEでは年に1回の海外カンファレンス補助があるので、ベルギーのDevoxxに来てます。

DevoxxはヨーロッパのJavaコミュニティで、ロンドンやパリなど各地でカンファレンスを行なっていますが、ベルギーが最大です。
毎年、Javaのびっくり発表がDevoxx Belgiumというイベントであるというのを認識していて気になっていたのですが、今回初めて来てみました。

今日はConference Daysの初日でキーノートから始まりました。
https://devoxx.be/wednesday-schedule/

今日聞いたのはキーノートの他に次のセッションですが、Spring BootをGraalVM Native Imageで動かすセッションが一番おもしろかったです。

KeyNote

Conference Daysの初日ということで、キーノートから始まります。
キーノートは3つのセッションにわかれていました。
ところでDevoxx Belgiumは映画館で行われていて、各部屋300-500人くらい入る感じですが、キーノートで一気に数千人入るような部屋はありません。なので、一番大きい部屋でキーノートが行われて他の部屋に配信される感じになっています。
この部屋には話してる人いませんね。
f:id:nowokay:20191107104927j:plain

この部屋にいました。
f:id:nowokay:20191107105527j:plain

Welcome to Devoxx: practical info

最初のキーノートはDevoxxについての説明です。
Devoxxはヨーロッパを中心に活動するコミュニティで、年間21のイベントをやっていて、先週がウクライナで来週がモロッコらしい。
その中でも最大なのがこのベルギーで、今年は3300人の登録とのこと。去年3500人でめっちゃ混んでたから3300人で打ち止めたということらしい。
そして去年は4ヶ月でsold outだったのが、今年は10日でsold outだったとか。来年はもっと早くなる気がする。
抽選にするかどうかということを話していました。

The Hitchhiker’s Guide to Diversity (Don't panic!)

2番目のセッションはダイバーシティについて。
なのですが、途中で配信が切れてしまった・・・
f:id:nowokay:20191107102256j:plain

「ゴスリンが話してくれたんだけどつないだ瞬間切れた」とか冗談を言ってましたが、4K対応したら電源が追いつかなくて落ちたということらしい。

Qualities of a Highly Effective Architect

よいアーキテクトがどうのというセッション。
パワポアーキテクトになってはいけない、という言葉が印象的
f:id:nowokay:20191107105607j:plain

Abstractions Without Regret with GraalVM

GraalVMのセッション。
だけどやはりNative Imageが中心になりますね。

今月出る19.3でJava 11をサポートするそうな。
f:id:nowokay:20191107110253j:plain

あとのSpringのセッションのほうが知らない情報でてたな。

Developing Java applications leveraging the Quantum Internet

JavaFXがんばってるJohan Vosさんの量子通信の話。 f:id:nowokay:20191107110931j:plain

途中で覗き見とかが難しいのでセキュアだと。
SuperpositionとかEntanglementとか量子の話をしたあと、スイッチとか入れるの難しいよねという話をして、ただスイッチ作れれば通信ができていいってことを話してました。
f:id:nowokay:20191107110759j:plain

そして、Javaでつくってる量子コンピュータシミュレータの紹介。
https://github.com/gluonhq/strange

Implementing a Simple JVM in Rust

RustでJVMを実装する話
f:id:nowokay:20191107111010j:plain

GCは実装してないということなので、unit256_tさんがRustで作ったJVMのほうがGCJITもあって実装が進んでますね。

会場への問いかけで、Rust使ってる人という質問には1/4くらいが手をあげてたのだけど、Rustをプロダクトで使ってる人という質問はだれも手をあげなかった。まあJavaイベントだからね。

簡単な実装をする上でのJVMのだいたいの仕組みというのがわかりやすくてよかった。
f:id:nowokay:20191107111239j:plain

あとはRustでの実装の説明 f:id:nowokay:20191107111355j:plain

Running Spring Boot applications as GraalVM native images

SpringをGraalVM Native Imageで動かす話
f:id:nowokay:20191107111701j:plain

Java Buildpack Memory Calculatorというのを紹介していました。メモリ使用量やクラス数から最適なオプションを計算してくれるユーティリティなのかな。
https://github.com/cloudfoundry/java-buildpack-memory-calculator
f:id:nowokay:20191107112021j:plain

Parallel GCはGraalVM EEに入るとか。
f:id:nowokay:20191107112545j:plain

Native Imageに必要な設定などはSpring Graal Nativeを見ればいいぽい
https://github.com/spring-projects-experimental/spring-graal-native

Spring Boot 2.2ではCGLIBやProxyを使わないようにできるので、native imageに優しくなっているらしい。すごい。
f:id:nowokay:20191107112748j:plain

あと、AOT用の工夫はJITでも有効だと言ってました。
相当がんばっとるな。
GraalVMチームと協力して開発をすすめているらしい。

Understanding Low Latency JVM GCs

G1GC、Shenandoah、ZGC、C4の説明のセッション。
f:id:nowokay:20191107113132j:plain

GCの使い分けのまとめ。しかし、ZGCはWindows対応するっぽいので、Windowsならってとこは変わりそう。
f:id:nowokay:20191107113455j:plain

しかし、話とともにちょっとずつ資料を表示するスタイルで疲れた・・・
GC使い分けとか、ちょっとずつ出されても・・・みたいな。

Evolving Java for the Serverless Era with Micronaut

Micronautのセッションなんだけど、初日に聞いたセッションの一部ぽいので途中退出。
f:id:nowokay:20191107113742j:plain

What's coming in Scala 3

ということでScala 3のセッションに。
f:id:nowokay:20191107113845j:plain

Scalaようわからんけど、楽しそうでした。

Meet & Greet in exhibition floor until 20h30

今日は会場でビールがでました。
ブロンド系なんだけど、銘柄まではわからず。ベルギービールを当てるのは種類が多すぎるし日本で飲みにくいものも多いので相当難しい・・・
f:id:nowokay:20191107113946j:plain

今日のビール

で、ホテルに戻って、気になっていたDuvelの看板がでている店に。
f:id:nowokay:20191107114330j:plain

ボトルかよ、という気持ちw
f:id:nowokay:20191107114242j:plain

そして、料理もない店でした。。。まあ4Eurでお釣りが来るくらい安くていいのだけど。ビールだけ出て料理は出ない店が結構多いふいんき

いつもどおりノンアルヒューガルデンを買って・・・と思ったら、ふつうのヒューガルデンだった。
f:id:nowokay:20191107114947j:plain

夜のアントワープ駅もきれい。
f:id:nowokay:20191107114621j:plain

聞かなかったセッション

ついでに、聞きたいけど裏番組だったりで聞かなかったのをまとめておきます。
Project Loom: Helping Write Concurrent Applications on the Java Platform

Quarkus why, how and what by Emmanuel Bernard

Java on ARM Theory, Applications and Workloads

Your Program as a Transpiler: Applying Compiler Design to Everyday Programming

Devoxx Belgium 2019 - Day 2

LINEでは年に1回の海外カンファレンス参加補助があるので、ベルギーのDevoxxに来ています。
(夏のJVMLSは自費です)

Devoxxは月・火のDeep Dive Daysとと水・木・金のConference Daysにわかれていて、今日はDeep Dive Daysの2日目です。
https://devoxx.be/tuesday-schedule/

会場はKinepolisという映画館
f:id:nowokay:20191106093910j:plain

映画館だけあって、スクリーンはでかいし席はすわりごこちいいし後ろの席からも見やすいです。

Solving Memory Leaks in the JVM

Kirkさんのセッションです。Deep Diveということで、3時間のコマです。
https://devoxx.be/talk/?id=109305 f:id:nowokay:20191106101215j:plain

セッションとしては、VIsualVMやjClarity、jcmd、jmapを使ってメモリリークを探す説明でした。
f:id:nowokay:20191106101416j:plain

しかしながら、英語がよく聞き取れなかったり説明をききのがしてたりで、なんのためにそのコマンドでオブジェクトがたくさん使われてるか発見するのかというのがよくわからなかった・・・
YouTubeでは字幕もつくので、見直すといいんではなかろうか・・・

Migrating AWS Lambda's frontend from Java 8 to 11

もとのタイトルは「Learnings from migrating a production service from JDK8 to JDK 11」でしたが、プレゼンタイトルではLambda FrontendのMigrationということになっていました。
https://devoxx.be/talk/?id=106451
f:id:nowokay:20191106102039j:plain

それでLambdaの説明が始まると出ていく人が結構いましたが、Lambda上で動かすコードをMigrateするのではなくて、Lambda自体の認証などを行うフロントエンド部分をMigrateしたという話で、おもしろかったです。

Java 8からJava 11でパフォーマンスにインパクトがあったのはG1GCがデフォルトになったこととCompact Stringだとのこと。
f:id:nowokay:20191106095653j:plain
あと、-XX:+UseStringDeduplicationで文字列の重複をなくすとメモリ利用が80%へったけどGC停止時間は増えたと。結局これどうしたんだろう?ライブラリ中の文字列重複を省いていったのかな。

デプロイは小さなリージョンから大きなリージョンへ。
f:id:nowokay:20191106095008j:plain

結果としてGC停止時間はかなり減っています。
f:id:nowokay:20191106095937j:plain

あと、レイテンシーが99パーセンタイルだと20%減って、99.99パーセンタイルだと33%減った、と。
f:id:nowokay:20191106095847j:plain

総じて、バグはなくパフォーマンスもよくなってよかった、という話でした。

GraalVM native images explained

Olegさんの、GraalVM native imageのセッション。身振り大きく説明していて、楽しかった。
https://devoxx.be/talk/?id=104405
f:id:nowokay:20191106102128j:plain

とりあえず前提として、native imageによるAOTと通常のJVMでのJITでこういう違いがあるよ、という話。
f:id:nowokay:20191106103433j:plain

クラスひとつでどれだけコンパイル時間がかかるんだ、ってことに関しては、システムクラスがたくさん使われているという話なのだけど、それを説明するために利用しているクラスを全部可視化するというのをやっていて、これすごく興味ある。
f:id:nowokay:20191106102250j:plain

あと、リフレクション使ってるコードに対してnative-image-agentを使って自動的に利用クラスの設定ファイルを出力するというデモをやっていました。
こんな感じで入力されたメソッドを呼び出すデモ。
f:id:nowokay:20191106103400j:plain

普通にnative imageを作るとうまく実行されないので、設定ファイルが必要なのでJava Agentを使うと。
f:id:nowokay:20191106102643j:plain

こんなJSONができています。

[
{
  "name":"HelloReflection",
  "methods":[{"name":"foo","parameterTypes":[] }]
}
]

あと、プログラムから読み込むリソースファイルなどは設定を書いておく必要があるけどMicronautとかは あらかじめ書いていてくれるよ、という話。
f:id:nowokay:20191106102920j:plain

最終的にはJITのいいところも取り込まれればいいよね、ってことでした。
f:id:nowokay:20191106103613j:plain

Choosing a JDK: Ask the Distributors

JDKバイナリ配布する人にいろいろ聞いてみよう、というBOFです。 https://devoxx.be/talk/?id=21103
f:id:nowokay:20191106103824j:plain

まんなかにいるAzulのSimon Ritterさんによる進行で、右はBellSoftのLibericaの人。左のひとはだれだったかよくわからない・・・
あと、プロジェクタの左側にSAP Machineの人が座っていました。
そんな感じで、JDKのバイナリ配布をしてる人たちがいろいろ話すBOFでした。

JavaLinuxみたいにいろいろなディストリビューションがあるんだという話。

Javaが動くVMの一覧。
f:id:nowokay:20191106103817j:plain

BOFにしては人が多くて50人くらい入っていました。 いろいろ挙手があったのだけど、Oracle JDKを使ってる人という質問には半分以上が手をあげていた。
Java 8を使ってる人がほとんどで、Java 11が1/4、13を使ってる人も少し、という感じ。
Intel CPUがほとんどで、ARM使ってる人が2人かな。
あと、Dockerで動かしてる人が1/3くらいいて、その半分はKubernetes

OpenJDKのDocker Imageを使ってる人という質問に手をあげる人はだれもいなくて、ダウンロードはたくさんあるので木になるとSimonさんは言ってた。

Dockerの話になったのは、Docker Imageを提供しないのかという質問をした人がいたからで、その人は最小のイメージが欲しいといっていたので、Libericaの人がAlpineを使えと切ってすてていた。そういえばLibericaの人は(Project Portola)https://openjdk.java.net/projects/portola/やってる人だったな。

サポートはどういう風にやっているかという質問があって、パッチについて - A: OpenJDKに還元する。変更は他のディストリビューションにも広まる - B: OpenJDKに提供しない

という選択肢があるし、お金払ってサポートするのだからBのほうがいいかもしれないけど、コミュニティに情報を共有するほうがいい、って言ってた気がする。

Oracle JDKとOpenJDKの違いについて、会場の人がJavaFXは入ってないしJava SEでもない、どこもJavaFXを入れていないということを言う人がいたんだけど、前にいるSimonさんとLibericaの人が「We do!!!」って手をあげたのがおもしろかった。

終了

電車で帰ります。
f:id:nowokay:20191106110914j:plain

今日のベルギービールはPrimus。
f:id:nowokay:20191106110901j:plain

まあ、普通のピルスナーなんで、ベルギーまで来て飲むほどのものではないけど、他の店が閉まっていたので・・・
BOFまで聞いて帰ると21時とかで店がしまっていて選択肢がなくなるのがつらい。
でもBier Centralでハンバーガーのほうがよかったかな。

今日もノンアルのヒューガルデンを買って帰ったのだけど、お店のおにいさんに「お前は酒飲みに見えるのになんでノンアルを買うんだ!」と聞かれました。
日本から来て、これは日本で売ってないというと、日本の酒はニッカとかヤマサキとかウイスキーが好きだと言っていました。
f:id:nowokay:20191106110838j:plain

ということで、明日からはConference Daysです。おやすみなさい。

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の話。
このセッションはすごく面白かったので、ひとつ動画を見るならこれをおすすめします。
f:id:nowokay:20190731190346j:plain

朝ごはんを食べながら聞いてます。 f:id:nowokay:20190731190303j:plain

JITとAOTについて比較しながら話がすすみます。
f:id:nowokay:20190731191918j:plain

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

比較はこんな感じに。
f:id:nowokay:20190731191926j:plain

そしてJITサーバー!!おもしろいことを考えるなーと思いました。
f:id:nowokay:20190731191930j:plain

そこまで含めた結果はこんな感じ。
f:id:nowokay:20190731191935j:plain


JIT and AOT in the JVM with Mark Stoodley

Improving GraalVM Native Image

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

いつものGraalVMの紹介
f:id:nowokay:20190731193054j:plain

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

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

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

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


Improving GraalVM Native Image with Christian Wimmer

GraalVM Workshop

GraalVMのネイティブイメージ生成についてのWorkshopでした。
f:id:nowokay:20190731195622j:plain

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

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

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

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

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

JIT and AOT in the CLR

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

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

いろいろ作ってて、いまは3世代目を作ってるということで、それぞれの世代の説明をしていました。
f:id:nowokay:20190731194913j:plain


JIT and AOT in the CLR with Mei-Chin Tsai

Lunch

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

デザートもありますが、だいたい取り損ねる。
f:id:nowokay:20190731191007j:plain

jWarmUp

Alibabaで作ってるjWarmupの話。
JEP draft: JWarmup precompile java hot methods at application startup f:id:nowokay:20190731195857j:plain

どうやってウォームアップするかという話でした。 f:id:nowokay:20190731195909j:plain

質疑も結構でてましたが、よく覚えてない・・・
f:id:nowokay:20190731200208j:plain

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

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

TornadoVM

JavaコードをGPUFPGAで動かすという話。
JEPもある!
JEP draft: Enable execution of Java methods on GPU
f:id:nowokay:20190731200939j:plain

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

コードにはforループに@Parallelをつける感じ。
f:id:nowokay:20190731200948j:plain

そうするとOpenCLに変換される。Aparapiを思い出す。
f:id:nowokay:20190731200959j:plain

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

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

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

Panama Update

Panamaの話。
f:id:nowokay:20190731202057j:plain

資料に子どもの写真がはさまって、みんな笑顔だった。
f:id:nowokay:20190731202037j:plain

内容としては、ポインタAPIとか、
f:id:nowokay:20190731202044j:plain

構造体レイアウトとか。
f:id:nowokay:20190731202054j:plain


Panama Update with Maurizio Cimadomore

Metropolis Workshop

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

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

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

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

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

Dinner

今日は公式ディナーの日。
f:id:nowokay:20190731191149j:plain

もちろん無限ビール!
f:id:nowokay:20190731191214j:plain

そして肉! f:id:nowokay:20190731191242j:plain

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

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

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はOracleWebLogicチームが開発しているフレームワークです。
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と入力すると2つに絞られます。

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をおして最新を選びます。
その後、groupIdartifactIdversionpackageを入力します。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が返ってきます。
f:id:nowokay:20190715073853p:plain

ネイティブ化

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にアクセスするとメッセージが表示されます。
f:id:nowokay:20190715075901p:plain

※ 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

groupIdartifactIdのほかに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 にアクセスするとメッセージが表示されます。 f:id:nowokay:20190715082238p:plain

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

f:id:nowokay:20190715093023p:plain
ネイティブ化すると圧倒的に起動が速くなってますが、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

f:id:nowokay:20190715092812p:plain

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

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をJavaJITコンパイラとして使うのがGraalVMのHotSpotモードです。ようするにjavaコマンドです。
Graalの最適化機構を一般のスクリプト言語から使えるようにしてJavaScriptRubyJITコンパイラにしてしまうのが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画像が出力されます。
f:id:nowokay:20190627042056p:plain

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がそれほど遅くないのだけど、コア数によるものかWindowsMacの違いか気になるところ。

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

グラフにするとこう。
f:id:nowokay:20190627045257p:plain

ということで、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を選びます。
f:id:nowokay:20190620004502p:plain

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

あとは適当にプロジェクト名などを。
f:id:nowokay:20190620005453p:plain

プロジェクトが作成されました。
f:id:nowokay:20190620005633p:plain

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

Native Imageの作成

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

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

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

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

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

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