malloc

[Giorgos Keramidas]

Barry Schwarz wrote:


Not *all* typical desktops perform the same; ISTR that FreeBSD
will happily overcommit knowing that all the memory (virtual + real)
will never ever be needed at the same time. When all processes
*do* attempt to run concurrently the OS picks a process and kills
it, so all malloc calls *always* return a pointer to memory.

I further seem to recall that this was tunable with a FreeBSD
kernel knob. If my memory serves me correctly, the concensus
on clc the last time this came up was that such an implementation
could not be considered conforming ...

<OT>
I can't recall if a kernel tunable for this ever existed, but malloc()
in FreeBSD has options to pre-zero or pre-set the allocated areas to a
magic value, which are mostly useful as debugging features. Quoting the
manpage of malloc(3) from FreeBSD 7.0-CURRENT (similar options exist in
the pre-7.0 implementation of malloc):

J Each byte of new memory allocated by malloc(), realloc() or
reallocf() will be initialized to 0xa5. All memory
returned by free(), realloc() or reallocf() will be
initialized to 0x5a. This is intended for debugging and
will impact performance negatively.

Z Each byte of new memory allocated by malloc(), realloc() or
reallocf() will be initialized to 0. Note that this
initialization only happens once for each byte, so
realloc() and reallocf() calls do not zero memory that was
previously allocated. This is intended for debugging and
will impact performance negatively.

A side-effect of these debugging features is that pages returned by the
kernel will be written to, which will force the 'write' part of ``copy
on write''. It's not really a tunable which can be considered an 100%
disabling of overcommit, but it's reasonably close.
</OT>