Sets the interval that the RTS clock ticks at. The runtime uses a single timer signal to count ticks; this timer signal is used to control the context switch timer (Section 4.14, “Using Concurrent Haskell”) and the heap profiling timer Section 5.4.1, “RTS options for heap profiling”. Also, the time profiler uses the RTS timer signal directly to record time profiling samples.

Normally, setting the -V option directly is not necessary: the resolution of the RTS timer is adjusted automatically if a short interval is requested with the -C or -i options. However, setting -V is required in order to increase the resolution of the time profiler.

Using a value of zero disables the RTS clock completely, and has the effect of disabling timers that depend on it: the context switch timer and the heap profiling timer. Context switches will still happen, but deterministically and at a rate much faster than normal. Disabling the interval timer is useful for debugging, because it eliminates a source of non-determinism at runtime.

If yes (the default), the RTS installs signal handlers to catch things like ctrl-C. This option is primarily useful for when you are using the Haskell code as a DLL, and want to set your own signal handlers.

Note that even with --install-signal-handlers=no, the RTS interval timer signal is still enabled. The timer signal is either SIGVTALRM or SIGALRM, depending on the RTS configuration and OS capabilities. To disable the timer signal, use the -V0 RTS option (see above).

WARNING: this option is for working around memory allocation problems only. Do not use unless GHCi fails with a message like “failed to mmap() memory below 2Gb”. If you need to use this option to get GHCi working on your machine, please file a bug.

On 64-bit machines, the RTS needs to allocate memory in the low 2Gb of the address space. Support for this across different operating systems is patchy, and sometimes fails. This option is there to give the RTS a hint about where it should be able to allocate memory in the low 2Gb of the address space. For example, +RTS -xm20000000 -RTS would hint that the RTS should allocate starting at the 0.5Gb mark. The default is to use the OS's built-in support for allocating memory in the low 2Gb if available (e.g. mmap with MAP_32BIT on Linux), or otherwise -xm40000000.

[Default: 512k] Set the allocation area size used by the garbage collector. The allocation area (actually generation 0 step 0) is fixed and is never resized (unless you use -H, below).

Increasing the allocation area size may or may not give better performance (a bigger allocation area means worse cache behaviour but fewer garbage collections and less promotion).

With only 1 generation (-G1) the -A option specifies the minimum allocation area, since the actual size of the allocation area will be resized according to the amount of data in the heap (see -F, below).

Use a compacting algorithm for collecting the oldest generation. By default, the oldest generation is collected using a copying algorithm; this option causes it to be compacted in-place instead. The compaction algorithm is slower than the copying algorithm, but the savings in memory use can be considerable.

For a given heap size (using the -H option), compaction can in fact reduce the GC cost by allowing fewer GCs to be performed. This is more likely when the ratio of live data to heap size is high, say >30%.

NOTE: compaction doesn't currently work when a single generation is requested using the -G1 option.

[Default: 30] Automatically enable compacting collection when the live data exceeds n% of the maximum heap size (see the -M option). Note that the maximum heap size is unlimited by default, so this option has no effect unless the maximum heap size is set with -Msize.

[Default: 2] This option controls the amount of memory reserved for the older generations (and in the case of a two space collector the size of the allocation area) as a factor of the amount of live data. For example, if there was 2M of live data in the oldest generation when we last collected it, then by default we'll wait until it grows to 4M before collecting it again.

The default seems to work well here. If you have plenty of memory, it is usually better to use -Hsize than to increase -Ffactor.

The -F setting will be automatically reduced by the garbage collector when the maximum heap size (the -Msize setting) is approaching.

[Default: 2] Set the number of generations used by the garbage collector. The default of 2 seems to be good, but the garbage collector can support any number of generations. Anything larger than about 4 is probably not a good idea unless your program runs for a long time, because the oldest generation will hardly ever get collected.

Specifying 1 generation with +RTS -G1 gives you a simple 2-space collector, as you would expect. In a 2-space collector, the -A option (see above) specifies the minimum allocation area size, since the allocation area will grow with the amount of live data in the heap. In a multi-generational collector the allocation area is a fixed size (unless you use the -H option, see below).

[New in GHC 6.12.1] [Default: 0] Use parallel GC in generation gen and higher. Omitting gen turns off the parallel GC completely, reverting to sequential GC.

The default parallel GC settings are usually suitable for parallel programs (i.e. those using par, Strategies, or with multiple threads). However, it is sometimes beneficial to enable the parallel GC for a single-threaded sequential program too, especially if the program has a large amount of heap data and GC is a significant fraction of runtime. To use the parallel GC in a sequential program, enable the parallel runtime with a suitable -N option, and additionally it might be beneficial to restrict parallel GC to the old generation with -qg1.

[New in GHC 6.12.1] [Default: 1] Use load-balancing in the parallel GC in generation gen and higher. Omitting gen disables load-balancing entirely.

Load-balancing shares out the work of GC between the available cores. This is a good idea when the heap is large and we need to parallelise the GC work, however it is also pessimal for the short young-generation collections in a parallel program, because it can harm locality by moving data from the cache of the CPU where is it being used to the cache of another CPU. Hence the default is to do load-balancing only in the old-generation. In fact, for a parallel program it is sometimes beneficial to disable load-balancing entirely with -qb.

[Default: 0] This option provides a “suggested heap size” for the garbage collector. Think of -Hsize as a variable -A option. It says: I want to use at least size bytes, so use whatever is left over to increase the -A value.

This option does not put a limit on the heap size: the heap may grow beyond the given size as usual.

If size is omitted, then the garbage collector will take the size of the heap at the previous GC as the size. This has the effect of allowing for a larger -A value but without increasing the overall memory requirements of the program. It can be useful when the default small -A value is suboptimal, as it can be in programs that create large amounts of long-lived data.

(default: 0.3) In the threaded and SMP versions of the RTS (see -threaded, Section 4.12.6, “Options affecting linking”), a major GC is automatically performed if the runtime has been idle (no Haskell computation has been running) for a period of time. The amount of idle time which must pass before a GC is performed is set by the -Iseconds option. Specifying -I0 disables the idle GC.

For an interactive application, it is probably a good idea to use the idle GC, because this will allow finalizers to run and deadlocked threads to be detected in the idle time when no Haskell computation is happening. Also, it will mean that a GC is less likely to happen when the application is busy, and so responsiveness may be improved. However, if the amount of live data in the heap is particularly large, then the idle GC can cause a significant delay, and too small an interval could adversely affect interactive responsiveness.

This is an experimental feature, please let us know if it causes problems and/or could benefit from further tuning.

[Default: 1k] Set the initial stack size for new threads. (Note: this flag used to be simply -k, but was renamed to -ki in GHC 7.2.1. The old name is still accepted for backwards compatibility, but that may be removed in a future version).

Thread stacks (including the main thread's stack) live on the heap. As the stack grows, new stack chunks are added as required; if the stack shrinks again, these extra stack chunks are reclaimed by the garbage collector. The default initial stack size is deliberately small, in order to keep the time and space overhead for thread creation to a minimum, and to make it practical to spawn threads for even tiny pieces of work.

[Default: 32k] Set the size of “stack chunks”. When a thread's current stack overflows, a new stack chunk is created and added to the thread's stack, until the limit set by -K is reached.

The advantage of smaller stack chunks is that the garbage collector can avoid traversing stack chunks if they are known to be unmodified since the last collection, so reducing the chunk size means that the garbage collector can identify more stack as unmodified, and the GC overhead might be reduced. On the other hand, making stack chunks too small adds some overhead as there will be more overflow/underflow between chunks. The default setting of 32k appears to be a reasonable compromise in most cases.

[Default: 1k] Sets the stack chunk buffer size. When a stack chunk overflows and a new stack chunk is created, some of the data from the previous stack chunk is moved into the new chunk, to avoid an immediate underflow and repeated overflow/underflow at the boundary. The amount of stack moved is set by the -kb option.

Note that to avoid wasting space, this value should typically be less than 10% of the size of a stack chunk (-kc), because in a chain of stack chunks, each chunk will have a gap of unused space of this size.

[Default: 80% physical memory size] Set the maximum stack size for an individual thread to size bytes. If the thread attempts to exceed this limit, it will be sent the StackOverflow exception. The limit can be disabled entirely by specifying a size of zero.

This option is there mainly to stop the program eating up all the available memory in the machine if it gets into an infinite loop.

Minimum % n of heap which must be available for allocation. The default is 3%.

[Default: unlimited] Set the maximum heap size to size bytes. The heap normally grows and shrinks according to the memory requirements of the program. The only reason for having this option is to stop the heap growing without bound and filling up all the available swap space, which at the least will result in the program being summarily killed by the operating system.

The maximum heap size also affects other garbage collection parameters: when the amount of live data in the heap exceeds a certain fraction of the maximum heap size, compacting collection will be automatically enabled for the oldest generation, and the -F parameter will be reduced in order to avoid exceeding the maximum heap size.

These options produce runtime-system statistics, such as the amount of time spent executing the program and in the garbage collector, the amount of memory allocated, the maximum size of the heap, and so on. The three variants give different levels of detail: -T collects the data but produces no output -t produces a single line of output in the same format as GHC's -Rghc-timing option, -s produces a more detailed summary at the end of the program, and -S additionally produces information about each and every garbage collection.

The output is placed in file. If file is omitted, then the output is sent to stderr.

If you use the -T flag then, you should access the statistics using GHC.Stats.

If you use the -t flag then, when your program finishes, you will see something like this:

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

This tells you:

You can also get this in a more future-proof, machine readable format, with -t --machine-readable:

 [("bytes allocated", "36169392")
 ,("num_GCs", "69")
 ,("average_bytes_used", "603392")
 ,("max_bytes_used", "1065272")
 ,("num_byte_usage_samples", "2")
 ,("peak_megabytes_allocated", "3")
 ,("init_cpu_seconds", "0.00")
 ,("init_wall_seconds", "0.00")
 ,("mutator_cpu_seconds", "0.02")
 ,("mutator_wall_seconds", "0.02")
 ,("GC_cpu_seconds", "0.07")
 ,("GC_wall_seconds", "0.07")
 ]

If you use the -s flag then, when your program finishes, you will see something like this (the exact details will vary depending on what sort of RTS you have, e.g. you will only see profiling data if your RTS is compiled for profiling):

      36,169,392 bytes allocated in the heap
       4,057,632 bytes copied during GC
       1,065,272 bytes maximum residency (2 sample(s))
          54,312 bytes maximum slop
               3 MB total memory in use (0 MB lost due to fragmentation)

  Generation 0:    67 collections,     0 parallel,  0.04s,  0.03s elapsed
  Generation 1:     2 collections,     0 parallel,  0.03s,  0.04s elapsed

  SPARKS: 359207 (557 converted, 149591 pruned)

  INIT  time    0.00s  (  0.00s elapsed)
  MUT   time    0.01s  (  0.02s elapsed)
  GC    time    0.07s  (  0.07s elapsed)
  EXIT  time    0.00s  (  0.00s elapsed)
  Total time    0.08s  (  0.09s elapsed)

  %GC time      89.5%  (75.3% elapsed)

  Alloc rate    4,520,608,923 bytes per MUT second

  Productivity  10.5% of total user, 9.1% of total elapsed

The -S flag, as well as giving the same output as the -s flag, prints information about each GC as it happens:

    Alloc    Copied     Live    GC    GC     TOT     TOT  Page Flts
    bytes     bytes     bytes  user  elap    user    elap
   528496     47728    141512  0.01  0.02    0.02    0.02    0    0  (Gen:  1)
[...]
   524944    175944   1726384  0.00  0.00    0.08    0.11    0    0  (Gen:  0)

For each garbage collection, we print:

(can be shortened to -h.) Generates a basic heap profile, in the file prog.hp. To produce the heap profile graph, use hp2ps (see Section 5.5, “hp2ps--heap profile to PostScript”). The basic heap profile is broken down by data constructor, with other types of closures (functions, thunks, etc.) grouped into broad categories (e.g. FUN, THUNK). To get a more detailed profile, use the full profiling support (Chapter 5, Profiling).

Log events in binary format to the file program.eventlog. Without any flags specified, this logs a default set of events, suitable for use with tools like ThreadScope.

For some special use cases you may want more control over which events are included. The flags is a sequence of zero or more characters indicating which classes of events to log. Currently these the classes of events that can be enabled/disabled:

You can disable specific classes, or enable/disable all classes at once:

For example, -l-ag would disable all event classes (-a) except for GC events (g).

For spark events there are two modes: sampled and fully accurate. There are various events in the life cycle of each spark, usually just creating and running, but there are some more exceptional possibilities. In the sampled mode the number of occurrences of each kind of spark event is sampled at frequent intervals. In the fully accurate mode every spark event is logged individually. The latter has a higher runtime overhead and is not enabled by default.

The format of the log file is described by the header EventLogFormat.h that comes with GHC, and it can be parsed in Haskell using the ghc-events library. To dump the contents of a .eventlog file as text, use the tool ghc-events show that comes with the ghc-events package.

Log events as text to standard output, instead of to the .eventlog file. The flags are the same as for -l, with the additional option t which indicates that the each event printed should be preceded by a timestamp value (in the binary .eventlog file, all events are automatically associated with a timestamp).

Sound the bell at the start of each (major) garbage collection.

Oddly enough, people really do use this option! Our pal in Durham (England), Paul Callaghan, writes: “Some people here use it for a variety of purposes—honestly!—e.g., confirmation that the code/machine is doing something, infinite loop detection, gauging cost of recently added code. Certain people can even tell what stage [the program] is in by the beep pattern. But the major use is for annoying others in the same office…”

An RTS debugging flag; only available if the program was linked with the -debug option. Various values of x are provided to enable debug messages and additional runtime sanity checks in different subsystems in the RTS, for example +RTS -Ds -RTS enables debug messages from the scheduler. Use +RTS -? to find out which debug flags are supported.

Debug messages will be sent to the binary event log file instead of stdout if the -l option is added. This might be useful for reducing the overhead of debug tracing.

Produce “ticky-ticky” statistics at the end of the program run (only available if the program was linked with -debug). The file business works just like on the -S RTS option, above.

For more information on ticky-ticky profiling, see Section 5.8, “Using “ticky-ticky” profiling (for implementors)”.

(Only available when the program is compiled for profiling.) When an exception is raised in the program, this option causes a stack trace to be dumped to stderr.

This can be particularly useful for debugging: if your program is complaining about a head [] error and you haven't got a clue which bit of code is causing it, compiling with -prof -fprof-auto and running with +RTS -xc -RTS will tell you exactly the call stack at the point the error was raised.

The output contains one report for each exception raised in the program (the program might raise and catch several exceptions during its execution), where each report looks something like this:

*** Exception raised (reporting due to +RTS -xc), stack trace:
  GHC.List.CAF
  --> evaluated by: Main.polynomial.table_search,
  called from Main.polynomial.theta_index,
  called from Main.polynomial,
  called from Main.zonal_pressure,
  called from Main.make_pressure.p,
  called from Main.make_pressure,
  called from Main.compute_initial_state.p,
  called from Main.compute_initial_state,
  called from Main.CAF
  ...

The stack trace may often begin with something uninformative like GHC.List.CAF; this is an artifact of GHC's optimiser, which lifts out exceptions to the top-level where the profiling system assigns them to the cost centre "CAF". However, +RTS -xc doesn't just print the current stack, it looks deeper and reports the stack at the time the CAF was evaluated, and it may report further stacks until a non-CAF stack is found. In the example above, the next stack (after --> evaluated by) contains plenty of information about what the program was doing when it evaluated head [].

Implementation details aside, the function names in the stack should hopefully give you enough clues to track down the bug.

See also the function traceStack in the module Debug.Trace for another way to view call stacks.

Turn off “update-frame squeezing” at garbage-collection time. (There's no particularly good reason to turn it off, except to ensure the accuracy of certain data collected regarding thunk entry counts.)

Is this program linked against the GHC RTS? (always "YES").

The version of GHC used to compile this program.

The variant (“way”) of the runtime. The most common values are rts_v (vanilla), rts_thr (threaded runtime, i.e. linked using the -threaded option) and rts_p (profiling runtime, i.e. linked using the -prof option). Other variants include debug (linked using -debug), t (ticky-ticky profiling) and dyn (the RTS is linked in dynamically, i.e. a shared library, rather than statically linked into the executable itself). These can be combined, e.g. you might have rts_thr_debug_p.

These are the platform the program is compiled to run on.

These are the platform where the program was built on. (That is, the target platform of GHC itself.) Ordinarily this is identical to the target platform. (It could potentially be different if cross-compiling.)

These are the platform where GHC itself was compiled. Again, this would normally be identical to the build and target platforms.

Either "32" or "64", reflecting the word size of the target platform.

Was this program compiled with an “unregistered” version of GHC? (I.e., a version of GHC that has no platform-specific optimisations compiled in, usually because this is a currently unsupported platform.) This value will usually be no, unless you're using an experimental build of GHC.

Putting info tables directly next to entry code is a useful performance optimisation that is not available on all platforms. This field tells you whether the program has been compiled with this optimisation. (Usually yes, except on unusual platforms.)