using malloc and brk: something to
gordon at sneaky.UUCP
gordon at sneaky.UUCP
Sun Jun 22 11:36:00 AEST 1986
> Keywords: malloc, brk
> Summary: beware of stdio doing malloc behind your back
> If you want to use brk() or sbrk() to do memory allocation, there is
> something you have to keep in mind: the standard I/O library does
> mallocs to allocate buffers for files that it handles. The problem
> is that, at least on our system (UTX/32, a 4.2BSD derivative), malloc
> maintains its own notion of where the top of memory is, and it doesn't
> know about brk or sbrk calls done external to it. (Actually, this makes
> sense from a performance standpoint: if malloc had to check the actual
> top of memory, that would mean a system call for every malloc.)
[ detail deleted ]
> Now for the flame: There should be some way to confine malloc to a certain
> heap space by setting an upper limit on how high it can allocate memory.
> This way, the programmer could use malloc and still have clear memory
> above the top of the heap space.
I think there's a better way to handle this. On 4.1bsd and Xenix/68000
Version 3, and probably v7 also, malloc does not have its own idea of
"top of memory". It has its own idea of "memory assigned to malloc",
which is not a single number. If malloc needs more memory, it tries to
get a chunk from sbrk(), possibly more than was requested, and it keeps
track of that chunk. It doesn't assume that that chunk is contiguous
with the previous one it got, and user calls to sbrk() don't get in the
way of malloc, or vice versa, UNLESS the user program makes the assumption
that it can free something it allocated with sbrk() (and, along the way,
everything past it) by calling brk() or sbrk() with a negative argument.
You can still get the same performance: if malloc allocates large chunks
and hands out individual small pieces, it can avoid one system call per
malloc.
sbrk() isn't really a system call, and sbrk's idea of where the end of
memory is is kept in the user data area. Xenix/68000 V 3 has this problem
with a feature called "shared data", which grows the data segment without
telling sbrk() about it. Guess what happens if you mix shared data and
malloc()? Also, guess what happens if you accidentally write on sbrk()'s
hidden variable?
>
> Dave Cornutt
> Gould Computer Systems
> Ft. Lauderdale, FL
>
Gordon Burditt
...!convex!ctvax!trsvax!sneaky!gordon
More information about the Comp.unix
mailing list