RTSの時計が進行する時間間隔を設定する。ランタイムは単一のタイマシグナルを使って時計を進行させる。コンテクストスイッチのタイマ(4.14. Concurrent Haskellを使う)およびヒーププロファイル時のタイマ(5.4.1. ヒーププロファイルのためのRTSオプション)を制御するのにはこれが使われる。また、時間プロファイルをとるときは、プロファイルの標本を記録するのにRTSのタイマシグナルを直接使うことになる。

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

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

yes(デフォルト)なら、RTSはctrl-Cの類を捕捉するためのシグナルハンドラを設置する。このオプションは、HaskellコードをDLLとして使っていて、自分でシグナルハンドラを設定したいときに特に有用である。

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

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

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

[デフォルト: 512k]ガベッジコレクタが使う確保領域の大きさを設定する。確保領域(実際には世代0・段階0)は固定されており、大きさが変わることはない。(-Hを使った場合はこの限りでない。下記参照)

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

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

もっとも古い世代を回収するときにコンパクト化アルゴリズムを使う。デフォルトでは最古世代はコピーアルゴリズムで回収されるが、このオプションが使われると、その場でコンパクト化されるようになる。コンパクト化アルゴリズムはコピーアルゴリズムより遅いが、相当量のメモリを節約できることがある。

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

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

[デフォルト: 30] 生存データがヒープの大きさの上限(-Mオプションを見よ)のn%を超えたときに自動的にコンパクト化を有効にする。デフォルトではヒープの大きさに上限はないので、-Msizeでヒープの大きさの上限が指定されない限り、このオプションには効果がない。

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

これについてはデフォルトがうまく働いているようである。潤沢なメモリがあるなら、通常、-Ffactorを増やすよりも-Hsizeを使った方が良い。

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

[デフォルト: 2] ガベッジコレクタが使う世代の数を設定する。デフォルトの2は良い選択のようだが、ガベッジコレクタは任意の数の世代をサポートしている。プログラムが長い時間に渡って実行されるのでない限り、4程度より大きな値はおそらく良くない。最古の世代が一回も回収されないということになるからである。

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

[GHC 6.12.1から] [デフォルト: 0] 世代genとそれより上の世代において、並列GCを使う。genを省略すると、並列GCは完全に無効になり、逐次GCに戻る。

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

[GHC 6.12.1から] [デフォルト: 1] 並列GCにおいて、世代genとそれより上の世代で負荷分散を使う。genを省略すると、負荷分散を完全に無効にする。

負荷分散とは、GCの作業を空いているコア間で分配することである。これは、ヒープが大きく、GCの作業を並列化する必要がある場合には良いことである。しかし、並列プログラムの若い世代における短い回収では、これは最悪である。なぜなら、データをCPUのキャッシュから動かすことで、局所性を損うからである。(訳注: 理解できないのでだれか助けて 原文は because it can harm locality by moving data from the cache of the CPU where is it being used to the cache of another CPU.)。実際、並列プログラムでは、-qbで負荷分散を完全に無効にした方が良いこともある。

[デフォルト: 0] このオプションはガベッジコレクタに「推奨されるヒープの大きさ」を提示する。-Hsizeは可変の-Aオプションだと思うと良い。これは次のように述べる。私は少なくともsizeバイトを使いたいので、残ったものは全部-Aを増やすのに使え。

このオプションはヒープの大きさに制限を加えるものではない。ヒープは通常同様に与えられた大きさを超えて成長し得る。

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

(デフォルト: 0.3) スレッド化された、またはSMP版のRTS(-threadedを見よ。4.12.6. リンクに影響するオプション)においては、ランタイムが一定期間待機状態である(Haskellの計算が実行されていない)とき、自動的に大GCが実行される。GCが実行されるまでの時間を指定するのが-Isecondsオプションである。-I0を指定すると待機状態でのGCが無効になる。

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

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

[デフォルト: 1k] スレッドの初期スタックサイズを設定する。(注意: このフラグは単に-kであったが、GHC 7.2.1で-kiに改名された。古い名前も後方互換性のためにまだ受け付けられるが、将来の版では削除されるかもしれない)

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

[デフォルト: 32k] “スタックチャンク”の大きさを設定する。スレッドの現行スタックがオーバーフローしたとき、-Kで設定された上限に達するまでは、新しいスタックチャンクが作成されてスレッドのスタックに加えられる。

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

[デフォルト: 1k] スタックチャンクバッファの大きさを設定する。スタックチャンクがオーバーフローして新しいチャンクが作成される時、前のスタックのデータの一部が新しいチャンクに移動される。これは、即座にアンダーフローが発生し、境界でオーバーフロー/アンダーフローが繰り返されるのを防ぐためである。ここで動かされるスタックの量が-kbによって設定される。

空間を無駄にするのを防ぐために、この値は典型的にはスタックチャンクの大きさ(-kc)の10%未満に設定されるべきである。スタックチャンクの連鎖の中で、それぞれのチャンクがこの大きさの未使用の空間を隙間として持つことになるからである。

[デフォルト: 8M] 個々のスレッドの最大スタックサイズをsizeに設定する。スレッドがこの制限を超えようとした場合、StackOverflow例外が送られる。

このオプションは主に、プログラムが無限ループに陥ったときに利用可能なメモリを使い果たすことがないようするために存在している。

ヒープのうち確保可能な(訳注: 未使用な)部分の最小%を指定する。デフォルトは3%である。

[デフォルト: 無制限] 最大ヒープサイズをsizeに設定する。ヒープは通常プログラムのメモリ要求に従って伸長したり収縮したりする。このオプションの唯一の存在理由は、ヒープが際限なく膨張してスワップ空間を使い果たす(結果として、少なくともプログラムが即座にOSに殺されることになる)のを防ぐことである。

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

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

出力内容はfileに置かれる。fileが省略された場合、出力はstderrに送られる。

-Tフラグを使った場合、統計にアクセスするにはGHC.Statsを使う。

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

<<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>>

これは以下のことを伝えている。

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

 [("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")
 ]

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

      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

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

    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)

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

(-hに短縮可。) 基本的なヒーププロファイルを、prog.hpというファイルに生成する。ヒーププロファイルのグラフを作成するには、hp2ps(5.5. hp2ps––ヒーププロファイルをPostScriptへを見よ)を使えばよい。この基本的なヒーププロファイルは、データ構築子ごとに分類され、その他の種類のクロージャはFUNやTHUNKといった広い範疇ごとにまとめられている。より詳細なプロファイルを得るには、完全なプロファイルサポート(第5章. プロファイルを取る)を使えばよい。

イベントをバイナリ形式でprogram.eventlogというファイルに記録する。flagsが指定されなかった場合、ThreadScopeなどのツールに適したデフォルトのイベント集合を記録する。

特殊な利用状況では、どのイベントを含むかをもっと細かく制御したいかもしれない。flagsは、どの種類のイベントを記録するかを意味する文字を零個以上並べたものである。現在、有効/無効にできるイベントの種類は以下である。

特定の種類を無効にしたり、全ての種類を一度に有効/無効にしたりすることができる。

例えば、-l-agはGCイベント(g)を除いて全てのイベント(-a)を無効にする。

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

記録ファイルの形式はGHCに付属するEventLogFormat.hに記述されており、Haskellではghc-eventsライブラリを使うことでパースできる。.eventlogファイルの内容をテキストとしてダンプするには、ghc-eventsパッケージに付属しているghc-events showというツールが使える。

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

GC(大)が始まるたびにベルを鳴らす。

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

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

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

プログラムの実行終了時に「ticky-ticky」統計情報を生成する(プログラムが-debugオプション付きでリンクされている場合にのみ利用可能)。fileの扱いは上にある-SRTSオプションの場合と同じである。

ticky-tickyプロファイルについての更なる情報は、5.8. 「ticky-ticky」プロファイルを使うを見よ。

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

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

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

*** 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
  ...

スタックトレースはしばしば、GHC.List.CAFのような役に立たないものから始まる。これはGHCの最適化器が例外を最上位に移した痕跡である。これに対してプロファイルシステムはコスト集約点「CAF」を割り当てた。しかし+RTS -xcは単に現在のスタックを表示するだけでなく、より深く見てそのCAFが評価された時点のスタックを報告する。CAFでないスタックが見つかるまでさらにスタックを報告するかもしれない。上の例では、次のスタック(--> evaluated byの後)が、プログラムがhead []を評価したときに何をしていたかについて、沢山の情報を含んでいる。

実装の詳細はさておき、スタック中の関数名は願わくばバグを見つけだすのに十分な手掛りをあなたに与えるだろう。

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

GC時の「update-frame-squeezing」を無効にする。(There's no particularly good reason to turn it off, except to ensure the accuracy of certain data collected regarding thunk entry counts.(訳注: 訳せません。助けて))

このプログラムはGHC RTSにリンクされているか？(常に"YES")

このプログラムをコンパイルするのに用いられたGHCのバージョン

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

プログラムが走ることを意図されたプラットフォーム。

プログラムがビルドされたプラットフォーム。(つまり、GHC自身のターゲットプラットフォームである)。通常これはターゲットプラットフォームと同じである。(クロスコンパイルの際には異なることが考えられる)

GHC自身がコンパイルされたプラットフォーム。これも、通常はビルドおよびターゲットのプラットフォームと同じである。

ターゲットプラットフォームのワードの大きさに応じて、"32"または"64"。

このプログラムは「非レジスタ化」版のGHC(すなわち、通常未対応のプラットフォームであるために、プラットフォーム固有の最適化なしでコンパイルされたGHC)によってコンパイルされたか？実験的なGHCのビルドを使っているのでない限り、この値は通常noである。

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