タグ

GCに関するtom__boのブックマーク (7)

  • GC - GCアルゴリズム詳細解説 - livedoor Wiki(ウィキ)

    GC¥¢¥ë¥´¥ê¥º¥à¾ÜºÙ²òÀâ ÆüËܸì¤Î»ñÎÁ¤¬¤¹¤¯¤Ê¤¤GC¥¢¥ë¥´¥ê¥º¥à¤Ë¤Ä¤¤¤Æ¾ÜºÙ¤Ë²òÀ⤷¤Þ¤¹ ¥È¥Ã¥×¥Ú¡¼¥¸¥Ú¡¼¥¸°ìÍ÷¥á¥ó¥Ð¡¼ÊÔ½¸ GC ºÇ½ª¹¹¿·¡§ author_nari 2010ǯ03·î14Æü(Æü) 20:47:11ÍúÎò Tweet ¤³¤ÎWiki¤¬Ìܻؤ¹½ê GC¤È¤Ï¡© GC¤ò³Ø¤ÖÁ°¤ËÃΤäƤª¤¯»ö ¼Â¹Ô»þ¥á¥â¥ê¹½Â¤ ´ðËÜ¥¢¥ë¥´¥ê¥º¥àÊÔ Reference Counter Mark&Sweep Copying ±þÍÑ¥¢¥ë¥´¥ê¥º¥àÊÔ IncrementalGC À¤ÂåÊÌGC ¥¹¥Ê¥Ã¥×¥·¥ç¥Ã¥È·¿GC LazySweep TwoFinger Lisp2 Pa

    GC - GCアルゴリズム詳細解説 - livedoor Wiki(ウィキ)
    tom__bo
    tom__bo 2017/05/01
  • Golangの新しいGCアルゴリズム Transaction Oriented Collector(TOC)

    http://golang.org/s/gctoc Goの新しいGCのProposalが出た.まだProposal段階であり具体的な実装はないが簡単にどのようなものであるかをまとめておく. GoのGCはGo1.5において単純なStop The World(STW)からConcurrent Mark & Sweepへと変更され大きな改善があった(詳しくは“GolangのGCを追う”に書いた).先の記事に書いたようにGo1.5におけるGCの改善は主にレイテンシ(最大停止時間)に重きが置かれいた.数値目標として10msが掲げられGo1.6においては大きなヒープサイズ(500GB)においてそれを達成していた. GCの評価項目はレイテンシのみではない.スループットやヒープの使用効率(断片化の対処)なども重要である.Go1.6までのGCではそれらについて大きく言及されていなかった(と思う).例えばスル

  • Getting Started with the G1 Garbage Collector

    Purpose This tutorial covers the basics of how to use the G1 garbage collector and how it can be used with the Hotspot JVM. You will learn how the G1 collector functions internally, the key command line switches for using G1, and options for logging its operation. Time to Complete Approximately 1 hour Introduction This OBE covers the basics of Java Virtual Machine(JVM) G1 Garbage Collection (GC) i

    tom__bo
    tom__bo 2015/11/24
  • jstat

    Java仮想マシン(JVM)の統計情報をモニターします。このコマンドは試験的なものであり、サポート対象外になっています。 形式 jstat [ generalOption | outputOptions vmid [ interval[s|ms] [ count ] ] generalOption 単一の一般的なコマンド行オプション-helpまたは-optionsです。「一般オプション」を参照してください。 outputOptions 単一のstatOptionに加えて、-t、-hおよび-Jオプションのいずれかで構成される1つ以上の出力オプションです。「出力オプション」を参照してください。 vmid ターゲットJVMを示す文字列である仮想マシン識別子です。一般的な構文は次のとおりです。 [protocol:][//]lvmid[@hostname[:port]/servername] vm

    tom__bo
    tom__bo 2015/11/18
    java8
  • Java8のHotSpotVMからPermanent領域が消えた理由とその影響 | ギークを目指して

    今回も前回の記事につづき、Java8による変更点で未だあまり紹介されていないポイントを記事にしようと思う。 今回はJava8のHotSpotVMの話。Java8ではJEP122が取り込まれ、VMのメモリモデルが変更された。JEP122のタイトル「Remove the Permanent Generation」から想像できるとおり、Java8のHotSpotVMからは従来のPermanent領域が無くなった。 なぜ、こういった変更が行われたのだろうか?また、元々Permanent領域に格納されていた情報は何処にいってしまったのか?JVM付属のツールにどういった影響があるのか? 今回の記事ではこの点をまとめていこうと思う。 なお、HotSpotVMのメモリモデルについて詳しくない方は、先にこちらの項番(「補足 – HotSpotVMのメモリ構造概説)を読んでいただくとスムーズに読み進められるだ

    Java8のHotSpotVMからPermanent領域が消えた理由とその影響 | ギークを目指して
  • Garbage First Garbage Collector (G1 GC) - Migration to, Expectations and Advanced Tuning

    Since JDK 9, G1 GC is the default garbage collector (JEP 248). Up until 2017, Monica has shared some G1 GC details, performance tips, and optimizations that help G1's adaptiveness and provided advice on manual tuning. Since then, G1 has come a long way in improving its adaptiveness. In this session, Monica will cover most of the important optimizations that are delivered from JDK9+ and how they ca

    Garbage First Garbage Collector (G1 GC) - Migration to, Expectations and Advanced Tuning
  • 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

    Java 7 CMS GCの基本的な情報の整理 - nekop's blog
  • 1