Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Newer
Older
100644 933 lines (778 sloc) 65.996 kb
96a515c @mkotha 6.6.1
authored
1 <?xml version="1.0" encoding="UTF-8"?>
97da4f5 @mkotha update runtime_control.xml
authored
2 <sect1 id="runtime-control">
96a515c @mkotha 6.6.1
authored
3 <title>コンパイル済みプログラムを実行する</title>
4
5 <indexterm><primary>runtime control of Haskell programs</primary></indexterm>
6 <indexterm><primary>running, compiled program</primary></indexterm>
7 <indexterm><primary>RTS options</primary></indexterm>
8
2b7e60a @mkotha update runtime_control.xml
authored
9 <para>実行可能なプログラムを作るとき、GHCシステムはコードをコンパイルし、それを自明でないランタイムシステム(RTS)とリンクする。これは、記憶領域の管理、スレッドのスケジュール、プロファイルの取得などを行う。</para>
96a515c @mkotha 6.6.1
authored
10
2b7e60a @mkotha update runtime_control.xml
authored
11 <para>RTSは、振る舞いを制御するための沢山のオプションを持っている。例えば、コンテキストスイッチの間隔やヒープのデフォルトの大きさを変えたり、ヒーププロファイルを有効にしたりである。こうしたオプションは色々な方法でランタイムシステムに渡すことができる。次の節(<xref linkend="setting-rts-options"/>)ではこれらの方法を記述し、それ以降の節ではRTSオプション自体について記述する。</para>
96a515c @mkotha 6.6.1
authored
12
97da4f5 @mkotha update runtime_control.xml
authored
13 <sect2 id="setting-rts-options">
2b7e60a @mkotha update runtime_control.xml
authored
14 <title>RTSオプションを設定する</title>
15 <indexterm><primary>RTS options, setting</primary></indexterm>
96a515c @mkotha 6.6.1
authored
16
2b7e60a @mkotha update runtime_control.xml
authored
17 <para>RTSオプションを設定するのには四つの方法がある。
18
19 <itemizedlist>
20 <listitem>
21 <para>プログラムを実行する際、コマンド行の<literal>+RTS ... -RTS</literal>の間で。(<xref linkend="rts-opts-cmdline" />)</para>
22 </listitem>
23 <listitem>
24 <para>コンパイル時に、<option>--with-rtsopts</option>を使って。(<xref linkend="rts-opts-compile-time" />)</para>
25 </listitem>
26 <listitem>
27 <para>環境変数<envar>GHCRTS</envar>で。(<xref linkend="rts-options-environment" />)</para>
28 </listitem>
29 <listitem>
30 <para>ランタイムシステムの&ldquo;フック&rdquo;を上書きすることによって。(<xref linkend="rts-hooks" />)</para>
31 </listitem>
32 </itemizedlist>
33 </para>
96a515c @mkotha 6.6.1
authored
34
97da4f5 @mkotha update runtime_control.xml
authored
35 <sect3 id="rts-opts-cmdline">
2b7e60a @mkotha update runtime_control.xml
authored
36 <title>コマンド行でRTSオプションを設定する</title>
96a515c @mkotha 6.6.1
authored
37
2b7e60a @mkotha update runtime_control.xml
authored
38 <para>リンク時に<literal>-rtsopts</literal>フラグを適切に設定していたなら、プログラムを実行するときにRTSオプションをコマンド行で与えることができる。</para>
96a515c @mkotha 6.6.1
authored
39
2b7e60a @mkotha update runtime_control.xml
authored
40 <para>Haskellプログラムの実行が開始されるとき、RTSはコマンド行引数から<option>+RTS</option><indexterm><primary><option>+RTS</option></primary></indexterm>と<option>-RTS</option><indexterm><primary><option>-RTS</option></primary></indexterm>で囲まれた部分を自分用に抽出する。以下のような例を考える。</para>
41
42 <screen>
43 $ ghc prog.hs -rtsopts
44 [1 of 1] Compiling Main ( prog.hs, prog.o )
45 Linking prog ...
46 $ ./prog -f +RTS -H32m -S -RTS -h foo bar
47 </screen>
48
49 <para>RTSは<option>-H32m</option> <option>-S</option>を横取りし、プログラムが<function>System.Environment.getArgs</function>を読んだときには残りの引数である<literal>-f -h foo bar</literal>が渡される。</para>
50
51 <para>次の例のように、ランタイムシステムへのオプションがコマンド行の最後まで続くときは、<option>-RTS</option>オプションは必要ない。</para>
52
53 <screen>
96a515c @mkotha 6.6.1
authored
54 % hls -ltr /usr/etc +RTS -A5m
2b7e60a @mkotha update runtime_control.xml
authored
55 </screen>
96a515c @mkotha 6.6.1
authored
56
2b7e60a @mkotha update runtime_control.xml
authored
57 <para>残りのオプションを問答無用で(RTSでなく)プログラムに渡したいなら、<option>&ndash;&ndash;RTS</option><indexterm><primary><option>--RTS</option></primary></indexterm>を使うことができる。</para>
96a515c @mkotha 6.6.1
authored
58
2b7e60a @mkotha update runtime_control.xml
authored
59 <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>
96a515c @mkotha 6.6.1
authored
60
a8a1a23 @mkotha update runtime_control.xml
authored
61 <para><literal>+RTS -?</literal><indexterm><primary><option>-?</option></primary><secondary>RTS option</secondary></indexterm>オプションを与えれば、実際に利用可能なRTSオプションを表示することができる。(これはどのようにコンパイルされたかによって異なる)</para>
96a515c @mkotha 6.6.1
authored
62
2b7e60a @mkotha update runtime_control.xml
authored
63 <para>注意: GHCはそれ自身GHCでコンパイルされているので、通常の<literal>+RTS ... -RTS</literal>の組み合わせを使ってRTSオプションを変更することができる。例えば、コンパイル時の最大ヒープサイズを128Mに増やすには、<literal>+RTS -M128m -RTS</literal>をコマンド行に加えれば良い。</para>
97da4f5 @mkotha update runtime_control.xml
authored
64 </sect3>
96a515c @mkotha 6.6.1
authored
65
97da4f5 @mkotha update runtime_control.xml
authored
66 <sect3 id="rts-opts-compile-time">
2b7e60a @mkotha update runtime_control.xml
authored
67 <title>コンパイル時にRTSオプションを設定する</title>
96a515c @mkotha 6.6.1
authored
68
294c679 @mkotha update runtime_control.xml
authored
69 <para><literal>-with-rtsopts</literal>フラグ(<xref linkend="options-linker"/>)を使うことで、プログラムのRTSオプションをコンパイル時に設定することができる。これのよくある使い方は、デフォルトよりも大きなヒープ/スタックサイズを初期値としてプログラムに与えることである。例えば<literal>-H128m -K64m</literal>を設定するには、<literal>-with-rtsopts="-H128m -K64m"</literal>付きでリンクすればよい。</para>
97da4f5 @mkotha update runtime_control.xml
authored
70 </sect3>
96a515c @mkotha 6.6.1
authored
71
97da4f5 @mkotha update runtime_control.xml
authored
72 <sect3 id="rts-options-environment">
2b7e60a @mkotha update runtime_control.xml
authored
73 <title><envar>RTSOPTS</envar>でRTSオプションを設定する</title>
96a515c @mkotha 6.6.1
authored
74
2b7e60a @mkotha update runtime_control.xml
authored
75 <indexterm><primary>RTS options</primary><secondary>from the environment</secondary></indexterm>
76 <indexterm><primary>environment variable</primary><secondary>for
77 setting RTS options</secondary></indexterm>
96a515c @mkotha 6.6.1
authored
78
2b7e60a @mkotha update runtime_control.xml
authored
79 <para>リンク時に<literal>-rtsopts</literal>フラグが<literal>none</literal>以外に設定されているなら、RTSオプションは環境変数<envar>GHCRTS</envar><indexterm><primary><envar>GHCRTS</envar></primary></indexterm>からも採られる。例えば、GHCでコンパイルされた全てのプログラムについて最大ヒープサイズを2Gにするなら、次のようにすれば良い。(<literal>sh</literal>系のシェルを使っていると仮定する)</para>
96a515c @mkotha 6.6.1
authored
80
2b7e60a @mkotha update runtime_control.xml
authored
81 <screen>
82 GHCRTS='-M2G'
83 export GHCRTS
84 </screen>
96a515c @mkotha 6.6.1
authored
85
2b7e60a @mkotha update runtime_control.xml
authored
86 <para><envar>GHCRTS</envar>環境変数から採られたRTSオプションはコマンド行からオプションを与えることで上書きできる。</para>
87
88 <para>ヒント: あなたの環境に<literal>GHCRTS=-M2G</literal>のようなものを設定しておくと、Haskellプログラムがあなたのマシンの実メモリを超えて成長することを簡単に防ぐことができる。誤ってこういうことをするのは良くあることであり、OSがそのプロセスを殺すことを決めるまでマシンがゆっくりと地を這うことになる。(そして、ちゃんと正しいのを殺してくれるといいね)</para>
97da4f5 @mkotha update runtime_control.xml
authored
89 </sect3>
2b7e60a @mkotha update runtime_control.xml
authored
90
97da4f5 @mkotha update runtime_control.xml
authored
91 <sect3 id="rts-hooks">
2b7e60a @mkotha update runtime_control.xml
authored
92 <title>RTSの振る舞いを変更するためのフック</title>
93
94 <indexterm><primary>hooks</primary><secondary>RTS</secondary></indexterm>
95 <indexterm><primary>RTS hooks</primary></indexterm>
96 <indexterm><primary>RTS behaviour, changing</primary></indexterm>
97
294c679 @mkotha update runtime_control.xml
authored
98 <para>GHCでは、ランタイムシステムから呼ばれるフックをコンパイル時に含めることで、任意のプログラムのRTS設定の一部をある程度制御することができる。RTSにはこれらのフックのスタブ定義が含まれているが、自分の版を書いてGHCのコマンド行からリンクすることで、デフォルトと異なるものを使える。</para>
2b7e60a @mkotha update runtime_control.xml
authored
99
100 <para>DLLリンクの気まぐれのせいで、これらのフックはWindowsでプログラムが動的リンクでビルドされるときには働かない。</para>
101
294c679 @mkotha update runtime_control.xml
authored
102 <para>ランタイムシステムがどうしようもなくなったとき(例えばスタックオーバーフロー)に表示される文言を変更することができる。このためのフックは以下である。</para>
2b7e60a @mkotha update runtime_control.xml
authored
103
104 <variablelist>
105
106 <varlistentry>
107 <term>
108 <function>void OutOfHeapHook (unsigned long, unsigned long)</function>
109 <indexterm><primary><function>OutOfHeapHook</function></primary></indexterm>
110 </term>
111 <listitem>
112 <para>ヒープオーバーフローのメッセージ。</para>
113 </listitem>
114 </varlistentry>
115
116 <varlistentry>
117 <term>
118 <function>void StackOverflowHook (long int)</function>
119 <indexterm><primary><function>StackOverflowHook</function></primary></indexterm>
120 </term>
121 <listitem>
122 <para>スタックオーバーフローのメッセージ。</para>
123 </listitem>
124 </varlistentry>
125
126 <varlistentry>
127 <term>
128 <function>void MallocFailHook (long int)</function>
129 <indexterm><primary><function>MallocFailHook</function></primary></indexterm>
130 </term>
131 <listitem>
132 <para><function>malloc</function>が失敗したときに表示されるメッセージ。</para>
133 </listitem>
134 </varlistentry>
135 </variablelist>
97da4f5 @mkotha update runtime_control.xml
authored
136 </sect3>
137 </sect2>
2b7e60a @mkotha update runtime_control.xml
authored
138
97da4f5 @mkotha update runtime_control.xml
authored
139 <sect2 id="rts-options-misc">
96a515c @mkotha 6.6.1
authored
140 <title>いろいろなRTSオプション</title>
141
142 <variablelist>
143 <varlistentry>
a2be81e @mkotha runtime_control.xml
authored
144 <term><option>-V<replaceable>secs</replaceable></option>
96a515c @mkotha 6.6.1
authored
145 <indexterm><primary><option>-V</option></primary><secondary>RTS
a2be81e @mkotha runtime_control.xml
authored
146 option</secondary></indexterm></term>
96a515c @mkotha 6.6.1
authored
147 <listitem>
a2be81e @mkotha runtime_control.xml
authored
148 <para>RTSの時計が進行する時間間隔を設定する。ランタイムは単一のタイマシグナルを使って時計を進行させる。コンテクストスイッチのタイマ(<xref linkend="using-concurrent"/>)およびヒーププロファイル時のタイマ(<xref linkend="rts-options-heap-prof"/>)を制御するのにはこれが使われる。また、時間プロファイルをとるときは、プロファイルの標本を記録するのにRTSのタイマシグナルを直接使うことになる。</para>
96a515c @mkotha 6.6.1
authored
149
150 <para>通常、<option>-V</option>オプションを直接指定する必要はない。<option>-C</option>や<option>-i</option>オプションで短い間隔が指定されたときは、自動的にRTSタイマの分解能も調整されるからである。しかし、時間プロファイルの分解能を増したいときには、<option>-V</option>を設定することが必要になる。</para>
a2be81e @mkotha runtime_control.xml
authored
151
deedbde @mkotha 決定的 -> 決定論的
authored
152 <para>値0を使うと、RTSの時計は完全に無効にされ、それに依存したタイマも無効になる。コンテクストスイッチのタイマとプロファイルタイマである。それでもコンテクストスイッチは発生するが、決定論的に、かつ通常よりずっと高い頻度で発生するようになる。インターバルタイマを無効にすると、実行時の非決定性の源が一つ除かれるわけであり、デバッグに便利である。</para>
96a515c @mkotha 6.6.1
authored
153 </listitem>
154 </varlistentry>
155
156 <varlistentry>
157 <term><option>--install-signal-handlers=<replaceable>yes|no</replaceable></option>
158 <indexterm><primary><option>--install-signal-handlers</option></primary><secondary>RTS
159 option</secondary></indexterm></term>
160 <listitem>
a2be81e @mkotha runtime_control.xml
authored
161 <para>yes(デフォルト)なら、RTSはctrl-Cの類を捕捉するためのシグナルハンドラを設置する。このオプションは、HaskellコードをDLLとして使っていて、自分でシグナルハンドラを設定したいときに特に有用である。</para>
8aaad97 @mkotha update runtime_control
authored
162
163 <para><option>--install-signal-handlers=no</option>の場合でも、RTSの時間間隔タイマは変わらずに有効だということに注意。タイマシグナルはSIGVTALRMかSIGALRMで、RTSの設定とOSの能力によって異なる。このタイマシグナルを無効化するにはRTSオプション<literal>-V0</literal>を使う。(上記参照)</para>
96a515c @mkotha 6.6.1
authored
164 </listitem>
165 </varlistentry>
3324701 @mkotha update runtime_control.xml
authored
166
167 <varlistentry>
168 <term><option>-xm<replaceable>address</replaceable></option>
169 <indexterm><primary><option>-xm</option></primary><secondary>RTS
170 option</secondary></indexterm></term>
171 <listitem>
172 <para>
173 警告: このオプションはメモリ確保の問題を回避するためだけのものである。GHCiが「<literal>failed to mmap() memory below 2Gb</literal>」のようなメッセージを表示して失敗するのでない限り、使ってはいけない。あなたの機械でGHCiを動かすのにこのオプションを使う必要があるなら、バグとして報告してほしい。
174 </para>
a8a1a23 @mkotha update runtime_control.xml
authored
175
3324701 @mkotha update runtime_control.xml
authored
176 <para>
177 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>である。
178 </para>
179 </listitem>
180 </varlistentry>
96a515c @mkotha 6.6.1
authored
181 </variablelist>
97da4f5 @mkotha update runtime_control.xml
authored
182 </sect2>
96a515c @mkotha 6.6.1
authored
183
97da4f5 @mkotha update runtime_control.xml
authored
184 <sect2 id="rts-options-gc">
96a515c @mkotha 6.6.1
authored
185 <title>ガベッジコレクタを制御するためのRTSオプション</title>
186
187 <indexterm><primary>garbage collector</primary><secondary>options</secondary></indexterm>
188 <indexterm><primary>RTS options</primary><secondary>garbage collection</secondary></indexterm>
189
190 <para>ガベッジコレクタの挙動を精密に制御するために、いくつかのオプションが存在する。通常時には、これらはどれも使う必要がない(といいのだが)。それでも、最高の性能を得たいときのために、いくつかの箇所を調整することができるようになっている。</para>
191
192 <variablelist>
193
194 <varlistentry>
195 <term>
196 <option>-A</option><replaceable>size</replaceable>
197 <indexterm><primary><option>-A</option></primary><secondary>RTS option</secondary></indexterm>
198 <indexterm><primary>allocation area, size</primary></indexterm>
199 </term>
200 <listitem>
631d66d @mkotha update runtime_control.xml
authored
201 <para>&lsqb;デフォルト: 512k&rsqb;ガベッジコレクタが使う確保領域の大きさを設定する。確保領域(実際には世代0・段階0)は固定されており、大きさが変わることはない。(<option>-H</option>を使った場合はこの限りでない。下記参照)</para>
96a515c @mkotha 6.6.1
authored
202
203 <para>確保領域の大きさを増すことは、性能の向上につながるかもしれないし、そうでないかもしれない。(より大きい確保領域を使うと、キャッシュの振舞は悪化するが、ガベッジコレクションの回数は減り、昇格(promotion)も少なくなる)</para>
204
205 <para>世代数が一しかないとき(<option>-G1</option>)は、<option>-A</option>オプションは最小の確保領域を指定する。これは、実際の確保領域の大きさがヒープ中のデータの量によって変動するからである。(下記の<option>-F</option>を見よ)</para>
206 </listitem>
207 </varlistentry>
208
209 <varlistentry>
210 <term>
211 <option>-c</option>
212 <indexterm><primary><option>-c</option></primary><secondary>RTS option</secondary></indexterm>
213 <indexterm><primary>garbage collection</primary><secondary>compacting</secondary></indexterm>
214 <indexterm><primary>compacting garbage collection</primary></indexterm>
215 </term>
216 <listitem>
217 <para>もっとも古い世代を回収するときにコンパクト化アルゴリズムを使う。デフォルトでは最古世代はコピーアルゴリズムで回収されるが、このオプションが使われると、その場でコンパクト化されるようになる。コンパクト化アルゴリズムはコピーアルゴリズムより遅いが、相当量のメモリを節約できることがある。</para>
218
219 <para>ヒープの大きさ(これは<option>-H</option>オプションで変えられる)が一定のとき、コンパクト化を使うことでかえってGCのコストが削減できるということがあり得る(GCの回数が減らせるかもしれないので)。ヒープの大きさに対する生存データの比が高いとき(>30%、例えば)には特にその傾向が強い。</para>
220
221 <para>注意: 現在、コンパクト化は、<option>-G1</option>で単一世代が指定されているときには動作しない。</para>
222 </listitem>
223 </varlistentry>
224
225 <varlistentry>
226 <term><option>-c</option><replaceable>n</replaceable></term>
227
228 <listitem>
229 <para>&lsqb;デフォルト: 30&rsqb; 生存データがヒープの大きさの上限(<option>-M</option>オプションを見よ)の<replaceable>n</replaceable>%を超えたときに自動的にコンパクト化を有効にする。デフォルトではヒープの大きさに上限はないので、<option>-M</option><replaceable>size</replaceable>でヒープの大きさの上限が指定されない限り、このオプションには効果がない。</para>
230 </listitem>
231 </varlistentry>
232
233 <varlistentry>
234 <term>
235 <option>-F</option><replaceable>factor</replaceable>
236 <indexterm><primary><option>-F</option></primary><secondary>RTS option</secondary></indexterm>
237 <indexterm><primary>heap size, factor</primary></indexterm>
238 </term>
239 <listitem>
240
241 <para>&lsqb;デフォルト: 2&rsqb; このオプションは、古い世代のために予約されるメモリの量(two-space GCのときは確保領域の大きさ)を、生存データの量との比で指定する。例えば、最後に最も古い世代が回収されたときに生存データが2Mあったとすると、デフォルトでは、4Mにまでなるのを待ってから再び回収する。</para>
242
243 <para>これについてはデフォルトがうまく働いているようである。潤沢なメモリがあるなら、通常、<option>-F</option><replaceable>factor</replaceable>を増やすよりも<option>-H</option><replaceable>size</replaceable>を使った方が良い。</para>
244
245 <para><option>-F</option>の値は、ヒープの最大の大きさ(<option>-M</option><replaceable>size</replaceable>で設定する)に近づいたときには、ガベッジコレクタによって自動的に減らされる。</para>
246 </listitem>
247 </varlistentry>
248
249 <varlistentry>
250 <term>
251 <option>-G</option><replaceable>generations</replaceable>
252 <indexterm><primary><option>-G</option></primary><secondary>RTS option</secondary></indexterm>
253 <indexterm><primary>generations, number of</primary></indexterm>
254 </term>
255 <listitem>
256 <para>&lsqb;デフォルト: 2&rsqb; ガベッジコレクタが使う世代の数を設定する。デフォルトの2は良い選択のようだが、ガベッジコレクタは任意の数の世代をサポートしている。プログラムが<emphasis>長い</emphasis>時間に渡って実行されるのでない限り、4程度より大きな値はおそらく良くない。最古の世代が一回も回収されないということになるからである。</para>
257
258 <para><option>+RTS -G1</option>で一世代を指定すると、当然、単純な2-spaceコレクタになる。2-spaceコレクタでは、<option>-A</option>オプション(上記参照)が指定するのは確保領域の<emphasis>最小の</emphasis>大きさである。これは、ヒープ中の生存データの量が増えるに従って確保領域も拡大されるからである。複数世代のコレクタでは確保領域の大きさは固定である。(<option>-H</option>オプションを使う場合はこの限りでない。下を見よ)</para>
259 </listitem>
260 </varlistentry>
261
262 <varlistentry>
5913a40 @mkotha update runtime_control.xml
authored
263 <term>
631d66d @mkotha update runtime_control.xml
authored
264 <option>-qg<optional><replaceable>gen</replaceable></optional></option>
265 <indexterm><primary><option>-qg</option><secondary>RTS
266 option</secondary></primary></indexterm>
5913a40 @mkotha update runtime_control.xml
authored
267 </term>
268 <listitem>
631d66d @mkotha update runtime_control.xml
authored
269 <para>&lsqb;GHC 6.12.1から&rsqb; &lsqb;デフォルト: 0&rsqb;
270 世代<replaceable>gen</replaceable>とそれより上の世代において、並列GCを使う。<replaceable>gen</replaceable>を省略すると、並列GCは完全に無効になり、逐次GCに戻る。</para>
a8a1a23 @mkotha update runtime_control.xml
authored
271
631d66d @mkotha update runtime_control.xml
authored
272 <para>デフォルトの並列GC設定は、通常、並列プログラム(<literal>par</literal>やStrategyや複数のスレッドを使うもの)に適している。しかし、単一スレッドの逐次的なプログラムに関しても、並列GCを有効にする恩恵があることがある。特に、プログラムが大量のヒープデータを持ち、実行時間のかなりの部分をGCが占めるような場合である。逐次的なプログラムにおいて並列GCを使うには、適切な<literal>-N</literal>オプションを使って並列ランタイムを有効にすればよい。加えて、<literal>-qg1</literal>を使って並列GCを古い世代のみに制限すると良いかもしれない。</para>
273 </listitem>
a8a1a23 @mkotha update runtime_control.xml
authored
274 </varlistentry>
5913a40 @mkotha update runtime_control.xml
authored
275
631d66d @mkotha update runtime_control.xml
authored
276 <varlistentry>
277 <term>
278 <option>-qb<optional><replaceable>gen</replaceable></optional></option>
279 <indexterm><primary><option>-qb</option><secondary>RTS
280 option</secondary></primary></indexterm>
281 </term>
282 <listitem>
283 <para>
284 &lsqb;GHC 6.12.1から&rsqb; &lsqb;デフォルト: 1&rsqb;
285 並列GCにおいて、世代<replaceable>gen</replaceable>とそれより上の世代で負荷分散を使う。<replaceable>gen</replaceable>を省略すると、負荷分散を完全に無効にする。</para>
a8a1a23 @mkotha update runtime_control.xml
authored
286
631d66d @mkotha update runtime_control.xml
authored
287 <para>
288 負荷分散とは、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.)。実際、並列プログラムでは、<literal>-qb</literal>で負荷分散を完全に無効にした方が良いこともある。
289 </para>
5913a40 @mkotha update runtime_control.xml
authored
290 </listitem>
291 </varlistentry>
292
293 <varlistentry>
96a515c @mkotha 6.6.1
authored
294 <term>
294c679 @mkotha update runtime_control.xml
authored
295 <option>-H</option><optional><replaceable>size</replaceable></optional>
96a515c @mkotha 6.6.1
authored
296 <indexterm><primary><option>-H</option></primary><secondary>RTS option</secondary></indexterm>
297 <indexterm><primary>heap size, suggested</primary></indexterm>
298 </term>
299 <listitem>
294c679 @mkotha update runtime_control.xml
authored
300 <para>&lsqb;デフォルト: 0&rsqb; このオプションはガベッジコレクタに「推奨されるヒープの大きさ」を提示する。<option>-H<replaceable>size</replaceable></option>は可変の<option>-A</option>オプションだと思うと良い。これは次のように述べる。私は少なくとも<replaceable>size</replaceable>バイトを使いたいので、残ったものは全部<option>-A</option>を増やすのに使え。</para>
301
302 <para>このオプションはヒープの大きさに<emphasis>制限</emphasis>を加えるものではない。ヒープは通常同様に与えられた大きさを超えて成長し得る。</para>
96a515c @mkotha 6.6.1
authored
303
294c679 @mkotha update runtime_control.xml
authored
304 <para><replaceable>size</replaceable>を省略すると、ガベッジコレクタは前回のGC時におけるヒープの大きさを<replaceable>size</replaceable>として取る。これは、プログラムの全体的なメモリ要求を増やさずに、より大きな<option>-A</option>の値を許す効果がある。長生きするデータを大量に作成するプログラムなど、デフォルトの小さな<option>-A</option>の値が適していないときに使える。</para>
305 </listitem>
96a515c @mkotha 6.6.1
authored
306 </varlistentry>
307
308 <varlistentry>
309 <term>
310 <option>-I</option><replaceable>seconds</replaceable>
311 <indexterm><primary><option>-I</option></primary>
312 <secondary>RTS option</secondary>
313 </indexterm>
314 <indexterm><primary>idle GC</primary>
315 </indexterm>
316 </term>
317 <listitem>
a45e658 @mkotha メジャーGC -> 大GC
authored
318 <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>
96a515c @mkotha 6.6.1
authored
319
320 <para>対話的アプリケーションでは、待機時GCが多くの場合有効である。これは、Haskellの計算が起こっていない待機状態の間に、終了子を走らせたりデッドロックしたスレッドを感知したりできるからである。さらに、アプリケーションが忙しいときにGCが起こる可能性が減るので、反応性が向上するかもしれない。しかし、ヒープ中の生存データの割合があまりに高いと、待機時GCが重大な遅れを引き起こすことがある。また、時間間隔が短すぎると、対話的な反応性に悪影響を及ぼすことになるかもしれない。</para>
321
322 <para>これは実験的な機能である。問題が起きたり、改善案があるなら、知らせてほしい。</para>
323 </listitem>
324 </varlistentry>
325
326 <varlistentry>
327 <term>
a8a1a23 @mkotha update runtime_control.xml
authored
328 <option>-ki</option><replaceable>size</replaceable>
96a515c @mkotha 6.6.1
authored
329 <indexterm><primary><option>-k</option></primary><secondary>RTS option</secondary></indexterm>
a8a1a23 @mkotha update runtime_control.xml
authored
330 <indexterm><primary>stack, initial size</primary></indexterm>
96a515c @mkotha 6.6.1
authored
331 </term>
332 <listitem>
a8a1a23 @mkotha update runtime_control.xml
authored
333 <para>&lsqb;デフォルト: 1k&rsqb; スレッドの初期スタックサイズを設定する。(注意: このフラグは単に<option>-k</option>であったが、GHC 7.2.1で<option>-ki</option>に改名された。古い名前も後方互換性のためにまだ受け付けられるが、将来の版では削除されるかもしれない)</para>
96a515c @mkotha 6.6.1
authored
334
a8a1a23 @mkotha update runtime_control.xml
authored
335 <para>スレッドのスタック(主スレッドのスタックも含めて)はヒープ上にとられる。スタックが成長するにつれ、必要に応じて新しいチャンクが追加される。スタックが再び収縮する場合、これらの追加されたスタックチャンクはGCによって回収される。デフォルトの初期スタックサイズは意図的に小さくしてある。これは、スレッド生成の時間的空間的オーバーヘッドを最小にとどめることで、ごく小さい仕事のためにスレッドを生成することを現実的にするためである。</para>
336 </listitem>
337 </varlistentry>
338
339 <varlistentry>
340 <term>
341 <option>-kc</option><replaceable>size</replaceable>
342 <indexterm><primary><option>-kc</option></primary><secondary>RTS
343 option</secondary></indexterm>
344 <indexterm><primary>stack</primary><secondary>chunk size</secondary></indexterm>
345 </term>
346 <listitem>
347 <para>
348 &lsqb;デフォルト: 32k&rsqb; &ldquo;スタックチャンク&rdquo;の大きさを設定する。スレッドの現行スタックがオーバーフローしたとき、<option>-K</option>で設定された上限に達するまでは、新しいスタックチャンクが作成されてスレッドのスタックに加えられる。
349 </para>
350
351 <para>チャンクサイズを小さくすることの利点はこうである。ガベッジコレクタは、チャンクが前回のGC以降変更されていないことが分かると、それらを走査しないで済ませることができる。よって、チャンクサイズを減らすと、ガベッジコレクタがより多くのスタックを未変更と知ることができるので、GCのオーバーヘッドを削ることができるかもしれない。一方で、スタックチャンクを小さくしすぎると、チャンク間のオーバーフロー/アンダーフローが増えるので、オーバーヘッドが増える。32kというデフォルト設定は、大部分の場合においてそれなりな妥協点のようである。</para>
352 </listitem>
353 </varlistentry>
354
355 <varlistentry>
356 <term>
357 <option>-kb</option><replaceable>size</replaceable>
358 <indexterm><primary><option>-kc</option></primary><secondary>RTS
359 option</secondary></indexterm>
360 <indexterm><primary>stack</primary><secondary>chunk buffer size</secondary></indexterm>
361 </term>
362 <listitem>
363 <para>
364 &lsqb;デフォルト: 1k&rsqb; スタックチャンクバッファの大きさを設定する。スタックチャンクがオーバーフローして新しいチャンクが作成される時、前のスタックのデータの一部が新しいチャンクに移動される。これは、即座にアンダーフローが発生し、境界でオーバーフロー/アンダーフローが繰り返されるのを防ぐためである。ここで動かされるスタックの量が<option>-kb</option>によって設定される。</para>
365 <para>空間を無駄にするのを防ぐために、この値は典型的にはスタックチャンクの大きさ(<option>-kc</option>)の10%未満に設定されるべきである。スタックチャンクの連鎖の中で、それぞれのチャンクがこの大きさの未使用の空間を隙間として持つことになるからである。</para>
366 </listitem>
96a515c @mkotha 6.6.1
authored
367 </varlistentry>
368
369 <varlistentry>
370 <term>
371 <option>-K</option><replaceable>size</replaceable>
372 <indexterm><primary><option>-K</option></primary><secondary>RTS option</secondary></indexterm>
373 <indexterm><primary>stack, maximum size</primary></indexterm>
374 </term>
375 <listitem>
a8a1a23 @mkotha update runtime_control.xml
authored
376 <para>&lsqb;デフォルト: 8M&rsqb; 個々のスレッドの最大スタックサイズを<replaceable>size</replaceable>に設定する。スレッドがこの制限を超えようとした場合、<literal>StackOverflow</literal>例外が送られる。</para>
377 <para>このオプションは主に、プログラムが無限ループに陥ったときに利用可能なメモリを使い果たすことがないようするために存在している。</para>
96a515c @mkotha 6.6.1
authored
378 </listitem>
379 </varlistentry>
380
381 <varlistentry>
382 <term>
383 <option>-m</option><replaceable>n</replaceable>
384 <indexterm><primary><option>-m</option></primary><secondary>RTS option</secondary></indexterm>
385 <indexterm><primary>heap, minimum free</primary></indexterm>
386 </term>
387 <listitem>
388 <para>ヒープのうち確保可能な(訳注: 未使用な)部分の最小%を指定する。デフォルトは3%である。</para>
389 </listitem>
390 </varlistentry>
391
392 <varlistentry>
393 <term>
394 <option>-M</option><replaceable>size</replaceable>
395 <indexterm><primary><option>-M</option></primary><secondary>RTS option</secondary></indexterm>
396 <indexterm><primary>heap size, maximum</primary></indexterm>
397 </term>
398 <listitem>
399 <para>&lsqb;デフォルト: 無制限&rsqb; 最大ヒープサイズを<replaceable>size</replaceable>に設定する。ヒープは通常プログラムのメモリ要求に従って伸長したり収縮したりする。このオプションの唯一の存在理由は、ヒープが際限なく膨張してスワップ空間を使い果たす(結果として、少なくともプログラムが即座にOSに殺されることになる)のを防ぐことである。</para>
400
401 <para>ヒープの最大サイズは他のGCパラメタにも影響する。ヒープ中の生存データが最大ヒープサイズに対して一定の割合を越えると、最古の世代に対して自動的にコンパクト化回収が有効になり、最大ヒープサイズを越えることがないように<option>-F</option>パラメタが減少せしめられる。</para>
402 </listitem>
403 </varlistentry>
404
405 <varlistentry>
5913a40 @mkotha update runtime_control.xml
authored
406 <term>
294c679 @mkotha update runtime_control.xml
authored
407 <option>-T</option>
408 <indexterm><primary><option>-T</option></primary><secondary>RTS option</secondary></indexterm>
409 </term>
410 <term>
5913a40 @mkotha update runtime_control.xml
authored
411 <option>-t</option><optional><replaceable>file</replaceable></optional>
412 <indexterm><primary><option>-t</option></primary><secondary>RTS option</secondary></indexterm>
413 </term>
96a515c @mkotha 6.6.1
authored
414 <term>
5913a40 @mkotha update runtime_control.xml
authored
415 <option>-s</option><optional><replaceable>file</replaceable></optional>
96a515c @mkotha 6.6.1
authored
416 <indexterm><primary><option>-s</option></primary><secondary>RTS option</secondary></indexterm>
417 </term>
418 <term>
5913a40 @mkotha update runtime_control.xml
authored
419 <option>-S</option><optional><replaceable>file</replaceable></optional>
96a515c @mkotha 6.6.1
authored
420 <indexterm><primary><option>-S</option></primary><secondary>RTS option</secondary></indexterm>
421 </term>
3324701 @mkotha update runtime_control.xml
authored
422 <term>
423 <option>--machine-readable</option>
424 <indexterm><primary><option>--machine-readable</option></primary><secondary>RTS option</secondary></indexterm>
425 </term>
96a515c @mkotha 6.6.1
authored
426 <listitem>
294c679 @mkotha update runtime_control.xml
authored
427 <para>これらのオプションはランタイムシステムの統計情報を生成する。プログラムを実行するのに使った時間、ガベッジコレクタで使った時間、確保されたメモリの量、ヒープの最大サイズ、といったものである。この三種類のオプションは、詳細さの度合いが異なる。<option>-T</option>はデータを収集するものの出力を生成しない。<option>-t</option>はGHCの<option>-Rghc-timing</option>オプションと同じ形式で一行だけの出力を生成する。<option>-s</option>はプログラムの最後にもっと詳細なまとめを生成しする。<option>-S</option>はさらにガベッジコレクション一回一回について情報を生成する。</para>
5913a40 @mkotha update runtime_control.xml
authored
428
429 <para>出力内容は<replaceable>file</replaceable>に置かれる。<replaceable>file</replaceable>が省略された場合、出力は<constant>stderr</constant>に送られる。</para>
430
431 <para>
294c679 @mkotha update runtime_control.xml
authored
432 <literal>-T</literal>フラグを使った場合、統計にアクセスするには<ulink url="&libraryBaseLocation;/GHC-Stats.html">GHC.Stats</ulink>を使う。
433 </para>
434
435 <para>
5913a40 @mkotha update runtime_control.xml
authored
436 <literal>-t</literal>フラグを使った場合、プログラムの終了時、次のようなものを見ることになるだろう。
437 </para>
438
439 <programlisting>
440 &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;
441 </programlisting>
442
443 <para>
444 これは以下のことを伝えている。
445 </para>
446
447 <itemizedlist>
448 <listitem>
631d66d @mkotha update runtime_control.xml
authored
449 <para>この実行全体にわたってプログラムによって確保されたバイトの総量。
5913a40 @mkotha update runtime_control.xml
authored
450 </para>
451 </listitem>
452 <listitem>
631d66d @mkotha update runtime_control.xml
authored
453 <para>実行されたガベッジコレクションの合計回数。
5913a40 @mkotha update runtime_control.xml
authored
454 </para>
455 </listitem>
456 <listitem>
6ca539d @mkotha small fixes
authored
457 <para>「内容量(residency)」の平均値および最大値。内容量とは、生存しているデータの量をバイト単位で表したものである。ランタイムが生存データの量を決定できるのは大GCの間だけなので、標本の数が大GCの数に対応する(これは比較的小さい数になる)。プログラムのヒープの性質についてのよりよい描像を得るためには、<option>-hT</option>を使うこと(<xref linkend="rts-profiling"/>)。</para>
5913a40 @mkotha update runtime_control.xml
authored
458 </listitem>
459 <listitem>
460 <para>RTSがOSから確保したメモリの最大値。
461 </para>
462 </listitem>
463 <listitem>
464 <para>ランタイムシステムの初期化(INIT)、プログラム自体の実行(MUT, the mutator)、ガベッジコレクション(GC)それぞれのCPU時間と経過した実時間。
465 </para>
466 </listitem>
467 </itemizedlist>
468
3324701 @mkotha update runtime_control.xml
authored
469 <para><literal>-t --machine-readable</literal>とすれば、よりfuture-proofな、機械可読の形式でこれを得ることができる。
470 </para>
471
472 <programlisting>
473 [("bytes allocated", "36169392")
474 ,("num_GCs", "69")
475 ,("average_bytes_used", "603392")
476 ,("max_bytes_used", "1065272")
477 ,("num_byte_usage_samples", "2")
478 ,("peak_megabytes_allocated", "3")
479 ,("init_cpu_seconds", "0.00")
480 ,("init_wall_seconds", "0.00")
481 ,("mutator_cpu_seconds", "0.02")
482 ,("mutator_wall_seconds", "0.02")
483 ,("GC_cpu_seconds", "0.07")
484 ,("GC_wall_seconds", "0.07")
485 ]
486 </programlisting>
487
5913a40 @mkotha update runtime_control.xml
authored
488 <para><literal>-s</literal>フラグを使った場合、プログラムの終了時に次のようなものを目にすることになるだろう。(細部が厳密にどうなるかは使っているRTSの種類によって異なる。例えば、プロファイルのデータを見られるのはRTSがプロファイル用にコンパイルされている場合だけである)
489 </para>
490
491 <programlisting>
492 36,169,392 bytes allocated in the heap
493 4,057,632 bytes copied during GC
494 1,065,272 bytes maximum residency (2 sample(s))
495 54,312 bytes maximum slop
496 3 MB total memory in use (0 MB lost due to fragmentation)
497
498 Generation 0: 67 collections, 0 parallel, 0.04s, 0.03s elapsed
499 Generation 1: 2 collections, 0 parallel, 0.03s, 0.04s elapsed
500
631d66d @mkotha update runtime_control.xml
authored
501 SPARKS: 359207 (557 converted, 149591 pruned)
502
5913a40 @mkotha update runtime_control.xml
authored
503 INIT time 0.00s ( 0.00s elapsed)
504 MUT time 0.01s ( 0.02s elapsed)
505 GC time 0.07s ( 0.07s elapsed)
506 EXIT time 0.00s ( 0.00s elapsed)
507 Total time 0.08s ( 0.09s elapsed)
508
509 %GC time 89.5% (75.3% elapsed)
510
511 Alloc rate 4,520,608,923 bytes per MUT second
512
513 Productivity 10.5% of total user, 9.1% of total elapsed
514 </programlisting>
515
516 <itemizedlist>
517 <listitem>
631d66d @mkotha update runtime_control.xml
authored
518 <para>"bytes allocated in the heap"はこの実行全体にわたってプログラムによって確保されたバイトの総量である。
5913a40 @mkotha update runtime_control.xml
authored
519 </para>
520 </listitem>
521 <listitem>
631d66d @mkotha update runtime_control.xml
authored
522 <para>GHCはデフォルトではコピーGCを使っている。"bytes copied during GC"はガベッジコレクション中にコピーしなければならなかったバイト数を示す。
5913a40 @mkotha update runtime_control.xml
authored
523 </para>
524 </listitem>
525 <listitem>
526 <para>プログラムによって実際に使われた空間の最大値が"bytes maximum residency"の数値である。これは大GCのときにしか検査されないから、単なる近似値である。標本(sample)の数によって何回検査されたかが分かる。
527 </para>
528 </listitem>
529 <listitem>
631d66d @mkotha update runtime_control.xml
authored
530 <para>"bytes maximum slop"は、GHCがメモリをブロック単位で確保することによって無駄になった空間の最大値である。 slopとはブロックの無駄になった後方部分である。これを制御する方法はない。どれだけのメモリがこうやって失われたか見たいだけである。
5913a40 @mkotha update runtime_control.xml
authored
531 </para>
532 </listitem>
533 <listitem>
534 <para>"total memory in use"はRTSがOSから確保したメモリの最大値である。
535 </para>
536 </listitem>
537 <listitem>
631d66d @mkotha update runtime_control.xml
authored
538 <para>次に、行われたガベッジコレクションについての情報がある。それぞれの世代について、ガベッジコレクションが何回行われたか、そのうち何回が並列に行われたか、その世代をGCするために使われたCPU時間の合計、その世代をGCするために経過した実時間の合計、が示されている。
5913a40 @mkotha update runtime_control.xml
authored
539 </para>
540 </listitem>
541 <listitem>
ffd6d0e @mkotha spark is "スパーク"
authored
542 <para>統計情報<literal>SPARKS</literal>は、プログラム中での<literal>Control.Parallel.par</literal>やこれに関連した機能の利用に関係する。個々のスパーク(spark)は<literal>par</literal>の一回の呼び出しを表す。スパークが「変換される(converted)」とは、それが並列に実行されることである。スパークが「刈り取られる(pruned)」とは、それが既に評価済みであることが分かり、ガベッジコレクタによってプールから捨てられることである。実行が終わると残っているスパークはすべて捨てられるので、「変換された」ものと「刈り取られた」ものを足しても合計に見たないことがあり得る。</para>
631d66d @mkotha update runtime_control.xml
authored
543 </listitem>
544 <listitem>
5913a40 @mkotha update runtime_control.xml
authored
545 <para>次に、CPU時間と経過した実時間を、そのときランタイムシステムが何をしていたかによって項目分けしたものがある。INITはランタイムシステムの初期化である。MUTはmutator time、すなわち実際にあなたのコードを走らせるのに掛かった時間である。GCはガベッジコレクションを行うのに掛かった時間である。RPは維持原因プロファイルを行うのに掛かった時間である。PROFはその他のプロファイルを行うのに掛かった時間である。EXITはランタイムシステムの終了処理時間である。最後に、Totalは、もちろん、合計である。
546 </para>
547 <para>%GCは、GCが全体の何%を占めるかを表している。"Alloc rate"は"bytes allocated in the heap"をMUT CPU時間で割ったものである。"Productivity"はCPU時間および経過した実時間の合計の何%がmutator(MUT)で消費されたかである。
548 </para>
549 </listitem>
550 </itemizedlist>
551
552 <para><literal>-S</literal>フラグは、<literal>-s</literal>フラグと同じものを出力するのに加え、GCが発生するたびにそれについての情報を表示する。
553 </para>
554
555 <programlisting>
556 Alloc Copied Live GC GC TOT TOT Page Flts
557 bytes bytes bytes user elap user elap
558 528496 47728 141512 0.01 0.02 0.02 0.02 0 0 (Gen: 1)
559 [...]
560 524944 175944 1726384 0.00 0.00 0.08 0.11 0 0 (Gen: 0)
561 </programlisting>
562
563 <para>個々のガベッジコレクションについて、表示するのは以下のものである。
564 </para>
565
566 <itemizedlist>
567 <listitem>
568 <para>このGCで確保したバイト数。
569 </para>
570 </listitem>
571 <listitem>
572 <para>このGCでコピーしたバイト数。
573 </para>
574 </listitem>
575 <listitem>
576 <para>現在生存しているバイト数。
577 </para>
578 </listitem>
579 <listitem>
580 <para>このGCに掛かった時間(CPU時間および経過した実時間)。
581 </para>
582 </listitem>
583 <listitem>
584 <para>これまでにプログラムが実行された時間(CPU時間および経過した実時間)。
585 </para>
586 </listitem>
587 <listitem>
588 <para>このGCで起こったページフォールトの個数。
589 </para>
590 </listitem>
591 <listitem>
592 <para>直近のGCの終了以降に起こったページフォールトの個数。
593 </para>
594 </listitem>
595 <listitem>
596 <para>GC対象の世代。
597 </para>
598 </listitem>
599 </itemizedlist>
a8a1a23 @mkotha update runtime_control.xml
authored
600
96a515c @mkotha 6.6.1
authored
601 </listitem>
602 </varlistentry>
603 </variablelist>
604
97da4f5 @mkotha update runtime_control.xml
authored
605 </sect2>
96a515c @mkotha 6.6.1
authored
606
97da4f5 @mkotha update runtime_control.xml
authored
607 <sect2>
5913a40 @mkotha update runtime_control.xml
authored
608 <title>並行性と並列性に関するRTSオプション</title>
609
610 <para>並行実行に関わるRTSオプションは<xref linkend="using-concurrent"/>で、並列計算に関わる物は<xref linkend="parallel-options"/>で、それぞれ説明されている。</para>
97da4f5 @mkotha update runtime_control.xml
authored
611 </sect2>
5913a40 @mkotha update runtime_control.xml
authored
612
97da4f5 @mkotha update runtime_control.xml
authored
613 <sect2 id="rts-profiling">
5913a40 @mkotha update runtime_control.xml
authored
614 <title>プロファイルに関するRTSオプション</title>
96a515c @mkotha 6.6.1
authored
615
5913a40 @mkotha update runtime_control.xml
authored
616 <para>プロファイルについてのランタイムオプションの大部分は、プログラムをプロファイル用にコンパイルした場合にのみ利用可能である。(<xref linkend="prof-compiler-options" />を見よ、またランタイムオプションについては<xref linkend="rts-options-heap-prof" />を見よ)。ただし、通常の非プロファイル版実行ファイルでも利用できるプロファイルオプションがただ一つ存在する。</para>
617
618 <variablelist>
619 <varlistentry>
620 <term>
621 <option>-hT</option>
622 <indexterm><primary><option>-hT</option></primary><secondary>RTS
623 option</secondary></indexterm>
624 </term>
625 <listitem>
294c679 @mkotha update runtime_control.xml
authored
626 <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>
5913a40 @mkotha update runtime_control.xml
authored
627 </listitem>
628 </varlistentry>
629 </variablelist>
97da4f5 @mkotha update runtime_control.xml
authored
630 </sect2>
96a515c @mkotha 6.6.1
authored
631
97da4f5 @mkotha update runtime_control.xml
authored
632 <sect2 id="rts-eventlog">
631d66d @mkotha update runtime_control.xml
authored
633 <title>追跡情報を得る</title>
634
635 <indexterm><primary>tracing</primary></indexterm>
636 <indexterm><primary>events</primary></indexterm>
637 <indexterm><primary>eventlog files</primary></indexterm>
638
639 <para>プログラムが<option>-eventlog</option>オプション(<xref linkend="options-linker"/>)付きでリンクされている場合、実行時のイベントを二通りの方法で記録することができる。
640 </para>
641
642 <itemizedlist>
643 <listitem>
294c679 @mkotha update runtime_control.xml
authored
644 <para>バイナリ形式でファイルに記録し、後でいろいろなツールによって分析できるようにする。<ulink url="http://www.haskell.org/haskellwiki/ThreadScope">ThreadScope</ulink><indexterm><primary>ThreadScope</primary></indexterm>はそのようなツールの一つであり、イベント記録を解釈して、プログラムの視覚的な並列実行プロファイルを作成する。
631d66d @mkotha update runtime_control.xml
authored
645 </para>
646 </listitem>
647 <listitem>
648 <para>テキストとして標準出力に出力し、デバッグに供する。
649 </para>
650 </listitem>
651 </itemizedlist>
652
653 <variablelist>
654 <varlistentry>
655 <term>
f45ead8 @mkotha update runtime_control
authored
656 <option>-l<optional><replaceable>flags</replaceable></optional></option>
631d66d @mkotha update runtime_control.xml
authored
657 <indexterm><primary><option>-l</option></primary><secondary>RTS option</secondary></indexterm>
658 </term>
659 <listitem>
294c679 @mkotha update runtime_control.xml
authored
660 <para>イベントをバイナリ形式で<filename><replaceable>program</replaceable>.eventlog</filename>というファイルに記録する。<replaceable>flags</replaceable>が指定されなかった場合、ThreadScopeなどのツールに適したデフォルトのイベント集合を記録する。
661 </para>
662
663 <para>特殊な利用状況では、どのイベントを含むかをもっと細かく制御したいかもしれない。<replaceable>flags</replaceable>は、どの種類のイベントを記録するかを意味する文字を零個以上並べたものである。現在、有効/無効にできるイベントの種類は四つである。
664 <simplelist>
665 <member>
666 <option>s</option> &#8212; スケジューラのイベント、スレッドの作成、開始/停止のイベントを含む
667 </member>
668 <member>
669 <option>g</option> &#8212; GCのイベント、GCの開始/停止を含む
670 </member>
671 <member>
672 <option>p</option> &#8212; 並列スパーク(標本抽出)
673 </member>
674 <member>
675 <option>f</option> &#8212; 並列スパーク(完全に正確)
676 </member>
677 </simplelist>
678 </para>
679
680 <para>スパークのイベントには二つのモードがある。標本抽出と完全に正確である。個々のスパークの生涯にはいろいろなイベントがある。通常は作成と実行だけだが、もっと例外的なものもあり得る。標本抽出モードでは、短い間隔で、それぞれのスパークイベントの数が標本抽出される。完全に正確モードでは、全てのスパークが個々に記録される。後者の方が実行時のオーバーヘッドが高く、デフォルトでは有効になっていない。
631d66d @mkotha update runtime_control.xml
authored
681 </para>
682
294c679 @mkotha update runtime_control.xml
authored
683 <para>初期状態で有効なイベントの種類は「s」「g」「p」である。これに加えて、特定の種類を無効にしたり、全ての種類を一度に有効/無効にしたりできる。
684 <simplelist>
685 <member>
686 <option>a</option> &#8212; 上で挙げた全ての種類のイベントを有効にする
687 </member>
688 <member>
689 <option>-<replaceable>x</replaceable></option> &#8212; 与えられた種類のイベントを無効にする。上で挙げた種類をどれか指定するか、<option>-a</option>なら全てのイベントになる。
690 </member>
691 </simplelist>
692 例えば、<option>-l-ag</option>はGCイベント(<option>g</option>)を除いて全てのイベント(<option>-a</option>)を無効にする。</para>
693
694 <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>というツールが使える。
631d66d @mkotha update runtime_control.xml
authored
695 </para>
696 </listitem>
697 </varlistentry>
698
699 <varlistentry>
700 <term>
f45ead8 @mkotha update runtime_control
authored
701 <option>-v</option><optional><replaceable>flags</replaceable></optional>
631d66d @mkotha update runtime_control.xml
authored
702 <indexterm><primary><option>-v</option></primary><secondary>RTS option</secondary></indexterm>
703 </term>
704 <listitem>
f45ead8 @mkotha update runtime_control
authored
705 <para>イベントを、<literal>.eventlog</literal>ファイルにではなく、テキストとして標準出力に記録する。<replaceable>flags</replaceable>は<option>-l</option>の場合と同じであるが、追加のオプション<literal>t</literal>があって、これは、表示される個々のイベントの前にタイムスタンプを表示することを示す。(バイナリの<literal>.eventlog</literal>ファイルでは、全てのイベントは自動的にタイムスタンプと結び付けられる)
631d66d @mkotha update runtime_control.xml
authored
706 </para>
707 </listitem>
708 </varlistentry>
709
710 </variablelist>
711
712 <para>この追跡フレームワークで記録されるイベントを、デバッグオプション<option>-D<replaceable>x</replaceable></option>も生成する。デフォルトではこれらのイベントはテキストとして標準出力にダンプされる(<option>-D<replaceable>x</replaceable></option>によって<option>-v</option>が有効になる)が、<option>-l</option>を使うことでバイナリのイベント記録ファイルに保存することもできる。
713 </para>
97da4f5 @mkotha update runtime_control.xml
authored
714 </sect2>
631d66d @mkotha update runtime_control.xml
authored
715
97da4f5 @mkotha update runtime_control.xml
authored
716 <sect2 id="rts-options-debugging">
96a515c @mkotha 6.6.1
authored
717 <title>ハックする者、デバッグする者、及び好奇心過剰な魂のためのRTSオプション</title>
718
719 <indexterm><primary>RTS options, hacking/debugging</primary></indexterm>
720
721 <para>これらのRTSオプションは、(a)&nbsp;GHCのバグを回避するために、(b)&nbsp;「何が実際に起きているか」を知るために、(c)&nbsp;なんとなくそうしたいから、という理由で使うことができる。素人にはおすすめできない。</para>
722
723 <variablelist>
724
725 <varlistentry>
726 <term>
727 <option>-B</option>
728 <indexterm><primary><option>-B</option></primary><secondary>RTS option</secondary></indexterm>
729 </term>
730 <listitem>
a45e658 @mkotha メジャーGC -> 大GC
authored
731 <para>GC(大)が始まるたびにベルを鳴らす。</para>
96a515c @mkotha 6.6.1
authored
732
733 <para>実に奇妙なことだが、実際にこのオプションを使う人々が存在する。ダラム(イギリス)にいる我々の仲間、ポール・キャラハンは次のように書いている。「ここには色んな目的のためにこれを使う人々がいる&mdash;これは本当だ&mdash;例えば、コード/機械が何かをしているということを確認したり、無限ループを発見したり、最近付け加えたコードのコストを量ったりだ。ある種の人々はビープのパターンからプログラムがどの段階にいるかを聞き分けることさえできる。しかし最も重要な使いかたは、同じオフィスにいる他の人を鬱陶しがらせることである&hellip;」</para>
734 </listitem>
735 </varlistentry>
736
737 <varlistentry>
738 <term>
631d66d @mkotha update runtime_control.xml
authored
739 <option>-D</option><replaceable>x</replaceable>
96a515c @mkotha 6.6.1
authored
740 <indexterm><primary>-D</primary><secondary>RTS option</secondary></indexterm>
741 </term>
742 <listitem>
631d66d @mkotha update runtime_control.xml
authored
743 <para>RTSのデバッグフラグ。RTSが<option>DEBUG</option>オプション付きでリンクされているときのみ使える。RTSのいろいろな部分について、デバッグ出力や追加の実行時の正気チェックを有効にするための<replaceable>x</replaceable>の値が用意されている。例えば、<literal>+RTS -Ds -RTS</literal>とするとスケジューラのデバッグ出力が有効になる。どういうデバッグフラグがサポートされているかを知るには<literal>+RTS&nbsp;-?</literal>が使える。
744 </para>
745
746 <para><option>-l</option>オプションを追加すると、デバッグ出力が標準出力でなくバイナリのイベント記録ファイルに送られるようになる。デバッグ追跡にかかるオーバーヘッドを減らしたいときに便利かもしれない。
747 </para>
96a515c @mkotha 6.6.1
authored
748 </listitem>
749 </varlistentry>
750
751 <varlistentry>
752 <term>
753 <option>-r</option><replaceable>file</replaceable>
754 <indexterm><primary><option>-r</option></primary><secondary>RTS option</secondary></indexterm>
755 <indexterm><primary>ticky ticky profiling</primary></indexterm>
756 <indexterm><primary>profiling</primary><secondary>ticky ticky</secondary></indexterm>
757 </term>
758 <listitem>
631d66d @mkotha update runtime_control.xml
authored
759 <para>プログラムの実行終了時に「ticky-ticky」統計情報を生成する(プログラムが<option>-debug</option>オプション付きでリンクされている場合にのみ利用可能)。<replaceable>file</replaceable>の扱いは上にある<option>-S</option>RTSオプションの場合と同じである。</para>
96a515c @mkotha 6.6.1
authored
760
631d66d @mkotha update runtime_control.xml
authored
761 <para>ticky-tickyプロファイルについての更なる情報は、<xref linkend="ticky-ticky"/>を見よ。</para>
96a515c @mkotha 6.6.1
authored
762 </listitem>
763 </varlistentry>
764
765 <varlistentry>
766 <term>
767 <option>-xc</option>
768 <indexterm><primary><option>-xc</option></primary><secondary>RTS option</secondary></indexterm>
769 </term>
770 <listitem>
294c679 @mkotha update runtime_control.xml
authored
771 <para>(プログラムがプロファイルを取れるようにコンパイルしてある場合のみ利用可能) プログラム中で例外が発生したとき、このオプションが指定されていると、スタックトレースが<literal>stderr</literal>に出力される。</para>
96a515c @mkotha 6.6.1
authored
772
294c679 @mkotha update runtime_control.xml
authored
773 <para>これは特にデバッグ時に有用である。プログラムが<literal>head []</literal>エラーを起こすが、コードのどの部分が原因か分からないとき、<literal>-prof -fprof-auto</literal>を付けてコンパイルし、<literal>+RTS -xc -RTS</literal>を付けて実行すれば、エラーが発生した地点の呼び出しスタックが正確に分かる。</para>
96a515c @mkotha 6.6.1
authored
774
294c679 @mkotha update runtime_control.xml
authored
775 <para>出力には、プログラムで発生した例外それぞれ(プログラムは、実行を通して、例外を複数回発生させたり捕捉したりし得る)につき一つの報告を含む。個々の報告は以下のようなものである。</para>
96a515c @mkotha 6.6.1
authored
776
777 <screen>
294c679 @mkotha update runtime_control.xml
authored
778 *** Exception raised (reporting due to +RTS -xc), stack trace:
779 GHC.List.CAF
780 --> evaluated by: Main.polynomial.table_search,
781 called from Main.polynomial.theta_index,
782 called from Main.polynomial,
783 called from Main.zonal_pressure,
784 called from Main.make_pressure.p,
785 called from Main.make_pressure,
786 called from Main.compute_initial_state.p,
787 called from Main.compute_initial_state,
788 called from Main.CAF
789 ...
96a515c @mkotha 6.6.1
authored
790 </screen>
294c679 @mkotha update runtime_control.xml
authored
791 <para>スタックトレースはしばしば、<literal>GHC.List.CAF</literal>のような役に立たないものから始まる。これはGHCの最適化器が例外を最上位に移した痕跡である。これに対してプロファイルシステムはコスト集約点「CAF」を割り当てた。しかし<literal>+RTS -xc</literal>は単に現在のスタックを表示するだけでなく、より深く見てそのCAFが評価された時点のスタックを報告する。CAFでないスタックが見つかるまでさらにスタックを報告するかもしれない。上の例では、次のスタック(<literal>--> evaluated by</literal>の後)が、プログラムが<literal>head []</literal>を評価したときに何をしていたかについて、沢山の情報を含んでいる。</para>
792
793 <para>実装の詳細はさておき、スタック中の関数名は願わくばバグを見つけだすのに十分な手掛りをあなたに与えるだろう。</para>
96a515c @mkotha 6.6.1
authored
794
294c679 @mkotha update runtime_control.xml
authored
795 <para>呼び出しスタックを見る別の方法については、<literal>Debug.Trace</literal>モジュールの<literal>traceStack</literal>関数も見よ。
796 </para>
797 </listitem>
96a515c @mkotha 6.6.1
authored
798 </varlistentry>
799
800 <varlistentry>
801 <term>
802 <option>-Z</option>
803 <indexterm><primary><option>-Z</option></primary><secondary>RTS option</secondary></indexterm>
804 </term>
805 <listitem>
806 <para>GC時の「update-frame-squeezing」を<emphasis>無効に</emphasis>する。(There's no particularly good reason to turn it off, except to ensure the accuracy of certain data collected regarding thunk entry counts.(訳注: 訳せません。助けて))</para>
807 </listitem>
808 </varlistentry>
809 </variablelist>
810
97da4f5 @mkotha update runtime_control.xml
authored
811 </sect2>
a2be81e @mkotha runtime_control.xml
authored
812
294c679 @mkotha update runtime_control.xml
authored
813 <sect2 id="ghc-info">
a2be81e @mkotha runtime_control.xml
authored
814 <title>RTSに関する情報を取得する</title>
815
816 <indexterm><primary>RTS</primary></indexterm>
817
818 <para>RTSに、自分自身の情報をいくらか表示させることが可能である。これをするには<option>--info</option>フラグを使う。例えば次のように。</para>
819 <screen>
820 $ ./a.out +RTS --info
3324701 @mkotha update runtime_control.xml
authored
821 [("GHC RTS", "YES")
a2be81e @mkotha runtime_control.xml
authored
822 ,("GHC version", "6.7")
823 ,("RTS way", "rts_p")
824 ,("Host platform", "x86_64-unknown-linux")
3324701 @mkotha update runtime_control.xml
authored
825 ,("Host architecture", "x86_64")
826 ,("Host OS", "linux")
827 ,("Host vendor", "unknown")
a2be81e @mkotha runtime_control.xml
authored
828 ,("Build platform", "x86_64-unknown-linux")
3324701 @mkotha update runtime_control.xml
authored
829 ,("Build architecture", "x86_64")
830 ,("Build OS", "linux")
831 ,("Build vendor", "unknown")
a2be81e @mkotha runtime_control.xml
authored
832 ,("Target platform", "x86_64-unknown-linux")
3324701 @mkotha update runtime_control.xml
authored
833 ,("Target architecture", "x86_64")
834 ,("Target OS", "linux")
835 ,("Target vendor", "unknown")
836 ,("Word size", "64")
a2be81e @mkotha runtime_control.xml
authored
837 ,("Compiler unregisterised", "NO")
838 ,("Tables next to code", "YES")
839 ]
840 </screen>
3324701 @mkotha update runtime_control.xml
authored
841 <para>この情報は、<literal>[(String, String)]</literal>型の値として読めるように整形されている。現在、以下のフィールドが存在する。</para>
842
843 <variablelist>
844
845 <varlistentry>
846 <term><literal>GHC RTS</literal></term>
847 <listitem>
848 <para>このプログラムはGHC RTSにリンクされているか?(常に"YES")</para>
849 </listitem>
850 </varlistentry>
851
852 <varlistentry>
853 <term><literal>GHC version</literal></term>
854 <listitem>
855 <para>このプログラムをコンパイルするのに用いられたGHCのバージョン</para>
856 </listitem>
857 </varlistentry>
858
859 <varlistentry>
860 <term><literal>RTS way</literal></term>
861 <listitem>
862 <para>ランタイムの種類(「way」)。特によくある値は、<literal>rts</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>
863 </listitem>
864 </varlistentry>
865
866 <varlistentry>
867 <term>
868 <literal>Target platform</literal>,
869 <literal>Target architecture</literal>,
870 <literal>Target OS</literal>,
871 <literal>Target vendor</literal>
872 </term>
873 <listitem>
874 <para>プログラムが走ることを意図されたプラットフォーム。</para>
875 </listitem>
876 </varlistentry>
877
878 <varlistentry>
879 <term>
880 <literal>Build platform</literal>,
881 <literal>Build architecture</literal>,
882 <literal>Build OS</literal>,
883 <literal>Build vendor</literal>
884 </term>
885 <listitem>
886 <para>プログラムがビルドされたプラットフォーム。(つまり、GHC自身のターゲットプラットフォームである)。通常これはターゲットプラットフォームと同じである。(クロスコンパイルの際には異なることが考えられる)</para>
887 </listitem>
888 </varlistentry>
889
890 <varlistentry>
891 <term>
892 <literal>Host platform</literal>,
893 <literal>Host architecture</literal>
894 <literal>Host OS</literal>
895 <literal>Host vendor</literal>
896 </term>
897 <listitem>
898 <para>GHC自身がコンパイルされたプラットフォーム。これも、通常はビルドおよびターゲットのプラットフォームと同じである。</para>
899 </listitem>
900 </varlistentry>
901
902 <varlistentry>
903 <term><literal>Word size</literal></term>
904 <listitem>
905 <para>ターゲットプラットフォームのワードの大きさに応じて、<literal>"32"</literal>または<literal>"64"</literal>。</para>
906 </listitem>
907 </varlistentry>
908
909 <varlistentry>
910 <term><literal>Compiler unregistered(訳注: unregisteredでなくunregisterisedが正しいものと思われる)</literal></term>
911 <listitem>
294c679 @mkotha update runtime_control.xml
authored
912 <para>このプログラムは<link linkend="unreg">「非レジスタ化」</link>版のGHC(すなわち、通常未対応のプラットフォームであるために、プラットフォーム固有の最適化なしでコンパイルされたGHC)によってコンパイルされたか?実験的なGHCのビルドを使っているのでない限り、この値は通常noである。</para>
3324701 @mkotha update runtime_control.xml
authored
913 </listitem>
914 </varlistentry>
915
916 <varlistentry>
917 <term><literal>Tables next to code</literal></term>
918 <listitem>
919 <para>info tableをコードに直接隣接させて配置するという最適化は有用であるが、全てのプラットフォームで対応されている訳ではない。このフィールドは、プログラムがこの最適化を使ってコンパイルされているかどうかを示すものである。(珍しいプラットフォームでなければ通常yesである)</para>
920 </listitem>
921 </varlistentry>
922
923 </variablelist>
924
97da4f5 @mkotha update runtime_control.xml
authored
925 </sect2>
926 </sect1>
96a515c @mkotha 6.6.1
authored
927
928 <!-- Emacs stuff:
929 ;;; Local Variables: ***
930 ;;; sgml-parent-document: ("users_guide.xml" "book" "chapter" "sect1") ***
931 ;;; End: ***
932 -->
Something went wrong with that request. Please try again.