From 9daa35f72ff437d42b761383b08f13c7f27c589b Mon Sep 17 00:00:00 2001 From: Ivan Maidanski Date: Tue, 1 Dec 2015 11:49:02 +0300 Subject: [PATCH] Remove documentation about obsolete GC_REDIRECT_TO_LOCAL * doc/scale.html (GC_REDIRECT_TO_LOCAL): Remove documentation. * doc/simple_example.html (GC_REDIRECT_TO_LOCAL): Likewise. --- doc/scale.html | 11 ----------- doc/simple_example.html | 16 ---------------- 2 files changed, 27 deletions(-) diff --git a/doc/scale.html b/doc/scale.html index 9faff6cb..67928277 100644 --- a/doc/scale.html +++ b/doc/scale.html @@ -70,17 +70,6 @@ though it usually improves performance when thread-local allocation is used heavily, and thus the number of short-duration lock acquisitions is greatly reduced. -

-The easiest way to switch an application to thread-local allocation -in a pre-version-7.0 collector was to -

    -
  1. Define the macro GC_REDIRECT_TO_LOCAL, -and then include the gc.h -header in each client source file. -
  2. Invoke GC_thr_init() before any allocation. -
  3. Allocate using GC_MALLOC, GC_MALLOC_ATOMIC, -and/or GC_GCJ_MALLOC. -

The Parallel Marking Algorithm

We use an algorithm similar to that developed by diff --git a/doc/simple_example.html b/doc/simple_example.html index 98ae4244..22bf6948 100644 --- a/doc/simple_example.html +++ b/doc/simple_example.html @@ -143,22 +143,6 @@ should first define the macro GC_THREADS, and then include "gc.h". On some platforms this will redefine some threads primitives, e.g. to let the collector keep track of thread creation. -
  • - -To take advantage of fast thread-local allocation in versions before 7.0, -use the following instead -of including gc.h: - -
    -#define GC_REDIRECT_TO_LOCAL
-#include "gc_local_alloc.h"
-
    - -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. -

    C++

    -- 2.40.0