Shenandoah GC・ZGC・Epsilon GCをざっくり理解したい！ JJUG CCC 2018 Spring での発表資料です
introduction-to-modern-gc
Shenandoah GC・ZGC・Epsilon GCをざっくり理解したい！ JJUG CCC 2018 Spring での発表資料です
ざっくりわかった気になるモダンGC入門 - Cybozu Inside Out | サイボウズエンジニアのブログ
どうも！@yokotaso です！ 2018/05/26のJJUG CCC 2018で「ざっくりわかった気になるモダンGC入門」というタイトルで登壇させていただきました。 現在開発中の新しいGCアルゴリズムをざっくり理解することをテーマに発表しました。 発表練習用に作ったカンペの内容を公開します。ブックマークコメントでもツイートでも感想を書いていただけると喜びます！ 発表資料は、speakerdeck にあります。はじまり〜はじまり〜 はじめに 今日はざっくりわかった気になるモダンGC入門というお話をさせていただきます。 現在開発中のGCアルゴリズムの全体像を理解してもらうことを目的としたセッションです。よろしくおねがいします。 さて今日のアジェンダですが、まず簡単にこれまでのGCを復習した後に新しいGCが必要になってきた背景について少し話します。 次にShenandoahGC、ZGC、E
parallel と concurrent、並列と並行の違い - 本当は怖いHPC
2017/01/10 誤字脱字を修正しました 2016/11/07 内容を修正しました 2010/09/17 文章を修正しました 一般的に、parallelは並列、concurrentは並行と訳されます。検索してもずばり書かれた物がなかったので、僕なりの理解を書いてみます。 （注：言葉の定義の問題なので、複数の流儀があり得ます。端的に言えば、いわゆるCPUのSIMD命令を「並行」と見なすかどうかに違いが現れます） 参考リンク： http://d.hatena.ne.jp/NyaRuRu/20060129/p2 http://d.hatena.ne.jp/muimy/20070322/1174526368 一番妥当（だと思う）定義 一言で言えば、 Concurrent（並行）は「複数の動作が、論理的に、順不同もしくは同時に起こりうる」こと Parallel（並列）は、「複数の動作が、物理的に
Go言語のGCについて - LINE ENGINEERING
なぜGo言語はコンパクションを採用していないのか GoogleのRick Hudson氏によるISMM 2018 Keynote “Getting To Go”を参照すると、以下のことがわかります。 2014年の時点では”Read barrier free concurrent copying GC”を計画していた しかし期間的な制約から断念し、CMSに舵を切った（この時期に彼らは、ランタイムをCからGoに書き換える作業も行う必要がありました。Changes to the runtime） TCMallocをベースとしたメモリアロケーターを採用することで、断片化およびアロケーションの速度の問題を解決した Go言語のメモリアロケーションについては、ランタイムのコードのコメントにも詳しく記載されています。 malloc.go This was originally based on tcmal
Garbage First Garbage Collector (G1 GC) - Migration to, Expectations and Advanced Tuning
Garbage First Garbage Collector (G1 GC) - Migration to, Expectations and Advanced Tuning
G1GC Fundamentals: Lessons from Taming Garbage Collection
Object allocation > Region The primary pain point to the breaking apart of heap into isolated Regions is the large allocation, where large is relative to the Region size. How should G1GC handle an allocation that is 3x larger than a Region itself? G1GC names these problem allocations Humongous objects, and it must be noted that a Humongous object is single allocation such as a byte[30 * 1024 * 102
CMS GC おさらい - unnamed
この記事は Java Advent Calendar 2014 の一日目の記事です。 先日の JJUG CCC 2014 Fall で CMS GC について話してきました。 結構遅めの時間帯にも関わらず、200人規模の部屋がいっぱいに埋まるぐらいの盛況振りで、みなさんGCにお困りなんだなあと実感しました。スライドは以下に公開しています。CMS GC の挙動から GC ログの読み方、どういうケースが厄介なのかを紹介しているので是非ご覧ください！ Concurrent Mark-Sweep Garbage Collection #jjug_ccc from Yuji Kubota 嬉しいことにセッションの反応は良かったのですが、「遅めの時間帯で頭も疲れてるとガチ話辛い」という声もあったので、今回は CMS GC について比較的重要な点についてだけ簡単におさらいしたいと思います。 オプションに
Java弱参照メモ(Hishidama's Java Weak reference Memo)
Java弱参照クラス 通常のインスタンスは、どこかの変数が保持（参照）していれば、GCの対象にならない。 しかし弱参照にして保持すると、他の通常の参照が全て無くなれば、GCの対象になる。 （弱参照という用語を使う場合は、通常の参照は「強参照」と呼ぶ。強参照と弱参照の間に当たるソフト参照、弱参照より下のファントム参照というのもあるらしい） WeakHashMap WeakHashMapは、キーを弱参照で保持するHashMap。 このマップのキーに当たるオブジェクトの（他からの）強参照が全て無くなると、このマップ内からそのキー（と値）が削除される。 例： Map<Integer, String> map = new WeakHashMap<Integer, String>(); // キーを強参照で保持しつつ、マップに値をセット Integer[] force = new Integer[10
Javaのメモリ管理
本日のカクテルは「Javaのメモリ管理」です。 ネタ元はかつのりさんのBlogです。 GCについて勘違いしている人が結構多い JavaというとGC(ガーベッジコレクション)によって不要となったオブジェクトが回収される仕組みになっていますので、一般のプログラマはメモリの確保、解放について考える必要がありません。 ただし、プロフェッショナルなプログラマの方は一般のプログラマの分まで背負い込んで考えてもらう必要があります。 C言語のようにメモリの割り当てと解放を直接管理することはありませんが、まったく別種のメモリ管理が必要となってきます。 参照の種類 「要するに、参照がなくなればGCに回収される、参照があれば回収されない、それだけのことだろう？」 こうおっしゃるお客さんは沢山いらっしゃいます。では、参照にも種類があることをご存じですか？ 強い参照 (strong reference) ソフト参照
JavaのGC頻度に惑わされた年末年始の苦いメモリ
JavaのGC頻度に惑わされた年末年始の苦いメモリ：現場から学ぶWebアプリ開発のトラブルハック（9）（1/3 ページ） 本連載は、現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集である。現在起きているトラブルの解決や、今後の開発の参考として大いに活用していただきたい。（編集部） Java言語を利用するようになって、システムを開発するうえで楽になった要素は何かというアンケートがあったとき、読者の皆さんならどのように回答するだろうか。私は迷わず、「メモリ管理」と回答する。 同時に、Javaを利用してシステム開発を行う際に、注意していること、悩まされたことは何かとアンケートがあれば、「GC（ガベージ・コレクション）」と回答するだろう。 多くのシステム開発の現場では、いまこの瞬間も、JavaのGCの挙動に悩まされ、GC
Java 7 CMS GCの基本的な情報の整理 - nekop's blog
バッチ処理などスループット重視のアプリケーションはデフォルトのパラレルGCで良いが、Java EEアプリケーションサーバなどレスポンスタイム重視のものやHadoopなどのクラスタ系ソフトウェアで死活監視に引っ掛る系などのstop the worldをなるべく避けたいいわゆるサーバ系ソフトウェアを運用する場合には、UseConcMarkSweepGCを付与して停止時間の短いCMS GCを使う。その場合にCMSのチューニングに踏み込もうとするとなんだか難しい記述がいっぱいで若干困るので、簡単なガイドをメモとして書いておく。 対象バージョンは以下。 $ java -version java version "1.7.0_51" OpenJDK Runtime Environment (fedora-2.4.5.1.fc20-x86_64 u51-b31) OpenJDK 64-Bit Serve
メモリリークトラブルシューティング記 – その4: リーク箇所を確認する色々な方法 – yusuke.blog
– その1: 自宅サーバがハング – その2: フリーズの原因はガベージコレクション – その3: 侍でヒープ使用量を確認 – その4: リーク箇所を確認する色々な方法 前回のエントリではOld 領域にオブジェクトが溢れていることを突きとめた経緯を書きました。 次は、ヒープ領域にどんなオブジェクトが溜まっているのか確認する必要があります。 リークしているオブジェクトを検出する方法はいくつかあり、それぞれ以下のような特徴があります。 1. プロファイラ リーク検出を行う上で一番有名な方法。 JVM に特殊なフックをかけ、オブジェクトの生成、GC 等の挙動を監視します。 アプリケーションを動作させながら増加してくオブジェクトだけを抽出したり、オブジェクト生成に至るスタックトレースを確認したりと様々な視点で VM を調査できるのが特徴です。 一般的にプロファイラを使うと VM のパフォーマンスが
Javaメモリ、GCチューニングとそれにまつわるトラブル対応手順まとめ - 日記のような何か
GC周りでトラブルシューティングした際の経験や、Web等で調べたことをまとめてみる。 前提 ・JVMは、Sun Javaを想定。(他は使ったことないです。。。) ・Sun Java 1.5-1.6を想定。 目標 マイナーGC、Full GCそれぞれが頻発することなく、かつそれぞれの実行時間を1秒未満に抑えること。 マイナーGCは1秒未満どころではなく、もっと短くなるべき。どれくらいが理想かは？(0.1秒未満ぐらいを目指したい？) 連続した負荷状態(想定されるピークアクセス)でもOutOfMemoryErrorが発生しないこと。 理想的な状態は、上記に加えて、Full GCの発生が低頻度であること。 具体的には、できるだけマイナーGCで短命オブジェクト(1回使ったらもう使わないようなオブジェクト。逆にセッションオブジェクト等は長命オブジェクトとなる)を破棄させて、短命オブジェクトが、Tenu
徹底解剖「G1GC」実装編（β版）
本書はOpenJDK7のG1GCの実装と、それに関連する技術を解説します。 目次 スポンサーのみなさま はじめに 1.準備 2.オブジェクト管理機能 3.アロケータ 4.ヒープ構造 5.オブジェクト構造 6.HotspotVMのスレッド管理 7.スレッドの排他制御 8.GCスレッド（並列編） 9.GCスレッド（並行編） 10.並行マーキング 11.退避 12.予測とスケジューリング 13.正確なGCへの道 14.ライトバリアのコスト さらに勉強したい人へ その他参考文献 以下から（ある時点で）最新のebookをダウンロードできます。 徹底解剖「G1GC」実装編-20120915.epub 徹底解剖「G1GC」実装編-20120914.mobi 徹底解剖「G1GC」実装編-20120914.pdf 謝辞 本書はスポンサーのみなさまの金銭的支援によって執筆されました。 スポンサーのみなさま あ
G1 GC おさらいと #jjug_ccc で発表した話 - unnamed
この記事は Java Advent Calendar 2015 の一日目の記事です。二年連続でトップバッターだ！ 先日の JJUG CCC 2015 Fall で G1 GC について話してきました。 去年の CMS GC と同じく結構遅めの時間帯＆裏番組に伝説の灰色ページ管理人・ひしだま伝道師が発表するなどの豪華な時間帯にも関わらず、165人規模の部屋がいっぱいに埋まるぐらいの盛況でした。聴講頂いた皆様ありがとうございました！ スライドは以下に公開しました。G1 GC の挙動から GC ログの読み方、どういうケースが厄介なのかを紹介しているので是非ご覧ください！ Garbage First Garbage Collection (G1 GC) #jjug_ccc #ccc_cd6 from Yuji Kubota アフターフォロー、またはちょっとした補足 極力、後から参照可能なように資料
ガベージコレクション - Wikipedia
ガベージコレクション[注釈 1]（英: garbage collection、GC）とは、コンピュータプログラムが動的に確保したメモリ領域のうち、不要になった領域を自動的に解放する機能である。1959年ごろ、LISPにおける問題を解決するためジョン・マッカーシーによって発明された[1][2]。 メモリの断片化を解消する機能はコンパクション（英: memory compaction）と呼ばれ、実現方法によってはガベージコレクションと共にコンパクションも行う仕組みになっている。そのためコンパクションを含めてガベージコレクションと呼ぶ場合もあるが、厳密には区別される。 また、ガベージコレクションを行う主体はガベージコレクタ（英: garbage collector）と呼ばれる。ガベージコレクタはタスクやスレッドとして実装される場合が多い。 「ガベージコレクション」を直訳すれば「ゴミ集め」「ごみ拾
＠IT：Javaパフォーマンスチューニング 第3回
本記事は、HP-UX Developer Edgeに掲載された記事を株式会社アットマーク・アイティおよび本記事の筆者が独自の判断のもとに加筆・修正したものです。 今回は、Javaにおけるヒープ・メモリ管理の詳細を説明します。JVMのヒープ・メモリの中で、新しいオブジェクトと古いオブジェクトがどのように配置されるかを理解することで、ヒープ・メモリが有効に利用されているか否かを判断することができます。また、JVMが出力するガベージ・コレクションのログを解析し、オプションの指定によってヒープ・メモリのサイズを適切にチューニングする方法を紹介します。 Java ヒープ・メモリの構造 Javaにおけるガベージ・コレクションのメカニズムを理解するには、まずヒープ・メモリの構造を知っておく必要があります。 図1は、JVM におけるヒープ・メモリの構造を示したものです。この図が示すように、ヒープ・メモリの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Application Performance Monitoring | Splunk
Garbage First Garbage Collection (G1 GC) #jjug_ccc #ccc_cd6