2013/09/24

JavaOne 2013 SF 第3日目

このエントリーをはてなブックマークに追加

3 日目のメインイベントはなんといっても、明日のライブのチケットを取得すること。えっ、違う?

チケットは夕方から受け取れるのですが、これがないと明日のライブに入れません。ということで、ちゃんと受け取りました ^ ^;;

さて、今日聴講したのは、以下のセッションです。

今日のはじめの Samll Chage and Big Files .... は Joe Darcy と Alan Bateman というスペックリード 2 人のセッションなのですが、Java SE 7 の Project Coin と New File System API を紹介しただけ。

もう Java SE 7 がリリースされてからかなり時間がたっているんだから、いつもと同じ話ではなく、もうちょっと深いところとか、実装がどうなっているかとか、それ以降の予定とか、何でもいいから違った観点から喋ってもらいたかったです。

Collection も、Stream とか最近の話題をもうちょっと取り入れてほしかったです。ただ、このセッションも人気があって、5 分前に部屋に入ったら、もう席が残りすくないぐらいでした。

JavaFX の Widget はもともとあまり期待していなかったのですが... もっとセッションの構成をしっかりしていればおもしろくなるんですけどねぇ。説明不足だということが分からないのかなぁ....




Alan Bateman



Joe Darcy



Hendrik Ebbers と Mark Heckler
 

CON7941 Lambda: A Peek Under the Hood


スピーカは Brain Goetz。

去年も同タイトルのセッションがありましたが、内容は同じです。でも、去年よりも InvokeDynamic について分かってきたのか、今年の方がより理解が深まりました。

大きな問題として、Lambda 式の型をどうするかという点があります。初期のプランでは関数型だったのですが、いろいろと問題があって却下されました。そこで、導入されたのが Functional Interface です。

Functional Interface であれば、いままでの Java とのコンパチビリティも保たれます。

その次に問題になるのが、Lambda 式の表現です。一番簡単なのは内部無名クラスとして表すことです。初期の Project Lambda の実装では実際に内部クラスで表現されていました。

しかし、内部クラスだと、Lambda 式ごとにクラス生成を行う必要があります。また、毎回新しいインスタンスをアロケーションしてしまうという問題もあります。

そこで、新しい表現である MethodHandle で表すという案が浮かびます。Lambda 式は言語レベルのメソッドオブジェクトですが、MethodHandle は VM レベルのメソッドオブジェクトと考えられます。

そこで、Lambda 式を脱シュガーして、メソッドを取り出し、MethodHandle で表すということです。

しかし、Lambda 式を直接 MethodHandle に置き換えるにも問題があります。たとえば、メソッドのシグネチャが変化してしまうなどです。

最終的には InvokeDynamic で Lambda 式を表現するということになっています。

InvokeDynamic で扱うには、Lambda 式を脱シュガー化して static のメソッドに変換します。この変換は Lambda 式がはじめにコールされた時の bootstrap で動的に行います。

フォーマンスには以下の 3 つの観点があります。

  • Linkage cost: Lambdaをキャプチャする時に一度だけ
  • Capture cost: Lambdaのインスタンスする時のコスト
  • Invocation cost: Lambdaのメソッド実行のコスト

Linkage Cost は無名クラスに比べると早くなっており、Capture Cost は無名クラスと同等です。ただし、キャプチャしない場合は無名クラスよりパフォーマンスがよくなります。

CON9732 The Modular Java Platform and Project Jigsaw


スピーカは Java SE のチーフアーキテクトであり、Jigsaw のスペックリードである Mark Reinhold です。

昨年の JavaOne でも Jigsaw のセッションがあったのですが、一昨年とまったく同じ内容でした。これでは、Java SE 8 からドロップするのもしかたがないと思ったのでした。

まさか、3 年連続で同じ内容にはならないとは思っていましたが、若干の不安が。しかし、今年はずいぶん内容が変わりました。

昨年まで、モジュールを Java の文法的にどうやって表すかということが、セッションの半分を占めていましたが、今年はまったく出てきません。これが、モジュールを Java で表すことにあきらめたのか、それとも変化がないから解説しなかったのかは、Jigsaw の ML などでチェックしないと分からないです。

今回のセッションの中心はモジュールファイルをどのようにリンクするかということでした。

その前に、Java SE 8 のコンパクトプロファイルの話です。

コンパクトプロファイルには Compact 1, Compact 2, Compact 3 の 3 種類があり、それぞれランタイムのライブラリが 11MB、16MB、30MB となります。JRE 全体だと 54MB です。

コンパクトプロファイルは基本的には Java SE Embedded で使用されるものですが、ネイティブパッケージングなどにも使用することができます。

後半はモジュールファイルのリンケージについて。

Project Jigsaw ではモジュールを *.jmod ファイルで表します。この jmod ファイルを JRE にリンクさせるのが jlink コマンドです。

jlink -mods [モジュール名] -d $JRE のように使用します。また、javac コマンドに -mods オプションでも大丈夫です。実行時にリンクするのであれば、java コマンドに -mods オプションを使用します。

jlink の入力は jmod だけではなく、jar や class も使用できます。出力先は $JRE、もしくは JVM のイメージ、また jmod や jar も可能です。

JVM のイメージは .jai ファイルです。これを実行するには java -jai app.jar のようにします。

続いてセキュリティの話題。

今まで、Java では java もしくは javax ではじまるパッケージ以外にも sun.misc パッケージなどのクラスを使うことがありました。たとえば BASE64Encoder とか。

これらのクラスを使用してコンパイルすると警告が出たのですが、今後は使用することができなくなります。特にもモジュールを使用する場合は、アプリケーションの起動時に検出して IllegalAccessError を発生させます。

これに関して実際にデモが行われました。

CON6727 The invokedynamic Instruction in 45 Minutes


JRuby の Charles Nutter による invokedynamic の紹介セッション。

JVM での Java 以外の言語の取り組みというのはいろいろと行われてきましたが、2006 年までは Sun からの公式なサポートはありませんでした。

その後、JRuby チームを雇用したり、Java と他の言語との連携を行うフレームワークの導入など、サポートが行われ来ました。そして、JSR 292 InvokeDynamic が発足し、Java SE 7 に導入されています。

InvokeDynamic は動的言語だけと思われがちで、新しいインボケーションの仕組み、もしくは新しいバイトコードだと思われています。しかし、実際はそれにはとどまりません。

Charles は InvokeDynamic とはユーザがカスタマイズできるバイトコードとメソッドへのポインタの組み合わせといいます。

まず、メソッドへのポインタについて。これには MethodHandle クラスが使用されます。実際にはメソッドだけではなく、フィールドや配列へのポインタも含み、引数を操作したり、処理の順番を変えたりということもできます。

MethodHandles は MethodHandle のためのユーティリティクラスで、static な内部クラスにメソッドはフィールドを探索する MethodHandles.Lookup クラスがあります。その後、インボケーションを行いますが、これはリフレクションと同じように行います。

また、MethodHandles クラスには引数の操作などを行うメソッドも定義されています。これらを使うことにより、メソッドインボケーションをカスタマイズしていきます。

今までメソッドインボケーションを行うバイトコードは 4 種類ありましたが、新しく invokedynamic が加わりました。

invokedynami であるメソッドをはじめてコールする場合、まず bootstrap メソッドが実行されます。bootstrap では CallSite オブジェクトを作成し、そこには MethodHandle オブジェクトを保持させるようにします。そして、MethodHandle が指すメソッドの実行が行われます。

2 度目以降は bootstrap は実行されず、直接 MethodHandle が指すメソッドが実行されることになります。

BOF5802 No Guts, No Glory! A Deep Dive into the Internals of JavaFX

Richar Bair, Stephen Northover, Kevin Rushforth という JavaFX のコア部分を作成している 3 人による、JavaFX の内部構造に関するセッション。Jasper Potts がいないのは、私が予想するに、彼は比較的上位層の Controls などを担当しているからだと思います。

JavaFX にはいろいろとモジュールがあり、Base, Graphics, Controls などがあります。このセッションでは最大のモジュールである Graphics に関する解説が行われました。

Graphics モジュールは Glass, Prism, Quantum を含み、アプリケーションのライフサイクルから、実際の描画処理までを担当します。

Glass は OS や Window System に対する仮想レイヤになり、OS が異なっていても同じように使用できるためのレイヤとなります。Glass は UI-Thread で動作し、Window や View (Scene) を相当します。また、ネイティブのクリップボードやドラッグ & ドロップ、イベントなどに対する仮想化も行います。

実際に描画を行うのが Prism です。Glass は UI-Thread で動作しますが、Prism は Render Thread で動作し、Glass で Sync のイベントが処理される時に Prism でレンダリングが開始されます。

Quantum は AWT における Toolkit に相当します。

次にスレッドの話。

Glass では Scene Graph を Node で表しますが、これを Prism の Render Thread では NG Nodes として表し、描画を行います。この時に Lock が重要になり、Scene の状態によって synchronize を行うという方法で解決しています。

Prism ではハードウェアアクセラレーションを多用して描画行います。NG Nodes のツリーを ViewPainters がトラバースして描画を行います。イメージなどはテクスチャとして描画していきます。

GPU がマルチコアで構成されているのに対し、JavaFX 側では UI-Thread と Render Thread の 2 つのスレッドしか使用していません。そこで Command Buffer を使用してパフォーマンスを向上させています。

かなり内部のことに言及していて、かついろいろと話題が飛ぶので、追いつくのがやっとだったのですが、こういうセッションこそ JavaOne という感じがするセッションでした。




Stephen Northover



Richard Bair



Kevin Rushforth


BOF6223 Project Sumatra Update

Oracle の John Rose と、AMD の Gary Frost によるセッション。

Sumatra は昨年の JavaOne で発表された、GPU を高速演算に使用するためのプロジェクトです。

このような用途には OpenCL と CUDA という標準があり、Java からシームレスにこれらを使用していくようにします。GPU は多くの演算コアも持っており、これらを Java から使用していきます。

Java でマルチコアを扱う場合、スレッドを用います。しかし、スレッドは Java フレームやスタックなどを持ち、またシェアードメモリも使用します。このモデルは GPU での演算には向いていません。より小さい単位での処理を GPU で行わせます。

このセッションでは CUDA 用のアセンブラである PTX への変換と、AMD の HSA について解説されました。

Java のコードと変換後の PTX のコードを見せられたのですが、PTX はよく分かりません。アセンブラなので、ロードやらストアやらの命令が並んでいます。

現状は実験的な状態であるらしく、ゆくゆくは ParallelStream の演算をほぼ自動で変換していくことを目標にしています。

後半は AMD の HSA (Heterogeneous System Architecture) について。こちらは AMD の Gary Frost がプレゼンしています。

現在のプロトタイプでは Stream の forEach を HSA のオフロードコードに変換しているらしいです。こちらも HSA のコードが出されたのですが、いまいちよく分からず。

ここら辺は個人的にも、もうちょっと勉強しないと。

Gary Frost



John Rose


BOF7862 What and How Java Troubleshooters Think: Eight Years of Troubleshooting Java


今日の最後はアクロクエストの谷本さん、勝本さんによるトラブルシューティングについてのセッション。意外といっては失礼ですけど、結構人が入っていました。その中には Rockit の開発者というか、Flight Recorder の開発者の Marcus Hirt も!!

内容的には昨年の JavaOne Tokyo での焼き直し的な内容。そこそこ笑いもとっていたので、よかったのではないでしょうか。

ちなみに上の写真はやらせです。セッションの後に撮ってます ^ ^;; セッション後なので、この笑顔な分けです。

セッション前は、谷本さんにはめずらしく、ガチガチに緊張してました。セッション中もかなり脇汗が目立ってましたww それにもまして緊張していたように見えたのが勝本さん。まぁ、しかたないですけどね。

個人的に感じたことをいくつか書いておきます。

Java Puzzlers のようにクイズ形式で勧めていくのですが、選択肢にないものが答えだったりするのはどうかなと思いました。1 回はいいんです。そこで笑いをとれますから。でも、それを繰り返すと、聞いている方はどうせ答えは違うものだと考えて、思考停止してしまうと思います。

また、クイズ形式の構成が、状況の説明、選択肢とその回答、解説、モラルと進んでいくのですが、特に解説、モラル、とその次の問題に移行する時の間が悪いように感じました。モラルを解説しているのかと思うと、すでに次の問題に進んでいたりすることもあったので、ここからがモラルですよ、これから次の問題ですよとすぐに分かるように間を入れていくことが必要ではないかと思います。

まぁ、ネイティブではない英語で喋っているためというのはあると思うのですが、ちょっと浮き足立ってしまっていた部分もあったのかもしれません。

それにしても、ネイティブではない英語なのですから、全部を覚えようと思わずにカンペを使えばいいのではないかと感じます。

プレゼンでカンペを使うのは全然問題ありません。たとえば、今はなき Sun Microsystems の CEO だった Scott McNealy などは、スピーチに常にカンペを使っていました。

カンペを見ながら喋るのはダメですが、カンペを見て、それから顔を上げて喋るのは OK です。

それに、プレゼン用のカンペのカードって売っているんですよ。携帯電話ぐらいの大きさのカードを使うのですが、そこに書くこともルールがあります。

そこにすべての文章を書いてはダメです。自分もやったことがあるのですが、カードから目を離すと自分がいま読んでいる部分が分からなくなってしまうということがよくあるんです。そうなると頭が真っ白です。

私がネイティブの人に教えられたのは、原稿の名刺だけ写せというもの。日本人としては動詞も写しておきたいのですが、ダメだそうです。名詞がキーワードになるからなんでしょうね。

そして、1 枚のカードに 2 から多くて 5 センテンスを書いていきます。このぐらいの量であれば、かなり大きい文字で書けるので、今話している部分が分からなくなるということも少なくなります。

でも、谷本さんの場合は、直前まで資料を作っていたりするので、まずは余裕を持って準備をするということから始めなくてはダメでしょうね ^ ^;;




緊張で目が潤んでる






おまけ


今日の昼間、Taylor Street Cafe にいったら、四角いコンクリの塊がドーンと置いてありました。なにこれと思ったのですが、ロープの先を見てみると、テントの屋根につながっています。

ようするに、風でテントが飛ばされないようにするためのおもりだったわけです。

普段はビニールのカバーがかかっているので、気がつかなかったのですが、こうなっていたわけですね。




ロープの先を見てみると...






0 件のコメント: