sugarlife's blog

Javaとか、http://twitter.com/sugarlife

最近のProject Jigsaw の流れ:コミュニティ投票でNo (Public Review Ballot)

Java の新たなバージョンである JDK 9 のリリースが約 2 ヶ月後に控えているが、最大の目玉と言っても過言はない Project Jigsaw がコミュニティから No を突きつけられた。この最近の流れを、極力意見を混ぜずに事実を淡々と紹介する。

Project Jigsaw とは

  • 乱暴に言うと Java の新しい分割の仕方としてモジュールを導入しようという取組
  • 詳細は手前味噌ですが以下のスライド参考

前提

最近の流れ

Project Jigsaw は Draft Releases の期間でした。なお、私は OpenJDK 実装をそれなりに読んでおり、各自の立場から反対意見の要約を示すことができないと思いますので、詳細な内容は紹介しません。詳しくはリンク先を確認してみて下さい。

2017/1/17 - 2/16 Early Draft Review
  • Spec Lead (Oracle の Mark Reinhold氏) (と Expert Group) により JSR の要件に則った仕様書の草案が公開され、(場合によっては大幅な)レビュー&改訂作業が行われる。ここでは一般のレビューは行われません。
    • Spec Lead の Mark 氏は JDK 9 全体の Spec Lead も兼任している
3/21 - 4/20 Public Review
4/25 - 5/8 Public Review Ballot

f:id:cco:20170509194940p:plain

これからどうなるか

JCP で定められている通り、否決された場合は Spec Lead と Expert Group は 30 日以内に EC から提起された懸念に対応するための仕様草案の更新・修正を行い、再び審査投票を実施します。この審査投票でも否決された場合は JSR は終了し、Expert Group は解散されます。

ただ、JDK 9 のリリース予定日が 7/27 と差し迫っている中、懸念に対する仕様変更はまだしも、その実装は更に時間がかかる可能性が高く、リリースにも影響が及ぶことは十分に考えられる状況です。現在はまだ投票結果が出たばかりなので、今後の動向に注目していく必要があります。

追記

追記1:Jigsaw 否決の内情について

EC member は全団体が頭ごなしに No と表明しているわけではありません。その一例として Tomitribe のコメントを紹介します。

Though a No vote feels like rejection we ultimately believe it is the most supportive vote for gaining a greater level of consensus we believe is necessary from a JSR, while still keeping time pressure.

Jigsaw における技術的な課題について指摘している団体もおりますが、懸念について駆け込み的に対応しようとした Expert Group とのコンセンサスの取り方について疑問を持ち、最初の投票で Yes と投じにくいと判断した団体も多くいるようです。各団体のコメントは投票結果のページから確認ができます。

追記2: JDK 9 の JSR

JDK 9 も同じタイミングで JSR 379 Java SE 9 Release Contents にて JCP の承認プロセスを実施していますが、こっちは賛成多数で可決しました。

f:id:cco:20170509203914p:plain

jcmd と既存ツールの対応

はじめに

この記事はJava Advent Calendar 2016の 1 日目の記事です

先日の Java Casual #2) で jcmd について話してきました。

jcmd は Oracle 社のドキュメントでは推奨ツールとして扱われており、jps や jmap, jstat のような既存ツールは "Experimental" とされています。このため、既存ツールから jcmd への移行が進められる可能性があります。例えば Experimental であった jhat は Java 9 から削除されます。

Java 9 からの新機能を含めた jcmd の各種機能は上記スライドを見ていただくとして、ここでは jcmd でどのように既存ツール相当の機能が使えるかを紹介したいと思います

続きを読む

OpenJDK のリポジトリから特定バージョンの Java のソースコードを落とす方法

例:JDK8u77 のソースコードを落としたい

解説
  • OpenJDK のソースはタグ管理されているので、JDK8 Updates Master のタグ一覧を確認する
  • u77 の最新の b 番号は b03 なので jdk8u77-b03 が取得したいソースコード
  • これを mercurial コマンドと OpenJDK のツールから持ってくる
  • jdk8 以外は jdk8u の部分を適当に入れ替える。(※ただし動作確認してません)

G1 GC おさらいと #jjug_ccc で発表した話

この記事は Java Advent Calendar 2015 の一日目の記事です。二年連続でトップバッターだ!

先日の JJUG CCC 2015 Fall で G1 GC について話してきました。
去年の CMS GC と同じく結構遅めの時間帯&裏番組に伝説の灰色ページ管理人・ひしだま伝道師が発表するなどの豪華な時間帯にも関わらず、165人規模の部屋がいっぱいに埋まるぐらいの盛況でした。聴講頂いた皆様ありがとうございました!
スライドは以下に公開しました。G1 GC の挙動から GC ログの読み方、どういうケースが厄介なのかを紹介しているので是非ご覧ください!

アフターフォロー、またはちょっとした補足

極力、後から参照可能なように資料を作っていますが、どうしても口頭で補っている部分はあります。
セッションのハッシュタグである #ccc_cd6 で Twitter 検索した結果 なども合わせてご確認ください。

一般的な注意事項について
  • JDK9 から G1GC がデフォルト化されます。JDK9 を導入される際は使用する GC を明示的に指定することをお勧めします。
  • ヒープサイズが小さい環境で G1 GC を選択する際は注意してください。元々ヒープサイズが巨大な環境のために開発されたものなので、ヒープの使用「率」(-XX:InitiatingHeapOccupancyPercent) が比較的低い段階から活発に GC が実行されるなど、本来のメリットがデメリットとして襲い掛かってくることがあります
オプションについて
  • CMS GC と同様に -Xmx と -Xms は同じ値にしたほうが、拡張/シュリンク時のコストが発生しないのでお勧めです。
  • オプションで Young 領域(Eden、Survivor 空間)のサイズは指定しないほうが性能が良いケースがあります。これは Young 領域のサイズを設定しない場合は状況に応じて JVM が動的に変更するため、人間が決め打ちでやるより効率が良くなるパターンが往々にしてあるからです。
  • -XX:MaxGCPauseMillis は STW の時間を指定するものではありません(主にマーキングサイクルのコンカレント部分に効く)
検索して引っかかる古い情報について
  • 以下のスライドの Mixed GC の処理条件が最近のアップデート(JDK-8059452, JDK8 update 40)で、緩めなOld 領域をより徹底的に回収する条件に変更されてます。JDK9 でデフォルト化の話がこの辺りで出てきたので、それに前もって導入された印象です。
    • G1MixedGCLiveThreshold が 65 から 85 に変更
    • G1HeapWastePercent が 10 から 5 に変更
    • 追記 2015/12/1 12:40 @den2sn さんよりコメント頂き表現を修正。合わせてスライドも表現が誤っていたので修正。

  • 以下のスライドの Evacuation Failure が発生した際、次のページに書かれてるようにログに (to-space exhausted) という文字列が出力されます。しかし、 Oracle のドキュメント等によると (to-space overflow) と出力されるバージョンもあるようです。今回の発表スライド作成時に確認したソースコードにはそういう文字列はありませんでした。古いバージョンを利用する場合はこの文字列も注意してください。

伝えたかったこと

これまで 渋谷Java で OutOfMemoryError の話をきっかけに、JJUG CCC 2014 Fall で CMS GCJava 女子部で JVM のいろは、そして今回の G1 GC の話をしてきました。これらの発表の原動力は去年の夏の JJUG ナイトセミナー LT 大会でした「楽して JVM を学びたい」という発表が大元です。

勉強するためには、体系だった知識が下敷きにあるとないとで理解の差が段違いです。特に自分は難聴者なので、分かりやすい資料や書籍があるかが大きな差となりました。なるべく JVM の勉強をしてみたいという人に向けて、特に問題になりがちなメモリ管理の分野に関して、実際のトラブルで役に立つ知識を中心に、後から読み返してもスッと入ってこれる体系だった丁寧な資料作りを心がけてきました。

これまで OpenJDK のソースコードを読み、数々のそれなりにタフなトラブルシュートを駆け抜け、たまに OpenJDK パッチを書いて投稿しという活動を繰り返してきました。いまだにコミッターどころか Author にもなれてませんが、自分なりに Java のコミュニティに貢献できればと思い発表してきました。どこかの誰かの「楽して JVM を学びたい」という気持ちに答えられていたら幸いです

www.slideshare.net

www.slideshare.net
www.slideshare.net
www.slideshare.net
www.slideshare.net

おまけ

最終回っぽい〆をしてますが、別に Java はやめません :p

JDK9 新機能ダイジェスト (JDK9 Features) #java

JJUG ナイト・セミナー 「ビール片手にLT&納涼会」で、来年出る予定のJDK9の新機能(2015/7/31時点)について喋ってきました。JDK9の機能が全て出揃う(Feature Complete)のは 2015/12/10 ですが、これから大量に出てくるのも考えにくいので LT の時点で出ている分をまとめました。

JDK8 で導入された機能についても過去にまとめてあります

新たな JDK で導入される機能について

Java 関連の周辺技術標準化は JCP(Java Community Process) によって行われ、新しい技術仕様や改訂仕様(既存技術仕様の改訂)は JSR (Java Specification Request) として提案され、標準化に関する作業が管理されます。
では、JSR を追って行けば JDK の新機能が解るのか?実はそれは違っていて、JDK で何かしらの新機能を加える場合、その内容は JEP (JDK Enhancement-Proposal) として管理されています。JDK 9 の機能部分は、Oracle 社独自の変更(解りやすい例としてFlight Recorder周り)以外の変更点は、OpenJDK 9 プロジェクトの Features から確認できます。今回はこの JEP についてダイジェストをまとめてみました。

発表資料

以下、JDK9 新機能のダイジェストです、ご査収ください

以下の英語版はもうちょっとだけ詳しく書いてます

LT 時は五分でおさまるように練習したのに、遅刻気味で全力疾走からの飲酒を決めて酔っ払い、5分で喋りきれませんでした。すみません(・ω<)てへぺろ

JDK9 の影響

それぞれで影響が大きい機能は異なってきますが、以下の機能は多くのプロダクトに影響が大きいかもしれません。

  • Project Jigsaw (JEP 220、他)
    • sun.* パッケージの扱い (JEP 193、他)
  • JVM ログ統一 (JEP 158)
  • G1GC デフォルト化 (JEP 248)

個人的には P.12 にまとめた sun.misc.Unsafe の動向が超重要(JDK内部でも使ってるし即消えることはないとは思いますが…)で、G1GC リプレース型の新 GC (Shenandoah) どこ行ったという所感です。

「Java パフォーマンス」感想

本書の翻訳者の一人である@cero_tより献本頂きました、ありがとうございます。というわけで一週間かけて読んでみた。

www.amazon.co.jp

今現在 Java で開発している人、特に運用者や試験者は間違いなく買っておくべき本です。Javaに限らない一般的なパフォーマンスチューニングの考え方・観点から、Java アプリケーションにおいてボトルネックになりやすい GCJIT の詳細な確認方法からチューニング方法が解説されている。特にすごいのが Java の世界のみならず、OS の世界まで触れている点。流石に OS の世界はここに書かれているのが全てではないけれど、Java アプリに関わる部分で問題になりやすい点は割と触れている。

JDK8 にも対応しており、今現在手に入る情報としては一番頼もしいと思う。4000 円程度でこの知識量が手に入るなら非常に安い。

お勧めの読み方

個人的にお勧めの読み方はパフォーマンスの観点やツールの使い方が書かれている 1-3 章は誰でも先ず読んでおき (3.4 は HeapStats でも良いよ!)、使っている GC アルゴリズムに合わせて GC について書かれている 5-6 章を読むのがお勧めです。GC ログの読み方から解説されているので、今現在で問題が出てないかの確認も行えるのが便利。CMS GC に関しては拙作のスライドもあわせてどうぞ。

Java で今まさにコーディングしている人は 9,12 章でコーディングにおける効率的な書き方を学びつつ、メモリ使用状況をどう確認するべきか 7-8 章 で学ぶのが良さそう。これらの章以外もちょくちょく読み進めておき Java の世界(JITとか)と Java を取り囲む世界でどのように確認すべきか少しずつ観点を増やしていけます。

この本の凄いところ

この本でサポートできないのは、よりコアな一般的でないチューニング(大抵稼働がかかり過ぎるのでやるべきではない)や、JVM の実装に依存する内容(バグとか)、JNI や sun.misc を利用した黒魔術コーディング、よりハードウェアを意識したコーディング/チューニング等なので、基本的にこの本に書かれている内容を実践するだけで大方の運用面における問題は解決するか、解決の糸口が掴めると思います。

コアな一般的でないチューニングとは言うけれど、この書籍のように Large Page や TLB キャッシュ率、オブジェクトのロックコストなどに一冊で言及した書籍なんてそうそうありません。特に GC でどういった状況が発生したら問題で、その解決方法(チューニング)を割と網羅しており、各種ランタイム情報の確認方法まで書かれているので、この本で解決しないなら結構な経験者や OpenJDK に詳しい人を引っ張りださないと辛いと思う。

ちなみに CMS GC の注意すべきケースとして promotion failed というのがありますが、これは「昇格の失敗」という日本語になっていました。訳としては正しいのですがログには promotion failed と出ますが、その単語からは索引できないので注意が必要です。

おわりに

日本語でこのレベルを読めるようになったのは便利だなあ。数年前からJavaメモリモデルを意識したコーディングや、ハードウェアを意識したチューニングが JavaOne とかで発表されてましたが、より多くの所がその水準に行くための土台ができてき始めてるかもしれませんね。

(´-`).oO(新人教育や知識継承、この本読めば済みそう)

How specify JVM options by file.

Use -XX:+Flags=<file>. You can specify *ONLY* "-XX" options.


OpenJDK checks this option when vm parses the arguments as following.