Pass --enable-shared and --with-hscolour to ghc-cabal configure
[ghc-hetmet.git] / docs / users_guide / runtime_control.xml
index d8735e2..69e26bc 100644 (file)
           <indexterm><primary>allocation area, size</primary></indexterm>
         </term>
        <listitem>
-         <para>&lsqb;Default: 256k&rsqb; Set the allocation area size
+         <para>&lsqb;Default: 512k&rsqb; 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 <option>-H</option>, below).</para>
     <itemizedlist>
       <listitem>
         <para>
-          The total bytes allocated by the program. This may be less
-          than the peak memory use, as some may be freed. 
+          The total number of bytes allocated by the program over the
+          whole run.
         </para>
       </listitem>
       <listitem>
         <para>
-          The total number of garbage collections that occurred.
+          The total number of garbage collections performed.
         </para>
       </listitem>
       <listitem>
         <para>
-          The average and maximum space used by your program.
-          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 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 <option>-hT</option> RTS option
+          (<xref linkend="rts-profiling" />).
         </para>
       </listitem>
       <listitem>
       <listitem>
         <para>
         The "bytes allocated in the heap" is the total bytes allocated
-        by the program. This may be less than the peak memory use, as
-        some may be freed.
+        by the program over the whole run.
         </para>
       </listitem>
       <listitem>
         <para>
-        GHC uses a copying garbage collector. "bytes copied during GC" 
-        tells you how many bytes it had to copy during garbage collection.
+        GHC uses a copying garbage collector by default. "bytes copied
+        during GC" tells you how many bytes it had to copy during
+        garbage collection.
         </para>
       </listitem>
       <listitem>
       <listitem>
         <para>
         The "bytes maximum slop" tells you the most space that is ever
-        wasted due to the way GHC packs data into so-called "megablocks".
+        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.
         </para>
       </listitem>
       <listitem>
         <para>
         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 used multiple threads,
+        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.
       </listitem>
       <listitem>
         <para>
-        Next there is the CPU time and wall clock time elapsedm broken
-        down by what the runtiem system was doing at the time.
+        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.
@@ -1020,12 +1027,22 @@ char *ghc_rts_opts = "-H128m -K1m";
     itself. To do this, use the <option>--info</option> flag, e.g.</para>
 <screen>
 $ ./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")
  ]
@@ -1039,8 +1056,8 @@ $ ./a.out +RTS --info
       <varlistentry>
         <term><literal>GHC RTS</literal></term>
         <listitem>
-          <para>Is this program linked against the GHC RTS? (Currently
-          the answer is always yes.)</para>
+          <para>Is this program linked against the GHC RTS? (always
+          "YES").</para>
         </listitem>
       </varlistentry>
 
@@ -1054,45 +1071,71 @@ $ ./a.out +RTS --info
       <varlistentry>
         <term><literal>RTS way</literal></term>
         <listitem>
-          <para>The variant (&ldquo;way&rdquo;) of the runtime. Possible
-          values are <literal>rts</literal> (vanilla), 
+          <para>The variant (&ldquo;way&rdquo;) of the runtime. The
+          most common values are <literal>rts</literal> (vanilla),
           <literal>rts_thr</literal> (threaded runtime, i.e. linked using the
           <literal>-threaded</literal> option) and <literal>rts_p</literal>
           (profiling runtime, i.e. linked using the <literal>-prof</literal>
-          option). Other variants include <literal>t</literal>
-          (ticky-ticky profiling) and <literal>dyn</literal> (the RTS is
+          option). Other variants include <literal>debug</literal>
+          (linked using <literal>-debug</literal>),
+          <literal>t</literal> (ticky-ticky profiling) and
+          <literal>dyn</literal> (the RTS is
           linked in dynamically, i.e. a shared library, rather than statically
-          linked into the executable itself).</para>
+          linked into the executable itself). These can be combined,
+          e.g. you might have <literal>rts_thr_debug_p</literal>.</para>
         </listitem>
       </varlistentry>
 
       <varlistentry>
-        <term><literal>Target platform</literal></term>
+        <term>
+            <literal>Target platform</literal>,
+            <literal>Target architecture</literal>,
+            <literal>Target OS</literal>,
+            <literal>Target vendor</literal>
+        </term>
         <listitem>
-          <para>This is the platform the program is compiled to run on.</para>
+          <para>These are the platform the program is compiled to run on.</para>
         </listitem>
       </varlistentry>
 
       <varlistentry>
-        <term><literal>Build platform</literal></term>
+        <term>
+            <literal>Build platform</literal>,
+            <literal>Build architecture</literal>,
+            <literal>Build OS</literal>,
+            <literal>Build vendor</literal>
+        </term>
         <listitem>
-          <para>This is the platform where the program was compiled
-          from. (That is, the target platform of GHC itself.) Ordinarily
+          <para>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.)</para>
         </listitem>
       </varlistentry>
 
       <varlistentry>
-        <term><literal>Host platform</literal></term>
+        <term>
+            <literal>Host platform</literal>,
+            <literal>Host architecture</literal>
+            <literal>Host OS</literal>
+            <literal>Host vendor</literal>
+        </term>
         <listitem>
-          <para>This is the platform where GHC itself was compiled.
+          <para>These are the platform where GHC itself was compiled.
           Again, this would normally be identical to the build and
           target platforms.</para>
         </listitem>
       </varlistentry>
 
       <varlistentry>
+        <term><literal>Word size</literal></term>
+        <listitem>
+          <para>Either <literal>"32"</literal> or <literal>"64"</literal>,
+          reflecting the word size of the target platform.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
         <term><literal>Compiler unregistered</literal></term>
         <listitem>
           <para>Was this program compiled with an &ldquo;unregistered&rdquo;