2013/12/18

CQRSの和訳

DDDとCQRSについて

DDD (Domain Driven Design = ドメイン駆動設計)が世間に知られるようになってきましたが、今度はDDDをさらにスケーラビリティにするCQRS (Command Query Responsibility Segregation = コマンドクエリ責務分離)が出てきました。

DDD提唱者の英語本の和訳版「エリック・エヴァンスのドメイン駆動設計」がAmazonにありますが、非常に分厚く高価です。概要をまとめた資料が「Domain Driven Design(ドメイン駆動設計) Quickly 日本語版 - InfoQ」から入手できます。

CQRSはデータベース設計とイベントソーシングも含めた壮大なWebアプリケーションのアーキテクチャですが、日本語の資料がまだ少ないです。CQRSを適用したアプリケーションを構築できるインフラがWindows Azureにあるようですが、Java EEにはまだ無いようです。

Greg Young流CQRSの和訳版

DDDもCQRSもスケールが大きな設計手法で、容易に理解できるものではありませんが、理念や概要を知っておくだけでも、かなり見えてくるものがあると思います。というわけで、Greg Young氏著の「CQRS Documents by Greg Young」を和訳しました。Greg Young氏の許可をいただけましたので、公開します。拙者は英語が苦手なので、和訳内容に誤りや不適切な表現が随所にあることをご了承ください。
翻訳内容の訂正や指摘などございましたら、ご教示いただけると嬉しいです。修正して入れ替えます!!

2013/06/22

JMS 2.0チュートリアル with NetBeans 7.3.1 and GlassFish4


JMS 2.0チュートリアル with NetBeans 7.3.1 and GlassFish4
本チュートリアルは、「NetBeansおよびGlassFishを使用した、簡単なJava Message Service(JMS)プロデューサの作成」を参考にして作成しました。
JMSは一般的には、異なるJava EEアプリケーション間のコミュニケーション手段として使いますが、ここでは、1つのWebアプリケーションでJMS 2.0のキューを利用したメッセージ送信とメッセージ受信の両方を実装します。


【目次】
  1. Webアプリケーションプロジェクトの作成
  2. メッセージ送信処理の実装
    1. メッセージ送信するJSF管理対象Beanの作成
    2. メッセージ送信するJSFページの作成
  3. メッセージ受信処理の実装
  4. 実行してみる

Webアプリケーションプロジェクトの作成

以下の手順でWebアプリケーションのプロジェクトを作成します。
  1. NetBeansのメニューバーから、[ファイル] > [新規プロジェクト]を実行します。

  2. [新規プロジェクト]画面の[1. プロジェクトを選択]ステップにて、
    [カテゴリ]で[Java Web]、[プロジェクト]で[Webアプリケーション]を選択し、[次 >]を押下します。


  3. [新規 Webアプリケーション]画面の[2. 名前と場所]ステップにて、[プロジェクト名]に[JMSSample]を入力し、[次 >]を押下します。
    なお、[プロジェクトの場所]は任意です。


  4. [新規 Webアプリケーション]画面の[3. サーバと設定]ステップにて、
    次の画面のようになっていることを確認し、[次 >]を押下します。


  5. [新規 Webアプリケーション]画面の[4. フレームワーク]ステップにて、[JavaServer Faces]を選択し、「終了]を押下します。
以上で、Webアプリケーションのプロジェクト作成は完了です。

メッセージ送信処理の実装

メッセージを送信する部品として、JSFページとJSF管理対象Beanの2つを作成します。
JSFページでメッセージを入力して送信を実行したら、JSF管理対象BeanでメッセージをJMSキューに入れるという処理になります。
なお、JMSキューではメッセージ送信部品をProducerと呼びます。

メッセージ送信するJSF管理対象Beanの作成

以下の手順で、JSFページで入力したメッセージを取り出して、JMSキューに入れるJSF管理対象Beanを作成します。
なお、JSFページは後で作成します。
  1. [プロジェクト]の[ソース・パッケージ]を右クリックして、ポップアップメニューから[新規] > [その他]を実行します。
  2. [新規ファイル]画面の[1. ファイル・タイプを選択]ステップにて、
    [カテゴリ]で[JavaServer Face]を、[ファイル・タイプ]で[JSF管理対象Bean]を選択し、[次 >]を押下します。
  3. [New JSF管理対象Bean]画面の[2. 名前と場所]ステップにて、
    [クラス名]に[MessageProducerBean]、[パッケージ]に[jms2]を入力し、[スコープ]で[request]を選択し、[終了]を押下します。
  4. 以上のウィザードで生成されたjms2.MessageProducerクラスをプログラミングします。
    messageフィールドとそのgetter/setterを作成し、sendメソッドを入れます。
    (赤字がプログラミングする部分)
    package jms2;
    
    import javax.inject.Named;
    import javax.enterprise.context.RequestScoped;
    
    @Named(value = "messageProducerBean")
    @RequestScoped
    public class MessageProducerBean {
        private String message;
    
        public MessageProducerBean() {
        }
    
        public String getMessage() {
            return message;
        }
    
        public void setMessage(String message) {
            this.message = message;
        }
    
        public void send(){
        }
    }
  5. sendメソッドの閉じかっこ「}」の後ろで[Alt]+[Insert]キーを押下して、ポップアップメニューから[JMSメッセージを送信...]を実行します。
  6. [JMSメッセージを送信]画面の、[プロジェクトの送信先]で[追加]を押下して[jms/queue1]を追加し、[OK]を押下します。
  7. jms2.MessageProducerクラスにコードが自動挿入され、次の内容になります。
    また、[サーバー・リソース]フォルダ配下の[glassfish-resources.xml]にも「jms/queue1」などが自動挿入されます。
    (赤字が自動挿入されたコード)
    package jms2;
    
    import javax.annotation.Resource;
    import javax.inject.Named;
    import javax.enterprise.context.RequestScoped;
    import javax.inject.Inject;
    import javax.jms.JMSConnectionFactory;
    import javax.jms.JMSContext;
    import javax.jms.Queue;
    
    @Named(value = "messageProducerBean")
    @RequestScoped
    public class MessageProducerBean {
        @Resource(mappedName = "jms/queue1")
        private Queue queue1;
        @Inject
        @JMSConnectionFactory("java:comp/DefaultJMSConnectionFactory")
        private JMSContext context;
        private String message;
    
        public MessageProducerBean() {
        }
    
        public String getMessage() {
            return message;
        }
    
        public void setMessage(String message) {
            this.message = message;
        }
    
        public void send(){
        }
    
        private void sendJMSMessageToQueue1(String messageData) {
            context.createProducer().send(queue1, messageData);
        }
    }
  8. sendメソッドをプログラミングします。
    (赤字がプログラミングする部分)
        public void send(){
            FacesContext facesContext = FacesContext.getCurrentInstance();
            sendJMSMessageToQueue1(message);
            FacesMessage facesMessage = new FacesMessage("Message sent: " + message);
            facesMessage.setSeverity(FacesMessage.SEVERITY_INFO);
            facesContext.addMessage(null, facesMessage);
        }
    
  9. jms2.MessageProducerBeanクラスを保存します。
以上で、jms2.MessageProducerBeanクラスの作成は完了です。

メッセージ送信するJSFページの作成

[Webページ]フォルダ配下の[index.xhtml]を次の内容になるようにプログラミングして、保存します。
(赤字がプログラミングする部分)
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://xmlns.jcp.org/jsf/html">
    <h:head>
        <title>JMS Message Producer</title>
    </h:head>
    <h:body>
        JMS Message Producer
        <h:form>
            <h:outputLabel value="Message: " for="message"/>
            <h:inputText id="message" value="#{messageProducerBean.message}"/>
            <h:commandButton value="Send Message" action="#{messageProducerBean.send}"/>
            <h:messages globalOnly="true"/>
        </h:form>
    </h:body>
</html>

メッセージ受信処理の実装

メッセージを受信する部品として、MDB(Message Driven Bean)を作成します。
今回作成するのは、JMSキューからメッセージを取り出して、コンソールに出力するだけの簡単なMDBです。 なお、JMSキューではメッセージ受信部品をConsumerと呼びます。
  1. [ソース・パッケージ]の[jms2]パッケージを右クリックして、ポップアップメニューから[新規] > [その他]を実行します。
  2. [新規ファイル]画面の[1. ファイル・タイプを選択]ステップにて、
    [カテゴリ]で[エンタープライズJavaBeans]を、[ファイル・タイプ]で[メッセージ駆動型Bean]を選択し、[次 >]を押下します。
  3. [New メッセージ駆動型Bean]画面の[2. 名前と場所]ステップにて、
    [EJB名]に[MessageConsumerBean]を入力し、[次 >]を押下します。
  4. [新規ファイル]画面の[3. アクティブ化構成プロパティ]ステップでは、そのまま[終了]を押下します。
  5. jms2.MessageConsumerBeanクラスのonMessageメソッドをプログラミングします。
    (赤字がプログラミングする部分)
    @Override
    public void onMessage(Message message) {
        try {
            TextMessage tm = (TextMessage) message;
            System.out.println("Consumed message: " + tm.getText());
        } catch (JMSException ex) {
            ex.printStackTrace(System.err);
        }
    }
  6. jms2.MessageConsumerBeanクラスを保存します。

実行してみる

  1. [JMSSample]を右クリックし、ポップアップメニューから[実行]を実行します。
  2. ブラウザでJSFページが表示されます。
    [Message]に任意のメッセージを入力して[Send Message]を押下します。
  3. NetBeansのコンソールに、次が出力されていたら成功です。
以上、簡単なJMS 2.0のチュートリアルでした。
JMS 1.1までの開発経験がある方にとっては、プログラミング量がかなり減ったことがわかっていただけるでしょう。

2013/05/22

Java™ 7でのガーベジコレクションの選択

Java 7のガーベジコレクションの入り口

Java 7のガーベジコレクションの仕様や実装を調べるなら、次の2つが入り口となるでしょう。

Java 7でガーベジコレクションを選択する方法(6種類)

Java 7ではエルゴノミクス機能により、自動的にガーベジコレクション(GC)を決定します。
エルゴノミクス機能による決定を無効にして自分でGCを選択したい場合、次の6種類のオプションの指定方法があります。

  • -XX:+UseSerialGC
  • -XX:+UseParallelGC
  • -XX:+UseParallelGC -XX:+UseParallelOldGC
  • -XX:+UseConcMarkSweepGC
  • -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode
  • -XX:+UseG1GC
-XX:+UseSerialGC
New世代領域、Old世代領域ともに、GCを単一スレッドで実行。
-XX:+UseParallelGC
New世代領域では、GCを複数スレッドで実行。
Old世代領域が不足したら、Full GCを単一スレッドで実行。
-XX:+UseParallelGC -XX:+UseParallelOldGC
New世代領域では、GCを複数スレッドで実行。
Old世代領域が不足したら、Full GCを複数スレッドで実行。
-XX:+UseConcMarkSweepGC
New世代領域は-XX:+UseParallelGCと同様の処理。
Old世代領域でCMS GCを実行。
CMS GCは、アプリケーションスレッドと並列してGCを実行することにより、Stop the worldを減らすのが狙い。
CMS GCはコンパクションを行わないので、CMS GCでもメモリが不足する場合は、フォールバックとしてFull GCを実行。
-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode
-XX:+UseConcMarkSweepGCをインクリメンタル・モードで実行。
インクリメンタルモードの詳細は未調査だが、Old世代領域のGCを少しずつ実行するイメージ)
Oracleのドキュメントでは「i-cms」で説明されています。
-XX:+UseG1GC
Java 7新機能のG1 GCを実行。
Javaヒープを細かく細分化し、New世代領域やOld世代領域などを割り当てる方式。
詳細は、上の「Getting Started with the G1 Garbage Collector」を参照。

なお、Full GCはMark Sweep and Compaction方式です。
また「-Xincgc」は上の5つめの「-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode」と同じになります。
なおCMS GCは「Concurrent Mark Sweep [Garbage] Collectorの略称で、CMS GCの説明は「Java SE 6 HotSpot™ Virtual Machine Garbage Collection Tuning」にあります。

Java 7でのSystem.gc()の実行について

十分プログラムを追えていませんが、

  1. \jdk\src\share\classes\java\lang\Runtime.java
  2. \jdk\src\share\native\java\lang\Runtime.c
  3. hotspot\src\share\vm\prims\jvm.cpp
  4. hotspot\src\share\vm\memory\universe.cpp

と追っていくと、

  • GenCollectedHeap::collect(GCCause::Cause cause)と
  • G1CollectedHeap::collect(GCCause::Cause cause)

に辿り着きます。
条件によっては、FullGCを実行するように見えます。「条件によっては」と書いたのですが、基本的にFull GCになると期待しています。
「Java™ Platform, Standard Edition 7 API Specification」のRuntime.gc()のところに

Runs the garbage collector. Calling this method suggests that the Java virtual machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the virtual machine has made its best effort to recycle all discarded objects.

ガベージコレクタを実行します。このメソッドを呼び出すと、Java 仮想マシンは使用していないオブジェクトをリサイクルし、使用中のメモリーをすばやく再利用可能な状態にします。メソッド呼び出しから制御が戻された時点で、仮想マシンは破棄されたオブジェクトをすべて再利用するよう最善を尽くしたことになります。

とあります。Full GCを実行することが明記されていないし、コンパクションを行うかも判りませんが、「-verbose:gc」でログを取るなどしてウラを取ってみたいと考えています。

2013/05/16

Getting Started with the G1 Garbage Collectorの日本語訳

本書は次の英文資料を日本語訳したものです。
不備や質問がありましたら、訳者にご連絡いただければ幸いです。
2013/03/16
  隆行
turbo[at]minato.tv


Overview | 概要
Purpose | 目的
このチュートリアルでは、G1 ガーベジコレクタの基本的な使用方法と、Hotspot JVMにおけるG1ガーベジコレクタの使われ方を説明します。またG1 ガーベジコレクタの内部機能、コマンドラインオプション、および、ログに関するオプションについて説明します。

Time to Complete | 完読時間
およそ1時間。

Introduction | はじめに
このOBE (Oracle by Example)では、Java仮想マシン(JVM)および G1 ガーベジコレクション (GC)を説明します。まず、JVMの概要について、ガーベジコレクションと性能を紹介しながら説明します。次に、CMSコレクタの動作手順を復習し、G1ガーベジコレクションの動作手順を説明します。最後に、G1ガーベジコレクタで使用可能なコマンドライン・オプションや、ログ出力のオプションを説明します。

Hardware and Software Requirements | ハードウェアとソフトウェアの要件
ハードウェアとソフトウェア要件の一覧:
o    Windows XP以降が動作するPCMac OS X、またはLinux。ハンズオンはWindows 7で行ったものです。すべてのプラットフォームでテストしたわけではありませんが、OS XまたはLinuxでも動作します。また、複数コアを搭載したマシンで動作するのを推奨します。
o    Java 7 Update 9以降
o    最新のJava 7 Demos and SamplesZipファイル

Prerequisites | 必要条件
このチュートリアルを始める前にやること:
o    JDK 7 u9以降が未インストールであれば、ダウンロードしてインストールしてください。
Java 7 JDK Downloads
o    Demos and Sampleszipファイルを同じところからダウンロードしてください。 ダウンロードしたzipファイルは、例えば「C:\javademos」ディレクトリ配下に解凍してください。



Java Technology and the JVM | JavaテクノロジーとJVM


Java Overview | Javaの概要

JavaSun Microsystems社が1995年に初めてリリースしたプログラミング言語とコンピューティング・プラットフォームです。Javaはユーティリティ、ゲーム、ビジネスアプリケーションを含むJavaプログラムの原動力となった基礎テクノロジーです。Javaは世界中で850万(8.5億)を超えるパーソナルコンピュータと数十億のモバイル端末やテレビなどのデバイスで動作しています。Javaの全体像は、Javaプラットフォームを構築するための多くの重要なコンポーネントから構成されています。

Java Runtime Edition | Javaランタイム版

ダウンロードしたJavaには、Java Runtime Environment (JRE)が含まれています。JREは、Java 仮想マシン (JVM)Javaコアクラス、および、Javaライブラリのサポート機能で構成されています。この3つはすべて、コンピュータ上でJavaアプリケーションが動作するために必要なものです。Java 7で動作するJavaアプリケーションには、OSから起動するデスクトップアプリケーション、Java Web Startを使用してWebから起動するデスクトップアプリケーション、あるいは、ブラウザ上で動作するWeb組み込みアプリケーション(Java FXを使用)があります。

Java Programming Language | Javaプログラミング言語

Javaは次の特徴を持つオブジェクト指向プログラミング言語です。
    • プラットフォーム非依存 - Javaアプリケーションをコンパイルするとバイトコードを生成します。バイトコードはクラスファイル内にあり、JVMがロードします。アプリケーションはJVM上で動作するので、様々なOSやデバイス上で動作可能です。
    • オブジェクト指向- Javaは、CC++の多くの特徴を導入し、更なる改良を加えたオブジェクト指向言語です。
    • 自動ガーベジコレクション – Javaはメモリ割り当てと解除を自動的に行うので、プログラムにはメモリ操作の負担がありません。
    • 豊かな標準ライブラリ – Javaには、入出力処理、ネットワーク処理および、日付操作などを行うための非常に多くのオブジェクトをあらかじめ用意しています。

Java Development Kit | Java開発キット

Java仮想マシンは、Javaプログラミング言語を解釈するのではなく、特定のバイナリフォーマットであるクラスファイルを解釈します。クラスファイルには、Java仮想マシンの命令(もしくはバイトコード)、シンボルテーブルや、他の補助情報が含まれます。

セキュリティのために、Java仮想マシンは、統語的かつ構造的な制約を強く課したクラスファイルを扱います。有効なクラスファイルであれば、Java仮想マシンはJava以外のどんな言語でも処理できます。したがって、Java以外の言語の実装者も、Java仮想マシンの可搬性とマシン非依存のプラットフォームに惹きつけられて、その言語の動作環境としてのJava仮想マシンに関心を持ちます。 (1) The Java Virtual Machine

Exploring the JVM Architecture | JVMアーキテクチャの探検

Hotspot Architecture | Hotspotアーキテクチャ

HotSpot JVMには、強力な機能(features)と能力(capabilities)の基盤をサポートするアーキテクチャと、高い性能とスケーラビリティを実現する能力(ability)をサポートするアーキテクチャがあります。たとえば、HotSpot JVMJITコンパイラは動的最適化を行います。Javaアプリケーション動作中に最適化を行い、システムアーキテクチャ向けの高性能なネイティブ命令を生成します。また、実行環境およびマルチスレッドで動作するガーベジコレクタは、継続的な改良により成熟した進化を遂げました。これらによりHotSpot JVMは高性能なコンピュータシステム上でも高いスケーラビリティを提供します。


JVMの主要コンポーネントには、クラスローダ(Class Loader)、ランタイムデータ領域(Runtime Data Area)と、実行エンジン(Execute Engine)があります。

Key Hotspot Components | 主要なHotspotコンポーネント

下図では、JVMの主要なコンポーネントのうち、性能に関する部分をハイライトで示しています。

図でハイライト表示したJVM3つのコンポーネントは、性能をチューニングするときに重要となるものです。ヒープはオブジェクトデータを格納する領域であり、Javaプログラムを起動するときに指定したガーベジコレクタがヒープを管理します。多くのチューニングオプションは、アプリケーションの状況に応じてヒープサイズを指定したり、最適なガーベジコレクションの選択したりするものです。JITコンパイラは性能に大きな影響を及びますが、最近のJVMでは滅多にチューニングする必要はありません。

Performance Basics | 性能の基本

一般的にJavaアプリケーションのチューニングでは、2つの主な目的である「応答性」と「スループット」のうち、どちらか1つに焦点を当てます。このチュートリアルではこの2つの概念を引用します。

Responsiveness | レスポンス性能

レスポンス性能は、アプリケーションまたはシステムが、リクエストされたデータに対してどれだけ迅速に応答するかを示すものです。例を次に示します。
    • デスクトップUIがどれだけ速くイベントに応答するか
    • Webサイトがどれだけ速くページを返してくるか
    • データベースのクエリがどれだけ速く返ってくるか
レスポンス性能を重視するアプリケーションは、長時間の停止を避け、どれだけ短い時間で応答するかを重視します。

Throughput | スループット性能

スループット性能は、指定時間にアプリケーションがどれだけの処理をこなすかに焦点を当てます。スループット性能を計測する方法の例を、次に示します。
    • 与えられた時間に処理したトランザクション数
    • 1時間にバッチプログラムが消化したジョブ数
    • 1時間に処理したデータベースクエリ数
スループット性能を重視するアプリケーションは、長時間のベンチマークを重視します。迅速な応答性を考慮しないので、長時間の停止は問題視しません。




The G1 Garbage Collector | G1ガーベジコレクタ

The G1 Garbage Collector | G1ガーベジコレクタ

Garbage-First (G1)コレクタは、サーバスタイルのガーベジコレクタで、マルチプロセッサと大容量メモリを搭載したマシンが対象です。G1コレクタは、高いスループットを達成するために、ガーベジコレクション (GC) 停止時間の目標に対して高確率で対処します。
    • CMSコレクタのように、アプリケーションスレッドと並行して動作できること
    • 停止時間を伴うGCを行わずに、断片化した空き領域を結合すること(コンパクション)
    • GC停止時間を予測可能であることが求められること
    • できるだけスループット性能を低下させないこと
    • 巨大なJavaヒープを必要としないこと
G1Concurrent Mark-Sweepコレクタ (CMS)に取って代わる長期的なものとして計画します。CMSと比較して、G1が良いソリューションとなる相違点があります。1つ目の相違点は、G1はコンパクションを行うコレクタであることです。G1は、きめ細かいフリーリストを使わずに、細かく分割した領域を活用して、十分なコンパクションを行います。コレクタの一部処理を単純化し、潜在的な断片化問題をほとんど除去します。また、G1CMSコレクタよりもガーベジコレクション停止時間の予測精度を高め、ユーザが希望する停止時間の目標を達成できるようにします。

G1 Operational Overview | G1操作上の概要

シリアル、パラレル、CMSでは、ヒープを固定サイズのYoung世代、Old世代、Permannent世代に分割します。

すべてのメモリオブジェクトは、3つの領域のどれかに入ります。
G1コレクタは、異なるアプローチを採ります。

ヒープを1組の同じサイズの領域に分割します。各領域は仮想メモリ内の連続した区間です。各領域は、以前のコレクターと同様にEdenSurvivorOldを割り当てますが、サイズが固定ではない点で異なります。これはメモリ使用量に応じて、より優れた柔軟性を提供します。

ガーベジコレクションを実行しているとき、G1CMSコレクタと似た方法で動作します。G1は、ヒープの隅々までオブジェクトの生存を決定するために、並列グローバルマーキングフェーズを実行します。そのマークフェーズが完了すると、G1はどの領域が最も空いているかがわかります。まず、これらの領域上で回収し、通常、多くの空き領域を作ります。この理由により、このガーベジコレクション方式をガーベジファーストと呼びます。名前の通りに、G1は回収可能なオブジェクト(つまりゴミ)でいっぱいになりそうなヒープの領域上で回収とコンパクション活動に集中します。G1はユーザ定義の停止時間目標に対処するために停止予測モデルを使用し、指定された停止時間目標に基づいて回収を行う領域数を選択します。

G1が分割した各領域がいっぱいになると、エバキュエーションを使用して、1つか2つ以上の領域から別の1つの領域にオブジェクトを移動します。そのときにコンパクションも行い、メモリの空き領域を広げます。エバキュエーションは、停止時間を減らしてスループット性能を向上させるために、マルチプロセッサ上では並列処理します。G1は断片化を減らすよう継続的に回収を続け、ユーザが指定した停止時間以内に終わらせるようにします。これにより以前の方式より高い能力を実現します。CMS(コンカレント・マーク・スイープ)ガーベジコレクタは、コンパクションを行いません。ParallelOldガーベジコレクションでは、ヒープ全体のコンパクションのみ行うので停止時間が長くなります。

G1はリアルタイムのコレクタでないことに注意してください。停止時間目標に高い確率で対処しますが、必ずしも確実ではありません。前回のコレクションのデータに基づいて、G1はユーザ指定の停止時間目標以内にどれだけの領域を回収できるかを推測します。G1は複数の領域を回収するコストを計算する精密なモデルを備えていて、停止時間以内に回収できるように、回収対象の領域をどれにするかどのくらいにするかを決めます。

注意: G1は、ConcurrentフェーズとParallelフェーズの両方を持ちます。Concurrentフェーズとは、複数のアプリケーションスレッドと共に1つのGCスレッドが動作し、RefinementMarkingCleanupを行うものです。Paralleljフェーズとは、GCを複数スレッドで動作し、Stop the worldの原因となるものです。FullGCは単一スレッドで動作しますが、アプリケーションを適切にチューニングすれば、FullGCを回避できる場合があります。

G1 Footprint | G1フットプリント

ParallelOldGCまたはCMSコレクタからG1に移行するとき、JVMプロセスのサイズがより大きく見えるでしょう。これはRemembered SetsCollection Setsといった「accounting」データ構造によるものです。

Remembered Sets (RSets)は、担当する領域内で、オブジェクトの参照を追跡します。ヒープ内の領域ごとに1つずつRSetがあります。RSetは領域に対する回収をパラレルかつ独立にできるようにします。Rsetsの全体的なフットプリントの影響は5%未満です。

Collection Sets (CSets)は、GCで回収する領域のセットです。CSets内のすべての生存データは、CGによってエバキュエート(コピー/移動)します。領域のセットは、EdenSurvivor  and/or Old世代のどれにもなることができます。CSetsの影響は、JVMのサイズに対して 1%未満です。

Recommended Use Cases for G1 | G1利用を推奨するケース

G1の最初の焦点は、限られたGCレイテンシで、巨大ヒープを必要とするアプリケーションを動作するためのソリューションを提供することです。ヒープサイズが6GB以上であり、安定かつ予測可能な停止時間が0.5秒以下というアプリケーションです。

現在動作中のアプリケーションがCMSまたはParallelOldGCガーベジコレクタのいずれかを使っているとき、次の特徴のいずれかを満たしていれば、G1に変更するメリットがある可能性があります。
    • Full GCの実行時間が非常に長いか、Full GCが非常に頻発する
    • オブジェクトを割り当てる割合か、Old世代領域に昇進する割合が著しく異なる場合
    • ガーベジコレクションまたはコンパクションによる停止時間が長い場合(0.51秒を超過)
注意: アプリケーションがCMSまたはParallelOldGCを使っていて、長いガーベジコレクション停止が起きていない場合、G1に変更せずに現在のコレクタを使い続けるのが良いでしょう。G1コレクタに変更することは、最新のJDKを使う場合でも、G1コレクタに変更しなければならないわけではありません。



Reviewing GC with the CMS | CMS GCの復習

Reviewing Generational GC and CMS | 世代GCCMSの復習

コンカレント・マーク・スイープ(CMS)コレクタは、concurrent low pause collectorとも呼ばれ、Tenured世代(Old世代のこと)を回収します。CMSは多くのガーベジコレクションの処理を、アプリケーションスレッドと並行して実行することによって、停止時間を最小限にします。通常、CMSは生存オブジェクトのコピーまたはコンパクションは行わないので、断片化が問題になる場合、アプリケーションのヒープサイズを大きくする必要があります。

注意:  CMSYoung世代上ではパラレルコレクタと同じアルゴリズムを使います。

CMS Collection Phases | CMSコレクションフェーズ

CMSは、ヒープのOld世代上では、次のフェーズで動作します。
Phase
フェーズ
Description
概要
(1) Initial Mark
(Stop the World Event)
Old世代内のオブジェクトは、Young世代から到着可能なオブジェクトも含め、到着可能なものをマークします。停止時間は一般的にマイナーコレクションの停止時間と比べて短いです。
(2) Concurrent Marking
Javaアプリケーションスレッドの実行と同時に、Old世代のオブジェクトグラフを横切って、到着可能なオブジェクトを調べます。マークされたオブジェクトからスキャンを始め、ルートから到着可能なすべてのオブジェクトを推移的にマークします。ミューテータ(*1)は、フェーズ(2)(3)(5)で実行します。これらのフェーズの実行中に、すべてのオブジェクト(昇進したオブジェクトを含む)はすぐに生存オブジェクトとしてマークされます。
*1:
ミューテータはオブジェクトを生成したり参照の更新を行ったりするもの。ミューテータが参照できるオブジェクトは生存オブジェクトで、参照できないオブジェクトは死んだオブジェクトとみなす。
(3) Remark
(Stop the World Event)
コンカレントコレクタがそのオブジェクトを追跡した後に、Javaアプリケーションスレッドによって更新されたために、Concurrent Markingフェーズで見つけられなったオブジェクトにマークを付けます。
(4) Concurrent Sweep Markingフェーズで到着可能でなかったオブジェクトを回収します。死んだオブジェクトのコレクションは、以降のオブジェクト割り当てに備えて、そのオブジェクトの空間をフリーリストに追加します。死んだオブジェクトのCoalescing(*2)はこの時点で起きる場合があります。生存オブジェクトは移動しないことに注意してください。
*2:
連続した空き領域を、1つの空き領域にまとめること。
(5) Resetting データ構造をクリアして、次のコンカレントコレクションに向けて準備します。

Reviewing Garbage Collection Steps | ガーベジコレクション手順の復習

次に、CMSコレクタの動作手順を復習しましょう。

Heap Structure for CMS Collector | CMSコレクタのヒープ構造
ヒープを3つの空間に分割します。

Young世代は、Eden領域と2つのSurvivor領域に分割します。Old世代は1つの連続した空間です。オブジェクトの回収は適宜に行いますが、Full GCがない限りコンパクションは行いません。

How Young GC works in CMS | CMSにおけるYoung GCの動作について
下図は、アプリケーションがしばらく動作した後のCMSの状況の例を示したものですYoung世代はうす緑色、Old世代は青色です。オブジェクトはOld世代領域で散在しています。

CMSでは、Old世代のオブジェクトを適宜に解放しますが、移動はしません。Full GCがない限り、空き領域のコンパクションは行ないません。

Young Generation Collection | Young世代コレクション
生存オブジェクトはEden空間とSurvivor空間から、他のSurvivor空間にコピーされます。年齢のしきい値に到着した古いオブジェクトはOld世代に移動されます。


After Young GC | Young GC実行後
Young GC実行後、Eden領域をクリアし、片方のSuvivor空間もクリアします。
上図では、Old世代に昇進したオブジェクトを暗い青色で示しています。緑色のオブジェクトは生き残ったYoung世代のオブジェクトで、まだOld世代に移動されていないものです。


Old Generation Collection with CMS | CMSでのOld世代コレクション
Initial markフェーズとRemarkフェースの2つでStop the worldが発生します。Old世代の占有率がしきい値を超えると、CMSを起動します。

 (1) Initial Markフェーズは短い停止を伴うフェーズであり、生存オブジェクト(到着可能なオブジェクト)をマークします。(2) Concurrent Markingフェーズは、アプリケーションの実行と並行して生存オブジェクトを探します。(3) 最後にRemarkフェーズでは、前フェーズのConcurrent Markingフェーズで見つけられなかったオブジェクトを探します。

Old Generation Collection - Concurrent Sweep | Old世代コレクション – Concurrent Sweep
前のフェーズでマークされなかったオブジェクトは、適宜に解放します。コンパクションは行いません。

Note: Unmarked objects == Dead Objects
注意: マークされていないオブジェクト == 死亡オブジェクト

Old Generation Collection - After Sweeping | Old世代コレクション - スイープ後
 (4)Sweepフェーズの後に、下図に示すとおり、多くのメモリが解放されています。またコンパクションが行われていないことも示しています。

最後に、CMSコレクタは(5)Resettingフェーズに移行したあと、Old世代の占有率がしきい値に達するまで待機します。




The G1 Garbage Collector Step by Step
ステップバイステップで見るG1ガーベジコレクタ

The G1 Garbage Collector Step by Step
ステップバイステップで見るG1ガーベジコレクタ

G1コレクタはヒープの割り当て方について異なるアプローチを採っています。以降、G1システムについて、図を交えながらステップバイステップで示します。

G1 Heap Structure | G1ヒープ構造
ヒープは1つのメモリ領域であり、多くの固定サイズの領域に分割します。

JVM起動時に領域のサイズを選択します。JVMは、サイズが132MB2000個前後の領域を、一般的な目標とします。

G1 Heap Allocation | G1ヒープ割り当て
実際に、これらの領域をEden領域、Survivor領域およびOld世代領域の論理表現にマップします。

図では、領域のロールに応じて色を使い分けています。生存オブジェクトは1つの領域から他方の領域にエバキュエート(コピーまたは移動)します。アプリケーションスレッドすべてを停止するかどうかに関わらず、各領域を並列して回収するよう設計しています。
図示のとおり、各領域はEden領域、Survivor領域およびOld世代領域として割り当て可能です。さらにHumongous領域と呼ばれる4番目のタイプがあります。Humongous領域は、標準的な領域(Eden領域、Survivor領域、Old世代のこと)のサイズの50%かそれ以上の巨大オブジェクトを保持します。巨大オブジェクトは1組の連続した領域に保存します。最後にはHumongous領域は、(訳注:オブジェクトを破棄すれば、)ヒープの未使用領域になります。
注意: 現時点では、Humongous領域の回収は最適化しません。したがって、巨大なサイズのオブジェクトを生成しないようにしてください。

Young Generation in G1 | G1Young世代
ヒープをおおよそ2000の領域に分割します。領域の最少サイズは1MBで、最大サイズは32MBです。青色の領域はOld世代のオブジェクトを保持し、緑色の領域はYoung世代のオブジェクトを保持します。

以前のガーベジコレクタのように、Young世代は連続した領域でなければならないわけではありません。

A Young GC in G1 | G1Young GC
生存オブジェクトは1個またはそれ以上のSurvivor領域にエバキュエート(コピーまたは移動)します。年齢のしきい値に達したら、いくつかのオブジェクトはOld世代領域に昇進します。

Young GCStop the world (STW)を起こします。Eden領域とSuvivor領域のサイズは、次回のYoung GCに向けて計算します。このAccounting情報は、領域サイズを計算するために保持します。停止時間の目標などは考慮します。
このアプローチは、領域サイズの調整を非常に容易にし、必要に応じて領域のサイズを大きくしたり小さくしたりします。

End of a Young GC with G1 | G1でのYoung GCの終了
生存オブジェクトは、Survivor領域かOld世代領域にエバキュエートします。

図では、Old世代領域に昇進したオブジェクトを暗い青色で、Survivor領域にコピーしたオブジェクトを緑色で示します。(訳注:図に青色がないのは作成ミス?)
G1Young世代についてまとめたものを、次に列挙します。
    • 1つのメモリ領域であるヒープは、複数の領域に分割します。
    • Young世代領域は非連続の領域のセットであり、必要に応じてサイズが動的に変化します。
    • Young世代GCまたはYoung GCStop the worldを起こし、すべてのアプリケーションスレッドが停止します。
    • Young GCは複数スレッドを使用して並行に処理します。
    • 生存オブジェクトは新しいSuvivor領域またはOld世代領域にコピーします。

Old Generation Collection with G1 | G1でのOld世代コレクション


CMSコレクタと同様、G1コレクタもOld世代の回収を低負荷で実行します。

G1 Collection Phases - Concurrent Marking Cycle Phases
G1
コレクションのフェーズ - コンカレント・マーキング・サイクルフェーズ

G1コレクタは、ヒープのOld世代領域に対して、下表に示すフェーズで動作します。いくつかのフェーズはYoung世代コレクションの一部のフェーズである点に注意してください。

Phase Description
(1) Initial Mark
(Stop the World Event)
Stop the worldを起こします。G1では、通常のYoung GCに便乗します。Old世代のオブジェクトを参照している可能性があるSurvivor領域(Root領域)をマークします。
(2) Root Region Scanning Survivor領域をスキャンし、Old世代への参照があるかどうかを調べます。アプリケーションスレッドと並行して動作します。このフェーズは、(次の?Young GCが発生する前に完了していなければなりません。
(3) Concurrent Marking ヒープ全体を探して生存オブジェクトを見つけます。アプリケーションスレッドと並行して動作します。このフェーズは(次の)Young GCによって中断されることがあります。
(4) Remark
(Stop the World Event)
ヒープ上の生存オブジェクトのマークを完了します。Snapshot-At-The-Beginning (SATB)というアルゴリズムを使います。CMSRemarkフェーズより高速です。
(5) Cleanup
(Stop the World Event and Concurrent)
o    生存オブジェクトのAccountingを実行し、完全な空き領域にします(Stop the World発生)。
o    Remember Setをクリアします
o    空き領域をリセットし、フリーリストに返します(並列処理)
(*) Copying
(Stop the World Event)
新しい未使用利用域に生存オブジェクトをエバキュエート(コピー)します。Stop the worldを起こします。このフェーズはYoung世代領域に対しても実行可能です。Young世代に対して実行する場合は"[GC pause (young)]"とログ出力し、Young世代とOld世代の両方に対して実行する場合は"[GC Pause (mixed)]"とログ出力します。

G1 Old Generation Collection Step by Step
G1
Old世代回収のステップ・バイ・ステップ

G1コレクタにおいて、これらのフェーズがどのようにOld世代で相互作用するか見ていきましょう。

Initial Marking Phase | Initial Markingフェーズ
生存オブジェクトの初期マーキングは、Young世代ガーベジコレクションに便乗します。" GC pause (young)(inital-mark)"とログ出力します。

Concurrent Marking Phase | Concurrent Markingフェーズ
もし空き領域が見つかったら(図で"X"の部分)、すぐRemarkフェーズで削除します。また生存を決めるAccounting情報をすぐ計算します。

Remark Phase | Remarkフェーズ
空き領域を削除し、回収します。そして、領域の生存を計算します。

Copying/Cleanup Phase | Copying/Cleanupフェーズ
G1は回収が速くできるように生存オブジェクトが少ない領域を選択し、Young GCでそれらの領域を回収します。Young世代とOld世代を同時に回収するので、"[GC pause (mixed)]"とログ出力します。

After Copying/Cleanup Phase | Copying/Cleanupフェーズ後
選択した領域の回収およびコンパクションが完了します。下図の藍色と深緑色で示している部分です。

Summary of Old Generation GC | Old世代GCの概要

Old世代に対するG1ガーベジコレクションに関するキーポイントを、次に列挙します。
    • Concurrent Marking Phase | Concurrent Markingフェーズ
      • アプリケーション実行中に、並列して生存情報を計算します
      • 生存情報により、エバキュエーションによる停止中にどの領域を回収するのがベストかを確認します
      • CMSSweepフェーズがありません
    • Remark Phase | Remarkフェーズ
      • Snapshot-at-the-Beginning (SATB)アルゴリズムを使用し、CMSよりも高速に動作します
      • 空き領域を完全に回収します
    • Copying/Cleanup Phase | Copying/Cleanupフェーズ
      • Young世代とOld世代を同時に回収します
      • オブジェクトの生存率に基づいてOld世代領域を選択します




Command Line Options and Best Practices
コマンドライン・オプションとベストプラクティス

Command Line Options and Best Practices
コマンドライン・オプションとベストプラクティス

このセクションでは、G1の様々なコマンドライン・オプションを見ていきましょう。

Basic Command Line | 基本的なオプション

G1コレクタを有効化:-XX:+UseG1GC
次は、"JDK demos and samples"に含まれているJava2Demoを起動するコマンドラインのサンプルです
java -Xmx50m -Xms50m -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -jar c:\javademos\demo\jfc\Java2D\Java2demo.jar

Key Command Line Switches | 主要なオプション

-XX:+UseG1GC – G1ガーベジコレクタの使用をJVMに指示する
-XX:MaxGCPauseMillis=200 最大のGC停止時間目標を設定します。ソフトな目標であり、JVMは目標達成に努めますが、ベストエフォートなので必ずしも達成できるとは限りません。デフォルト値は200ミリ秒です。
-XX:InitiatingHeapOccupancyPercent=45 – G1がコンカレントGCのサイクルを起動する契機となる(全体の)ヒープの占有率です。1つの世代ではなく全体ヒープの占有率です。0の場合、恒常的にGCを繰り返すことを意味します。デフォルトは45(占有率45%)です。

Best Practices | ベストプラクティス

以下にG1のベストプラクティスをいくつか示します。
Do not Set Young Generation Size | Young世代のサイズを設定しないこと
はっきり言って、-XmnオプションでYoung世代のサイズを設定することは、G1コレクタのデフォルト動作に干渉します。
    • G1はもはや停止時間目標を顧慮しなくなります。本質的には、Young世代のサイズの設定は、停止時間目標を無効にします。
    • G1はもはやYoung世代領域を必要に応じて拡張・請負をしなくなります。サイズが固定になり、サイズの変更もありません。
Response Time Metrics | 時間メトリクスの顧慮
-XX:MaxGCPauseMillis=<N>オプションを設定して測定基準として平均応答時間(ART)を使う際、設定値の90%以上は目標時間を超えてしまうことを考慮してください。ユーザリクエストの90%は、目標以上の応答時間が得られない可能性があるためです。停止時間は目標であって、常に達成できるとは限らないことを念頭に置いてください。
What is an Evacuation Failure? | エバキュエーションの失敗とは?
JVM実行時に、Suvivor領域か昇進オブジェクトに対するGC実行中にヒープ領域が不足すると、昇進に失敗します。ヒープはすでに最大なので拡張できません。-XX:+PrintGCDetailsオプションを指定すればTo領域が満杯になったことを示すGCログを出力します。ログ出力はコストが高いので注意してください。
    • GCは空き領域を作るために継続します。
    • コピーに成功しなかったオブジェクトは、Old世代へ適宜にコピーしなければなりません。
    • CSetにある領域のRSetsの更新を再実行しなければなりません。
    • すべてのステップはコストが高いです。
How to avoid Evacuation Failure | エバキュエーションの失敗を回避するには?
エバキュエーションの失敗を回避するには、次のオプションを考慮してください。
    • ヒープサイズの拡大
      • -XX:G1ReservePercent=nオプションで拡大します。デフォルトは10です
      • G1To領域が要求される場面で、予備メモリ領域(予約済みメモリ領域)の空き領域の維持を試みることによりfalse ceiling(吊天井)を生成します。
    • Markingサイクルを早めに開始してください
    • -XX:ConcGCThreads=n オプションを使って、Markingを実行するスレッドの個数を増やしてください。

Complete List of G1 GC Switches | G1 GCの完全なオプション一覧

下表はG1 GCオプションの完全な一覧です。前述したベストプラクティスを考慮の上でオプションを使ってください。
Option and Default Value
Description
-XX:+UseG1GC ガーベジファースト(G1)コレクタを使用します。
-XX:MaxGCPauseMillis=n GCによる最大停止時間の目標を設定します。ソフトな目標であり、JVMは指定された数値を達成するように努めますが、ベストエフォートです。
-XX:InitiatingHeapOccupancyPercent=n
コンカレントCGのサイクルを起動する契機となる(全体)ヒープの占有率です。ヒープ全体の占有率であり、1つの世代ではありません。0の場合、恒常的にGCサイクルを継続します。デフォルトは45(占有率45%)です。
-XX:NewRatio=n New世代/Old世代のサイズの割合です。デフォルト2です。
-XX:SurvivorRatio=n Eden領域/Survivor領域のサイズの割合です。デフォルト値は8です。
-XX:MaxTenuringThreshold=n Old世代へ昇進するしきい値です。デフォルト値は15です。
-XX:ParallelGCThreads=n GCの各Parallelフェーズにて、GCを実行するスレッドの個数を設定します。デフォルト値は、JVMが動作するプラットフォームによって異なります。(訳注:Parallelフェーズは、アプリケーションスレッドを止めてGCスレッドだけを並行実行する)
-XX:ConcGCThreads=n
コンカレントGCのスレッド数を設定します。デフォルト値はJVMが動作するプラットフォームによって異なります。(訳注:Concurrentフェーズは、アプリケーションスレッドと並行してGCを実行する)
-XX:G1ReservePercent=n
false ceiling(吊天井)として予約するヒープ総量を設定します。これはOld世代への昇進に失敗する可能性を減らすためです。デフォルト値は10です。
-XX:G1HeapRegionSize=n
G1ではJavaヒープは非公開サイズの領域に分割します。分割した個々の領域のサイズを設定します。デフォルト値はヒープのサイズに基づいて自動的に決定します(エルゴノミックス)。最小値は1MBで最大値は32MBです。




Logging GC with G1 | G1のログ出力

Logging GC with G1 | G1のログ出力

最後のこのトピックでは、ログ情報からG1コレクタの性能を分析する方法を説明します。このセクションでは、ログ情報からデータや情報を収集するためのオプションの概観を示します。

Setting the Log Detail | 詳細ログの設定

ログの詳細レベルを3段階で設定できます。
 (1) -verbosegc (-XX:+PrintGCと同様) ログの詳細レベルを"fine"に設定します。
Sample Output | 出力例
[GC pause (G1 Humongous Allocation) (young) (initial-mark) 24M- >21M(64M), 0.2349730 secs]
[GC pause (G1 Evacuation Pause) (mixed) 66M->21M(236M), 0.1625268 secs]    
(2) -XX:+PrintGCDetails ログの詳細レベルを"finer"に設定します。次の情報を出力します。
    • 各フェーズの所要時間の平均値、最小値および最大値
    • ルート・スキャン、RSet更新(処理したバッファ情報で)RSetのスキャン、オブジェクトのコピーおよび終了(試行回数)
    • CSetの選択、参照処理、参照のエンキューおよびCSetの解放などの所要時間
    • Eden領域、Survivor領域およびヒープ全体の使用量
Sample Output | 出力例
[Ext Root Scanning (ms): Avg: 1.7 Min: 0.0 Max: 3.7 Diff: 3.7]
[Eden: 818M(818M)->0B(714M) Survivors: 0B->104M Heap: 836M(4096M)->409M(4096M)]
(3) -XX:+UnlockExperimentalVMOptions -XX:G1LogLevel=finestログの詳細レベルを"finest"に設定します。"finer"の内容に加えて、個々のワーカースレッドの情報も出力します。
[Ext Root Scanning (ms): 2.1 2.4 2.0 0.0
           Avg: 1.6 Min: 0.0 Max: 2.4 Diff: 2.3]
       [Update RS (ms):  0.4  0.2  0.4  0.0
           Avg: 0.2 Min: 0.0 Max: 0.4 Diff: 0.4]
           [Processed Buffers : 5 1 10 0
           Sum: 16, Avg: 4, Min: 0, Max: 10, Diff: 10]

Determining Time | 時間の特定

次の2つのオプションは、GCに要した時間を出力します。
(1) -XX:+PrintGCTimeStamps - JVM起動後の経過時間を出力します。
Sample Output | 出力例
    1.729: [GC pause (young) 46M->35M(1332M), 0.0310029 secs]
(2) -XX:+PrintGCDateStamps - Adds a time of day prefix to each entry.
(2) 
-XX:+PrintGCDateStamps - ログの先頭に日付と時間を追加します。
    2012-05-02T11:16:32.057+0200: [GC pause (young) 46M->35M(1332M), 0.0317225 secs]

Understanding G1 Log | G1ログを理解する

このセクションでは、ログを理解するために、実際のGCログ出力を使っていくつかの用語を定義します。以降、ログ出力の例を、用語と値の説明を交えて紹介します。
注意: 詳細は、「Poonam Bajaj's Blog post on G1 GC logs.」を参照してください。

G1 Logging Terms Index | G1ログ用語の一覧

l  Clear CT
l  CSet
l  External Root Scanning
l  Free CSet
l  GC Worker End
l  GC Worker Other
l  Object Copy
l  Other
l  Parallel Time
l  Ref Eng
l  Ref Proc
l  Scanning Remembered Sets
l  Termination Time
l  Update Remembered Set
l  Worker Start
Parallel Time
414.557: [GC pause (young), 0.03039600 secs] [Parallel Time: 22.9 ms]
[GC Worker Start (ms): 7096.0 7096.0 7096.1 7096.1 706.1 7096.1 7096.1 7096.1 7096.2 7096.2 7096.2 7096.2
       Avg: 7096.1, Min: 7096.0, Max: 7096.2, Diff: 0.2]
Parallel Time – Parallelの全体な経過時間(停止時間内に処理した時間)
Worker Start ワーカースレッドが起動した時間のタイムスタンプ
Note: 
スレッドIDThe logs are ordered on thread id and are consistent on each entry
External Root Scanning
[Ext Root Scanning (ms): 3.1 3.4 3.4 3.0 4.2 2.0 3.6 3.2 3.4 7.7 3.7 4.4
     Avg: 3.8, Min: 2.0, Max: 7.7, Diff: 5.7]
External root scanning – External Rootのスキャンに要した時間 (例:ヒープ領域へのポイントを示すSystem dictionaryなど)
Update Remembered Set
[Update RS (ms): 0.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 Avg: 0.0, Min: 0.0, Max: 0.1, Diff: 0.1]
   [Processed Buffers : 26 0 0 0 0 0 0 0 0 0 0 0
    Sum: 26, Avg: 2, Min: 0, Max: 26, Diff: 26]
Update Remembered Set - バッファはConcurrent refinementスレッドによる処理が未実施であれば、停止を開始する前に更新されなければなりません。処理時間はカードの密度に依存し、カードが多ければ多いほど処理時間が長くなります。
Scanning Remembered Sets
[Scan RS (ms): 0.4 0.2 0.1 0.3 0.0 0.0 0.1 0.2 0.0 0.1 0.0 0.0 Avg: 0.1, Min: 0.0, Max: 0.4, Diff: 0.3]F
Scanning Remembered Sets - Collection Setへのポイントを探します。
Object Copy
[Object Copy (ms): 16.7 16.7 16.7 16.9 16.0 18.1 16.5 16.8 16.7 12.3 16.4 15.7 Avg: 16.3, Min: 12.3, Max:  18.1, Diff: 5.8]
Object copy 個々のスレッドがオブジェクトのコピーとエバキュエーションに消費した時間
Termination Time
[Termination (ms): 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] [Termination Attempts : 1 1 1 1 1 1 1 1 1 1 1 1 Sum: 12, Avg: 1, Min: 1, Max: 1, Diff: 0]
Termination time - ワーカースレッドはその特定オブジェクトのコピーとスキャンが終了したとき、終了処理に入ります。スチールする処理を探し、その処理が完了したら、再び終了処理に入ります。終了試行回数は、スチール処理の試行回数の総数です。
GC Worker End
[GC Worker End (ms): 7116.4 7116.3 7116.4 7116.3 7116.4 7116.3 7116.4 7116.4 7116.4 7116.4 7116.3 7116.3
    Avg: 7116.4, Min: 7116.3, Max: 7116.4, Diff:   0.1]
[GC Worker (ms): 20.4 20.3 20.3 20.2 20.3 20.2 20.2 20.2 20.3 20.2 20.1 20.1
     Avg: 20.2, Min: 20.1, Max: 20.4, Diff: 0.3]
GC worker end time 個々のGCワーカーの停止時間のタイムスタンプ
GC worker time 個々のGCワーカースレッドの消費時間
GC Worker Other
[GC Worker Other (ms): 2.6 2.6 2.7 2.7 2.7 2.7 2.7 2.8 2.8 2.8 2.8 2.8
    Avg: 2.7, Min: 2.6, Max: 2.8, Diff: 0.2]
GC worker other 個々のワーカースレッドが先述のどのフェーズにも属さなかった時間。この値は小さくあるべきです。極端に高い数値が出た前例では、JVMの他の部分でボトルネックに起因していました。たとえば、TieredによるCode Cache占有の増加です。(訳注:Tired CompilationとはJITで採用しているコンパイル技術→"Java HotSpot™ Virtual Machine Performance EnhancementsTiered Compilation"を参照)
Clear CT
[Clear CT: 0.6 ms]
Rsetのカードテーブル(メタデータをスキャンするもの)のクリアに要した時間。
Other
[Other: 6.8 ms]
GC停止時にシーケンシャルで動作するさまざまなフェーズでの所要時間。
CSet
[Choose CSet: 0.1 ms]
領域セットでの回収を終了させるのに要した時間。通常、短い時間です。Old世代の場合、少し長くなります。
Ref Proc
[Ref Proc: 4.4 ms]
GCの前フェーズから参照しているSoftリファレンス、Weakリファレンスの処理に要した時間。
Ref Enq
[Ref Enq: 0.1 ms]
Softリファレンス、Weakリファレンスなどを保留リストに入れるのに要した時間。
Free CSet
[Free CSet: 2.0 ms]
回収済みの領域セットおよびRSetsを解放するのに要した時間。




Summary | サマリ

このOBEでは、JVM G1ガーベジコレクタの概要に触れました。最初にヒープとガーベジレクタがJVMの主要なものであることを学びました。次に、CMSコレクタとG1コレクタがどのように動作するかを復習しました。その次にG1コマンドラインオプションとベストプラクティスについて学びました。最後に、GCログが出力するデータについて学びました。
このチュートリアルでは、次を学びました:
    • The components of the Java JVM
    • An overview of the G1 Collector
    • A review of the CMS collector
    • A review of the G1 collector
    • Command line switches and best practices
    • Logging with G1

Resources | 関連文献

For more information and related information please see these site and links.

Credits | 謝辞

    • Curriculum Developer: Michael J Williams
    • QA: Krishnanjani Chitta