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