From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from gatech.edu (gatech.edu [130.207.244.244]) by werple.mira.net.au (8.6.12/8.6.9) with SMTP id GAA03614 for <mason@werple.mira.net.au>; Sat, 15 Jul 1995 06:54:22 +1000
Received: from math (math.skiles.gatech.edu) by gatech.edu with SMTP id AA04231
  (5.65c/Gatech-10.0-IDA for <mason@werple.mira.net.au>); Fri, 14 Jul 1995 16:52:09 -0400
Received: by math (5.x/SMI-SVR4)
	id AA09388; Fri, 14 Jul 1995 14:18:31 -0400
Resent-Date: Fri, 14 Jul 1995 10:59:09 -0700
Old-Return-Path: <schaefer@zyrcon.z-code.ncd.com>
From: schaefer@z-code.com (Barton E. Schaefer)
Message-Id: <950714105914.ZM20365@zyrcon.z-code.com>
Date: Fri, 14 Jul 1995 10:59:09 -0700
In-Reply-To: hzoli@cs.elte.hu (Zoltan Hidvegi)
        "Some glob.c cleanups" (Jul 14,  4:10pm)
References: <9507141410.AA06571@turan.elte.hu>
Reply-To: schaefer@z-code.com
X-Face: czU|*h"p8AX?4.I.yU.^s%TIMx|"-s,*'|#H^|e,QjE&!jL%<]:-.U/;khS%3a2BC5_d#)(
 mz=$$G0u9P&*N8cA~b[URf;lgKRif@#qEf[ltie#Gg0%6$b`e`k.Cgw:\qJx\\a7c(K7^3;gXW:e1@
 J<dlE"_MR!jLyY^_Ig[6-B#D2;B2V
X-Mailer: Z-Mail Lite (3.3dev.713 13jul95)
To: hzoli@cs.elte.hu (Zoltan Hidvegi),
        zsh-workers@math.gatech.edu (zsh-workers)
Subject: Re: Some glob.c cleanups
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Resent-Message-Id: <"bSetu1.0.YI2.rJh1m"@math>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/204
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

On Jul 14,  4:10pm, Zoltan Hidvegi wrote:
} Subject: Some glob.c cleanups
}
} Also on some machines or on all machines with ZSH_MEM, this larege
} allocated heap area was not given back to the system after it was not
} needed, probably because the memory fragmented in a way that prevented
} this.

Just as a note:  I don't know of *any* malloc library that will compact
heap and return it to the system, no matter what allocation behavior
your application has.  Malloc maintains and re-uses its own internal
free list; when the free list doesn't contain a large-enough block for
a particular allocation, sbrk() is used to get more from the system,
but that new memory simply goes into the internal free list when freed.

Applications that release memory back to the system, like GNU emacs, use
their own heap allocation and compaction algorithms, and avoid malloc.
-- 
Bart Schaefer                     Vice President, Technology, Z-Code Software
schaefer@z-code.com                  Division of NCD Software Corporation
http://www.well.com/www/barts