used heavily, and thus the number of short-duration lock acquisitions
is greatly reduced.
</ul>
-<P>
-The easiest way to switch an application to thread-local allocation
-in a pre-version-7.0 collector was to
-<OL>
-<LI> Define the macro <TT>GC_REDIRECT_TO_LOCAL</tt>,
-and then include the <TT>gc.h</tt>
-header in each client source file.
-<LI> Invoke <TT>GC_thr_init()</tt> before any allocation.
-<LI> Allocate using <TT>GC_MALLOC</tt>, <TT>GC_MALLOC_ATOMIC</tt>,
-and/or <TT>GC_GCJ_MALLOC</tt>.
-</ol>
<H2>The Parallel Marking Algorithm</h2>
We use an algorithm similar to
<A HREF="http://www.yl.is.s.u-tokyo.ac.jp/gc/">that developed by
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>
-<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>:
-</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><FONT COLOR=green>C++</font></h3>