boehm-gc: revert all CACAO-specific modifications; this is now an exact copy of the...

[cacao.git] / src / mm / boehm-gc / doc / gcinterface.html
diff --git a/src/mm/boehm-gc/doc/gcinterface.html b/src/mm/boehm-gc/doc/gcinterface.html

index 312d37f417f9a8734fffe6870d18468daba50a05..bb0995d86f1dd29d024dae36fb3befd3ca8ef1d6 100644 (file)
--- a/src/mm/boehm-gc/doc/gcinterface.html
+++ b/src/mm/boehm-gc/doc/gcinterface.html
@@ -1,5 +1,7 @@
-<!DOCTYPE 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>Garbage Collector Interface</TITLE>
  </HEAD>
  <BODY>
@@ -8,7 +10,8 @@ On many platforms, a single-threaded garbage collector library can be built
  to act as a plug-in malloc replacement.
  (Build with <TT>-DREDIRECT_MALLOC=GC_malloc -DIGNORE_FREE</tt>.)
  This is often the best way to deal with third-party libraries
-which leak or prematurely free objects.  <TT>-DREDIRECT_MALLOC</tt> is intended
+which leak or prematurely free objects.
+<TT>-DREDIRECT_MALLOC=GC_malloc</tt> is intended
  primarily as an easy way to adapt old code, not for new development.
  <P>
  New code should use the interface discussed below.
@@ -47,7 +50,9 @@ Allocates and clears <I>nbytes</i> of storage.
  Requires (amortized) time proportional to <I>nbytes</i>.
  The resulting object will be automatically deallocated when unreferenced.
  References from objects allocated with the system malloc are usually not
-considered by the collector.  (See <TT>GC_MALLOC_UNCOLLECTABLE</tt>, however.)
+considered by the collector.  (See <TT>GC_MALLOC_UNCOLLECTABLE</tt>, however.
+Building the collector with <TT>-DREDIRECT_MALLOC=GC_malloc_uncollectable
+is often a way around this.)
  <TT>GC_MALLOC</tt> is a macro which invokes <TT>GC_malloc</tt> by default or,
  if <TT>GC_DEBUG</tt>
  is defined before <TT>gc.h</tt> is included, a debugging version that checks
@@ -152,8 +157,15 @@ for details.
  </dl>
  <P>
  If you are concerned with multiprocessor performance and scalability,
-you should consider enabling and using thread local allocation (<I>e.g.</i>
-<TT>GC_LOCAL_MALLOC</tt>, see <TT>gc_local_alloc.h</tt>.  If your platform
+you should consider enabling and using thread local allocation.
+For GC versions before 7.0, use <I>e.g.</i>
+<TT>GC_LOCAL_MALLOC</tt> and see <TT>gc_local_alloc.h</tt>;
+for later versions enabling thread-local allocations when the collector
+library is built changes the
+implementation of <TT>GC_MALLOC</tt>, so the client doesn't need to
+change.
+<P>
+If your platform
  supports it, you should build the collector with parallel marking support
  (<TT>-DPARALLEL_MARK</tt>, or <TT>--enable-parallel-mark</tt>).
  <P>