[PATCH] Slightly better way to __USE_MALLOC

Loren James Rittle rittle@latour.rsch.comm.mot.com
Fri Oct 18 13:46:00 GMT 2002

In article <20021017204209.A6598@disaster.jaj.com>,
Phil Edwards<phil@jaj.com> writes:

> Very nice, gentlemen.  And as an unexpected bonus, this dovetails
> nicely (I think, so far) with my plans to unify stl_alloc.h and
> stl_pthread_alloc.h/pthread_allocimpl.h.

Thanks Phil.  Committing on mainline next.  It would be great if any
ABI changes we want to make with allocators were semi-stable at 3.3
cut time.  I.e. if support for other global behavior overrides
(e.g. one for pthread_alloc?) could be woven into the
default_allocator like we did here to finally remove __USE_MALLOC.

> 1)  We should note, if you didn't do so, which versions support this
>     technique.  (I think the "extensions howto" is already split up to
>     do this, depending on whether this is backported for 3.2.)

> 2)  Please add some phrase about "the /value/ of the environment variable
>     doesn't matter in version <foo>, just as long as it's present in the
>     environment."  I could see the value making a difference later.

OK, I will commit this doc patch instead:

Index: docs/html/23_containers/howto.html
RCS file: /cvs/gcc/gcc/libstdc++-v3/docs/html/23_containers/howto.html,v
retrieving revision 1.24
diff -u -r1.24 howto.html
--- docs/html/23_containers/howto.html	7 Oct 2002 18:11:20 -0000	1.24
+++ docs/html/23_containers/howto.html	18 Oct 2002 20:02:26 -0000
@@ -251,41 +251,11 @@
       solution would probably be more trouble than it's worth.
    <p>The STL implementation is currently configured to use the
-      high-speed caching memory allocator.  If you absolutely think
-      you must change this on a global basis for your platform to better
-      support multi-threading, then please consult all commentary in
-      include/bits/stl_alloc.h and the allocators link below.
+      high-speed caching memory allocator.  Some people like to
+      test and/or normally run threaded programs with a different
+      default.  For all details about how to globally override this
+      at application run-time see <a href="../ext/howto.html#3">here</a>.
-   <blockquote>
-      <p>(Explicit warning since so many people get confused while
-      attempting this:)
-      </p>
-      <p><strong>Adding -D__USE_MALLOC on the command
-      line is almost certainly a bad idea.</strong>  Memory efficiency is
-      almost guaranteed to suffer as a result; this is
-      <a href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00136.html">why
-      we disabled it for 3.0 in the first place</a>.
-      </p>
-      <p>Related to threading or otherwise, the current recommendation is
-      that users not add any macro defines on the command line to remove or
-      otherwise disable features of libstdc++-v3.  There is
-      no condition under which it will help you without causing other
-      issues to perhaps raise up (possible linkage/ABI problems).  In
-      particular, __USE_MALLOC should only be added to a libstdc++-v3
-      configuration file, include/bits/c++config (where such user
-      action is cautioned against), and the entire library should be
-      rebuilt.  If you do not, then you might be violating the
-      one-definition rule of C/C++ and you might cause yourself untold
-      problems.
-      </p>
-   </blockquote>
-   <p>If you find any platform where gcc reports a
-      threading model other than single, and where libstdc++-v3 builds
-      a buggy container allocator when used with threads unless you
-      define __USE_MALLOC, we want to hear about it ASAP.  In the
-      past, correctness was the main reason people were led to believe
-      that they should define __USE_MALLOC when using threads.
-   </p>
    <p>There is a better way (not standardized yet):  It is possible to
       force the malloc-based allocator on a per-case-basis for some
       application code.  The library team generally believes that this
Index: docs/html/ext/howto.html
RCS file: /cvs/gcc/gcc/libstdc++-v3/docs/html/ext/howto.html,v
retrieving revision 1.23
diff -u -r1.23 howto.html
--- docs/html/ext/howto.html	7 Oct 2002 18:11:21 -0000	1.23
+++ docs/html/ext/howto.html	18 Oct 2002 20:02:26 -0000
@@ -280,19 +280,16 @@
          same as <code>allocator<T></code>.
-   <p>An internal typedef, <code> __mem_interface </code>, is defined to be
-      <code>__new_alloc</code> by default.
-   </p>
       <code> __default_alloc_template<bool thr, int inst> </code>
       is also available.  This is the high-speed pool, called the default
       node allocator.  The reusable memory is shared among identical
       instantiations of
-      this type.  It calls through <code>__mem_interface</code> to obtain
+      this type.  It calls through <code>__new_alloc</code> to obtain
       new memory when its lists run out.  If a client container requests a
       block larger than a certain threshold size, then the pool is bypassed,
       and the allocate/deallocate request is passed to
-      <code>__mem_interface</code> directly.
+      <code>__new_alloc</code> directly.
    <p>Its <code>inst</code> parameter is described below.  The
       <code>thr</code> boolean determines whether the pool should be
@@ -313,17 +310,25 @@
    <h3>A cannon to swat a fly:<code>  __USE_MALLOC</code></h3>
    <p>If you've already read <a href="../23_containers/howto.html#3">this
-      advice</a> and decided to define this macro, then the situation changes
-      thusly:
+      advice</a> but still think you remember how to use this macro from
+      SGI STL days.  We have removed it in gcc 3.3.  See next section
+      for the new way to get the same effect.
+   </p>
+   <h3>Globally disabling memory caching:<code>  GLIBCPP_FORCE_NEW</code></h3>
+   <p>Starting with gcc 3.3, if you want to globally disable memory
+      caching within the library for the default allocator (i.e.
+      the one you get for all library objects when you do not specify
+      which one to use), merely set GLIBCPP_FORCE_NEW (at this time,
+      with any value) into your environment before running the
+      program.  You will obtain a similar effect without having to
+      recompile your entire program and the entire library (the new
+      operator in gcc is a light wrapper around malloc).  If your
+      program crashes with GLIBCPP_FORCE_NEW in the environment,
+      it likely means that you linked against objects built against
+      the older library.  Code to support this extension is fully
+      compatible with 3.2 code if GLIBCPP_FORCE_NEW is not in the
+      environment.
-   <ol>
-     <li><code>__mem_interface</code>, and</li>
-     <li><code>__alloc</code>, and</li>
-     <li><code>__single_client_alloc</code> are all typedef'd to
-         <code>__malloc_alloc_template</code>.</li>
-     <li><code>__default_alloc_template</code> is no longer available.
-         At all.  Anywhere.</li>
-   </ol>
    <h3>Writing your own allocators</h3>
    <p>Depending on your application (a specific program, a generic library,
       etc), allocator classes tend to be one of two styles:  "SGI"

More information about the Libstdc++ mailing list