boehm-gc: revert all CACAO-specific modifications; this is now an exact copy of the...
[cacao.git] / src / mm / boehm-gc / doc / simple_example.html
index 0bc0953ef032d608cbaef5d0ac13f54313f1ddbc..6ca3eee6735ef9c786475613f3f58167e3f34764 100644 (file)
@@ -1,5 +1,7 @@
-<HTML>
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<html lang="en-us">
 <HEAD>
+<meta http-equiv="Content-Type" content="text/html;charset=US-ASCII" >
 <TITLE>Using the Garbage Collector: A simple example</title>
 </head>
 <BODY>
@@ -13,8 +15,8 @@ It can be skipped, especially on first reading</font>.
 If you haven't already so, unpack the collector and enter
 the newly created directory with
 <PRE>
-tar xvfz gc<version>.tar.gz
-cd gc<version>
+tar xvfz gc&lt;version&gt;.tar.gz
+cd gc&lt;version&gt;
 </pre>
 <P>
 You can configure, build, and install the collector in a private
@@ -27,8 +29,8 @@ make install
 </pre>
 Here the "<TT>make check</tt>" command is optional, but highly recommended.
 It runs a basic correctness test which usually takes well under a minute.
+<H3><FONT COLOR=green>Other platforms</font></h3>
 <FONT COLOR=green>
-<H3>Other platforms</h3>
 On non-Unix, non-Linux platforms, the collector is usually built by copying
 the appropriate makefile (see the platform-specific README in doc/README.xxx
 in the distribution) to the file "Makefile" (overwriting the copy of
@@ -36,24 +38,34 @@ Makefile.direct that was originally there), and then typing "make"
 (or "nmake" or ...).  This builds the library in the source tree.  You may
 want to move it and the files in the include directory to a more convenient
 place.
+</font>
 <P>
+<FONT COLOR=green>
 If you use a makefile that does not require running a configure script,
 you should first look at the makefile, and adjust any options that are
 documented there.
+</font>
 <P>
+<FONT COLOR=green>
 If your platform provides a "make" utility, that is generally preferred
 to platform- and compiler- dependent "project" files.  (At least that is the
 strong preference of the would-be maintainer of those project files.)
-<H3>Threads</h3>
+</font>
+<H3><FONT COLOR=green>Threads</font></h3>
+<FONT COLOR=green>
 If you need thread support, configure the collector with
-<PRE>
+</font>
+<PRE style="color:green">
 --enable-threads=posix --enable-thread-local-alloc --enable-parallel-mark
 </pre>
+<FONT COLOR=green>
 instead of
 <TT>--disable-threads</tt>
 If your target is a real old-fashioned uniprocessor (no "hyperthreading",
 etc.) you will want to omit <TT>--enable-parallel-mark</tt>.
-<H3>C++</h3>
+</font>
+<H3><FONT COLOR=green>C++</font></h3>
+<FONT COLOR=green>
 You will need to include the C++ support, which unfortunately tends to
 be among the least portable parts of the collector, since it seems
 to rely on some corner cases of the language.  On Linux, it
@@ -93,7 +105,7 @@ int main()
   int i;
 
   GC_INIT();   /* Optional on Linux/X86; see below.  */
-  for (i = 0; i < 10000000; ++i)
+  for (i = 0; i &lt; 10000000; ++i)
    {
      int **p = (int **) GC_MALLOC(sizeof(int *));
      int *q = (int *) GC_MALLOC_ATOMIC(sizeof(int));
@@ -105,55 +117,75 @@ int main()
   return 0;
 }
 </pre>
+<H3><FONT COLOR=green>Interaction with the system malloc</font></h3>
 <FONT COLOR=green>
-<H3>Interaction with the system malloc</h3>
 It is usually best not to mix garbage-collected allocation with the system
 <TT>malloc-free</tt>.  If you do, you need to be careful not to store
 pointers to the garbage-collected heap in memory allocated with the system
 <TT>malloc</tt>.
-<H3>Other Platforms</h3>
+</font>
+
+<H3><FONT COLOR=green>Other Platforms</font></h3>
+<FONT COLOR=green>
 On some other platforms it is necessary to call <TT>GC_INIT()</tt> from the main program,
 which is presumed to be part of the main executable, not a dynamic library.
 This can never hurt, and is thus generally good practice.
+</font>
 
-<H3>Threads</h3>
+<H3><FONT COLOR=green>Threads</font></h3>
+<FONT COLOR=green>
 For a multithreaded program some more rules apply:
+</font>
 <UL>
 <LI>
+<FONT COLOR=green>
 Files that either allocate through the GC <I>or make thread-related calls</i>
 should first define the macro <TT>GC_THREADS</tt>, and then
 include <TT>"gc.h"</tt>.  On some platforms this will redefine some
 threads primitives, e.g. to let the collector keep track of thread creation.
+</font>
 <LI>
-To take advantage of fast thread-local allocation, use the following instead
+<FONT COLOR=green>
+To take advantage of fast thread-local allocation in versions before 7.0,
+use the following instead
 of including <TT>gc.h</tt>:
-<PRE>
+</font>
+<PRE style="color:green">
 #define GC_REDIRECT_TO_LOCAL
 #include "gc_local_alloc.h"
 </pre>
+<FONT COLOR=green>
 This will cause GC_MALLOC and GC_MALLOC_ATOMIC to keep per-thread allocation
 caches, and greatly reduce the number of lock acquisitions during allocation.
+For versions after 7.0, this happens implicitly if the collector is built
+with thread-local allocation enabled.
+</font>
 </ul>
 
-<H3>C++</h3>
+<H3><FONT COLOR=green>C++</font></h3>
+<FONT COLOR=green>
 In the case of C++, you need to be especially careful not to store pointers
 to the garbage-collected heap in areas that are not traced by the collector.
 The collector includes some <A HREF="gcinterface.html">alternate interfaces</a>
 to make that easier.
+</font>
 
-<H3>Debugging</h3>
+<H3><FONT COLOR=green>Debugging</font></h3>
+<FONT COLOR=green>
 Additional debug checks can be performed by defining <TT>GC_DEBUG</tt> before
 including <TT>gc.h</tt>.  Additional options are available if the collector
-is also built with <TT>--enable-full_debug</tt> and all allocations are
+is also built with <TT>--enable-gc-debug</tt> (<TT>--enable-full-debug</tt> in
+some older versions) and all allocations are
 performed with <TT>GC_DEBUG</tt> defined.
+</font>
 
-<H3>What if I can't rewrite/recompile my program?</h3>
+<H3><FONT COLOR=green>What if I can't rewrite/recompile my program?</font></h3>
+<FONT COLOR=green>
 You may be able to build the collector with <TT>--enable-redirect-malloc</tt>
 and set the <TT>LD_PRELOAD</tt> environment variable to point to the resulting
 library, thus replacing the standard <TT>malloc</tt> with its garbage-collected
 counterpart.  This is rather platform dependent.  See the
 <A HREF="leak.html">leak detection documentation</a> for some more details.
-
 </font>
 
 <H2>Compiling and linking</h2>
@@ -171,10 +203,8 @@ directly on the compile line; the dynamic library could have been
 used instead, provided we arranged for the dynamic loader to find
 it, e.g. by setting <TT>LD_LIBRARY_PATH</tt>.
 
+<H3><FONT COLOR=green>Threads</font></h3>
 <FONT COLOR=green>
-
-<H3>Threads</h3>
-
 On pthread platforms, you will of course also have to link with
 <TT>-lpthread</tt>,
 and compile with any thread-safety options required by your compiler.
@@ -183,7 +213,6 @@ or <TT>-lrt</tt>.
 Looking at threadlibs.c in the GC build directory
 should give you the appropriate
 list if a plain <TT>-lpthread</tt> doesn't work.
-
 </font>
 
 <H2>Running the executable</h2>