blarson@skat.usc.edu (Bob Larson) (10/18/87)
Most versions of malloc will round the amount of memory you request to
some number convienient for it. Since the pointer returned must be
maximally alligned, this is normally a multiple of the size of the
largest type. What I need to know what sizes of memory requests to
malloc will reduce wasted space for a variety of systems: bsd 4.2, bsd
4.3, sun 3.*, ultrix 32, sys v (various releases & systems)
I also need to know what to #ifdef for the various systems. (BSD and
sys V are in separate files already, but I think the malloc stratagy
changed from 4.2 to 4.3, and likly did elsewhere.)
This is for mg (MicroGnuEmacs) (version 2a is under development). It
will be usable without this information, however it will be slower
(reallocating memory more often) and bigger.
Please mail your replies to one of the addresses below (or just use
r). I'll sumerize if anyone else wants the information.
--
Bob Larson Arpa: Blarson@Ecla.Usc.Edu
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson blarson@skat.usc.edu
Prime mailing list (requests): info-prime-request%fns1@ecla.usc.edubrett@wjvax.UUCP (Brett Galloway) (10/19/87)
In article <4753@oberon.USC.EDU> blarson@skat.usc.edu (Bob Larson) writes: >Most versions of malloc will round the amount of memory you request to >some number convienient for it. Since the pointer returned must be >maximally alligned, this is normally a multiple of the size of the >largest type. What I need to know what sizes of memory requests to >malloc will reduce wasted space for a variety of systems: bsd 4.2, bsd >4.3, sun 3.*, ultrix 32, sys v (various releases & systems) I am curious if any work has been done by the ANSI group with regard to malloc(). I don't see any portable way to optimize the use of malloc() *before* using it. However, it seems to me that a function to return the actual amount of room provided *by* a malloc() (greater than or equal to what you asked for) would be feasible, and could be used partially to address the problem alluded to by Bob above. -- ------------- Brett Galloway {pesnta,twg,ios,qubix,turtlevax,tymix,vecpyr,certes,isi}!wjvax!brett
rwhite@nusdhub.UUCP (Robert C. White Jr.) (10/21/87)
In article <1105@wjvax.UUCP>, brett@wjvax.UUCP (Brett Galloway) writes: > I am curious if any work has been done by the ANSI group with regard to > malloc(). Is mallopt(3X) part of the new ANSI standard? I know that you have to include <malloc.h> and it is an "extended" library on our system. Aparently it lets you "read" and "set" the granularity of the malloc() subsystem. While I havent tried it, but it looks like if you set the "granule size" to 1 it will round up the the "minimum granule" defined in the library. Where minimum granule is the smallest value which will provide alignment. It seems that if it is not ANSI, it should be. You could "set" 1 and then read the actual value to discover your alignment stats. Rob.
daveb@geac.UUCP (10/22/87)
In article <4753@oberon.USC.EDU> you write: >Most versions of malloc will round the amount of memory you request to >some number convienient for it. Since the pointer returned must be >maximally alligned, this is normally a multiple of the size of the >largest type. What I need to know what sizes of memory requests to >malloc will reduce wasted space for a variety of systems: bsd 4.2, bsd4.3, -- long sun 3.*, -- not known, probably int (its a 68k) ultrix 32, -- long sys v (various releases & systems) -- varies with machine The basic rule is laid down by the hardware designers: if a machine will fetch longwords from a byte address, its a don't-care. If it requires an even address, use int alignment. Otherwise use long. IBM /376's can require double! (/370's require long). The information should vary mostly with cpu-chip, and can be obtained from CPU manuals. You may find that the cost of the malloc header dominates the cost of alignment: I wrote a paranoid/debugging allocator for GCOS 8 and discovered header-size to be significant on that machine (which needed long alignment). --dave (I couldn't get through to you by mail) c-b -- David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months. -- David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
guy%gorodish@Sun.COM (Guy Harris) (10/23/87)
> Is mallopt(3X) part of the new ANSI standard?
No, nor should it be. Lots of the "mallopt" stuff is based on a *particular*
implementation of "malloc"; it is not ANSI's business to tell people *how* to
implement "malloc".
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
guy@sun.commike@unmvax.UUCP (11/02/87)
In article <1665@geac.UUCP>, daveb@geac writes:
~In article <4753@oberon.USC.EDU> you write:
~>Most versions of malloc will round the amount of memory you request to
~>some number convienient for it. Since the pointer returned must be
~>maximally alligned, this is normally a multiple of the size of the
~>largest type. What I need to know what sizes of memory requests to
~>malloc will reduce wasted space for a variety of systems:
~ The basic rule is laid down by the hardware designers: if a machine
~will fetch longwords from a byte address, its a don't-care. If it
~requires an even address, use int alignment. Otherwise use long.
~IBM /376's can require double! (/370's require long).
~ The information should vary mostly with cpu-chip, and can be
~obtained from CPU manuals.
This is not the whole story. On BSD, malloc uses a binary buddy
system. So, if you request 33 longs of data, you are liable to get
more like 60. (Not 64, because there is some header information kept
for free().)
--
Michael I. Bushnell
a/k/a Bach II
mike@turing.unm.edu
{ucbvax,gatech}!unmvax!turing!mike
---
Those aren't WINOS--that's my JUGGLER, my AERIALIST,
my SWORD SWALLOWER, and my LATEX NOVELTY SUPPLIER!!
-- Zippy the Pinhead
Michael I. Bushnell
a/k/a Bach II
mike@turing.unm.edu
{ucbvax,gatech}!unmvax!turing!mike
---
Those aren't WINOS--that's my JUGGLER, my AERIALIST,
my SWORD SWALLOWER, and my LATEX NOVELTY SUPPLIER!!
-- Zippy the Pinhead