Hatena::ブログ(Diary)

torutkの日記 RSSフィード

2016-05-24

[]Java Day Tokyo 2016に参加してきました #JavaDayTokyo

本日は、Java Day Tokyo 2016|日本オラクル に参加してきました。

なお、午前中は会社で仕事をして、午後からの参加でした。

会場は、東京マリオットホテル、品川駅から10分ほどの御殿山です。お昼を食べる余裕がなく、途中駅でパンを買ってきました。

ホテルに付いた後、会場の場所が分からずさまよってしまいました。入り口に案内がなく、あちこちうろうろしてやっと地下に降りて受付の案内板があり会場にたどり着くことができました。

  • Java Day Tokyo 2016のサイトには会場アクセスでホテル名までしか記載がない
  • ホテルの入り口にJava Day Tokyo 2016の案内が見当たらなかった

さて、午後の部最初のセッション Java SE 9 Overviewの会場に入りました。

入り口を入るときに会場係のお兄さんが「立ち見です」と言ってたので、壁に沿って中間まで進んでみると、前の方の席がちらほら空いているように見えました。行ってみるとそこそこ空席がありました。

Java SE 9 Overview

米オラクルのBernard Traversatさん。

  • Java 9の第1優先事項はセキュリティ
  • JVMプロセス間でもっとメモリ共有してメモリ使用量を削減
  • モジュールシステムの導入(Project Jigsawのことですね)
    • モジュールJAR java -listmods でJDKのモジュールJAR一覧が見れる
    • モジュールの定義で公開するパッケージ、公開しないパッケージを制御
  • G1GC
  • JShell
  • JDKのバージョン表記文字列の変更(ルールの明確化)
  • sun.misc.* と sun.reflect.* は削除。但し次は残る
    • Unsafe, Signal, SignalHandler, Cleaner, Reflection::getCallerClass, ReflectionFactory
  • JDK 9の機能は、JEPを見よ
  • Java SE Advanced Management Console
    • 複数のPCにJavaのバージョンがどう入っているかなどを管理(インベントリ管理みたいなもの?)

Java 9の先の話

  • Object Data Layout
    • ヒープ上にインスタンスを生成するとインスタンス自身の場所とインスタンスのフィールドで参照している別インスタンスの場所が散在する。配列(リスト)では散在っぷりが顕著になる。これを局所化できるようにすることを検討
  • Project Panama

Java SE 9リリース予定まで1年を切って、そろそろOpenJDK 9の開発もフィーチャーコンプリートとなるので、そろそろ固まってきたという印象です。

Project Jigsawではじめるモジュール開発

Java Champion 櫻庭 祐一さん。

  • 今のJARには2つの問題
    • ごちゃごちゃっとしたクラスパス
    • 巨大な標準APIのJAR(rt.jar)
  • JARは依存関係、バージョンの仕組みがないため「JAR HELL」を招く
    • Hadoopを実行するときは130個(!)のJARをクラスパスに定義
  • Project Jigsawでは、モジュールという仕組みを導入し、依存関係、公開、バージョンの3つを制御(ただしバージョンの制御は弱い)
    • 従来のJARの仕組みは継続して利用可能(unnamed なmoduleとして扱われる模様)
  • モジュール定義はmodule-info.java(ファイル名固定)に記述し、これはソースコードのディレクトリのトップに配置する
src - net - jitb - jigsaw -+- Peace.java
  |                        +- PeaceFactory.java
  |                        +- internal - Cutter.java
  +-- module-info.java  
    • コンパイル時にmodule-info.javaをファイルシステム上で再帰的に検索すると重いから、とのこと
  • 最低限のモジュール定義記述はモジュール名だけ
module net.jitb.jigsaw {
}
  • requires 文(末尾のsは複数形のsではなく、三単現のsなので、複数のモジュールをrequiresするときはひとつずつrequires文を記述)
    • クラスライブラリ net.jitb.jigsawパッケージ を作成し、この中のクラスがJavaFXを利用する場合、次のようにモジュール定義を記述
module net.jitb.jigsaw {
  requires javafx.controls;
  requires javafx.graphics;
  exports net.jitb.jigsaw;
}
    • exports に記載するのはパッケージ名、requiresに記載するのはモジュール名、まぎらわしいので注意を
    • net.jitb.jigsawモジュールを使用する上位のモジュールで、net.jitb.jigsawモジュールが依存するモジュールを直接使う場合、上位のモジュールでrequires文を記述するか、requires public文に替えて依存するモジュールを上位に公開する(requires public javafx.graphics;)
  • アプリケーションを実行する際、mainメソッドを持つクラスをモジュール外部(javaランチャ)から呼び出すので、メインクラスを含むパッケージはexportsしておく必要あり
  • javacコマンドに、モジュールが配置されているパスを指定する-mpオプションが追加される
    • mpオプションで指定するのはディレクトリ
  • jdepsコマンドでモジュールの依存関係を確認できる
  • jlinkコマンドで、JREから必要なモジュールを抽出してカスタムなJREを作成可能

その他

Java Concurrency, A(nother) Peek Under the Hood

日本オラクルのデイビッド・バック さん

  • シングルスレッドは学校の宿題まで
  • ハイゼンバグが厄介
  • メモリモデルの話
  • ここで特殊相対性理論の話に
    • プログラムのコードが、書かれた順番に実行されるとは限らない、ということを、相対性理論での観測者が異なると観測される事象の順番が同じとは限らない、ということと対比
  • Javaのメモリモデルは当初はsynchronizedとvolatileについて定めていたが、JSR-133でvolatileのhappened before、finalについて追加された。
  • JEP 188でメモリモデル改善
  • デモ)2つのスレッド間で happened beforeなイベントがないときに最適化の違い(HotSpot クライアントコンパイラとサーバーコンパイラ)で動きが変わる
  • JITコンパイラの生成したコードをHSDISでIntel CPUコード(アセンブリ言語コード)で確認
  • 書籍「Java並行処理プログラミング」超おすすめ

Java 9で進化する診断ツール

NTTコムウェア株式会社末永 恭正さん

  • jcmdとjhsdbのコマンドだけ覚えて帰ってね
  • jstack, jmapなどはもう使わない(JavaDocに「試験的」と書かれているツール)
  • jcmdは JDK8にも入っているが、JDK9で拡張
    • 一例としてJNIライブラリロード、JITコンパイラ、ファイナライザなどなどの情報収集
    • JavaVMログ出力の制御(例: jcmd 1234 VM.log output="file=gc.log" output_options="filecount=5,...)
    • VM.log rotateでその場でログローテーション実施可能(cronから動かせばデイリーでローテートができる)
      • 出力先がファイルで、filecountが有効であること
    • jcmd VM.infoでクラッシュレポートと同等のログを生成
    • JITcompilerのコンパイルコードキャッシュをダンプ
  • hsdb
    • コアファイルを開いてGUI表示(CUIもある)
    • クラッシュしたスレッドを見つける(hs_errを吐くクラッシュの場合)
    • ディスアセンブルしてコードを見る(hsdis必要)
    • hsdis必要、hsdisはkenaiサイトのものは古い(6年前)ので要注意

オラクルコンサルが語るJava SE 8新機能の勘所

日本オラクルの伊藤 智博さん

Java SE 8 で導入された次の3つの機能が従来の記述に対して優位性があるかをパフォーマンス観点で解析しました、という内容のセッションです。

  • Date and Time API
  • ラムダ式
  • Stream API

Java Flight RecorderとMission Controlを使って性能の計測と解析を実施、CPUリソース、JavaVMに中断された時間(GC)、処理時間を順次確認。

今回のデモでは、いずれも既存の書き方に対して同等以上でした。以下トピックメモ

  • Stream APIのparallel()の有効性を確認するのに物理36コア(72スレッド)のマシンを使用! 途中でGCが発生しないようメモリも128GB(? 256GBだったかも)を割当
  • まずCPU使用率を見て、測定プログラムがCPUを使いきっているかを確認
  • GCの実行回数を確認(比較対象の双方でほぼ同じGC状況かを見ていたようです)
  • 処理時間は、1億回実行して測定
  • Stream APIのparallel()では、並列数を1から72まで増やしながら計測
    • 物理コア数(36)までは、コア数を増やすと処理時間がリニアに減少
    • 物理コア数を超えて並列処理すると、処理時間はほぼ横ばい(72スレッドでは36スレッドでの処理時間より10%程度速い)

感想のようなもの

午前から参加したかったのですが、仕事の状況から午前仕事をしてから午後参加しました。12:00に会社を出て、13:00のセッションに入るため、昼食はとらず駅でパンを買って、それでもちょっと間に合わず・・・。パンは午後1つ目のセッション終了後に食べました。コーヒーが飲めなかったので午後はちょっと睡魔と戦う羽目に。

Java SE関係を中心に聴講しました。今回、NetBeans IDEの顔であるGeertjan Wielenga氏が初来日だったので、こちらのセッションも聴きたかったのですがちょっと残念。