torutkのブログ

ソフトウェア・エンジニアのブログ

JavaOne 2013 SF(09-25)

JavaOne 2013 SFの4日目(セッション3日目)です。概要だけ書いた暫定版です。

昨日はセッションが21:00過ぎまであって宿に戻ったのが22:00、ブログ(暫定)を書いたり翌日のセッションを確認したりと遅くなり、睡眠不足での参加です。

本日聴講したセッションは次です。

  • Java in Real-Time Secure Mission-Critical Applications (8:30-9:30)
  • Garbage-First Garbage Collector: Migration to, Expectations, and Advanced Tuning (10:00-11:00)
  • The Secret Society of Bug-Free Coding (11:30-12:30)
  • Converting to the New Date and Time API in JDK 8 (13:00-14:00)
  • Internet of Things Edge Devices: ARM Embedded for Java Developers (15:00-16:00)
  • Effective Foreign Function Interface: From JNI to JNR (16:30-17:30)

朝6時に起床、着替えて6時半にホテル1階に行き朝食をとります。今日はオムレツをオーダーで焼いてもらい食べました。
7時に部屋を出て、7時8分のBARTに乗り、7時50分にPowell St.駅到着、ヒルトンには8時に入っていました。通勤中に携帯の電源が20%減ってしまい、充電コーナーで20分ほど充電してから最初のセッションに入りました。

なお、今BARTの運行会社で労使協議が行われており、近々ストライキがあるとの情報が入り、ちょっと心配しています。帰りにストライキで停止すると空港いくのが大変です。

Java in Real-Time Secure Mission-Critical Applications【CON3656】

次の講師陣によるパネスディスカッションです。

  • Geertjan Wielenga氏(OracleNetBeans開発マネージャ)
  • Timothy Boudreau氏(書籍「Rich Client Programming」共著者)
  • Sal Cardinale氏(ノースロップ・グラマン
  • Sean Phillips氏(AIソリューション)
  • Chris Heidt氏(QinetiQ North America)

パネルディスカッション形式で(英語的に)少々理解が難しいセッションでした。

防衛・宇宙分野でリアルタイム性、セキュリティが求められ、かつシステム停止が致命的なミッションクリティカルなアプリケーションに関するディスカッションが行われていました。

なお、いずれもNetBeansをプラットフォームにしたアプリケーション事例となっています。そのため、「モジュラリティ」を強調していましたが、ちょっと強引な気もします。

ディスカッションはそれぞれが開発苦労話をして、それを共有したといったところだった気がします。英語力があればきっと楽しめたと思いますが、残念ながら・・・

Salvatore Cardinale氏

ノースロップ・グラマンのエンジニアで、「Agile Client」というC2(Command Control、「指揮統制」)システム向け可視化ソフトウェアツールの開発に携わっています。地図上に任務に応じた状況表示を行い、それを共有する、いわゆるCOP(Common Operation Picture)とその共有を行うものです。軍事用以外に、エネルギー、危機管理などのシステムの可視化に用いられています。
ソフトウェア規模が大きく、レイヤー毎にテストをしていると開発費が嵩む、統合が大変といった課題を解決するためにモジュラリティが大事、また開発プロセスアジャイルにするには組織の(?)マインドセットを変えることが必要とのことです。

Agile Client」の情報がここにありました。

Sean Phillips氏

Seanは翌日のJava Community Keynotesでも衛星の地上サポートシステム紹介で登場していました。

衛星の地上サポートシステム(地上から衛星の管制を行う)の事例を紹介していました。
衛星は百億ドル規模の費用をかけて立った一つの専用宇宙機を作って手の届かないところに送るので、停止が許されないミッションクリティカルということです。地上システムは手が届きますが、間違えると衛星がさ迷います。

地上システムは、Javaを使ってソフトウェアの開発・運用コストを下げているとのことです。

NetBeans RCPとJavaFXで構築されています。

Chris Heidt氏

政府との契約に関する仕事をしているようです。スライドなしでしゃべっていたので、知っている単語しかききとれません。
ビッグデータ、センサーシステム、リアルタイム、政府、Java SE 6にスタックし最新の7には上げられない、パッチ、ダウンロード、バージョンシステム、メジャー・マイナーバージョン、モジュラー、GISアプリ(Webサービス)、モジュールの分離(アイソレーション)、停止せずにホットスワップ

Tim Boudreau氏

同様単語のメモです。

国のSearch Engineer、デプロイ、アップデート、Certification & Accredication(検証と認定?)、システム文書のレビュー、
いろいろなシステムがあるが、その環境はどれをとっても同じものがない、
ソフトウェア採用許可リストなるものがあって、そこにシステムで採用できるソフトウェアが記載されているがバージョンが古いなどの問題がある、たとえばSSHが利用できないとか、
システムを素早く要求変化に対応させたいが、その解決策はない、強いて言えばモジュラライズすれば改善はされる

Garbage-First Garbage Collector: Migration to, Expectations, and Advanced Tuning【CON3754】

講師はJohn Cuthbertson氏(Azul), Monica Beckwith氏(Servergy), Charlie Hunt氏(Salesforce

既存のGC(Parallel、CMS)からG1GCに変更する前にちょっと考えてみよう、それから移行しよう、というセッションの趣旨です。

スループット、レイテンシ、フットプリント、消費電力についてCharlieが説明をしました。
期待値を明らかにし、何をメトリクスとしどこを計測するかを決めましょうということ(?)。

次にMonicaから、まずはParallel GCを使用しているソフトウェアが要求を満たせないときにどうG1GCに変えて計測して要求を満たすようチューニングするところをケーススタディで説明しました。

  • Full GCによる停止のためレイテンシを満たせなくなくなった
  • フットプリントが大きくなりすぎた(G1GCの方が小さい)
  • チューニングの余地がある間はParallel GCに留まれ
  • G1GCに移行するとオプション指定が変わる
    • -Xmn, -XX:UseAdaptiveSizePolicy, -XX:SurvivorRatioなどは使ってはだめ

ケーススタディは、

  • 性能要求が99%タイルで応答時間2秒以内、最大値10秒以内、想定の2倍の負荷においても99%タイル応答時間2秒以内、6GBヒープに対して
  • 現状性能がParallel GCでは99%タイル応答時間が2.5秒と性能要求を満たせない

という場合にG1GCへ移行するというものです。

まず、機械的GCオプションをParallelからG1GCに置き換え、そこから、計測とチューニングを開始します。

  • 99%タイル応答時間は1.4秒と改善
  • CPU使用率は29%から39%とG1GCに変えたことでオーバーヘッドが増加

このまま想定の2倍負荷にいくとCPU使用率の点で気になるので、CPU使用率の観点で調査をします。

G1GCの生ログを観察し、

  1. to-space overflow
  2. to-space exhausted
  3. Full GC

の発生有無を見ます。to-space overflow/exhaustedは、region evacuation失敗というコストの高い事象を示し、通常Full GCの後で発生します。

このときは、-XX:+PrintAdaptiveSizePolicyオプションを追加してGCログを観察します。
humongous(ばかでかい)アロケーションが発生していたら、これを回避するようにします。
まず、humongousなアロケーションのサイズを調べ(例では6.4MB)、humongousアロケーションがリージョンサイズの半分以下になるようリージョンサイズを-XX:G1HeapRegionSizeで増やします(指定する値は2の累乗で)。

これでCPU使用率が少し下がりました。

※ モニカ早口です!

最後はJohnから、CMS GCを使用しているソフトウェア(要求を満たせていない)をG1GCに変えてチューニングするところをケーススタディで説明しました。

CMS GCの場合、典型的には旧世代領域でフラグメントによるLatencyが問題になります。
通常G1GCの方がCMSよりオーバーヘッドが大きいです。

ケーススタディの例題は、1500ユーザーから、秒間2Txns/userが発生する状況で、99%タイルで250msの応答時間、最大値は1秒、12GB RAM、2倍負荷(3000ユーザー)に耐えられることが要求です。

CMSの場合、だいたい最大値が要求を超えてしまいます。また、高負荷時に99%タイルを超えてしまいます。ケーススタディの現状性能は、99%タイル応答時間が240msと要求内に入りますが、最大値が5秒と要求を超えています。また、2倍負荷時で99%タイルが310ms、最大値が8秒となっています。

最初に、CMS GCのログを観察し、

  1. promotion failed
  2. CMS Permの時間

に着目します。この2つがCMSの問題の兆候です。

G1GCに替えて性能計測(Latency)をしてみると、99%タイルは78msと大きく改善されました。
最大値も582msといい感じです。CPU使用率も微増に留まっています。

では、2倍負荷で計測してみます。
99%タイルは103msと要求内に納まっていますが、最大値は5960msとぐっと遅くなってしまいました。CPU使用率はCMSより若干下回る値です。どうしましょうか?

まず、G1GCのログを観察します。GC pause(young)の時間とUpdate RSの最大時間に着目します。2倍負荷のログではそれぞれ次の値でした。

  • GC pause(young) : 0.9929170 secs
  • Update RS(ms) : Max: 980.2

応答時間の要求が200msなのに対し、GC pauseの時間が大き過ぎます。
Rsetの最大値も大き過ぎます。

RSet update timeの調整は次の2つのパラメータです

  • -XX:G1RSetUpdatingPauseTimePercent(デフォルト10)
  • -XX:G1ConcRefinementThreads(デフォルトは-XX:ParallelGCThreadsの値で仮想CPU数12のマシンでは10となっていた)

セッションでは、前者を5に、後者を10から12(仮想CPU数と同じ)に変更して再計測しました。すると、2倍負荷での性能が、99%タイル 194msと調整前より増加しましたが要求性能内に納まり、最大応答時間は548msとぐっと小さくなり要求性能内に入ることができました。CPU使用率は調整前とほぼ同じとなりました。

さあ、これでおしまい? いえ、G1GCログをさらに観察して改善を進めます。
Monicaの説明にもあった、humongousアロケーションがないことを確認します。
marking & mixed GC cycleにおけるspace reclaimedの量を調べます。

  • 各サイクルで1GB-2GB(Javaヒープの10-20%)
  • mixed GCサイクルの直前に90%ヒープ占有

となっており、これはいい感じの値らしいです。

GCの解析ツールでJClarityを紹介していました。

最後の説明でParallel Reference Processingについて
G1GCログから

  • Ref Proc
  • GC ref-proc

を探し、この値が高いときは、-XX:+ParallelRefProcEnabledを指定することを紹介。

質疑応答は非常に活発で時間超過していました。
質問の中に、

  • 数百MBのヒープサイズは何が適している? → SerialGC
  • 1.5TBのヒープはどうか? → とっても興味深い現象が見れるよ(にやり)
  • InfoQについてMonicaが何か言及
    • 2013/9/17付けでMonicaがInfoQに投稿した記事「Tips for Tuning the Garbage First Garbage Collector」のことかな?

http://www.infoq.com/articles/tuning-tips-G1-GC

The Secret Society of Bug-Free Coding【CON3078】

講師は、Ashwin Rao氏、Martin Entlicher氏(両氏ともOracle

世界最初の(コンピュータにおける)バグの紹介から始まりました。1946年にコンピュータ(Harvard Mark II)に入り込んだ虫による機能異常です。

Common Weakness Enumeration (CWE) ソフトウェアの脆弱性の種類の公式リストの話があり、ついでNetBeansのコードアシスタンス(ヒント)、FindBugsプラグインを使った検証、Performance Analyzerで実行性能を図った検証をコーディング時に行うというものです。

デモでは、NetBeansのコードヒントで、次の例を紹介しました。

  • ダイアモンドオペレータの使用を推奨(コードの書き換え)
  • マルチキャッチの使用を推奨(コードの書き換え)
  • スコープ間の名前の衝突

FindBugsを使ったデモでは、synchronziedメソッドのget/setの整合性チェックを紹介しました。

パフォーマンスバグに対して、NetBeansのProfilerを使用したデモを実施しました。

また、デバッグの紹介では、デバッガで途中停止させ、if文の評価式内のメソッドの呼び出し式と評価結果が確認できるデモを紹介しました。このデモでは、if文の評価式で、例えば || 演算子を使っていた場合、どの部分式が真となったかが示される例を見せていました。

このセッションは、タイトルの割には初歩的な紹介であり、途中退席する人が後を絶ちませんでした。

Converting to the New Date and Time API in JDK 8【CON6091】

講師はXueming Shen氏(Oracle)、Roger Riggs氏(Oracle)、Stephen Colebourne氏(OpenGamma)です。

java.timeは、かなりISO8601を意識したライブラリです。最初の方に登場したISOの日付時刻書式のまとめスライドはうまいなと思います。自分でまとめを作ろうとしたときは、1枚のスライドにはまとまりませんでした。

java.timeと既存のCalendar, Dateと比較して、そのあとはjava.timeのフォーマット、DatePickerコントロールJavaFX)、Temporal Adjustersといったところです。

java.time APIでは、月が列挙型になります。Calendarクラスでの1月が整数0になるという厄介な仕様からやっと離脱できます。
目的に応じてクラスが提供されるので、APIとしてクラス数が増えて複雑になっていますが、従来のCalendarが One fit for all なものだったので、個人的には歓迎です。

メソッド名は、一見Javaの慣習には合っていない(個人的にはC++的な雰囲気を感じる)のですが、一貫性はあるようです。
static importを使って可読性を上げるとよいという紹介がありました。

フォーマットについては、事前定義されているのはISO8601、RFC1123だそうで、それ以外のフォーマットは自力で作成する必要があります。
java.util.Formatterは、java.timeをサポートするよう拡張されるようです。
夏時間対処について何か言及していたと思われます。

Q&Aで、Java SE 7で使えるバックポートがあるか質問が上がり、Java SE 8向けにFixしてから出すそうです。
また、Q&Aでメモリフットプリントについて質問が挙がり、Dateは小さくていいよと、Instanceはちょっと大きい(96bit?)と言っていました。

Internet of Things Edge Devices: ARM Embedded for Java Developers【CON6607】

講師はDominic Pajak氏(Embedded, ARM)

遅れて参加したら、セッションがたった30分で終わってしまい、なんともだったセッションです。
Oracle Java ME Embeddedの話があり、NetBeansで開発OK、Cortex-M3ボードKEILがあるよ、といった内容だったかと思います。

Java SE Embeddedは、JREの60%のフットプリントで、ARM固有のC2 JIT、ハードフロート、JavaFXなどの話をしていました。

ラズベリーPIの話も少し触れていました。

時間が余ったので、Taylor Street Cafeに行ってみました。

ビールが並んでいます。無料でもらえます。
ただ、この日は風が強く、日陰だと冷えてしまい長居はできませんでした。ビールを無料で飲んで、でも寒いのでコーヒーを飲みました。

Effective Foreign Function Interface: From JNI to JNR【CON4767】

講師は、Ryan Sciampacone氏(IBM)、Thomas Enebo氏(Red Hat)です。

2013-10-17現在JavaOneコンテンツにはスライドがありませんが、slideshareに置かれていました。

このスライドもセッションで使われていたかと思います。

Ryan

FFIは、直接関数呼び出し、スピード大事、データのマーシャリングが高価、あとGCと言っていました。JVMTIは内部ではJNIを使っているよ、とのことです。
時間のかかる処理はField IDなので、キャッシュするとよいとのことです。
Critical Sectionは使わないのが吉だそうです。

解決策は、Packed Object(CON5758)だそうです。(スライドが現時点ではないです)

Thomas

JNIはコンパイルベースなので各プラットフォーム毎にバイナリを用意する必要があります。JNRはDLL上の関数を呼びだします。実行時にバインドするので事前にネイティブのコンパイルは不要です。

多くのOSに対応しています。またPOSIXインタフェースなどを標準でサポートしているので、POSIXの関数は簡単に呼び出しできます。

今後、JSR化を目指す(?)、segmentation違反でJavaごと落ちないようにする、構造体を自動生成する、などがあるそうです。

JNAと似たライブラリ・ツールです。
JNAとの性能比較は、Q&Aで出ていて、「10倍早い」と答えていましたが、どっちが早いかは聞きとれませんでした。

質疑応答は白熱した議論となり、ついていけず・・・。
SWIGを使ったらという話題があったようです。

会場のサービス

JavaOneは各会場や廊下などに飲料水とコップが用意されています。また、ヒルトン横のTaylor通りを閉鎖して設営されたTaylor Street Caffeでは、珈琲等と午後はビールが無料で提供されます。珈琲は紙カップでキャップもあるので会場へ持っていくこともできます。
また、14:00-15:00のセッション休止時間は、展示会場奥に珈琲、紅茶、クッキーが並べられます。ニッコーホテルのラウンジコーナーにも並んでいました。

また、朝利用した充電コーナーもあります。

お昼は各自に配られた引き換え券でサンドイッチ等(数種類から選べる)と炭酸飲料がもらえます。食べる場所は、廊下のあちこちに用意されたテーブルが取れればラッキーで、そうでなければ隅っこに座り込んで食べることになります。おいしいといえば嘘になりますが、そもそも昼休みはなくセッションがあるので、いそいそと片隅で食べて次のセッション会場へ移動するので、味が云々する余裕はありません。

食事

朝食は、今回宿泊したホテルで食べています。

昼食は、JavaOne配給の昼食か、近所に食べに行きます。今日は、配給食は辞退して、14:00-15:00のセッション間の時間で近所のMacy'sにあるBoudin Bakeryでクラムチャウダーを食べました。

パンを繰り抜いて中にクラムチャウダーを入れたもので、パンはとってもサワーな味です(ドイツを思い出す)。

今日は、夜にOracle Appreciation Eventという、トレジャーアイランドを貸し切りにしてライブと飲み食いを提供するイベントがあるため、セッションは夕方までとなり、参加者は送迎バスで会場へ行き楽しむという日です。参加した人はたっぷり飲み食いできたことと思います。
夜は寒いのと(ホテルが遠いので荷物を置いて厚着をするという芸当ができず)、また、帰りが遅くなると電車でホテルに戻れるか不安だったので、このイベントには行かず、買い物をして早めにホテルに戻りました。ただ、あとから調べると、割と好きな時間に送迎バスに乗って戻ってこれたようです。

街中にはOracle模様のバスがいました。

夜はホテルのレストランでハンバーガーを食べました。ホテルのレストランで11ドルのハンバーガーはこんな感じでした。肉がおいしかったです。