Hatena::ブログ(Diary)

めざせ!細マッチョ このページをアンテナに追加 RSSフィード Twitter

Pivotal
Pivotal.IO 2018Replatforming for Cloud-Native Business〜 デジタル時代のクラウドネイティブ・プラットフォーム戦略〜https://omniattend.com/seminar/pivotal/io2018
Pivotal
Pivotal CEOが語るKubernetes、そして一般企業のデジタルトランスフォーメーションhttp://www.atmarkit.co.jp/ait/articles/1709/08/news034.html
GemFire
インメモリデータグリッドによる データベース設計・構築・管理入門〜データベースエンジニアからインメモリデータグリッドエンジニアへの橋渡しhttps://dinnovation.io/article/memo_pivo

2012-01-30 今日判明した謎

[] UseCompressedOops オプションデフォルト

Java SE 6 な JVMOracle 実装(いわゆる元 Sun の Hotspot VM)Update 14 のタイミングで、64 ビット版で UseCompressedOops というオプションが使えるようになりました。本オプション技術概要については、下記サイトとか参照してください。

UseCompressedOops - Hotspot JVMの圧縮OOP

ものすごく単純に言ったバージョンは、Update 14 のリリースノート参照。

http://java.sun.com/javase/ja/6/webnotes/6u14.html

-XX:+UseCompressedOops オプションを使用すると、Java オブジェクトヒープのサイズが 32 ギガバイト未満の場合に、64 ビット JREパフォーマンスを向上させることができます。この場合、HotSpot はオブジェクト参照を 32 ビットに圧縮して、処理する必要のあるデータの量を減らします。

64 ビットアドレス空間だと、論理的には 16 エクサバイトバイナリワールドでは、エクサテラの 1,048,576 倍)のメモリ空間を扱えるくらい広大。「ビッグデータ」がバズワード化している昨今においても、一つのシステムでそんなに使わない。むしろ、Java場合無駄オブジェクトポインタ用に使用する管理領域メモリ使用量が 32 ビットのそれに比べてとても増えてしまう。なんで、オブジェクトポインタだけを 32 ビットにして、その分、指定可能な最大の java ヒープサイズを 32 ギガバイトに抑えて(現実的に考えて十分なサイズ)、オブジェクトポインタメモリフットプリントを削減して効率的メモリを使用しましょう、というオプションだと理解。

それでもって、興味本位でこのオプションデフォルト値を調べてみた。そのためには以下のオプションが便利。

-XX:+PrintFlagsFinal

これをつけると、使用可能な JVM オプション一覧と現在の値を表示してくれるのです。なので、他のオプション何もつけずにこれだけつけて java コマンドを実行すればデフォルト値がわかるというわけ(PrintFlagsFinal のデフォルト値を除く)。で、以下の感じで、UseCompressedOops のデフォルトを調べてみた。

java -XX:+PrintFlagsFinal | grep UseCompressedOops

結果は、true でした。つまり、UseCompressedOops はデフォルト有効で、64 ビット JVM でも最大 java ヒープサイズは 32GB に抑えられているわけだ。次にこうしてみた。

java -Xmx32g -XX:+PrintFlagsFinal | grep UseCompressedOops

結果は false でした。どうやら、最大 java ヒープサイズを 32GB 以上に設定すると、自動的に UseCompressedOops は無効化される模様。なんで、Compressed Oops の存在を知らなくても、JVM勝手自動的に最大ヒープサイズに応じて調整してくれるわけだ。じゃ、これはどうでしょう

java -Xms32g -XX:+PrintFlagsFinal | grep UseCompressedOops

結果は、true でした。現状の実装では、java ヒープの初期値を 32GB 以上に設定しても、UseCompressedOops は無効化されないようで(Java SE 6 Update 29 で確認)。なんで、私が試した限り、マシンにいくら物理メモリを搭載していたとしても、以下のように初期ヒープサイズを 32GB を超えるようなオプション設定だとアプリケーションが全く動作するそぶりを見せずにいきなり JVM がクラッシュするよ。

java -Xms35g jp.ne.quitada.HogeHoge

-Xmx を明示的に指定せずに、-Xms を指定って、あまりないかもしれないけど、これってバグっぽくね?

ま、ワークアラウンドとしては、以下のように UseCompressedOops を明示的に無効にすればよいけど。

java -Xms35g -XX:-UseCompressedOops jp.co.quitada.HogeHoge

quitadaquitada 2013/03/20 15:40 以下のサイトで本ブログエントリが言及されました。ありがとうございます。

[Eclipse起動時エラーの傾向と対策]
http://www.andr0o0id.com/?p=854

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/quitada/20120130/p1
リンク元