X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=docs%2Fusers_guide%2Fruntime_control.xml;h=69e26bc9208ea67c35b1a81d01e065f05a459324;hb=9ee105bd1f977a8fd68281e7658383d5a0c86156;hp=62a01acdda4b35b98dbe307c4a24c7fd48ff538d;hpb=5263c9ab4408e3b62dbf7505ab40a81946d4e49b;p=ghc-hetmet.git
diff --git a/docs/users_guide/runtime_control.xml b/docs/users_guide/runtime_control.xml
index 62a01ac..69e26bc 100644
--- a/docs/users_guide/runtime_control.xml
+++ b/docs/users_guide/runtime_control.xml
@@ -130,6 +130,35 @@
own signal handlers.
+
+
+
+ RTS
+ option
+
+
+ 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.
+
+
+
@@ -153,7 +182,7 @@
allocation area, size
- [Default: 256k] Set the allocation area size
+ [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 , below).
@@ -268,6 +297,57 @@
+
+
+ RTS
+ option
+
+
+ [New in GHC 6.12.1] Disable the parallel GC.
+ The parallel GC is turned on automatically when parallel
+ execution is enabled with the option;
+ this option is available to turn it off if
+ necessary.
+
+ Experiments have shown that parallel GC usually
+ results in a performance improvement given 3 cores or
+ more; with 2 cores it may or may not be beneficial,
+ depending on the workload. Bigger heaps work better with
+ parallel GC, so set your value high (3
+ or more times the maximum residency). Look at the timing
+ stats with to see whether you're
+ getting any benefit from parallel GC or not. If you find
+ parallel GC is significantly slower
+ (in elapsed time) than sequential GC, please report it as
+ a bug.
+
+ In GHC 6.10.1 it was possible to use a different
+ number of threads for GC than for execution, because the GC
+ used its own pool of threads. Now, the GC uses the same
+ threads as the mutator (for executing the program).
+
+
+
+
+
+
+ RTS
+ option
+
+
+
+ [Default: 1] [New in GHC 6.12.1]
+ Enable the parallel GC only in
+ generation n and greater.
+ Parallel GC is often not worthwhile for collections in
+ generation 0 (the young generation), so it is enabled by
+ default only for collections in generation 1 (and higher,
+ if applicable).
+
+
+
+
+ sizeRTS option
@@ -399,46 +479,290 @@
+
+ file
+ RTS option
+
- file
+ fileRTS option
- file
+ fileRTS option
-
- Write modest () or verbose
- () garbage-collector statistics into file
- file. The default
- file is
- program.stat. The
- filestderr
- is treated specially, with the output really being sent to
- stderr.
-
- This option is useful for watching how the storage
- manager adjusts the heap size based on the current amount of
- live data.
-
-
-
-
-
- RTS option
+
+ RTS option
- Write a one-line GC stats summary after running the
- program. This output is in the same format as that produced
- by the option.
-
- As with , the default
- file is
- program.stat. The
- filestderr
- is treated specially, with the output really being sent to
- stderr.
+ 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:
+ produces a single line of output in the
+ same format as GHC's option,
+ produces a more detailed summary at the
+ end of the program, and 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, 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:
+
+
+
+
+
+ The total number of bytes allocated by the program over the
+ whole run.
+
+
+
+
+ The total number of garbage collections performed.
+
+
+
+
+ The average and maximum "residency", which is the amount of
+ live data in bytes. The runtime can only determine the
+ amount of live data during a major GC, which is why the
+ number of samples corresponds to the number of major GCs
+ (and is usually relatively small). To get a better picture
+ of the heap profile of your program, use
+ the RTS option
+ ().
+
+
+
+
+ The peak memory the RTS has allocated from the OS.
+
+
+
+
+ The amount of CPU time and elapsed wall clock time while
+ initialising the runtime system (INIT), running the program
+ itself (MUT, the mutator), and garbage collecting (GC).
+
+
+
+
+
+ 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 "bytes allocated in the heap" is the total bytes allocated
+ by the program over the whole run.
+
+
+
+
+ GHC uses a copying garbage collector by default. "bytes copied
+ during GC" tells you how many bytes it had to copy during
+ garbage collection.
+
+
+
+
+ The maximum space actually used by your program is the
+ "bytes maximum residency" figure. This is only checked during
+ major garbage collections, so it is only an approximation;
+ the number of samples tells you how many times it is checked.
+
+
+
+
+ The "bytes maximum slop" tells you the most space that is ever
+ wasted due to the way GHC allocates memory in blocks. Slop is
+ memory at the end of a block that was wasted. There's no way
+ to control this; we just like to see how much memory is being
+ lost this way.
+
+
+
+
+ The "total memory in use" tells you the peak memory the RTS has
+ allocated from the OS.
+
+
+
+
+ Next there is information about the garbage collections done.
+ For each generation it says how many garbage collections were
+ done, how many of those collections were done in parallel,
+ the total CPU time used for garbage collecting that generation,
+ and the total wall clock time elapsed while garbage collecting
+ that generation.
+
+
+
+ The SPARKS statistic refers to the
+ use of Control.Parallel.par and related
+ functionality in the program. Each spark represents a call
+ to par; a spark is "converted" when it is
+ executed in parallel; and a spark is "pruned" when it is
+ found to be already evaluated and is discarded from the pool
+ by the garbage collector. Any remaining sparks are
+ discarded at the end of execution, so "converted" plus
+ "pruned" does not necessarily add up to the total.
+
+
+
+ Next there is the CPU time and wall clock time elapsed broken
+ down by what the runtime system was doing at the time.
+ INIT is the runtime system initialisation.
+ MUT is the mutator time, i.e. the time spent actually running
+ your code.
+ GC is the time spent doing garbage collection.
+ RP is the time spent doing retainer profiling.
+ PROF is the time spent doing other profiling.
+ EXIT is the runtime system shutdown time.
+ And finally, Total is, of course, the total.
+
+
+ %GC time tells you what percentage GC is of Total.
+ "Alloc rate" tells you the "bytes allocated in the heap" divided
+ by the MUT CPU time.
+ "Productivity" tells you what percentage of the Total CPU and wall
+ clock elapsed times are spent in the mutator (MUT).
+
+
+
+
+
+ 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:
+
+
+
+
+
+ How many bytes we allocated this garbage collection.
+
+
+
+
+ How many bytes we copied this garbage collection.
+
+
+
+
+ How many bytes are currently live.
+
+
+
+
+ How long this garbage collection took (CPU time and elapsed
+ wall clock time).
+
+
+
+
+ How long the program has been running (CPU time and elapsed
+ wall clock time).
+
+
+
+
+ How many page faults occured this garbage collection.
+
+
+
+
+ How many page faults occured since the end of the last garbage
+ collection.
+
+
+
+
+ Which generation is being garbage collected.
+
+
+
+
@@ -446,14 +770,46 @@
- RTS options for profiling and parallelism
+ RTS options for concurrency and parallelism
- The RTS options related to profiling are described in , those for concurrency in
+ The RTS options related to concurrency are described in
, and those for parallelism in
.
+
+ RTS options for profiling
+
+ Most profiling runtime options are only available when you
+ compile your program for profiling (see
+ , and
+ for the runtime options).
+ However, there is one profiling option that is available
+ for ordinary non-profiled executables:
+
+
+
+
+
+ RTS
+ option
+
+
+ Generates a basic heap profile, in the
+ file prog.hp.
+ To produce the heap profile graph,
+ use hp2ps (see ). 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 ().
+
+
+
+
+
RTS options for hackers, debuggers, and over-interested
souls
@@ -671,18 +1027,137 @@ char *ghc_rts_opts = "-H128m -K1m";
itself. To do this, use the flag, e.g.
$ ./a.out +RTS --info
- [("GHC RTS", "Yes")
+ [("GHC RTS", "YES")
,("GHC version", "6.7")
,("RTS way", "rts_p")
,("Host platform", "x86_64-unknown-linux")
+ ,("Host architecture", "x86_64")
+ ,("Host OS", "linux")
+ ,("Host vendor", "unknown")
,("Build platform", "x86_64-unknown-linux")
+ ,("Build architecture", "x86_64")
+ ,("Build OS", "linux")
+ ,("Build vendor", "unknown")
,("Target platform", "x86_64-unknown-linux")
+ ,("Target architecture", "x86_64")
+ ,("Target OS", "linux")
+ ,("Target vendor", "unknown")
+ ,("Word size", "64")
,("Compiler unregisterised", "NO")
,("Tables next to code", "YES")
]
The information is formatted such that it can be read as a
- of type [(String, String)].
+ of type [(String, String)]. Currently the following
+ fields are present:
+
+
+
+
+ GHC RTS
+
+ Is this program linked against the GHC RTS? (always
+ "YES").
+
+
+
+
+ GHC version
+
+ The version of GHC used to compile this program.
+
+
+
+
+ RTS way
+
+ The variant (“way”) of the runtime. The
+ most common values are rts (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.
+
+
+
+
+
+ Target platform,
+ Target architecture,
+ Target OS,
+ Target vendor
+
+
+ These are the platform the program is compiled to run on.
+
+
+
+
+
+ Build platform,
+ Build architecture,
+ Build OS,
+ Build vendor
+
+
+ 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.)
+
+
+
+
+
+ Host platform,
+ Host architecture
+ Host OS
+ Host vendor
+
+
+ These are the platform where GHC itself was compiled.
+ Again, this would normally be identical to the build and
+ target platforms.
+
+
+
+
+ Word size
+
+ Either "32" or "64",
+ reflecting the word size of the target platform.
+
+
+
+
+ Compiler unregistered
+
+ 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.
+
+
+
+
+ Tables next to code
+
+ 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.)
+
+
+
+
+