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