Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site allegra.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!allegra!jpl
From: jpl@allegra.UUCP (John P. Linderman)
Newsgroups: net.lang.c
Subject: Re: malloc(), virtual memory
Message-ID: <5079@allegra.UUCP>
Date: Tue, 10-Sep-85 11:04:53 EDT
Article-I.D.: allegra.5079
Posted: Tue Sep 10 11:04:53 1985
Date-Received: Wed, 11-Sep-85 06:33:36 EDT
References: <1285@brl-tgr.ARPA> <1506@umcp-cs.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 19

> The size you hand to malloc has (in our C library at any rate) 4
> added to it, then the result is brought up to the nearest power of
> two.  So if you give it ((1 << 22) - 4) you will get a 4M chunk;
> one more byte and malloc will require an 8M chunk.
> -- 
> In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)

Chris is right (as usual) about the 4.2 malloc being about 50%
efficient when allocating blocks whose size is a power of 2,
(like the buffers that stdio will allocate).  Another ``gotcha''
to beware of is that space, once allocated, is never broken
into smaller pieces.  For example, if I allocate a 4 meg
temporary workspace, free it, then allocate a 2 meg area,
malloc will not reuse the freed space, it will try for a new
area, and, thanks to the aforementioned quirks, it will fail
with the standard 6 meg per-process limit.  Dunno if this is
fixed under 4.3.  One can hope, but I wouldn't bet the farm.

John P. Linderman  Space Cadet  allegra!jpl