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