RTSの時計が進行する時間間隔を設定する。ランタイムは単一のタイマシグナルを使って時計を進行させる。コンテクストスイッチのタイマ(4.13. 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に大きな値を指定すると良い。GCの性能を向上させるには、通常、-Asizeよりも-Hsizeを使った方が良い。

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

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

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

[デフォルト: 1k] スレッドの初期スタックサイズを設定する。スレッドのスタック(主スレッドのスタックも含めて)はヒープ上にとられ、必要に応じて成長する。デフォルト値はたくさんの小さなスレッドを使う並行アプリケーションに適している。あなたのプログラムがこれに沿わないなら、このオプションを増加させると性能が向上するかもしれない。

通常、主スレッドはやや大きめのヒープで開始される。これは、プログラムが開始するときに起こる不必要なスタックの伸長を低減するためである。

[デフォルト: 8M] 個々のスレッドの最大スタックサイズをsizeに設定する。このオプションは、プログラムが無限ループに陥ったときに利用可能なメモリを使い果たすことがないようするためだけに存在している。

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

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

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

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

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

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

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

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

イベントをバイナリ形式でprogram.eventlogというファイルに記録する。ここで、flagsは、どの種類のイベントを記録するかを示す文字の零個以上の並びである。現在、対応している型はひとつだけである。すなわち、-lsでスケジューラのイベントを記録する。

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

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

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

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

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

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

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

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

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

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

発生した例外一つにつき一行が出力される。(プログラムは、実行を通して、例外を複数回発生させたり捕捉したりし得る)。各行は以下の形を取る。

< cc1, ..., ccn >

それぞれのcc_iはプログラム中のコスト集約点(5.1. コスト集約点とコスト集約点スタックを見よ)であり、この列は例外が発生した地点での「呼び出しスタック」を表している。最も右にあるのが最も外側の関数である。

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である)