Microport and SCO Xenix Memory Managment Problems
Daniel M. Frank
dan at prairie.UUCP
Thu Oct 30 01:21:44 AEST 1986
>Unfortunately, malloc wasn't fixed to properly deal with the
>screwy behavior of brk and sbrk. For small malloc requests,
>malloc asks for a 1K chunk and allocates from that. Each time it
>decides to grab another 1K it gets it from a NEW segment. The
>net effect is that malloc squanders segments and can run out
>of memory because of a lack of LDT entries before it even comes
>close to hitting other limits.
In the System V/286 port done by Intel, and further ported by
Microport and AT&T (SV/AT and 6300+ Unix), there is an additional
malloc library (described in malloc(3x)) which may be used instead
of the usual malloc stuff. This library includes a routine called
mallopt(), which allows the following parameters to be set:
M_MXFAST Allocate all blocks below the size of maxfast in large
groups.
M_NLBLKS Each large group allocated will contain numlblks.
M_GRAIN The sizes of all blocks smaller than maxfast are
considered to be rounded up to the nearest multiple of
grain.
M_KEEP Emulates behaviour of old malloc() by keeping the
data in a block intact until that block is used again.
By judicious use of these calls, the segment usage behaviour,
and most likely the speed, of memory allocation under SV/286 can
be significantly enhanced.
--
Dan Frank
uucp: ... uwvax!prairie!dan
arpa: dan%caseus at spool.wisc.edu
More information about the Comp.lang.c
mailing list