Overhaul of infrastructure for profiling, coverage (HPC) and breakpoints
[ghc.git] / docs / users_guide / runtime_control.xml
1 <?xml version="1.0" encoding="iso-8859-1"?>
2 <sect1 id="runtime-control">
3 <title>Running a compiled program</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
9 <para>To make an executable program, the GHC system compiles your
10 code and then links it with a non-trivial runtime system (RTS),
11 which handles storage management, thread scheduling, profiling, and
12 so on.</para>
13
14 <para>
15 The RTS has a lot of options to control its behaviour. For
16 example, you can change the context-switch interval, the default
17 size of the heap, and enable heap profiling. These options can be
18 passed to the runtime system in a variety of different ways; the
19 next section (<xref linkend="setting-rts-options" />) describes
20 the various methods, and the following sections describe the RTS
21 options themselves.
22 </para>
23
24 <sect2 id="setting-rts-options">
25 <title>Setting RTS options</title>
26 <indexterm><primary>RTS options, setting</primary></indexterm>
27
28 <para>
29 There are four ways to set RTS options:
30
31 <itemizedlist>
32 <listitem>
33 <para>
34 on the command line between <literal>+RTS ... -RTS</literal>, when running the program
35 (<xref linkend="rts-opts-cmdline" />)
36 </para>
37 </listitem>
38 <listitem>
39 <para>at compile-time, using <option>--with-rtsopts</option>
40 (<xref linkend="rts-opts-compile-time" />)
41 </para>
42 </listitem>
43 <listitem>
44 <para>with the environment variable <envar>GHCRTS</envar>
45 (<xref linkend="rts-options-environment" />)
46 </para>
47 </listitem>
48 <listitem>
49 <para>by overriding &ldquo;hooks&rdquo; in the runtime system
50 (<xref linkend="rts-hooks" />)
51 </para>
52 </listitem>
53 </itemizedlist>
54 </para>
55
56 <sect3 id="rts-opts-cmdline">
57 <title>Setting RTS options on the command line</title>
58
59 <para>
60 If you set the <literal>-rtsopts</literal> flag appropriately
61 when linking (see <xref linkend="options-linker" />), you can
62 give RTS options on the command line when running your
63 program.
64 </para>
65
66 <para>
67 When your Haskell program starts up, the RTS extracts
68 command-line arguments bracketed between
69 <option>+RTS</option><indexterm><primary><option>+RTS</option></primary></indexterm>
70 and
71 <option>-RTS</option><indexterm><primary><option>-RTS</option></primary></indexterm>
72 as its own. For example:
73 </para>
74
75 <screen>
76 $ ghc prog.hs -rtsopts
77 [1 of 1] Compiling Main ( prog.hs, prog.o )
78 Linking prog ...
79 $ ./prog -f +RTS -H32m -S -RTS -h foo bar
80 </screen>
81
82 <para>
83 The RTS will
84 snaffle <option>-H32m</option> <option>-S</option> for itself,
85 and the remaining arguments <literal>-f -h foo bar</literal>
86 will be available to your program if/when it calls
87 <function>System.Environment.getArgs</function>.
88 </para>
89
90 <para>
91 No <option>-RTS</option> option is required if the
92 runtime-system options extend to the end of the command line, as in
93 this example:
94 </para>
95
96 <screen>
97 % hls -ltr /usr/etc +RTS -A5m
98 </screen>
99
100 <para>
101 If you absolutely positively want all the rest of the options
102 in a command line to go to the program (and not the RTS), use a
103 <option>&ndash;&ndash;RTS</option><indexterm><primary><option>--RTS</option></primary></indexterm>.
104 </para>
105
106 <para>
107 As always, for RTS options that take
108 <replaceable>size</replaceable>s: If the last character of
109 <replaceable>size</replaceable> is a K or k, multiply by 1000; if an
110 M or m, by 1,000,000; if a G or G, by 1,000,000,000. (And any
111 wraparound in the counters is <emphasis>your</emphasis>
112 fault!)
113 </para>
114
115 <para>
116 Giving a <literal>+RTS -?</literal>
117 <indexterm><primary><option>-?</option></primary><secondary>RTS option</secondary></indexterm> option
118 will print out the RTS options actually available in your program
119 (which vary, depending on how you compiled).</para>
120
121 <para>
122 NOTE: since GHC is itself compiled by GHC, you can change RTS
123 options in the compiler using the normal
124 <literal>+RTS ... -RTS</literal>
125 combination. eg. to set the maximum heap
126 size for a compilation to 128M, you would add
127 <literal>+RTS -M128m -RTS</literal>
128 to the command line.
129 </para>
130 </sect3>
131
132 <sect3 id="rts-opts-compile-time">
133 <title>Setting RTS options at compile time</title>
134
135 <para>
136 GHC lets you change the default RTS options for a program at
137 compile time, using the <literal>-with-rtsopts</literal>
138 flag (<xref linkend="options-linker" />). For example, to
139 set <literal>-H128m -K64m</literal>, link
140 with <literal>-with-rtsopts="-H128m -K64m"</literal>.
141 </para>
142 </sect3>
143
144 <sect3 id="rts-options-environment">
145 <title>Setting RTS options with the <envar>GHCRTS</envar>
146 environment variable</title>
147
148 <indexterm><primary>RTS options</primary><secondary>from the environment</secondary></indexterm>
149 <indexterm><primary>environment variable</primary><secondary>for
150 setting RTS options</secondary></indexterm>
151
152 <para>
153 If the <literal>-rtsopts</literal> flag is set to
154 something other than <literal>none</literal> when linking,
155 RTS options are also taken from the environment variable
156 <envar>GHCRTS</envar><indexterm><primary><envar>GHCRTS</envar></primary>
157 </indexterm>. For example, to set the maximum heap size
158 to 2G for all GHC-compiled programs (using an
159 <literal>sh</literal>-like shell):
160 </para>
161
162 <screen>
163 GHCRTS='-M2G'
164 export GHCRTS
165 </screen>
166
167 <para>
168 RTS options taken from the <envar>GHCRTS</envar> environment
169 variable can be overridden by options given on the command
170 line.
171 </para>
172
173 <para>
174 Tip: setting something like <literal>GHCRTS=-M2G</literal>
175 in your environment is a handy way to avoid Haskell programs
176 growing beyond the real memory in your machine, which is
177 easy to do by accident and can cause the machine to slow to
178 a crawl until the OS decides to kill the process (and you
179 hope it kills the right one).
180 </para>
181 </sect3>
182
183 <sect3 id="rts-hooks">
184 <title>&ldquo;Hooks&rdquo; to change RTS behaviour</title>
185
186 <indexterm><primary>hooks</primary><secondary>RTS</secondary></indexterm>
187 <indexterm><primary>RTS hooks</primary></indexterm>
188 <indexterm><primary>RTS behaviour, changing</primary></indexterm>
189
190 <para>GHC lets you exercise rudimentary control over the RTS
191 settings for any given program, by compiling in a
192 &ldquo;hook&rdquo; that is called by the run-time system. The RTS
193 contains stub definitions for all these hooks, but by writing your
194 own version and linking it on the GHC command line, you can
195 override the defaults.</para>
196
197 <para>Owing to the vagaries of DLL linking, these hooks don't work
198 under Windows when the program is built dynamically.</para>
199
200 <para>The hook <literal>ghc_rts_opts</literal><indexterm><primary><literal>ghc_rts_opts</literal></primary>
201 </indexterm>lets you set RTS
202 options permanently for a given program, in the same way as the
203 newer <option>-with-rtsopts</option> linker option does. A common use for this is
204 to give your program a default heap and/or stack size that is
205 greater than the default. For example, to set <literal>-H128m
206 -K1m</literal>, place the following definition in a C source
207 file:</para>
208
209 <programlisting>
210 char *ghc_rts_opts = "-H128m -K1m";
211 </programlisting>
212
213 <para>Compile the C file, and include the object file on the
214 command line when you link your Haskell program.</para>
215
216 <para>These flags are interpreted first, before any RTS flags from
217 the <literal>GHCRTS</literal> environment variable and any flags
218 on the command line.</para>
219
220 <para>You can also change the messages printed when the runtime
221 system &ldquo;blows up,&rdquo; e.g., on stack overflow. The hooks
222 for these are as follows:</para>
223
224 <variablelist>
225
226 <varlistentry>
227 <term>
228 <function>void OutOfHeapHook (unsigned long, unsigned long)</function>
229 <indexterm><primary><function>OutOfHeapHook</function></primary></indexterm>
230 </term>
231 <listitem>
232 <para>The heap-overflow message.</para>
233 </listitem>
234 </varlistentry>
235
236 <varlistentry>
237 <term>
238 <function>void StackOverflowHook (long int)</function>
239 <indexterm><primary><function>StackOverflowHook</function></primary></indexterm>
240 </term>
241 <listitem>
242 <para>The stack-overflow message.</para>
243 </listitem>
244 </varlistentry>
245
246 <varlistentry>
247 <term>
248 <function>void MallocFailHook (long int)</function>
249 <indexterm><primary><function>MallocFailHook</function></primary></indexterm>
250 </term>
251 <listitem>
252 <para>The message printed if <function>malloc</function>
253 fails.</para>
254 </listitem>
255 </varlistentry>
256 </variablelist>
257
258 <para>For examples of the use of these hooks, see GHC's own
259 versions in the file
260 <filename>ghc/compiler/parser/hschooks.c</filename> in a GHC
261 source tree.</para>
262 </sect3>
263
264 </sect2>
265
266 <sect2 id="rts-options-misc">
267 <title>Miscellaneous RTS options</title>
268
269 <variablelist>
270 <varlistentry>
271 <term><option>-V<replaceable>secs</replaceable></option>
272 <indexterm><primary><option>-V</option></primary><secondary>RTS
273 option</secondary></indexterm></term>
274 <listitem>
275 <para>Sets the interval that the RTS clock ticks at. The
276 runtime uses a single timer signal to count ticks; this timer
277 signal is used to control the context switch timer (<xref
278 linkend="using-concurrent" />) and the heap profiling
279 timer <xref linkend="rts-options-heap-prof" />. Also, the
280 time profiler uses the RTS timer signal directly to record
281 time profiling samples.</para>
282
283 <para>Normally, setting the <option>-V</option> option
284 directly is not necessary: the resolution of the RTS timer is
285 adjusted automatically if a short interval is requested with
286 the <option>-C</option> or <option>-i</option> options.
287 However, setting <option>-V</option> is required in order to
288 increase the resolution of the time profiler.</para>
289
290 <para>Using a value of zero disables the RTS clock
291 completely, and has the effect of disabling timers that
292 depend on it: the context switch timer and the heap profiling
293 timer. Context switches will still happen, but
294 deterministically and at a rate much faster than normal.
295 Disabling the interval timer is useful for debugging, because
296 it eliminates a source of non-determinism at runtime.</para>
297 </listitem>
298 </varlistentry>
299
300 <varlistentry>
301 <term><option>--install-signal-handlers=<replaceable>yes|no</replaceable></option>
302 <indexterm><primary><option>--install-signal-handlers</option></primary><secondary>RTS
303 option</secondary></indexterm></term>
304 <listitem>
305 <para>If yes (the default), the RTS installs signal handlers to catch
306 things like ctrl-C. This option is primarily useful for when
307 you are using the Haskell code as a DLL, and want to set your
308 own signal handlers.</para>
309
310 <para>Note that even
311 with <option>--install-signal-handlers=no</option>, the RTS
312 interval timer signal is still enabled. The timer signal
313 is either SIGVTALRM or SIGALRM, depending on the RTS
314 configuration and OS capabilities. To disable the timer
315 signal, use the <literal>-V0</literal> RTS option (see
316 above).
317 </para>
318 </listitem>
319 </varlistentry>
320
321 <varlistentry>
322 <term><option>-xm<replaceable>address</replaceable></option>
323 <indexterm><primary><option>-xm</option></primary><secondary>RTS
324 option</secondary></indexterm></term>
325 <listitem>
326 <para>
327 WARNING: this option is for working around memory
328 allocation problems only. Do not use unless GHCi fails
329 with a message like &ldquo;<literal>failed to mmap() memory below 2Gb</literal>&rdquo;. If you need to use this option to get GHCi working
330 on your machine, please file a bug.
331 </para>
332
333 <para>
334 On 64-bit machines, the RTS needs to allocate memory in the
335 low 2Gb of the address space. Support for this across
336 different operating systems is patchy, and sometimes fails.
337 This option is there to give the RTS a hint about where it
338 should be able to allocate memory in the low 2Gb of the
339 address space. For example, <literal>+RTS -xm20000000
340 -RTS</literal> would hint that the RTS should allocate
341 starting at the 0.5Gb mark. The default is to use the OS's
342 built-in support for allocating memory in the low 2Gb if
343 available (e.g. <literal>mmap</literal>
344 with <literal>MAP_32BIT</literal> on Linux), or
345 otherwise <literal>-xm40000000</literal>.
346 </para>
347 </listitem>
348 </varlistentry>
349 </variablelist>
350 </sect2>
351
352 <sect2 id="rts-options-gc">
353 <title>RTS options to control the garbage collector</title>
354
355 <indexterm><primary>garbage collector</primary><secondary>options</secondary></indexterm>
356 <indexterm><primary>RTS options</primary><secondary>garbage collection</secondary></indexterm>
357
358 <para>There are several options to give you precise control over
359 garbage collection. Hopefully, you won't need any of these in
360 normal operation, but there are several things that can be tweaked
361 for maximum performance.</para>
362
363 <variablelist>
364
365 <varlistentry>
366 <term>
367 <option>-A</option><replaceable>size</replaceable>
368 <indexterm><primary><option>-A</option></primary><secondary>RTS option</secondary></indexterm>
369 <indexterm><primary>allocation area, size</primary></indexterm>
370 </term>
371 <listitem>
372 <para>&lsqb;Default: 512k&rsqb; Set the allocation area size
373 used by the garbage collector. The allocation area
374 (actually generation 0 step 0) is fixed and is never resized
375 (unless you use <option>-H</option>, below).</para>
376
377 <para>Increasing the allocation area size may or may not
378 give better performance (a bigger allocation area means
379 worse cache behaviour but fewer garbage collections and less
380 promotion).</para>
381
382 <para>With only 1 generation (<option>-G1</option>) the
383 <option>-A</option> option specifies the minimum allocation
384 area, since the actual size of the allocation area will be
385 resized according to the amount of data in the heap (see
386 <option>-F</option>, below).</para>
387 </listitem>
388 </varlistentry>
389
390 <varlistentry>
391 <term>
392 <option>-c</option>
393 <indexterm><primary><option>-c</option></primary><secondary>RTS option</secondary></indexterm>
394 <indexterm><primary>garbage collection</primary><secondary>compacting</secondary></indexterm>
395 <indexterm><primary>compacting garbage collection</primary></indexterm>
396 </term>
397 <listitem>
398 <para>Use a compacting algorithm for collecting the oldest
399 generation. By default, the oldest generation is collected
400 using a copying algorithm; this option causes it to be
401 compacted in-place instead. The compaction algorithm is
402 slower than the copying algorithm, but the savings in memory
403 use can be considerable.</para>
404
405 <para>For a given heap size (using the <option>-H</option>
406 option), compaction can in fact reduce the GC cost by
407 allowing fewer GCs to be performed. This is more likely
408 when the ratio of live data to heap size is high, say
409 &gt;30&percnt;.</para>
410
411 <para>NOTE: compaction doesn't currently work when a single
412 generation is requested using the <option>-G1</option>
413 option.</para>
414 </listitem>
415 </varlistentry>
416
417 <varlistentry>
418 <term><option>-c</option><replaceable>n</replaceable></term>
419
420 <listitem>
421 <para>&lsqb;Default: 30&rsqb; Automatically enable
422 compacting collection when the live data exceeds
423 <replaceable>n</replaceable>&percnt; of the maximum heap size
424 (see the <option>-M</option> option). Note that the maximum
425 heap size is unlimited by default, so this option has no
426 effect unless the maximum heap size is set with
427 <option>-M</option><replaceable>size</replaceable>. </para>
428 </listitem>
429 </varlistentry>
430
431 <varlistentry>
432 <term>
433 <option>-F</option><replaceable>factor</replaceable>
434 <indexterm><primary><option>-F</option></primary><secondary>RTS option</secondary></indexterm>
435 <indexterm><primary>heap size, factor</primary></indexterm>
436 </term>
437 <listitem>
438
439 <para>&lsqb;Default: 2&rsqb; This option controls the amount
440 of memory reserved for the older generations (and in the
441 case of a two space collector the size of the allocation
442 area) as a factor of the amount of live data. For example,
443 if there was 2M of live data in the oldest generation when
444 we last collected it, then by default we'll wait until it
445 grows to 4M before collecting it again.</para>
446
447 <para>The default seems to work well here. If you have
448 plenty of memory, it is usually better to use
449 <option>-H</option><replaceable>size</replaceable> than to
450 increase
451 <option>-F</option><replaceable>factor</replaceable>.</para>
452
453 <para>The <option>-F</option> setting will be automatically
454 reduced by the garbage collector when the maximum heap size
455 (the <option>-M</option><replaceable>size</replaceable>
456 setting) is approaching.</para>
457 </listitem>
458 </varlistentry>
459
460 <varlistentry>
461 <term>
462 <option>-G</option><replaceable>generations</replaceable>
463 <indexterm><primary><option>-G</option></primary><secondary>RTS option</secondary></indexterm>
464 <indexterm><primary>generations, number of</primary></indexterm>
465 </term>
466 <listitem>
467 <para>&lsqb;Default: 2&rsqb; Set the number of generations
468 used by the garbage collector. The default of 2 seems to be
469 good, but the garbage collector can support any number of
470 generations. Anything larger than about 4 is probably not a
471 good idea unless your program runs for a
472 <emphasis>long</emphasis> time, because the oldest
473 generation will hardly ever get collected.</para>
474
475 <para>Specifying 1 generation with <option>+RTS -G1</option>
476 gives you a simple 2-space collector, as you would expect.
477 In a 2-space collector, the <option>-A</option> option (see
478 above) specifies the <emphasis>minimum</emphasis> allocation
479 area size, since the allocation area will grow with the
480 amount of live data in the heap. In a multi-generational
481 collector the allocation area is a fixed size (unless you
482 use the <option>-H</option> option, see below).</para>
483 </listitem>
484 </varlistentry>
485
486 <varlistentry>
487 <term>
488 <option>-qg<optional><replaceable>gen</replaceable></optional></option>
489 <indexterm><primary><option>-qg</option><secondary>RTS
490 option</secondary></primary></indexterm>
491 </term>
492 <listitem>
493 <para>&lsqb;New in GHC 6.12.1&rsqb; &lsqb;Default: 0&rsqb;
494 Use parallel GC in
495 generation <replaceable>gen</replaceable> and higher.
496 Omitting <replaceable>gen</replaceable> turns off the
497 parallel GC completely, reverting to sequential GC.</para>
498
499 <para>The default parallel GC settings are usually suitable
500 for parallel programs (i.e. those
501 using <literal>par</literal>, Strategies, or with multiple
502 threads). However, it is sometimes beneficial to enable
503 the parallel GC for a single-threaded sequential program
504 too, especially if the program has a large amount of heap
505 data and GC is a significant fraction of runtime. To use
506 the parallel GC in a sequential program, enable the
507 parallel runtime with a suitable <literal>-N</literal>
508 option, and additionally it might be beneficial to
509 restrict parallel GC to the old generation
510 with <literal>-qg1</literal>.</para>
511 </listitem>
512 </varlistentry>
513
514 <varlistentry>
515 <term>
516 <option>-qb<optional><replaceable>gen</replaceable></optional></option>
517 <indexterm><primary><option>-qb</option><secondary>RTS
518 option</secondary></primary></indexterm>
519 </term>
520 <listitem>
521 <para>
522 &lsqb;New in GHC 6.12.1&rsqb; &lsqb;Default: 1&rsqb; Use
523 load-balancing in the parallel GC in
524 generation <replaceable>gen</replaceable> and higher.
525 Omitting <replaceable>gen</replaceable> disables
526 load-balancing entirely.</para>
527
528 <para>
529 Load-balancing shares out the work of GC between the
530 available cores. This is a good idea when the heap is
531 large and we need to parallelise the GC work, however it
532 is also pessimal for the short young-generation
533 collections in a parallel program, because it can harm
534 locality by moving data from the cache of the CPU where is
535 it being used to the cache of another CPU. Hence the
536 default is to do load-balancing only in the
537 old-generation. In fact, for a parallel program it is
538 sometimes beneficial to disable load-balancing entirely
539 with <literal>-qb</literal>.
540 </para>
541 </listitem>
542 </varlistentry>
543
544 <varlistentry>
545 <term>
546 <option>-H</option><optional><replaceable>size</replaceable></optional>
547 <indexterm><primary><option>-H</option></primary><secondary>RTS option</secondary></indexterm>
548 <indexterm><primary>heap size, suggested</primary></indexterm>
549 </term>
550 <listitem>
551 <para>&lsqb;Default: 0&rsqb; This option provides a
552 &ldquo;suggested heap size&rdquo; for the garbage
553 collector. Think
554 of <option>-H<replaceable>size</replaceable></option> as a
555 variable <option>-A</option> option. It says: I want to
556 use at least <replaceable>size</replaceable> bytes, so use
557 whatever is left over to increase the <option>-A</option>
558 value.</para>
559
560 <para>This option does not put
561 a <emphasis>limit</emphasis> on the heap size: the heap
562 may grow beyond the given size as usual.</para>
563
564 <para>If <replaceable>size</replaceable> is omitted, then
565 the garbage collector will take the size of the heap at
566 the previous GC as the <replaceable>size</replaceable>.
567 This has the effect of allowing for a
568 larger <option>-A</option> value but without increasing
569 the overall memory requirements of the program. It can be
570 useful when the default small <option>-A</option> value is
571 suboptimal, as it can be in programs that create large
572 amounts of long-lived data.</para>
573 </listitem>
574 </varlistentry>
575
576 <varlistentry>
577 <term>
578 <option>-I</option><replaceable>seconds</replaceable>
579 <indexterm><primary><option>-I</option></primary>
580 <secondary>RTS option</secondary>
581 </indexterm>
582 <indexterm><primary>idle GC</primary>
583 </indexterm>
584 </term>
585 <listitem>
586 <para>(default: 0.3) In the threaded and SMP versions of the RTS (see
587 <option>-threaded</option>, <xref linkend="options-linker" />), a
588 major GC is automatically performed if the runtime has been idle
589 (no Haskell computation has been running) for a period of time.
590 The amount of idle time which must pass before a GC is performed is
591 set by the <option>-I</option><replaceable>seconds</replaceable>
592 option. Specifying <option>-I0</option> disables the idle GC.</para>
593
594 <para>For an interactive application, it is probably a good idea to
595 use the idle GC, because this will allow finalizers to run and
596 deadlocked threads to be detected in the idle time when no Haskell
597 computation is happening. Also, it will mean that a GC is less
598 likely to happen when the application is busy, and so
599 responsiveness may be improved. However, if the amount of live data in
600 the heap is particularly large, then the idle GC can cause a
601 significant delay, and too small an interval could adversely affect
602 interactive responsiveness.</para>
603
604 <para>This is an experimental feature, please let us know if it
605 causes problems and/or could benefit from further tuning.</para>
606 </listitem>
607 </varlistentry>
608
609 <varlistentry>
610 <term>
611 <option>-ki</option><replaceable>size</replaceable>
612 <indexterm><primary><option>-k</option></primary><secondary>RTS option</secondary></indexterm>
613 <indexterm><primary>stack, initial size</primary></indexterm>
614 </term>
615 <listitem>
616 <para>
617 &lsqb;Default: 1k&rsqb; Set the initial stack size for new
618 threads. (Note: this flag used to be
619 simply <option>-k</option>, but was renamed
620 to <option>-ki</option> in GHC 7.2.1. The old name is
621 still accepted for backwards compatibility, but that may
622 be removed in a future version).
623 </para>
624
625 <para>
626 Thread stacks (including the main thread's stack) live on
627 the heap. As the stack grows, new stack chunks are added
628 as required; if the stack shrinks again, these extra stack
629 chunks are reclaimed by the garbage collector. The
630 default initial stack size is deliberately small, in order
631 to keep the time and space overhead for thread creation to
632 a minimum, and to make it practical to spawn threads for
633 even tiny pieces of work.
634 </para>
635 </listitem>
636 </varlistentry>
637
638 <varlistentry>
639 <term>
640 <option>-kc</option><replaceable>size</replaceable>
641 <indexterm><primary><option>-kc</option></primary><secondary>RTS
642 option</secondary></indexterm>
643 <indexterm><primary>stack</primary><secondary>chunk size</secondary></indexterm>
644 </term>
645 <listitem>
646 <para>
647 &lsqb;Default: 32k&rsqb; Set the size of &ldquo;stack
648 chunks&rdquo;. When a thread's current stack overflows, a
649 new stack chunk is created and added to the thread's
650 stack, until the limit set by <option>-K</option> is
651 reached.
652 </para>
653
654 <para>
655 The advantage of smaller stack chunks is that the garbage
656 collector can avoid traversing stack chunks if they are
657 known to be unmodified since the last collection, so
658 reducing the chunk size means that the garbage collector
659 can identify more stack as unmodified, and the GC overhead
660 might be reduced. On the other hand, making stack chunks
661 too small adds some overhead as there will be more
662 overflow/underflow between chunks. The default setting of
663 32k appears to be a reasonable compromise in most cases.
664 </para>
665 </listitem>
666 </varlistentry>
667
668 <varlistentry>
669 <term>
670 <option>-kb</option><replaceable>size</replaceable>
671 <indexterm><primary><option>-kc</option></primary><secondary>RTS
672 option</secondary></indexterm>
673 <indexterm><primary>stack</primary><secondary>chunk buffer size</secondary></indexterm>
674 </term>
675 <listitem>
676 <para>
677 &lsqb;Default: 1k&rsqb; Sets the stack chunk buffer size.
678 When a stack chunk overflows and a new stack chunk is
679 created, some of the data from the previous stack chunk is
680 moved into the new chunk, to avoid an immediate underflow
681 and repeated overflow/underflow at the boundary. The
682 amount of stack moved is set by the <option>-kb</option>
683 option.
684 </para>
685 <para>
686 Note that to avoid wasting space, this value should
687 typically be less than 10&percnt; of the size of a stack
688 chunk (<option>-kc</option>), because in a chain of stack
689 chunks, each chunk will have a gap of unused space of this
690 size.
691 </para>
692 </listitem>
693 </varlistentry>
694
695 <varlistentry>
696 <term>
697 <option>-K</option><replaceable>size</replaceable>
698 <indexterm><primary><option>-K</option></primary><secondary>RTS option</secondary></indexterm>
699 <indexterm><primary>stack, maximum size</primary></indexterm>
700 </term>
701 <listitem>
702 <para>&lsqb;Default: 8M&rsqb; Set the maximum stack size for
703 an individual thread to <replaceable>size</replaceable>
704 bytes. If the thread attempts to exceed this limit, it will
705 be send the <literal>StackOverflow</literal> exception.
706 </para>
707 <para>
708 This option is there mainly to stop the program eating up
709 all the available memory in the machine if it gets into an
710 infinite loop.
711 </para>
712 </listitem>
713 </varlistentry>
714
715 <varlistentry>
716 <term>
717 <option>-m</option><replaceable>n</replaceable>
718 <indexterm><primary><option>-m</option></primary><secondary>RTS option</secondary></indexterm>
719 <indexterm><primary>heap, minimum free</primary></indexterm>
720 </term>
721 <listitem>
722 <para>Minimum &percnt; <replaceable>n</replaceable> of heap
723 which must be available for allocation. The default is
724 3&percnt;.</para>
725 </listitem>
726 </varlistentry>
727
728 <varlistentry>
729 <term>
730 <option>-M</option><replaceable>size</replaceable>
731 <indexterm><primary><option>-M</option></primary><secondary>RTS option</secondary></indexterm>
732 <indexterm><primary>heap size, maximum</primary></indexterm>
733 </term>
734 <listitem>
735 <para>&lsqb;Default: unlimited&rsqb; Set the maximum heap size to
736 <replaceable>size</replaceable> bytes. The heap normally
737 grows and shrinks according to the memory requirements of
738 the program. The only reason for having this option is to
739 stop the heap growing without bound and filling up all the
740 available swap space, which at the least will result in the
741 program being summarily killed by the operating
742 system.</para>
743
744 <para>The maximum heap size also affects other garbage
745 collection parameters: when the amount of live data in the
746 heap exceeds a certain fraction of the maximum heap size,
747 compacting collection will be automatically enabled for the
748 oldest generation, and the <option>-F</option> parameter
749 will be reduced in order to avoid exceeding the maximum heap
750 size.</para>
751 </listitem>
752 </varlistentry>
753
754 <varlistentry>
755 <term>
756 <option>-t</option><optional><replaceable>file</replaceable></optional>
757 <indexterm><primary><option>-t</option></primary><secondary>RTS option</secondary></indexterm>
758 </term>
759 <term>
760 <option>-s</option><optional><replaceable>file</replaceable></optional>
761 <indexterm><primary><option>-s</option></primary><secondary>RTS option</secondary></indexterm>
762 </term>
763 <term>
764 <option>-S</option><optional><replaceable>file</replaceable></optional>
765 <indexterm><primary><option>-S</option></primary><secondary>RTS option</secondary></indexterm>
766 </term>
767 <term>
768 <option>--machine-readable</option>
769 <indexterm><primary><option>--machine-readable</option></primary><secondary>RTS option</secondary></indexterm>
770 </term>
771 <listitem>
772 <para>These options produce runtime-system statistics, such
773 as the amount of time spent executing the program and in the
774 garbage collector, the amount of memory allocated, the
775 maximum size of the heap, and so on. The three
776 variants give different levels of detail:
777 <option>-t</option> produces a single line of output in the
778 same format as GHC's <option>-Rghc-timing</option> option,
779 <option>-s</option> produces a more detailed summary at the
780 end of the program, and <option>-S</option> additionally
781 produces information about each and every garbage
782 collection.</para>
783
784 <para>The output is placed in
785 <replaceable>file</replaceable>. If
786 <replaceable>file</replaceable> is omitted, then the output
787 is sent to <constant>stderr</constant>.</para>
788
789 <para>
790 If you use the <literal>-t</literal> flag then, when your
791 program finishes, you will see something like this:
792 </para>
793
794 <programlisting>
795 &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;
796 </programlisting>
797
798 <para>
799 This tells you:
800 </para>
801
802 <itemizedlist>
803 <listitem>
804 <para>
805 The total number of bytes allocated by the program over the
806 whole run.
807 </para>
808 </listitem>
809 <listitem>
810 <para>
811 The total number of garbage collections performed.
812 </para>
813 </listitem>
814 <listitem>
815 <para>
816 The average and maximum "residency", which is the amount of
817 live data in bytes. The runtime can only determine the
818 amount of live data during a major GC, which is why the
819 number of samples corresponds to the number of major GCs
820 (and is usually relatively small). To get a better picture
821 of the heap profile of your program, use
822 the <option>-hT</option> RTS option
823 (<xref linkend="rts-profiling" />).
824 </para>
825 </listitem>
826 <listitem>
827 <para>
828 The peak memory the RTS has allocated from the OS.
829 </para>
830 </listitem>
831 <listitem>
832 <para>
833 The amount of CPU time and elapsed wall clock time while
834 initialising the runtime system (INIT), running the program
835 itself (MUT, the mutator), and garbage collecting (GC).
836 </para>
837 </listitem>
838 </itemizedlist>
839
840 <para>
841 You can also get this in a more future-proof, machine readable
842 format, with <literal>-t --machine-readable</literal>:
843 </para>
844
845 <programlisting>
846 [("bytes allocated", "36169392")
847 ,("num_GCs", "69")
848 ,("average_bytes_used", "603392")
849 ,("max_bytes_used", "1065272")
850 ,("num_byte_usage_samples", "2")
851 ,("peak_megabytes_allocated", "3")
852 ,("init_cpu_seconds", "0.00")
853 ,("init_wall_seconds", "0.00")
854 ,("mutator_cpu_seconds", "0.02")
855 ,("mutator_wall_seconds", "0.02")
856 ,("GC_cpu_seconds", "0.07")
857 ,("GC_wall_seconds", "0.07")
858 ]
859 </programlisting>
860
861 <para>
862 If you use the <literal>-s</literal> flag then, when your
863 program finishes, you will see something like this (the exact
864 details will vary depending on what sort of RTS you have, e.g.
865 you will only see profiling data if your RTS is compiled for
866 profiling):
867 </para>
868
869 <programlisting>
870 36,169,392 bytes allocated in the heap
871 4,057,632 bytes copied during GC
872 1,065,272 bytes maximum residency (2 sample(s))
873 54,312 bytes maximum slop
874 3 MB total memory in use (0 MB lost due to fragmentation)
875
876 Generation 0: 67 collections, 0 parallel, 0.04s, 0.03s elapsed
877 Generation 1: 2 collections, 0 parallel, 0.03s, 0.04s elapsed
878
879 SPARKS: 359207 (557 converted, 149591 pruned)
880
881 INIT time 0.00s ( 0.00s elapsed)
882 MUT time 0.01s ( 0.02s elapsed)
883 GC time 0.07s ( 0.07s elapsed)
884 EXIT time 0.00s ( 0.00s elapsed)
885 Total time 0.08s ( 0.09s elapsed)
886
887 %GC time 89.5% (75.3% elapsed)
888
889 Alloc rate 4,520,608,923 bytes per MUT second
890
891 Productivity 10.5% of total user, 9.1% of total elapsed
892 </programlisting>
893
894 <itemizedlist>
895 <listitem>
896 <para>
897 The "bytes allocated in the heap" is the total bytes allocated
898 by the program over the whole run.
899 </para>
900 </listitem>
901 <listitem>
902 <para>
903 GHC uses a copying garbage collector by default. "bytes copied
904 during GC" tells you how many bytes it had to copy during
905 garbage collection.
906 </para>
907 </listitem>
908 <listitem>
909 <para>
910 The maximum space actually used by your program is the
911 "bytes maximum residency" figure. This is only checked during
912 major garbage collections, so it is only an approximation;
913 the number of samples tells you how many times it is checked.
914 </para>
915 </listitem>
916 <listitem>
917 <para>
918 The "bytes maximum slop" tells you the most space that is ever
919 wasted due to the way GHC allocates memory in blocks. Slop is
920 memory at the end of a block that was wasted. There's no way
921 to control this; we just like to see how much memory is being
922 lost this way.
923 </para>
924 </listitem>
925 <listitem>
926 <para>
927 The "total memory in use" tells you the peak memory the RTS has
928 allocated from the OS.
929 </para>
930 </listitem>
931 <listitem>
932 <para>
933 Next there is information about the garbage collections done.
934 For each generation it says how many garbage collections were
935 done, how many of those collections were done in parallel,
936 the total CPU time used for garbage collecting that generation,
937 and the total wall clock time elapsed while garbage collecting
938 that generation.
939 </para>
940 </listitem>
941 <listitem>
942 <para>The <literal>SPARKS</literal> statistic refers to the
943 use of <literal>Control.Parallel.par</literal> and related
944 functionality in the program. Each spark represents a call
945 to <literal>par</literal>; a spark is "converted" when it is
946 executed in parallel; and a spark is "pruned" when it is
947 found to be already evaluated and is discarded from the pool
948 by the garbage collector. Any remaining sparks are
949 discarded at the end of execution, so "converted" plus
950 "pruned" does not necessarily add up to the total.</para>
951 </listitem>
952 <listitem>
953 <para>
954 Next there is the CPU time and wall clock time elapsed broken
955 down by what the runtime system was doing at the time.
956 INIT is the runtime system initialisation.
957 MUT is the mutator time, i.e. the time spent actually running
958 your code.
959 GC is the time spent doing garbage collection.
960 RP is the time spent doing retainer profiling.
961 PROF is the time spent doing other profiling.
962 EXIT is the runtime system shutdown time.
963 And finally, Total is, of course, the total.
964 </para>
965 <para>
966 %GC time tells you what percentage GC is of Total.
967 "Alloc rate" tells you the "bytes allocated in the heap" divided
968 by the MUT CPU time.
969 "Productivity" tells you what percentage of the Total CPU and wall
970 clock elapsed times are spent in the mutator (MUT).
971 </para>
972 </listitem>
973 </itemizedlist>
974
975 <para>
976 The <literal>-S</literal> flag, as well as giving the same
977 output as the <literal>-s</literal> flag, prints information
978 about each GC as it happens:
979 </para>
980
981 <programlisting>
982 Alloc Copied Live GC GC TOT TOT Page Flts
983 bytes bytes bytes user elap user elap
984 528496 47728 141512 0.01 0.02 0.02 0.02 0 0 (Gen: 1)
985 [...]
986 524944 175944 1726384 0.00 0.00 0.08 0.11 0 0 (Gen: 0)
987 </programlisting>
988
989 <para>
990 For each garbage collection, we print:
991 </para>
992
993 <itemizedlist>
994 <listitem>
995 <para>
996 How many bytes we allocated this garbage collection.
997 </para>
998 </listitem>
999 <listitem>
1000 <para>
1001 How many bytes we copied this garbage collection.
1002 </para>
1003 </listitem>
1004 <listitem>
1005 <para>
1006 How many bytes are currently live.
1007 </para>
1008 </listitem>
1009 <listitem>
1010 <para>
1011 How long this garbage collection took (CPU time and elapsed
1012 wall clock time).
1013 </para>
1014 </listitem>
1015 <listitem>
1016 <para>
1017 How long the program has been running (CPU time and elapsed
1018 wall clock time).
1019 </para>
1020 </listitem>
1021 <listitem>
1022 <para>
1023 How many page faults occurred this garbage collection.
1024 </para>
1025 </listitem>
1026 <listitem>
1027 <para>
1028 How many page faults occurred since the end of the last garbage
1029 collection.
1030 </para>
1031 </listitem>
1032 <listitem>
1033 <para>
1034 Which generation is being garbage collected.
1035 </para>
1036 </listitem>
1037 </itemizedlist>
1038
1039 </listitem>
1040 </varlistentry>
1041 </variablelist>
1042
1043 </sect2>
1044
1045 <sect2>
1046 <title>RTS options for concurrency and parallelism</title>
1047
1048 <para>The RTS options related to concurrency are described in
1049 <xref linkend="using-concurrent" />, and those for parallelism in
1050 <xref linkend="parallel-options"/>.</para>
1051 </sect2>
1052
1053 <sect2 id="rts-profiling">
1054 <title>RTS options for profiling</title>
1055
1056 <para>Most profiling runtime options are only available when you
1057 compile your program for profiling (see
1058 <xref linkend="prof-compiler-options" />, and
1059 <xref linkend="rts-options-heap-prof" /> for the runtime options).
1060 However, there is one profiling option that is available
1061 for ordinary non-profiled executables:</para>
1062
1063 <variablelist>
1064 <varlistentry>
1065 <term>
1066 <option>-hT</option>
1067 <indexterm><primary><option>-hT</option></primary><secondary>RTS
1068 option</secondary></indexterm>
1069 </term>
1070 <listitem>
1071 <para>(can be shortened to <option>-h</option>.) Generates a basic heap profile, in the
1072 file <literal><replaceable>prog</replaceable>.hp</literal>.
1073 To produce the heap profile graph,
1074 use <command>hp2ps</command> (see <xref linkend="hp2ps"
1075 />). The basic heap profile is broken down by data
1076 constructor, with other types of closures (functions, thunks,
1077 etc.) grouped into broad categories
1078 (e.g. <literal>FUN</literal>, <literal>THUNK</literal>). To
1079 get a more detailed profile, use the full profiling
1080 support (<xref linkend="profiling" />).</para>
1081 </listitem>
1082 </varlistentry>
1083 </variablelist>
1084 </sect2>
1085
1086 <sect2 id="rts-eventlog">
1087 <title>Tracing</title>
1088
1089 <indexterm><primary>tracing</primary></indexterm>
1090 <indexterm><primary>events</primary></indexterm>
1091 <indexterm><primary>eventlog files</primary></indexterm>
1092
1093 <para>
1094 When the program is linked with the <option>-eventlog</option>
1095 option (<xref linkend="options-linker" />), runtime events can
1096 be logged in two ways:
1097 </para>
1098
1099 <itemizedlist>
1100 <listitem>
1101 <para>
1102 In binary format to a file for later analysis by a
1103 variety of tools. One such tool
1104 is <ulink url="http://www.haskell.org/haskellwiki/ThreadScope">ThreadScope</ulink><indexterm><primary>ThreadScope</primary></indexterm>,
1105 which interprets the event log to produce a visual parallel
1106 execution profile of the program.
1107 </para>
1108 </listitem>
1109 <listitem>
1110 <para>
1111 As text to standard output, for debugging purposes.
1112 </para>
1113 </listitem>
1114 </itemizedlist>
1115
1116 <variablelist>
1117 <varlistentry>
1118 <term>
1119 <option>-l<optional><replaceable>flags</replaceable></optional></option>
1120 <indexterm><primary><option>-l</option></primary><secondary>RTS option</secondary></indexterm>
1121 </term>
1122 <listitem>
1123 <para>
1124 Log events in binary format to the
1125 file <filename><replaceable>program</replaceable>.eventlog</filename>.
1126 Without any <replaceable>flags</replaceable> specified, this logs a
1127 default set of events, suitable for use with tools like ThreadScope.
1128 </para>
1129
1130 <para>
1131 For some special use cases you may want more control over which
1132 events are included. The <replaceable>flags</replaceable> is a
1133 sequence of zero or more characters indicating which classes of
1134 events to log. Currently there are four classes of events that can
1135 be enabled/disabled:
1136 <simplelist>
1137 <member>
1138 <option>s</option> &#8212; scheduler events, including Haskell
1139 thread creation and start/stop events
1140 </member>
1141 <member>
1142 <option>g</option> &#8212; GC events, including GC start/stop
1143 </member>
1144 <member>
1145 <option>p</option> &#8212; parallel sparks (sampled)
1146 </member>
1147 <member>
1148 <option>f</option> &#8212; parallel sparks (fully accurate)
1149 </member>
1150 </simplelist>
1151 </para>
1152
1153 <para>
1154 For spark events there are two modes: sampled and fully accurate.
1155 There are various events in the life cycle of each spark, usually
1156 just creating and running, but there are some more exceptional
1157 possibilities. In the sampled mode the number of occurrences of each
1158 kind of spark event is sampled at frequent intervals. In the fully
1159 accurate mode every spark event is logged individually. The latter
1160 has a higher runtime overhead and is not enabled by default.
1161 </para>
1162
1163 <para>
1164 The initial enabled event classes are 's', 'g' and 'p'. In addition
1165 you can disable specific classes, or enable/disable all classes at
1166 once:
1167 <simplelist>
1168 <member>
1169 <option>a</option> &#8212; enable all event classes listed above
1170 </member>
1171 <member>
1172 <option>-<replaceable>x</replaceable></option> &#8212; disable the
1173 given class of events, for any event class listed above or
1174 <option>-a</option> for all classes
1175 </member>
1176 </simplelist>
1177 For example, <option>-l-ag</option> would disable all event classes
1178 (<option>-a</option>) except for GC events (<option>g</option>).
1179 </para>
1180
1181 <para>
1182 The format of the log file is described by the header
1183 <filename>EventLogFormat.h</filename> that comes with
1184 GHC, and it can be parsed in Haskell using
1185 the <ulink url="http://hackage.haskell.org/package/ghc-events">ghc-events</ulink>
1186 library. To dump the contents of
1187 a <literal>.eventlog</literal> file as text, use the
1188 tool <literal>ghc-events-show</literal> that comes with
1189 the <ulink url="http://hackage.haskell.org/package/ghc-events">ghc-events</ulink>
1190 package.
1191 </para>
1192 </listitem>
1193 </varlistentry>
1194
1195 <varlistentry>
1196 <term>
1197 <option>-v</option><optional><replaceable>flags</replaceable></optional>
1198 <indexterm><primary><option>-v</option></primary><secondary>RTS option</secondary></indexterm>
1199 </term>
1200 <listitem>
1201 <para>
1202 Log events as text to standard output, instead of to
1203 the <literal>.eventlog</literal> file.
1204 The <replaceable>flags</replaceable> are the same as
1205 for <option>-l</option>, with the additional
1206 option <literal>t</literal> which indicates that the
1207 each event printed should be preceded by a timestamp value
1208 (in the binary <literal>.eventlog</literal> file, all
1209 events are automatically associated with a timestamp).
1210 </para>
1211 </listitem>
1212 </varlistentry>
1213
1214 </variablelist>
1215
1216 <para>
1217 The debugging
1218 options <option>-D<replaceable>x</replaceable></option> also
1219 generate events which are logged using the tracing framework.
1220 By default those events are dumped as text to stdout
1221 (<option>-D<replaceable>x</replaceable></option>
1222 implies <option>-v</option>), but they may instead be stored in
1223 the binary eventlog file by using the <option>-l</option>
1224 option.
1225 </para>
1226 </sect2>
1227
1228 <sect2 id="rts-options-debugging">
1229 <title>RTS options for hackers, debuggers, and over-interested
1230 souls</title>
1231
1232 <indexterm><primary>RTS options, hacking/debugging</primary></indexterm>
1233
1234 <para>These RTS options might be used (a)&nbsp;to avoid a GHC bug,
1235 (b)&nbsp;to see &ldquo;what's really happening&rdquo;, or
1236 (c)&nbsp;because you feel like it. Not recommended for everyday
1237 use!</para>
1238
1239 <variablelist>
1240
1241 <varlistentry>
1242 <term>
1243 <option>-B</option>
1244 <indexterm><primary><option>-B</option></primary><secondary>RTS option</secondary></indexterm>
1245 </term>
1246 <listitem>
1247 <para>Sound the bell at the start of each (major) garbage
1248 collection.</para>
1249
1250 <para>Oddly enough, people really do use this option! Our
1251 pal in Durham (England), Paul Callaghan, writes: &ldquo;Some
1252 people here use it for a variety of
1253 purposes&mdash;honestly!&mdash;e.g., confirmation that the
1254 code/machine is doing something, infinite loop detection,
1255 gauging cost of recently added code. Certain people can even
1256 tell what stage &lsqb;the program&rsqb; is in by the beep
1257 pattern. But the major use is for annoying others in the
1258 same office&hellip;&rdquo;</para>
1259 </listitem>
1260 </varlistentry>
1261
1262 <varlistentry>
1263 <term>
1264 <option>-D</option><replaceable>x</replaceable>
1265 <indexterm><primary>-D</primary><secondary>RTS option</secondary></indexterm>
1266 </term>
1267 <listitem>
1268 <para>
1269 An RTS debugging flag; only available if the program was
1270 linked with the <option>-debug</option> option. Various
1271 values of <replaceable>x</replaceable> are provided to
1272 enable debug messages and additional runtime sanity checks
1273 in different subsystems in the RTS, for
1274 example <literal>+RTS -Ds -RTS</literal> enables debug
1275 messages from the scheduler.
1276 Use <literal>+RTS&nbsp;-?</literal> to find out which
1277 debug flags are supported.
1278 </para>
1279
1280 <para>
1281 Debug messages will be sent to the binary event log file
1282 instead of stdout if the <option>-l</option> option is
1283 added. This might be useful for reducing the overhead of
1284 debug tracing.
1285 </para>
1286 </listitem>
1287 </varlistentry>
1288
1289 <varlistentry>
1290 <term>
1291 <option>-r</option><replaceable>file</replaceable>
1292 <indexterm><primary><option>-r</option></primary><secondary>RTS option</secondary></indexterm>
1293 <indexterm><primary>ticky ticky profiling</primary></indexterm>
1294 <indexterm><primary>profiling</primary><secondary>ticky ticky</secondary></indexterm>
1295 </term>
1296 <listitem>
1297 <para>Produce &ldquo;ticky-ticky&rdquo; statistics at the
1298 end of the program run (only available if the program was
1299 linked with <option>-debug</option>).
1300 The <replaceable>file</replaceable> business works just like
1301 on the <option>-S</option> RTS option, above.</para>
1302
1303 <para>For more information on ticky-ticky profiling, see
1304 <xref linkend="ticky-ticky"/>.</para>
1305 </listitem>
1306 </varlistentry>
1307
1308 <varlistentry>
1309 <term>
1310 <option>-xc</option>
1311 <indexterm><primary><option>-xc</option></primary><secondary>RTS option</secondary></indexterm>
1312 </term>
1313 <listitem>
1314 <para>(Only available when the program is compiled for
1315 profiling.) When an exception is raised in the program,
1316 this option causes the current cost-centre-stack to be
1317 dumped to <literal>stderr</literal>.</para>
1318
1319 <para>This can be particularly useful for debugging: if your
1320 program is complaining about a <literal>head []</literal>
1321 error and you haven't got a clue which bit of code is
1322 causing it, compiling with <literal>-prof
1323 -fprof-auto</literal> and running with <literal>+RTS -xc
1324 -RTS</literal> will tell you exactly the call stack at the
1325 point the error was raised.</para>
1326
1327 <para>The output contains one report for each exception
1328 raised in the program (the program might raise and catch
1329 several exceptions during its execution), where each report
1330 looks something like this:
1331 </para>
1332
1333 <screen>
1334 *** Exception raised (reporting due to +RTS -xc), stack trace:
1335 GHC.List.CAF
1336 --> evaluated by: Main.polynomial.table_search,
1337 called from Main.polynomial.theta_index,
1338 called from Main.polynomial,
1339 called from Main.zonal_pressure,
1340 called from Main.make_pressure.p,
1341 called from Main.make_pressure,
1342 called from Main.compute_initial_state.p,
1343 called from Main.compute_initial_state,
1344 called from Main.CAF
1345 ...
1346 </screen>
1347 <para>The stack trace may often begin with something
1348 uninformative like <literal>GHC.List.CAF</literal>; this is
1349 an artifact of GHC's optimiser, which lifts out exceptions
1350 to the top-level where the profiling system assigns them to
1351 the cost centre "CAF". However, <literal>+RTS -xc</literal>
1352 doesn't just print the current stack, it looks deeper and
1353 reports the stack at the time the CAF was evaluated, and it
1354 may report further stacks until a non-CAF stack is found. In
1355 the example above, the next stack (after <literal>-->
1356 evaluated by</literal>) contains plenty of information about
1357 what the program was doing when it evaluated <literal>head
1358 []</literal>.</para>
1359
1360 <para>Implementation details aside, the function names in
1361 the stack should hopefully give you enough clues to track
1362 down the bug.</para>
1363 </listitem>
1364 </varlistentry>
1365
1366 <varlistentry>
1367 <term>
1368 <option>-Z</option>
1369 <indexterm><primary><option>-Z</option></primary><secondary>RTS option</secondary></indexterm>
1370 </term>
1371 <listitem>
1372 <para>Turn <emphasis>off</emphasis> &ldquo;update-frame
1373 squeezing&rdquo; at garbage-collection time. (There's no
1374 particularly good reason to turn it off, except to ensure
1375 the accuracy of certain data collected regarding thunk entry
1376 counts.)</para>
1377 </listitem>
1378 </varlistentry>
1379 </variablelist>
1380
1381 </sect2>
1382
1383 <sect2>
1384 <title>Getting information about the RTS</title>
1385
1386 <indexterm><primary>RTS</primary></indexterm>
1387
1388 <para>It is possible to ask the RTS to give some information about
1389 itself. To do this, use the <option>--info</option> flag, e.g.</para>
1390 <screen>
1391 $ ./a.out +RTS --info
1392 [("GHC RTS", "YES")
1393 ,("GHC version", "6.7")
1394 ,("RTS way", "rts_p")
1395 ,("Host platform", "x86_64-unknown-linux")
1396 ,("Host architecture", "x86_64")
1397 ,("Host OS", "linux")
1398 ,("Host vendor", "unknown")
1399 ,("Build platform", "x86_64-unknown-linux")
1400 ,("Build architecture", "x86_64")
1401 ,("Build OS", "linux")
1402 ,("Build vendor", "unknown")
1403 ,("Target platform", "x86_64-unknown-linux")
1404 ,("Target architecture", "x86_64")
1405 ,("Target OS", "linux")
1406 ,("Target vendor", "unknown")
1407 ,("Word size", "64")
1408 ,("Compiler unregisterised", "NO")
1409 ,("Tables next to code", "YES")
1410 ]
1411 </screen>
1412 <para>The information is formatted such that it can be read as a
1413 of type <literal>[(String, String)]</literal>. Currently the following
1414 fields are present:</para>
1415
1416 <variablelist>
1417
1418 <varlistentry>
1419 <term><literal>GHC RTS</literal></term>
1420 <listitem>
1421 <para>Is this program linked against the GHC RTS? (always
1422 "YES").</para>
1423 </listitem>
1424 </varlistentry>
1425
1426 <varlistentry>
1427 <term><literal>GHC version</literal></term>
1428 <listitem>
1429 <para>The version of GHC used to compile this program.</para>
1430 </listitem>
1431 </varlistentry>
1432
1433 <varlistentry>
1434 <term><literal>RTS way</literal></term>
1435 <listitem>
1436 <para>The variant (&ldquo;way&rdquo;) of the runtime. The
1437 most common values are <literal>rts</literal> (vanilla),
1438 <literal>rts_thr</literal> (threaded runtime, i.e. linked using the
1439 <literal>-threaded</literal> option) and <literal>rts_p</literal>
1440 (profiling runtime, i.e. linked using the <literal>-prof</literal>
1441 option). Other variants include <literal>debug</literal>
1442 (linked using <literal>-debug</literal>),
1443 <literal>t</literal> (ticky-ticky profiling) and
1444 <literal>dyn</literal> (the RTS is
1445 linked in dynamically, i.e. a shared library, rather than statically
1446 linked into the executable itself). These can be combined,
1447 e.g. you might have <literal>rts_thr_debug_p</literal>.</para>
1448 </listitem>
1449 </varlistentry>
1450
1451 <varlistentry>
1452 <term>
1453 <literal>Target platform</literal>,
1454 <literal>Target architecture</literal>,
1455 <literal>Target OS</literal>,
1456 <literal>Target vendor</literal>
1457 </term>
1458 <listitem>
1459 <para>These are the platform the program is compiled to run on.</para>
1460 </listitem>
1461 </varlistentry>
1462
1463 <varlistentry>
1464 <term>
1465 <literal>Build platform</literal>,
1466 <literal>Build architecture</literal>,
1467 <literal>Build OS</literal>,
1468 <literal>Build vendor</literal>
1469 </term>
1470 <listitem>
1471 <para>These are the platform where the program was built
1472 on. (That is, the target platform of GHC itself.) Ordinarily
1473 this is identical to the target platform. (It could potentially
1474 be different if cross-compiling.)</para>
1475 </listitem>
1476 </varlistentry>
1477
1478 <varlistentry>
1479 <term>
1480 <literal>Host platform</literal>,
1481 <literal>Host architecture</literal>
1482 <literal>Host OS</literal>
1483 <literal>Host vendor</literal>
1484 </term>
1485 <listitem>
1486 <para>These are the platform where GHC itself was compiled.
1487 Again, this would normally be identical to the build and
1488 target platforms.</para>
1489 </listitem>
1490 </varlistentry>
1491
1492 <varlistentry>
1493 <term><literal>Word size</literal></term>
1494 <listitem>
1495 <para>Either <literal>"32"</literal> or <literal>"64"</literal>,
1496 reflecting the word size of the target platform.</para>
1497 </listitem>
1498 </varlistentry>
1499
1500 <varlistentry>
1501 <term><literal>Compiler unregistered</literal></term>
1502 <listitem>
1503 <para>Was this program compiled with an &ldquo;unregistered&rdquo;
1504 version of GHC? (I.e., a version of GHC that has no platform-specific
1505 optimisations compiled in, usually because this is a currently
1506 unsupported platform.) This value will usually be no, unless you're
1507 using an experimental build of GHC.</para>
1508 </listitem>
1509 </varlistentry>
1510
1511 <varlistentry>
1512 <term><literal>Tables next to code</literal></term>
1513 <listitem>
1514 <para>Putting info tables directly next to entry code is a useful
1515 performance optimisation that is not available on all platforms.
1516 This field tells you whether the program has been compiled with
1517 this optimisation. (Usually yes, except on unusual platforms.)</para>
1518 </listitem>
1519 </varlistentry>
1520
1521 </variablelist>
1522
1523 </sect2>
1524 </sect1>
1525
1526 <!-- Emacs stuff:
1527 ;;; Local Variables: ***
1528 ;;; sgml-parent-document: ("users_guide.xml" "book" "chapter" "sect1") ***
1529 ;;; End: ***
1530 -->