runtime_control.xml

<?xml version="1.0" encoding="UTF-8"?>
<sect1 id="runtime-control">
  <title>コンパイル済みプログラムを実行する</title>

  <indexterm><primary>runtime control of Haskell programs</primary></indexterm>
  <indexterm><primary>running, compiled program</primary></indexterm>
  <indexterm><primary>RTS options</primary></indexterm>

  <para>実行可能なプログラムを作るとき、GHCシステムはコードをコンパイルし、それを自明でないランタイムシステム(RTS)とリンクする。これは、記憶領域の管理、スレッドのスケジュール、プロファイルの取得などを行う。</para>

  <para>RTSは、振る舞いを制御するための沢山のオプションを持っている。例えば、コンテキストスイッチの間隔やヒープのデフォルトの大きさを変えたり、ヒーププロファイルを有効にしたりである。こうしたオプションは色々な方法でランタイムシステムに渡すことができる。次の節(<xref linkend="setting-rts-options"/>)ではこれらの方法を記述し、それ以降の節ではRTSオプション自体について記述する。</para>

  <sect2 id="setting-rts-options">
    <title>RTSオプションを設定する</title>
    <indexterm><primary>RTS options, setting</primary></indexterm>

    <para>RTSオプションを設定するのには四つの方法がある。

      <itemizedlist>
        <listitem>
          <para>プログラムを実行する際、コマンド行の<literal>+RTS ... -RTS</literal>の間で。(<xref linkend="rts-opts-cmdline" />)</para>
        </listitem>
        <listitem>
          <para>コンパイル時に、<option>--with-rtsopts</option>を使って。(<xref linkend="rts-opts-compile-time" />)</para>
        </listitem>
        <listitem>
          <para>環境変数<envar>GHCRTS</envar>で。(<xref linkend="rts-options-environment" />)</para>
        </listitem>
        <listitem>
          <para>ランタイムシステムの&ldquo;フック&rdquo;を上書きすることによって。(<xref linkend="rts-hooks" />)</para>
        </listitem>
      </itemizedlist>
    </para>

    <sect3 id="rts-opts-cmdline">
      <title>コマンド行でRTSオプションを設定する</title>

      <para>リンク時に<literal>-rtsopts</literal>フラグを適切に設定していたなら、プログラムを実行するときにRTSオプションをコマンド行で与えることができる。</para>

    <para>Haskellプログラムの実行が開始されるとき、RTSはコマンド行引数から<option>+RTS</option><indexterm><primary><option>+RTS</option></primary></indexterm>と<option>-RTS</option><indexterm><primary><option>-RTS</option></primary></indexterm>で囲まれた部分を自分用に抽出する。以下のような例を考える。</para>

    <screen>
$ ghc prog.hs -rtsopts
[1 of 1] Compiling Main             ( prog.hs, prog.o )
Linking prog ...
$ ./prog -f +RTS -H32m -S -RTS -h foo bar
    </screen>

      <para>RTSは<option>-H32m</option> <option>-S</option>を横取りし、プログラムが<function>System.Environment.getArgs</function>を読んだときには残りの引数である<literal>-f -h foo bar</literal>が渡される。</para>

      <para>次の例のように、ランタイムシステムへのオプションがコマンド行の最後まで続くときは、<option>-RTS</option>オプションは必要ない。</para>

    <screen>
% hls -ltr /usr/etc +RTS -A5m
    </screen>

      <para>残りのオプションを問答無用で(RTSでなく)プログラムに渡したいなら、<option>--RTS</option><indexterm><primary><option>--RTS</option></primary></indexterm>を使うことができる。</para>

      <para>いつもと同様、<replaceable>size</replaceable>を取るRTSオプションについては、以下が適用される。<replaceable>size</replaceable>の最後の文字がKまたはkなら、数値は1000倍される。Mまたはmなら、1,000,000倍される。GまたはG<!-- 訳注: たぶん誤り -->なら、1,000,000,000倍される。(カウンタのオーバーフローは<emphasis>あなたの</emphasis>責任である)</para>

      <para><literal>+RTS -?</literal><indexterm><primary><option>-?</option></primary><secondary>RTS option</secondary></indexterm>オプションを与えれば、実際に利用可能なRTSオプションを表示することができる。(これはどのようにコンパイルされたかによって異なる)</para>

      <para>注意: GHCはそれ自身GHCでコンパイルされているので、通常の<literal>+RTS ... -RTS</literal>の組み合わせを使ってRTSオプションを変更することができる。例えば、コンパイル時の最大ヒープサイズを128Mに増やすには、<literal>+RTS -M128m -RTS</literal>をコマンド行に加えれば良い。</para>
    </sect3>

    <sect3 id="rts-opts-compile-time">
      <title>コンパイル時にRTSオプションを設定する</title>

      <para><literal>-with-rtsopts</literal>フラグ(<xref linkend="options-linker"/>)を使うことで、プログラムのRTSオプションをコンパイル時に設定することができる。これのよくある使い方は、デフォルトよりも大きなヒープ/スタックサイズを初期値としてプログラムに与えることである。例えば<literal>-H128m -K64m</literal>を設定するには、<literal>-with-rtsopts="-H128m -K64m"</literal>付きでリンクすればよい。</para>
    </sect3>

    <sect3 id="rts-options-environment">
      <title><envar>RTSOPTS</envar>でRTSオプションを設定する</title>

      <indexterm><primary>RTS options</primary><secondary>from the environment</secondary></indexterm>
      <indexterm><primary>environment variable</primary><secondary>for
      setting RTS options</secondary></indexterm>

      <para>リンク時に<literal>-rtsopts</literal>フラグが<literal>none</literal>以外に設定されているなら、RTSオプションは環境変数<envar>GHCRTS</envar><indexterm><primary><envar>GHCRTS</envar></primary></indexterm>からも採られる。例えば、GHCでコンパイルされた全てのプログラムについて最大ヒープサイズを2Gにするなら、次のようにすれば良い。(<literal>sh</literal>系のシェルを使っていると仮定する)</para>

  <screen>
     GHCRTS='-M2G'
     export GHCRTS
  </screen>

      <para><envar>GHCRTS</envar>環境変数から採られたRTSオプションはコマンド行からオプションを与えることで上書きできる。</para>

        <para>ヒント: あなたの環境に<literal>GHCRTS=-M2G</literal>のようなものを設定しておくと、Haskellプログラムがあなたのマシンの実メモリを超えて成長することを簡単に防ぐことができる。誤ってこういうことをするのは良くあることであり、OSがそのプロセスを殺すことを決めるまでマシンがゆっくりと地を這うことになる。(そして、ちゃんと正しいのを殺してくれるといいね)</para>
      </sect3>

    <sect3 id="rts-hooks">
      <title>RTSの振る舞いを変更するためのフック</title>

      <indexterm><primary>hooks</primary><secondary>RTS</secondary></indexterm>
      <indexterm><primary>RTS hooks</primary></indexterm>
      <indexterm><primary>RTS behaviour, changing</primary></indexterm>

      <para>GHCでは、ランタイムシステムから呼ばれるフックをコンパイル時に含めることで、任意のプログラムのRTS設定の一部をある程度制御することができる。RTSにはこれらのフックのスタブ定義が含まれているが、自分の版を書いてGHCのコマンド行からリンクすることで、デフォルトと異なるものを使える。</para>

      <para>DLLリンクの気まぐれのせいで、これらのフックはWindowsでプログラムが動的リンクでビルドされるときには働かない。</para>

      <para>ランタイムシステムがどうしようもなくなったとき(例えばスタックオーバーフロー)に表示される文言を変更することができる。このためのフックは以下である。</para>

      <variablelist>

        <varlistentry>
          <term>
            <function>void OutOfHeapHook (unsigned long, unsigned long)</function>
            <indexterm><primary><function>OutOfHeapHook</function></primary></indexterm>
          </term>
          <listitem>
            <para>ヒープオーバーフローのメッセージ。</para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>
            <function>void StackOverflowHook (long int)</function>
            <indexterm><primary><function>StackOverflowHook</function></primary></indexterm>
          </term>
          <listitem>
            <para>スタックオーバーフローのメッセージ。</para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>
            <function>void MallocFailHook (long int)</function>
            <indexterm><primary><function>MallocFailHook</function></primary></indexterm>
          </term>
          <listitem>
            <para><function>malloc</function>が失敗したときに表示されるメッセージ。</para>
          </listitem>
        </varlistentry>
      </variablelist>
    </sect3>
  </sect2>

  <sect2 id="rts-options-misc">
    <title>いろいろなRTSオプション</title>

    <variablelist>
     <varlistentry>
       <term><option>-V<replaceable>secs</replaceable></option>
       <indexterm><primary><option>-V</option></primary><secondary>RTS
       option</secondary></indexterm></term>
       <listitem>
         <para>RTSの時計が進行する時間間隔を設定する。ランタイムは単一のタイマシグナルを使って時計を進行させる。コンテクストスイッチのタイマ(<xref linkend="using-concurrent"/>)およびヒーププロファイル時のタイマ(<xref linkend="rts-options-heap-prof"/>)を制御するのにはこれが使われる。また、時間プロファイルをとるときは、プロファイルの標本を記録するのにRTSのタイマシグナルを直接使うことになる。</para>

         <para>通常、<option>-V</option>オプションを直接指定する必要はない。<option>-C</option>や<option>-i</option>オプションで短い間隔が指定されたときは、自動的にRTSタイマの分解能も調整されるからである。しかし、時間プロファイルの分解能を増したいときには、<option>-V</option>を設定することが必要になる。</para>

         <para>値0を使うと、RTSの時計は完全に無効にされ、それに依存したタイマも無効になる。コンテクストスイッチのタイマとプロファイルタイマである。それでもコンテクストスイッチは発生するが、決定論的に、かつ通常よりずっと高い頻度で発生するようになる。インターバルタイマを無効にすると、実行時の非決定性の源が一つ除かれるわけであり、デバッグに便利である。</para>
       </listitem>
     </varlistentry>

     <varlistentry>
       <term><option>--install-signal-handlers=<replaceable>yes|no</replaceable></option>
       <indexterm><primary><option>--install-signal-handlers</option></primary><secondary>RTS
       option</secondary></indexterm></term>
       <listitem>
         <para>yes(デフォルト)なら、RTSはctrl-Cの類を捕捉するためのシグナルハンドラを設置する。このオプションは、HaskellコードをDLLとして使っていて、自分でシグナルハンドラを設定したいときに特に有用である。</para>

         <para><option>--install-signal-handlers=no</option>の場合でも、RTSの時間間隔タイマは変わらずに有効だということに注意。タイマシグナルはSIGVTALRMかSIGALRMで、RTSの設定とOSの能力によって異なる。このタイマシグナルを無効化するにはRTSオプション<literal>-V0</literal>を使う。(上記参照)</para>
       </listitem>
     </varlistentry>

     <varlistentry>
       <term><option>-xm<replaceable>address</replaceable></option>
       <indexterm><primary><option>-xm</option></primary><secondary>RTS
       option</secondary></indexterm></term>
       <listitem>
         <para>
           警告: このオプションはメモリ確保の問題を回避するためだけのものである。GHCiが「<literal>failed to mmap() memory below 2Gb</literal>」のようなメッセージを表示して失敗するのでない限り、使ってはいけない。あなたの機械でGHCiを動かすのにこのオプションを使う必要があるなら、バグとして報告してほしい。
         </para>

         <para>
           64ビットの機械では、RTSはアドレス空間の下方2Gbの中にメモリを確保する必要がある。種々のOSにおけるこれの対応は不完全であり、ときどき失敗する。このオプションは、アドレス空間の下方2Gbの中でどこのメモリを確保できるかについてRTSにヒントを与えるために存在する。例えば、<literal>+RTS -xm20000000 -RTS</literal>とすれば、RTSが0.5Gb markから確保を開始すべきというヒントになる。デフォルトは、可能なら下方2Gb中にメモリを確保するためのOS組み込みの手段(例えばLinuxなら<literal>MAP_32BIT</literal>付きの<literal>mmap</literal>)を使い、それがなければ<literal>-xm40000000</literal>である。
         </para>
       </listitem>
     </varlistentry>
    </variablelist>
  </sect2>

  <sect2 id="rts-options-gc">
    <title>ガベッジコレクタを制御するためのRTSオプション</title>

    <indexterm><primary>garbage collector</primary><secondary>options</secondary></indexterm>
    <indexterm><primary>RTS options</primary><secondary>garbage collection</secondary></indexterm>

    <para>ガベッジコレクタの挙動を精密に制御するために、いくつかのオプションが存在する。通常時には、これらはどれも使う必要がない(といいのだが)。それでも、最高の性能を得たいときのために、いくつかの箇所を調整することができるようになっている。</para>

    <variablelist>

      <varlistentry>
	<term>
          <option>-A</option><replaceable>size</replaceable>
          <indexterm><primary><option>-A</option></primary><secondary>RTS option</secondary></indexterm>
          <indexterm><primary>allocation area, size</primary></indexterm>
        </term>
	<listitem>
          <para>&lsqb;デフォルト: 512k&rsqb;ガベッジコレクタが使う確保領域の大きさを設定する。確保領域(実際には世代0・段階0)は固定されており、大きさが変わることはない。(<option>-H</option>を使った場合はこの限りでない。下記参照)</para>

          <para>確保領域の大きさを増すことは、性能の向上につながるかもしれないし、そうでないかもしれない。(より大きい確保領域を使うと、キャッシュの振舞は悪化するが、ガベッジコレクションの回数は減り、昇格(promotion)も少なくなる)</para>

          <para>世代数が一しかないとき(<option>-G1</option>)は、<option>-A</option>オプションは最小の確保領域を指定する。これは、実際の確保領域の大きさがヒープ中のデータの量によって変動するからである。(下記の<option>-F</option>を見よ)</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <option>-c</option>
          <indexterm><primary><option>-c</option></primary><secondary>RTS option</secondary></indexterm>
          <indexterm><primary>garbage collection</primary><secondary>compacting</secondary></indexterm>
          <indexterm><primary>compacting garbage collection</primary></indexterm>
        </term>
	<listitem>
          <para>もっとも古い世代を回収するときにコンパクト化アルゴリズムを使う。デフォルトでは最古世代はコピーアルゴリズムで回収されるが、このオプションが使われると、その場でコンパクト化されるようになる。コンパクト化アルゴリズムはコピーアルゴリズムより遅いが、相当量のメモリを節約できることがある。</para>

          <para>ヒープの大きさ(これは<option>-H</option>オプションで変えられる)が一定のとき、コンパクト化を使うことでかえってGCのコストが削減できるということがあり得る(GCの回数が減らせるかもしれないので)。ヒープの大きさに対する生存データの比が高いとき(>30%、例えば)には特にその傾向が強い。</para>

          <para>注意: 現在、コンパクト化は、<option>-G1</option>で単一世代が指定されているときには動作しない。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-c</option><replaceable>n</replaceable></term>

	<listitem>
          <para>&lsqb;デフォルト: 30&rsqb; 生存データがヒープの大きさの上限(<option>-M</option>オプションを見よ)の<replaceable>n</replaceable>%を超えたときに自動的にコンパクト化を有効にする。デフォルトではヒープの大きさに上限はないので、<option>-M</option><replaceable>size</replaceable>でヒープの大きさの上限が指定されない限り、このオプションには効果がない。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <option>-F</option><replaceable>factor</replaceable>
          <indexterm><primary><option>-F</option></primary><secondary>RTS option</secondary></indexterm>
          <indexterm><primary>heap size, factor</primary></indexterm>
        </term>
	<listitem>

          <para>&lsqb;デフォルト: 2&rsqb; このオプションは、古い世代のために予約されるメモリの量(two-space GCのときは確保領域の大きさ)を、生存データの量との比で指定する。例えば、最後に最も古い世代が回収されたときに生存データが2Mあったとすると、デフォルトでは、4Mにまでなるのを待ってから再び回収する。</para>

          <para>これについてはデフォルトがうまく働いているようである。潤沢なメモリがあるなら、通常、<option>-F</option><replaceable>factor</replaceable>を増やすよりも<option>-H</option><replaceable>size</replaceable>を使った方が良い。</para>

          <para><option>-F</option>の値は、ヒープの最大の大きさ(<option>-M</option><replaceable>size</replaceable>で設定する)に近づいたときには、ガベッジコレクタによって自動的に減らされる。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <option>-G</option><replaceable>generations</replaceable>
          <indexterm><primary><option>-G</option></primary><secondary>RTS option</secondary></indexterm>
          <indexterm><primary>generations, number of</primary></indexterm>
        </term>
	<listitem>
          <para>&lsqb;デフォルト: 2&rsqb; ガベッジコレクタが使う世代の数を設定する。デフォルトの2は良い選択のようだが、ガベッジコレクタは任意の数の世代をサポートしている。プログラムが<emphasis>長い</emphasis>時間に渡って実行されるのでない限り、4程度より大きな値はおそらく良くない。最古の世代が一回も回収されないということになるからである。</para>

          <para><option>+RTS -G1</option>で一世代を指定すると、当然、単純な2-spaceコレクタになる。2-spaceコレクタでは、<option>-A</option>オプション(上記参照)が指定するのは確保領域の<emphasis>最小の</emphasis>大きさである。これは、ヒープ中の生存データの量が増えるに従って確保領域も拡大されるからである。複数世代のコレクタでは確保領域の大きさは固定である。(<option>-H</option>オプションを使う場合はこの限りでない。下を見よ)</para>
	</listitem>
      </varlistentry>

      <varlistentry>
        <term>
          <option>-qg<optional><replaceable>gen</replaceable></optional></option>
          <indexterm><primary><option>-qg</option><secondary>RTS
          option</secondary></primary></indexterm>
        </term>
        <listitem>
          <para>&lsqb;GHC 6.12.1から&rsqb; &lsqb;デフォルト: 0&rsqb;
            世代<replaceable>gen</replaceable>とそれより上の世代において、並列GCを使う。<replaceable>gen</replaceable>を省略すると、並列GCは完全に無効になり、逐次GCに戻る。</para>

          <para>デフォルトの並列GC設定は、通常、並列プログラム(<literal>par</literal>やStrategyや複数のスレッドを使うもの)に適している。しかし、単一スレッドの逐次的なプログラムに関しても、並列GCを有効にする恩恵があることがある。特に、プログラムが大量のヒープデータを持ち、実行時間のかなりの部分をGCが占めるような場合である。逐次的なプログラムにおいて並列GCを使うには、適切な<literal>-N</literal>オプションを使って並列ランタイムを有効にすればよい。加えて、<literal>-qg1</literal>を使って並列GCを古い世代のみに制限すると良いかもしれない。</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term>
          <option>-qb<optional><replaceable>gen</replaceable></optional></option>
          <indexterm><primary><option>-qb</option><secondary>RTS
          option</secondary></primary></indexterm>
        </term>
        <listitem>
          <para>
            &lsqb;GHC 6.12.1から&rsqb; &lsqb;デフォルト: 1&rsqb;
            並列GCにおいて、世代<replaceable>gen</replaceable>とそれより上の世代で負荷分散を使う。<replaceable>gen</replaceable>を省略すると、負荷分散を完全に無効にする。</para>

          <para>
            負荷分散とは、GCの作業を空いているコア間で分配することである。これは、ヒープが大きく、GCの作業を並列化する必要がある場合には良いことである。しかし、並列プログラムの若い世代における短い回収では、これは最悪である。なぜなら、データを、それが使われているCPUのキャッシュから、別のCPUのキャッシュへと動かすことで、局所性を損うからである。実際、並列プログラムでは、<literal>-qb</literal>で負荷分散を完全に無効にした方が良いこともある。
          </para>
        </listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <option>-H</option><optional><replaceable>size</replaceable></optional>
          <indexterm><primary><option>-H</option></primary><secondary>RTS option</secondary></indexterm>
          <indexterm><primary>heap size, suggested</primary></indexterm>
        </term>
	<listitem>
          <para>&lsqb;デフォルト: 0&rsqb; このオプションはガベッジコレクタに「推奨されるヒープの大きさ」を提示する。<option>-H<replaceable>size</replaceable></option>は可変の<option>-A</option>オプションだと思うと良い。これは次のように述べる。私は少なくとも<replaceable>size</replaceable>バイトを使いたいので、残ったものは全部<option>-A</option>を増やすのに使え。</para>
          
          <para>このオプションはヒープの大きさに<emphasis>制限</emphasis>を加えるものではない。ヒープは通常同様に与えられた大きさを超えて成長し得る。</para>

          <para><replaceable>size</replaceable>を省略すると、ガベッジコレクタは前回のGC時におけるヒープの大きさを<replaceable>size</replaceable>として取る。これは、プログラムの全体的なメモリ要求を増やさずに、より大きな<option>-A</option>の値を許す効果がある。長生きするデータを大量に作成するプログラムなど、デフォルトの小さな<option>-A</option>の値が適していないときに使える。</para>
        </listitem>
      </varlistentry>

      <varlistentry>
	<term>
	  <option>-I</option><replaceable>seconds</replaceable>
	  <indexterm><primary><option>-I</option></primary>
	    <secondary>RTS option</secondary>
	  </indexterm>
	  <indexterm><primary>idle GC</primary>
	  </indexterm>
	  </term>
	<listitem>
          <para>(デフォルト: 0.3) スレッド化された、またはSMP版のRTS(<option>-threaded</option>を見よ。<xref linkend="options-linker"/>)においては、ランタイムが一定期間待機状態である(Haskellの計算が実行されていない)とき、自動的に大GCが実行される。GCが実行されるまでの時間を指定するのが<option>-I</option><replaceable>seconds</replaceable>オプションである。<option>-I0</option>を指定すると待機状態でのGCが無効になる。</para>

          <para>対話的アプリケーションでは、待機時GCが多くの場合有効である。これは、Haskellの計算が起こっていない待機状態の間に、終了子を走らせたりデッドロックしたスレッドを感知したりできるからである。さらに、アプリケーションが忙しいときにGCが起こる可能性が減るので、反応性が向上するかもしれない。しかし、ヒープ中の生存データの割合があまりに高いと、待機時GCが重大な遅れを引き起こすことがある。また、時間間隔が短すぎると、対話的な反応性に悪影響を及ぼすことになるかもしれない。</para>

          <para>これは実験的な機能である。問題が起きたり、改善案があるなら、知らせてほしい。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
         <option>-ki</option><replaceable>size</replaceable>
         <indexterm><primary><option>-k</option></primary><secondary>RTS option</secondary></indexterm>
         <indexterm><primary>stack, initial size</primary></indexterm>
        </term>
	<listitem>
          <para>&lsqb;デフォルト: 1k&rsqb; スレッドの初期スタックサイズを設定する。(注意: このフラグは単に<option>-k</option>であったが、GHC 7.2.1で<option>-ki</option>に改名された。古い名前も後方互換性のためにまだ受け付けられるが、将来の版では削除されるかもしれない)</para>

          <para>スレッドのスタック(主スレッドのスタックも含めて)はヒープ上にとられる。スタックが成長するにつれ、必要に応じて新しいチャンクが追加される。スタックが再び収縮する場合、これらの追加されたスタックチャンクはGCによって回収される。デフォルトの初期スタックサイズは意図的に小さくしてある。これは、スレッド生成の時間的空間的オーバーヘッドを最小にとどめることで、ごく小さい仕事のためにスレッドを生成することを現実的にするためである。</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term>
          <option>-kc</option><replaceable>size</replaceable>
          <indexterm><primary><option>-kc</option></primary><secondary>RTS
          option</secondary></indexterm>
          <indexterm><primary>stack</primary><secondary>chunk size</secondary></indexterm>
        </term>
        <listitem>
          <para>
            &lsqb;デフォルト: 32k&rsqb; &ldquo;スタックチャンク&rdquo;の大きさを設定する。スレッドの現行スタックがオーバーフローしたとき、<option>-K</option>で設定された上限に達するまでは、新しいスタックチャンクが作成されてスレッドのスタックに加えられる。
          </para>

          <para>チャンクサイズを小さくすることの利点はこうである。ガベッジコレクタは、チャンクが前回のGC以降変更されていないことが分かると、それらを走査しないで済ませることができる。よって、チャンクサイズを減らすと、ガベッジコレクタがより多くのスタックを未変更と知ることができるので、GCのオーバーヘッドを削ることができるかもしれない。一方で、スタックチャンクを小さくしすぎると、チャンク間のオーバーフロー/アンダーフローが増えるので、オーバーヘッドが増える。32kというデフォルト設定は、大部分の場合においてそれなりな妥協点のようである。</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term>
          <option>-kb</option><replaceable>size</replaceable>
          <indexterm><primary><option>-kc</option></primary><secondary>RTS
          option</secondary></indexterm>
          <indexterm><primary>stack</primary><secondary>chunk buffer size</secondary></indexterm>
        </term>
        <listitem>
          <para>
            &lsqb;デフォルト: 1k&rsqb; スタックチャンクバッファの大きさを設定する。スタックチャンクがオーバーフローして新しいチャンクが作成される時、前のスタックのデータの一部が新しいチャンクに移動される。これは、即座にアンダーフローが発生し、境界でオーバーフロー/アンダーフローが繰り返されるのを防ぐためである。ここで動かされるスタックの量が<option>-kb</option>によって設定される。</para>
          <para>空間を無駄にするのを防ぐために、この値は典型的にはスタックチャンクの大きさ(<option>-kc</option>)の10%未満に設定されるべきである。スタックチャンクの連鎖の中で、それぞれのチャンクがこの大きさの未使用の空間を隙間として持つことになるからである。</para>
        </listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <option>-K</option><replaceable>size</replaceable>
          <indexterm><primary><option>-K</option></primary><secondary>RTS option</secondary></indexterm>
          <indexterm><primary>stack, maximum size</primary></indexterm>
        </term>
	<listitem>
          <para>&lsqb;デフォルト: 物理メモリの大きさの80%&rsqb; 個々のスレッドの最大スタックサイズを<replaceable>size</replaceable>に設定する。スレッドがこの制限を超えようとした場合、<literal>StackOverflow</literal>例外が送られる。sizeとして0を指定すると、この検査は完全に無効になる。</para>
          <para>このオプションは主に、プログラムが無限ループに陥ったときに利用可能なメモリを使い果たすことがないようするために存在している。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <option>-m</option><replaceable>n</replaceable>
          <indexterm><primary><option>-m</option></primary><secondary>RTS option</secondary></indexterm>
          <indexterm><primary>heap, minimum free</primary></indexterm>
        </term>
	<listitem>
          <para>ヒープのうち確保可能な(訳注: 未使用な)部分の最小%を指定する。デフォルトは3%である。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <option>-M</option><replaceable>size</replaceable>
          <indexterm><primary><option>-M</option></primary><secondary>RTS option</secondary></indexterm>
          <indexterm><primary>heap size, maximum</primary></indexterm>
        </term>
	<listitem>
          <para>&lsqb;デフォルト: 無制限&rsqb; 最大ヒープサイズを<replaceable>size</replaceable>に設定する。ヒープは通常プログラムのメモリ要求に従って伸長したり収縮したりする。このオプションの唯一の存在理由は、ヒープが際限なく膨張してスワップ空間を使い果たす(結果として、少なくともプログラムが即座にOSに殺されることになる)のを防ぐことである。</para>

          <para>ヒープの最大サイズは他のGCパラメタにも影響する。ヒープ中の生存データが最大ヒープサイズに対して一定の割合を越えると、最古の世代に対して自動的にコンパクト化回収が有効になり、最大ヒープサイズを越えることがないように<option>-F</option>パラメタが減少せしめられる。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
        <term>
          <option>-T</option>
          <indexterm><primary><option>-T</option></primary><secondary>RTS option</secondary></indexterm>
        </term>
        <term>
          <option>-t</option><optional><replaceable>file</replaceable></optional>
          <indexterm><primary><option>-t</option></primary><secondary>RTS option</secondary></indexterm>
        </term>
	<term>
          <option>-s</option><optional><replaceable>file</replaceable></optional>
          <indexterm><primary><option>-s</option></primary><secondary>RTS option</secondary></indexterm>
        </term>
	<term>
          <option>-S</option><optional><replaceable>file</replaceable></optional>
          <indexterm><primary><option>-S</option></primary><secondary>RTS option</secondary></indexterm>
        </term>
	<term>
          <option>--machine-readable</option>
          <indexterm><primary><option>--machine-readable</option></primary><secondary>RTS option</secondary></indexterm>
        </term>
	<listitem>
	  <para>これらのオプションはランタイムシステムの統計情報を生成する。プログラムを実行するのに使った時間、ガベッジコレクタで使った時間、確保されたメモリの量、ヒープの最大サイズ、といったものである。この三種類のオプションは、詳細さの度合いが異なる。<option>-T</option>はデータを収集するものの出力を生成しない。<option>-t</option>はGHCの<option>-Rghc-timing</option>オプションと同じ形式で一行だけの出力を生成する。<option>-s</option>はプログラムの最後にもっと詳細なまとめを生成しする。<option>-S</option>はさらにガベッジコレクション一回一回について情報を生成する。</para>

          <para>出力内容は<replaceable>file</replaceable>に置かれる。<replaceable>file</replaceable>が省略された場合、出力は<constant>stderr</constant>に送られる。</para>

    <para>
        <literal>-T</literal>フラグを使った場合、統計にアクセスするには<ulink url="&libraryBaseLocation;/GHC-Stats.html">GHC.Stats</ulink>を使う。
    </para>

    <para>
        <literal>-t</literal>フラグを使った場合、プログラムの終了時、次のようなものを見ることになるだろう。
    </para>

<programlisting>
&lt;&lt;ghc: 36169392 bytes, 69 GCs, 603392/1065272 avg/max bytes residency (2 samples), 3M in use, 0.00 INIT (0.00 elapsed), 0.02 MUT (0.02 elapsed), 0.07 GC (0.07 elapsed) :ghc&gt;&gt;
</programlisting>

    <para>
        これは以下のことを伝えている。
    </para>

    <itemizedlist>
      <listitem>
        <para>この実行全体にわたってプログラムによって確保されたバイトの総量。
        </para>
      </listitem>
      <listitem>
        <para>実行されたガベッジコレクションの合計回数。
        </para>
      </listitem>
      <listitem>
        <para>「内容量(residency)」の平均値および最大値。内容量とは、生存しているデータの量をバイト単位で表したものである。ランタイムが生存データの量を決定できるのは大GCの間だけなので、標本の数が大GCの数に対応する(これは比較的小さい数になる)。プログラムのヒープの性質についてのよりよい描像を得るためには、<option>-hT</option>を使うこと(<xref linkend="rts-profiling"/>)。</para>
      </listitem>
      <listitem>
        <para>RTSがOSから確保したメモリの最大値。
        </para>
      </listitem>
      <listitem>
        <para>ランタイムシステムの初期化(INIT)、プログラム自体の実行(MUT, the mutator)、ガベッジコレクション(GC)それぞれのCPU時間と経過した実時間。
        </para>
      </listitem>
    </itemizedlist>

    <para><literal>-t --machine-readable</literal>とすれば、よりfuture-proofな、機械可読の形式でこれを得ることができる。
    </para>

<programlisting>
 [("bytes allocated", "36169392")
 ,("num_GCs", "69")
 ,("average_bytes_used", "603392")
 ,("max_bytes_used", "1065272")
 ,("num_byte_usage_samples", "2")
 ,("peak_megabytes_allocated", "3")
 ,("init_cpu_seconds", "0.00")
 ,("init_wall_seconds", "0.00")
 ,("mutator_cpu_seconds", "0.02")
 ,("mutator_wall_seconds", "0.02")
 ,("GC_cpu_seconds", "0.07")
 ,("GC_wall_seconds", "0.07")
 ]
</programlisting>

    <para><literal>-s</literal>フラグを使った場合、プログラムの終了時に次のようなものを目にすることになるだろう。(細部が厳密にどうなるかは使っているRTSの種類によって異なる。例えば、プロファイルのデータを見られるのはRTSがプロファイル用にコンパイルされている場合だけである)
    </para>

<programlisting>
      36,169,392 bytes allocated in the heap
       4,057,632 bytes copied during GC
       1,065,272 bytes maximum residency (2 sample(s))
          54,312 bytes maximum slop
               3 MB total memory in use (0 MB lost due to fragmentation)

  Generation 0:    67 collections,     0 parallel,  0.04s,  0.03s elapsed
  Generation 1:     2 collections,     0 parallel,  0.03s,  0.04s elapsed

  SPARKS: 359207 (557 converted, 149591 pruned)

  INIT  time    0.00s  (  0.00s elapsed)
  MUT   time    0.01s  (  0.02s elapsed)
  GC    time    0.07s  (  0.07s elapsed)
  EXIT  time    0.00s  (  0.00s elapsed)
  Total time    0.08s  (  0.09s elapsed)

  %GC time      89.5%  (75.3% elapsed)

  Alloc rate    4,520,608,923 bytes per MUT second

  Productivity  10.5% of total user, 9.1% of total elapsed
</programlisting>

    <itemizedlist>
      <listitem>
        <para>"bytes allocated in the heap"はこの実行全体にわたってプログラムによって確保されたバイトの総量である。
        </para>
      </listitem>
      <listitem>
        <para>GHCはデフォルトではコピーGCを使っている。"bytes copied during GC"はガベッジコレクション中にコピーしなければならなかったバイト数を示す。
        </para>
      </listitem>
      <listitem>
        <para>プログラムによって実際に使われた空間の最大値が"bytes maximum residency"の数値である。これは大GCのときにしか検査されないから、単なる近似値である。標本(sample)の数によって何回検査されたかが分かる。
        </para>
      </listitem>
      <listitem>
        <para>"bytes maximum slop"は、GHCがメモリをブロック単位で確保することによって無駄になった空間の最大値である。 slopとはブロックの無駄になった後方部分である。これを制御する方法はない。どれだけのメモリがこうやって失われたか見たいだけである。
        </para>
      </listitem>
      <listitem>
        <para>"total memory in use"はRTSがOSから確保したメモリの最大値である。
        </para>
      </listitem>
      <listitem>
        <para>次に、行われたガベッジコレクションについての情報がある。それぞれの世代について、ガベッジコレクションが何回行われたか、そのうち何回が並列に行われたか、その世代をGCするために使われたCPU時間の合計、その世代をGCするために経過した実時間の合計、が示されている。
        </para>
      </listitem>
      <listitem>
        <para>統計情報<literal>SPARKS</literal>は、プログラム中での<literal>Control.Parallel.par</literal>やこれに関連した機能の利用に関係する。個々のスパーク(spark)は<literal>par</literal>の一回の呼び出しを表す。スパークが「変換される(converted)」とは、それが並列に実行されることである。スパークが「刈り取られる(pruned)」とは、それが既に評価済みであることが分かり、ガベッジコレクタによってプールから捨てられることである。実行が終わると残っているスパークはすべて捨てられるので、「変換された」ものと「刈り取られた」ものを足しても合計に見たないことがあり得る。</para>
      </listitem>
      <listitem>
        <para>次に、CPU時間と経過した実時間を、そのときランタイムシステムが何をしていたかによって項目分けしたものがある。INITはランタイムシステムの初期化である。MUTはmutator time、すなわち実際にあなたのコードを走らせるのに掛かった時間である。GCはガベッジコレクションを行うのに掛かった時間である。RPは維持原因プロファイルを行うのに掛かった時間である。PROFはその他のプロファイルを行うのに掛かった時間である。EXITはランタイムシステムの終了処理時間である。最後に、Totalは、もちろん、合計である。
        </para>
        <para>%GCは、GCが全体の何%を占めるかを表している。"Alloc rate"は"bytes allocated in the heap"をMUT CPU時間で割ったものである。"Productivity"はCPU時間および経過した実時間の合計の何%がmutator(MUT)で消費されたかである。
        </para>
      </listitem>
    </itemizedlist>

    <para><literal>-S</literal>フラグは、<literal>-s</literal>フラグと同じものを出力するのに加え、GCが発生するたびにそれについての情報を表示する。
    </para>

<programlisting>
    Alloc    Copied     Live    GC    GC     TOT     TOT  Page Flts
    bytes     bytes     bytes  user  elap    user    elap
   528496     47728    141512  0.01  0.02    0.02    0.02    0    0  (Gen:  1)
[...]
   524944    175944   1726384  0.00  0.00    0.08    0.11    0    0  (Gen:  0)
</programlisting>

    <para>個々のガベッジコレクションについて、表示するのは以下のものである。
    </para>

    <itemizedlist>
      <listitem>
        <para>このGCで確保したバイト数。
        </para>
      </listitem>
      <listitem>
        <para>このGCでコピーしたバイト数。
        </para>
      </listitem>
      <listitem>
        <para>現在生存しているバイト数。
        </para>
      </listitem>
      <listitem>
        <para>このGCに掛かった時間(CPU時間および経過した実時間)。
        </para>
      </listitem>
      <listitem>
        <para>これまでにプログラムが実行された時間(CPU時間および経過した実時間)。
        </para>
      </listitem>
      <listitem>
        <para>このGCで起こったページフォールトの個数。
        </para>
      </listitem>
      <listitem>
        <para>直近のGCの終了以降に起こったページフォールトの個数。
        </para>
      </listitem>
      <listitem>
        <para>GC対象の世代。
        </para>
      </listitem>
    </itemizedlist>

	</listitem>
      </varlistentry>
    </variablelist>

  </sect2>

  <sect2>
    <title>並行性と並列性に関するRTSオプション</title>

    <para>並行実行に関わるRTSオプションは<xref linkend="using-concurrent"/>で、並列計算に関わる物は<xref linkend="parallel-options"/>で、それぞれ説明されている。</para>
  </sect2>

  <sect2 id="rts-profiling">
    <title>プロファイルに関するRTSオプション</title>

    <para>プロファイルについてのランタイムオプションの大部分は、プログラムをプロファイル用にコンパイルした場合にのみ利用可能である。(<xref linkend="prof-compiler-options" />を見よ、またランタイムオプションについては<xref linkend="rts-options-heap-prof" />を見よ)。ただし、通常の非プロファイル版実行ファイルでも利用できるプロファイルオプションがただ一つ存在する。</para>

    <variablelist>
      <varlistentry>
        <term>
          <option>-hT</option>
          <indexterm><primary><option>-hT</option></primary><secondary>RTS
              option</secondary></indexterm>
        </term>
        <listitem>
          <para>(<option>-h</option>に短縮可。) 基本的なヒーププロファイルを、<literal><replaceable>prog</replaceable>.hp</literal>というファイルに生成する。ヒーププロファイルのグラフを作成するには、<command>hp2ps</command>(<xref linkend="hp2ps" />を見よ)を使えばよい。この基本的なヒーププロファイルは、データ構築子ごとに分類され、その他の種類のクロージャは<literal>FUN</literal>や<literal>THUNK</literal>といった広い範疇ごとにまとめられている。より詳細なプロファイルを得るには、完全なプロファイルサポート(<xref linkend="profiling"/>)を使えばよい。</para>
        </listitem>
      </varlistentry>
    </variablelist>
  </sect2>

  <sect2 id="rts-eventlog">
    <title>追跡情報を得る</title>

    <indexterm><primary>tracing</primary></indexterm>
    <indexterm><primary>events</primary></indexterm>
    <indexterm><primary>eventlog files</primary></indexterm>

    <para>プログラムが<option>-eventlog</option>オプション(<xref linkend="options-linker"/>)付きでリンクされている場合、実行時のイベントを二通りの方法で記録することができる。
    </para>

    <itemizedlist>
      <listitem>
        <para>バイナリ形式でファイルに記録し、後でいろいろなツールによって分析できるようにする。<ulink url="http://www.haskell.org/haskellwiki/ThreadScope">ThreadScope</ulink><indexterm><primary>ThreadScope</primary></indexterm>はそのようなツールの一つであり、イベント記録を解釈して、プログラムの視覚的な並列実行プロファイルを作成する。
        </para>
      </listitem>
      <listitem>
        <para>テキストとして標準出力に出力し、デバッグに供する。
        </para>
      </listitem>
    </itemizedlist>

    <variablelist>
      <varlistentry>
        <term>
          <option>-l<optional><replaceable>flags</replaceable></optional></option>
          <indexterm><primary><option>-l</option></primary><secondary>RTS option</secondary></indexterm>
        </term>
        <listitem>
          <para>イベントをバイナリ形式で<filename><replaceable>program</replaceable>.eventlog</filename>というファイルに記録する。<replaceable>flags</replaceable>が指定されなかった場合、ThreadScopeなどのツールに適したデフォルトのイベント集合を記録する。
          </para>

          <para>特殊な利用状況では、どのイベントを含むかをもっと細かく制御したいかもしれない。<replaceable>flags</replaceable>は、どの種類のイベントを記録するかを意味する文字を零個以上並べたものである。現在、有効/無効にできるイベントの種類は以下である。
            <simplelist>
              <member>
                <option>s</option> &#8212; スケジューラのイベント、スレッドの作成、開始/停止のイベントを含む。デフォルトで有効。
              </member>
              <member>
                <option>g</option> &#8212; GCのイベント、GCの開始/停止を含む。デフォルトで有効。
              </member>
              <member>
                <option>p</option> &#8212; 並列スパーク(標本抽出)。デフォルトで有効。
              </member>
              <member>
                <option>f</option> &#8212; 並列スパーク(完全に正確)。デフォルトで無効。
              </member>
              <member>
                <option>u</option> &#8212; ユーザイベント。<literal>Debug.Trace.traceEvent</literal>などの関数を使ってHaskellコードから出力されるイベントである。デフォルトで有効。
              </member>
            </simplelist>
          </para>

          <para>特定の種類を無効にしたり、全ての種類を一度に有効/無効にしたりすることができる。
            <simplelist>
              <member>
                <option>a</option> &#8212; 上で挙げた全ての種類のイベントを有効にする
              </member>
              <member>
                <option>-<replaceable>x</replaceable></option> &#8212; 与えられた種類のイベントを無効にする。上で挙げた種類をどれか指定するか、<option>-a</option>なら全てのイベントになる。
              </member>
            </simplelist>
            例えば、<option>-l-ag</option>はGCイベント(<option>g</option>)を除いて全てのイベント(<option>-a</option>)を無効にする。</para>

          <para>スパークのイベントには二つのモードがある。標本抽出と完全に正確である。個々のスパークの生涯にはいろいろなイベントがある。通常は作成と実行だけだが、もっと例外的なものもあり得る。標本抽出モードでは、短い間隔で、それぞれのスパークイベントの数が標本抽出される。完全に正確モードでは、全てのスパークが個々に記録される。後者の方が実行時のオーバーヘッドが高く、デフォルトでは有効になっていない。
          </para>

          <para>記録ファイルの形式はGHCに付属する<filename>EventLogFormat.h</filename>に記述されており、Haskellでは<ulink url="http://hackage.haskell.org/package/ghc-events">ghc-events</ulink>ライブラリを使うことでパースできる。<literal>.eventlog</literal>ファイルの内容をテキストとしてダンプするには、<ulink url="http://hackage.haskell.org/package/ghc-events">ghc-events</ulink>パッケージに付属している<literal>ghc-events show</literal>というツールが使える。
          </para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term>
          <option>-v</option><optional><replaceable>flags</replaceable></optional>
          <indexterm><primary><option>-v</option></primary><secondary>RTS option</secondary></indexterm>
        </term>
        <listitem>
          <para>イベントを、<literal>.eventlog</literal>ファイルにではなく、テキストとして標準出力に記録する。<replaceable>flags</replaceable>は<option>-l</option>の場合と同じであるが、追加のオプション<literal>t</literal>があって、これは、表示される個々のイベントの前にタイムスタンプを表示することを示す。(バイナリの<literal>.eventlog</literal>ファイルでは、全てのイベントは自動的にタイムスタンプと結び付けられる)
          </para>
        </listitem>
      </varlistentry>

    </variablelist>

    <para>この追跡フレームワークで記録されるイベントを、デバッグオプション<option>-D<replaceable>x</replaceable></option>も生成する。デフォルトではこれらのイベントはテキストとして標準出力にダンプされる(<option>-D<replaceable>x</replaceable></option>によって<option>-v</option>が有効になる)が、<option>-l</option>を使うことでバイナリのイベント記録ファイルに保存することもできる。
    </para>
  </sect2>

  <sect2 id="rts-options-debugging">
    <title>ハックする者、デバッグする者、及び好奇心過剰な魂のためのRTSオプション</title>

    <indexterm><primary>RTS options, hacking/debugging</primary></indexterm>

    <para>これらのRTSオプションは、(a)&nbsp;GHCのバグを回避するために、(b)&nbsp;「何が実際に起きているか」を知るために、(c)&nbsp;なんとなくそうしたいから、という理由で使うことができる。素人にはおすすめできない。</para>

    <variablelist>

      <varlistentry>
	<term>
          <option>-B</option>
          <indexterm><primary><option>-B</option></primary><secondary>RTS option</secondary></indexterm>
        </term>
	<listitem>
          <para>GC(大)が始まるたびにベルを鳴らす。</para>

          <para>実に奇妙なことだが、実際にこのオプションを使う人々が存在する。ダラム(イギリス)にいる我々の仲間、ポール・キャラハンは次のように書いている。「ここには色んな目的のためにこれを使う人々がいる&mdash;これは本当だ&mdash;例えば、コード/機械が何かをしているということを確認したり、無限ループを発見したり、最近付け加えたコードのコストを量ったりだ。ある種の人々はビープのパターンからプログラムがどの段階にいるかを聞き分けることさえできる。しかし最も重要な使いかたは、同じオフィスにいる他の人を鬱陶しがらせることである&hellip;」</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <option>-D</option><replaceable>x</replaceable>
          <indexterm><primary>-D</primary><secondary>RTS option</secondary></indexterm>
        </term>
	<listitem>
	  <para>RTSのデバッグフラグ。RTSが<option>DEBUG</option>オプション付きでリンクされているときのみ使える。RTSのいろいろな部分について、デバッグ出力や追加の実行時の正気チェックを有効にするための<replaceable>x</replaceable>の値が用意されている。例えば、<literal>+RTS -Ds -RTS</literal>とするとスケジューラのデバッグ出力が有効になる。どういうデバッグフラグがサポートされているかを知るには<literal>+RTS&nbsp;-?</literal>が使える。
          </para>

          <para><option>-l</option>オプションを追加すると、デバッグ出力が標準出力でなくバイナリのイベント記録ファイルに送られるようになる。デバッグ追跡にかかるオーバーヘッドを減らしたいときに便利かもしれない。
          </para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <option>-r</option><replaceable>file</replaceable>
          <indexterm><primary><option>-r</option></primary><secondary>RTS option</secondary></indexterm>
          <indexterm><primary>ticky ticky profiling</primary></indexterm>
          <indexterm><primary>profiling</primary><secondary>ticky ticky</secondary></indexterm>
        </term>
	<listitem>
          <para>プログラムの実行終了時に「ticky-ticky」統計情報を生成する(プログラムが<option>-debug</option>オプション付きでリンクされている場合にのみ利用可能)。<replaceable>file</replaceable>の扱いは上にある<option>-S</option>RTSオプションの場合と同じである。</para>

          <para>ticky-tickyプロファイルについての更なる情報は、<xref linkend="ticky-ticky"/>を見よ。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <option>-xc</option>
          <indexterm><primary><option>-xc</option></primary><secondary>RTS option</secondary></indexterm>
        </term>
	<listitem>
          <para>(プログラムがプロファイルを取れるようにコンパイルしてある場合のみ利用可能) プログラム中で例外が発生したとき、このオプションが指定されていると、スタックトレースが<literal>stderr</literal>に出力される。</para>

          <para>これは特にデバッグ時に有用である。プログラムが<literal>head []</literal>エラーを起こすが、コードのどの部分が原因か分からないとき、<literal>-prof -fprof-auto</literal>を付けてコンパイルし、<literal>+RTS -xc -RTS</literal>を付けて実行すれば、エラーが発生した地点の呼び出しスタックが正確に分かる。</para>

          <para>出力には、プログラムで発生した例外それぞれ(プログラムは、実行を通して、例外を複数回発生させたり捕捉したりし得る)につき一つの報告を含む。個々の報告は以下のようなものである。</para>

<screen>
*** Exception raised (reporting due to +RTS -xc), stack trace:
  GHC.List.CAF
  --> evaluated by: Main.polynomial.table_search,
  called from Main.polynomial.theta_index,
  called from Main.polynomial,
  called from Main.zonal_pressure,
  called from Main.make_pressure.p,
  called from Main.make_pressure,
  called from Main.compute_initial_state.p,
  called from Main.compute_initial_state,
  called from Main.CAF
  ...
</screen>
          <para>スタックトレースはしばしば、<literal>GHC.List.CAF</literal>のような役に立たないものから始まる。これはGHCの最適化器が例外を最上位に移した痕跡である。これに対してプロファイルシステムはコスト集約点「CAF」を割り当てた。しかし<literal>+RTS -xc</literal>は単に現在のスタックを表示するだけでなく、より深く見てそのCAFが評価された時点のスタックを報告する。CAFでないスタックが見つかるまでさらにスタックを報告するかもしれない。上の例では、次のスタック(<literal>--> evaluated by</literal>の後)が、プログラムが<literal>head []</literal>を評価したときに何をしていたかについて、沢山の情報を含んでいる。</para>
 
          <para>実装の詳細はさておき、スタック中の関数名は願わくばバグを見つけだすのに十分な手掛りをあなたに与えるだろう。</para>

          <para>呼び出しスタックを見る別の方法については、<literal>Debug.Trace</literal>モジュールの<literal>traceStack</literal>関数も見よ。
          </para>
        </listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <option>-Z</option>
          <indexterm><primary><option>-Z</option></primary><secondary>RTS option</secondary></indexterm>
        </term>
	<listitem>
          <para>GC時の「update-frame-squeezing」を<emphasis>無効に</emphasis>する。サンクへの進入回数(entry count)についてのある種のデータを正確に収集したい場合を除いて、これを無効にする理由はあまりない。</para>
	</listitem>
      </varlistentry>
    </variablelist>

  </sect2>

  <sect2 id="ghc-info">
    <title>RTSに関する情報を取得する</title>

    <indexterm><primary>RTS</primary></indexterm>

    <para>RTSに、自分自身の情報をいくらか表示させることが可能である。これをするには<option>--info</option>フラグを使う。例えば次のように。</para>
<screen>
$ ./a.out +RTS --info
 [("GHC RTS", "YES")
 ,("GHC version", "6.7")
 ,("RTS way", "rts_p")
 ,("Host platform", "x86_64-unknown-linux")
 ,("Host architecture", "x86_64")
 ,("Host OS", "linux")
 ,("Host vendor", "unknown")
 ,("Build platform", "x86_64-unknown-linux")
 ,("Build architecture", "x86_64")
 ,("Build OS", "linux")
 ,("Build vendor", "unknown")
 ,("Target platform", "x86_64-unknown-linux")
 ,("Target architecture", "x86_64")
 ,("Target OS", "linux")
 ,("Target vendor", "unknown")
 ,("Word size", "64")
 ,("Compiler unregisterised", "NO")
 ,("Tables next to code", "YES")
 ]
</screen>
    <para>この情報は、<literal>[(String, String)]</literal>型の値として読めるように整形されている。現在、以下のフィールドが存在する。</para>

    <variablelist>

      <varlistentry>
        <term><literal>GHC RTS</literal></term>
        <listitem>
          <para>このプログラムはGHC RTSにリンクされているか？(常に"YES")</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term><literal>GHC version</literal></term>
        <listitem>
          <para>このプログラムをコンパイルするのに用いられたGHCのバージョン</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term><literal>RTS way</literal></term>
        <listitem>
          <para>ランタイムの種類(「way」)。特によくある値は、<literal>rts_v</literal>(バニラ)、<literal>rts_thr</literal>(スレッド化されたランタイム、つまり<literal>-threaded</literal>オプション付きでリンクされたもの)、<literal>rts_p</literal>(プロファイル用ランタイム、つまり<literal>-prof</literal>オプション付きでリンクされたもの)である。他の種類には、<literal>debug</literal>(<literal>-debug</literal>を使ってリンクされたもの)、<literal>dyn</literal>(RTSが動的にリンクされる、つまり実行ファイルに静的にリンクされているのでない共有ライブラリである)などがある。これらは組み合わせることができる。例えば、<literal>rts_thr_debug_p</literal>というものが可能である。</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term>
            <literal>Target platform</literal>,
            <literal>Target architecture</literal>,
            <literal>Target OS</literal>,
            <literal>Target vendor</literal>
        </term>
        <listitem>
          <para>プログラムが走ることを意図されたプラットフォーム。</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term>
            <literal>Build platform</literal>,
            <literal>Build architecture</literal>,
            <literal>Build OS</literal>,
            <literal>Build vendor</literal>
        </term>
        <listitem>
          <para>プログラムがビルドされたプラットフォーム。(つまり、GHC自身のターゲットプラットフォームである)。通常これはターゲットプラットフォームと同じである。(クロスコンパイルの際には異なることが考えられる)</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term>
            <literal>Host platform</literal>,
            <literal>Host architecture</literal>
            <literal>Host OS</literal>
            <literal>Host vendor</literal>
        </term>
        <listitem>
          <para>GHC自身がコンパイルされたプラットフォーム。これも、通常はビルドおよびターゲットのプラットフォームと同じである。</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term><literal>Word size</literal></term>
        <listitem>
          <para>ターゲットプラットフォームのワードの大きさに応じて、<literal>"32"</literal>または<literal>"64"</literal>。</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term><literal>Compiler unregistered(訳注: unregisteredでなくunregisterisedが正しいものと思われる)</literal></term>
        <listitem>
          <para>このプログラムは<link linkend="unreg">「非レジスタ化」</link>版のGHC(すなわち、通常未対応のプラットフォームであるために、プラットフォーム固有の最適化なしでコンパイルされたGHC)によってコンパイルされたか？実験的なGHCのビルドを使っているのでない限り、この値は通常noである。</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term><literal>Tables next to code</literal></term>
        <listitem>
          <para>info tableをコードに直接隣接させて配置するという最適化は有用であるが、全てのプラットフォームで対応されている訳ではない。このフィールドは、プログラムがこの最適化を使ってコンパイルされているかどうかを示すものである。(珍しいプラットフォームでなければ通常yesである)</para>
        </listitem>
      </varlistentry>

    </variablelist>

  </sect2>
</sect1>

<!-- Emacs stuff:
     ;;; Local Variables: ***
     ;;; sgml-parent-document: ("users_guide.xml" "book" "chapter" "sect1") ***
     ;;; End: ***
 -->