JVM（HotSpot VM）におけるIntrinsics（C2/Graal） - Fight the Future
Project Loomのソースを読んでいると、また遭遇しました。 public class Continuation { ... @HotSpotIntrinsicCandidate private static int doYield(int scopes) { throw new Error("Intrinsic not installed"); }; ... } @HotSpotIntrinsicCandidateアノテーションです。継続の停止処理であるdoYield()メソッドは、エラーをスローする実装になっています。もちろん実際はエラーとならず、停止処理が実行されるわけですが、どうなっているのでしょうか？ 僕は、@HotSpotIntrinsicCandidate、あーCPUアーキテクチャごとの処理があって実行されてるんだよね、くらいの認識でそれ以上深めてことはありませんでした
第9回 ［最終回］HotSpot JVMのGCを選択しよう | gihyo.jp
HotSpot JVMを使うとき、どのようにGCを設定していますか？ 検索して出てきたホームページを見て 「とりあえずこのホームページにあるように最新のGCを指定したし、同じようにオプションを設定したから大丈夫だろ」 と思ってしまう話をよく見聞きします。 図1 誤ったGCの選択 しかし、たとえばバッチのようにスループットを意識すべき処理にもかかわらず、レスポンスタイム重視のGCを選んでしまうのは適切ではありません。 最終回となる今回は、HotSpotにはどのようなGCがあり、どのようにそれらを選択すれば良いのかを紹介します。 4つのGCを使いこなす HotSpot JVMには、以下の4つのGCが実装されています。 シリアルGC パラレルGC コンカレント マーク＆スイープGC（CMS） ガベージファーストGC（G1GC） 1つずつ見ていきましょう。 シリアルGC このGCの特徴は、ヒープの
第8回 イレギュラーなヒープの動作を理解する | gihyo.jp
Tenured領域を早く使ってしまうパターン 前回ご紹介したように、HotSpotのヒープでは、アプリケーションがオブジェクトを作成するとまずはじめにEden領域が割り当てられ、マイナーGCによってSuvivor領域、Tenured領域へと移動していく流れが一般的でした。 しかし、このパターンではないイレギュラーなパターンがいくつか存在します。 その1つが、「オブジェクトが一般的なパターンに比べ、早くTenured領域に移動してしまう」というものです。 図1 Tenured領域を早く使ってしまう例 Tenured領域はメジャーGCの対象であり、メジャーGCはNew領域を対象とするマイナーGCに比べ、はるかに停止時間が長くなります。そのため、このようなパターンが頻繁に起こる場合は、メジャーGCの多発によってアプリケーションの停止時間が増加します。 図2 Tenured領域を早く使ってしまう
第7回 HotSpot JVMではどのようにオブジェクトが移動するのか | gihyo.jp
1回目のマイナーGCまでの流れを把握する 前回は、HotSpot JVM（以下HotSpot）のヒープ構造を解説しました。今回は、HotSpot JVMの4つのヒープ領域がどのように使用されていくのかを見ていきましょう。 まず、アプリケーションがオブジェクトを作成すると、HotSpotはそのオブジェクトにEden領域を割り当てます。 図1 オブジェクトが生成されるとEden領域が割り当てられる アプリケーションが処理を実行していくと、オブジェクトがどんどん作成されていきます。その結果、Eden領域が次々と使用されていきます。 Eden領域がいっぱいになり、空き領域がなくなると、HotSpotはNew領域を対象にGCを行います。このGCは「マイナーGC」と呼ばれ、世代別GCで言う「若い世代のGC」になります。 このように、Eden領域で短命なオブジェクトを回収することで、ヒープを再利用できる
第6回 HotSpot JVMのヒープ構造の仕組みを把握する | gihyo.jp
ヒープ構造は2つの領域から成り立つ 前回までの連載では、HotSpot JVM（以下HotSpot）やJRockit JVMなどのJVMの種類を問わない内容を紹介しました。今回からは、Oracle社より提供されるHotSpotをもとに、実装の具体的な特徴を見ていきましょう。 HotSpotは無料で使用できるJVMの1つで、デスクトップからサーバまで幅広い環境で使用されています。フルGCの発生回数を抑えてアプリケーションの停止時間を短くするために、第5回で紹介した世代別GCを採用しています。 HotSpotでは、ヒープを以下の2つの領域に分かれています。 New領域 ⇒ 若い世代の領域 Tenured領域 ⇒ 古い世代の領域 図1 HotSpotでの世代別ヒープ 比較的短命なオブジェクトは、New領域内のGCで回収されます。長時間使用されるオブジェクトは、New領域を対象とされるマイナーGC
第5回 チューニングのために理解しておきたいGCの4つのアルゴリズム | gihyo.jp
なぜアルゴリズムを学ぶのか GCによる停止時間が長くなり、アプリケーションの処理時間が短くなると、業務に使える時間が短くなってしまいます。その問題を解決するために、GCをチューニングすることで、アプリケーションの停止時間を短くすることが考えられます。 その際大事なのは、GCのアルゴルズムを把握しておくことです。 GCのチューニングを行うときは、GCで行われている処理の内、どの処理に時間がかかっているかをモニタリング⇒分析⇒チューニングする、という流れになります。しかし、GCのアルゴリズムを知らないと、モニタリング結果を見てもどこに問題があるかがわからず、分析やチューニングを行うことができません。 今回は、以下の4つのアルゴリズムをご紹介します。 マーク＆スイープGC コンパクション コピーGC 世代別GC GCのアルゴリズムはJVMの実装によって異なりますが、多くの場合、上記4つのアルゴリ
第2回 ヒープが再利用される仕組みを理解する | gihyo.jp
不要なオブジェクトを回収するしくみ～ガベージコレクタ 前回の最後で触れたように、あるオブジェクトに対する参照をすべて削除すると、そのオブジェクトへはたどり着くことができなくなるため、プログラム中で使用できなくなります。このようなオブジェクトが増えていくと、二度と参照されることのないオブジェクトがヒープを占有してしまい、ヒープが枯渇してしまいます。 図1 不要なオブジェクトであふれたヒープ 日常生活では、建物内にゴミが溜まってしまい、足の踏み場がなくなっても、週1～2回あるゴミの日にまとめて捨てれば部屋はきれいになります。しかし、不要なオブジェクトでヒープが占有されてしまったJVMは、どうすれば良いのでしょうか？ JVMでは、このような不要なオブジェクトを「ゴミ」として回収し、不要なオブジェクトが使用していたヒープを解放することで、ヒープが枯渇することを防ぎます。その仕組みが「ガベージコレク
第3回 システムトラブルの原因はGCの実装を知れば見えてくる | gihyo.jp
原因は大きく分けて3つあります。 1つめは、リソース不足です。たとえば、CPUのクロックやコアが足りず、処理の完了待ちであることなどが原因として考えられます。 図1 CPUのリソース不足の例 2つめは、M/W（ミドルウェア）からアプリケーションに提供されるスレッドや、コネクションのプールにあるリソースが不足していて、その提供待ち（無応答）になっている可能性です。 M/Wでプールしているリソースが不足した状況は、会社の書籍棚に1冊しかない本を社員で順番待ちしている状況に似ています。1冊しかないため、今借りている人が返すまでは他の人は借りれません。 図2 M/Wでプールされたリソースが不足しているケース 1つめのケースで問題がGCにある場合、GCに割り当てるリソースのバランスが悪いことが原因です。たとえば、特定のプロセスに対するCPUリソースの割り当てが大きい場合、GCが起きると、CPUリソー
第4回 3つのGCを使い分けて停止時間を最小にする | gihyo.jp
3つのGCを使い分けてCPUの使用率をコントロールする 「GCの時間が長くてシステムが反応してくれない……もっと短くならないかな？」 「GCが始まると、CPUが占有されちゃって、ほかのプロセスの動きが重くなるんだよね……」 「GCの停止時間が多少長くなってもいいから、ほかのプロセスへの影響を軽くできないかな？」 JVMを使用しているシステムでは、そんな話を耳にします。GCが起きていることまでは把握できているのですが、それからどうしたら良いのかわからないのです。 GCは、JVMの内部でGCスレッドがCPUに処理されることで行われています。そのため、GCが行われている間はCPUの使用率が増加してしまうのです。 GCをスレッドの観点で見ると、以下の3種類があります。 シリアルGC パラレルGC コンカレントGC これらの違いを把握すれば、CPUの使用率とアプリケーションの停止時間をコントロールす
第1回 JVMはどのようにメモリ空間を利用するのか | gihyo.jp
あのWebサービスもJVMを利用している 「Javaは大規模なエンタープライズシステムにしか使われない」 それが常識だと思っていませんか？ たしかに、これまでJava Virtual Machine（JVM）は、他の言語を実行すると遅く、Javaのプログラムを実行する環境にすぎないものでした。ところが、Java 7から実装されたInvokeDynamicにより、JVM上で、RubyやPHPなどさまざまなコンピュータ言語で記述されたプログラムをより高速に実行できるようになりました。 これにより、今までエンタープライズでJava言語で記述されたプログラムを実行するだけの環境であったJVMが、汎用的な実行環境になったと言えます。また、これまでJavaの実行環境として使用されていたノウハウが、他の言語で記述されたプログラムを実行する際にも利用できます。 最近では、TwitterがJVMをアプリケー
雑把の仮想マシン(JVM, .NET, BEAM, スクリプト言語, LLVM) | プログラマーズ雑記帳
今回は JVM, .NET といった仮想マシン(VM)についての記事です。 最初、 .NET と仮想マシンの説明のスライドを作っていたのですが、 最近 JVM と BEAM を少し調べて興味がでてきたので、合わせて VM の話としました。 そうすると今度は、スクリプト言語や LLVM の話も外せないなと思って足したら、結構な大作になってしまいました。 JVM に絞った話では、以下の記事にも説明を書いているので、こちらもご覧ください。 JDK のインストール(Windows)と Java 関連用語の説明 | プログラマーズ雑記帳 スライド版です。 ここからブログ版です。 はじめに 仮想マシンといっても、 OS のエミュレーターのようなものではなく、 JVM といったプロセス仮想マシンについてのお話です。 JVM 、 .NET Framework など最近、この仮想マシン(VM)のシェアが大幅
Throwableについて本気出して考えてみた - 都元ダイスケ IT-PRESS
Throwable、Exception、RuntimeException(RTE)、Errorあたりを整理しながら、色々考えてみた。私見に基づくので、間違っているかもしれないけれど、自分としては頭が整理できたかな、と感じたので晒してみる。異論があったらコメントください。 まず、一番基礎的なところで、継承関係の整理から。こんなツリーになっています。 Throwable Error Exception RuntimeException そして、本稿での用語の定義。caller＝呼出す側のコード callee＝呼出される側（throwする側）のコードとします。 Throwable Throwableは「throw文に指定できる何か」という意味ですね。 Instances of two subclasses, Error and Exception, are conventionally used
JVMはそんなに重くない | POSTD
Clojureに反対する大きな理由がJVMです。この役立たずは重いですからね。 これは、数週間前に ZA Tech のSlackで見た投稿です。休暇中にClojureの話題を何件か見たのですが、投稿者はJVMについても繰り返し言及していました。 私はこの投稿について Slack上で少しつぶやいていました が、もっと広く理解され議論されるように、本稿を書くことを決めました。 背景 以前は、私もJVMは重いと思っていました。2000年代の初めにJVMとPHPと比べていた頃の話です。当時は、.NETやColdFusionなど、別の重い製品が他にもありました。また、PerlやPythonという軽めの製品もありましたが、私はWindowsを使っていたのでActivePerlやActivePythonはやはり少し重めでした。 私が初めてJVMに対する“恐れ”を克服したのは、小規模な製品アプリを、JRu
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Inside The Java Virtual Machine
https://www.oracle.com/webfolder/technetwork/jp/javamagazine/Java-JA13-Architect-evans.pdf