From xemacs-m  Mon Sep 22 13:34:08 1997
Received: from bittersweet.inetarena.com (karlheg@bittersweet.inetarena.com [206.129.216.38])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id NAA06155
	for <xemacs-beta@xemacs.org>; Mon, 22 Sep 1997 13:34:04 -0500 (CDT)
Received: (from karlheg@localhost)
	by bittersweet.inetarena.com (8.8.7/8.8.7/Debian/GNU) id LAA11093;
	Mon, 22 Sep 1997 11:34:21 -0700
To: XEmacs BETA <xemacs-beta@xemacs.org>
Subject: Re: dlmalloc
References: <m27mcame88.fsf@altair.xemacs.org> <kig7mc91r56.fsf@jagor.srce.hr>
X-Face: /Q}=yl}1_v7nP)xXo5XjG8+tl@=uVu7o5u6)f]zN?+<hB!K.m9:[|*p34jVN`O;:XZXVSy>/\R>qDt(t8w!-i{(y0"`jFw^uk8inzO9wXabd'CdjUWfC\GHi:6nO*YC89#-qD>Q4r%9!V"<RYJ=7D#$";q=zML5'!=wvXk^$`6FT=5CMofQX)WUKt0p:OKl.mFOXx/D
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: multipart/mixed;
 boundary="Multipart_Mon_Sep_22_11:34:18_1997-1"
Content-Transfer-Encoding: 7bit
From: karlheg@inetarena.com (Karl M. Hegbloom)
Date: 22 Sep 1997 11:34:18 -0700
In-Reply-To: Hrvoje Niksic's message of "22 Sep 1997 14:15:17 +0200"
Message-ID: <87wwk9yz85.fsf_-_@bittersweet.inetarena.com>
Lines: 56
X-Mailer: Gnus v5.5/XEmacs 20.3(beta23) - "Sarajevo"

--Multipart_Mon_Sep_22_11:34:18_1997-1
Content-Type: text/plain; charset=US-ASCII

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic@srce.hr> writes:

    Hrvoje> Should we add the same stuff to XEmacs?  What *is*
    Hrvoje> DOUG_LEA_MALLOC anyway?  We need a malloc guru here.

 I'm not a malloc guru... but I know that the Doug Lea malloc is
 what's in the Linux glibc-2.  XEmacs won't work if you tell configure
 to use-system-malloc.  I wonder if that patch would fix it?  I used
 to be that if you compile with-system-malloc, that gnus won't start,
 it fails to make a 32k vector.

 If you follow the http below, it will lead you to some very
 interesting papers on memory management.


"bittersweet:/usr/src/glibc-2.0.4/malloc/malloc.c"
8<---------------------------------------------------.........
/* V2.6.4-pt3 Thu Feb 20 1997

  This work is mainly derived from malloc-2.6.4 by Doug Lea
  <dl@cs.oswego.edu>, which is available from:

                 ftp://g.oswego.edu/pub/misc/malloc.c

  Most of the original comments are reproduced in the code below.

* Why use this malloc?

  This is not the fastest, most space-conserving, most portable, or
  most tunable malloc ever written. However it is among the fastest
  while also being among the most space-conserving, portable and tunable.
  Consistent balance across these factors results in a good general-purpose
  allocator. For a high-level description, see
     http://g.oswego.edu/dl/html/malloc.html

  On many systems, the standard malloc implementation is by itself not
  thread-safe, and therefore wrapped with a single global lock around
  all malloc-related functions.  In some applications, especially with
  multiple available processors, this can lead to contention problems
  and bad performance.  This malloc version was designed with the goal
  to avoid waiting for locks as much as possible.  Statistics indicate
  that this goal is achieved in many cases.


--Multipart_Mon_Sep_22_11:34:18_1997-1
Content-Type: text/plain; charset=US-ASCII

mailto:karlheg@inetarena.com (Karl M. Hegbloom)
http://www.inetarena.com/~karlheg
Portland, OR  USA
Debian GNU 1.3.1+hamm  Linux pre-2.0.31-9+select+QNX  AMD K5 PR-133

--Multipart_Mon_Sep_22_11:34:18_1997-1--

