46 lines
2.1 KiB
Plaintext
46 lines
2.1 KiB
Plaintext
.\"
|
|
.\" ----------------------------------------------------------------------------
|
|
.\" "THE BEER-WARE LICENSE" (Revision 42):
|
|
.\" <phk@login.dknet.dk> wrote this file. As long as you retain this notice you
|
|
.\" can do whatever you want with this stuff. If we meet some day, and you think
|
|
.\" this stuff is worth it, you can buy me a beer in return. Poul-Henning Kamp
|
|
.\" ----------------------------------------------------------------------------
|
|
.\"
|
|
.\" $Id$
|
|
.\"
|
|
.ds RH Alternative implementations
|
|
.NH
|
|
Alternative implementations
|
|
.PP
|
|
These problems were actually the inspiration for the first alternative
|
|
malloc implementations.
|
|
Since their main aim was debugging, they would often use techniques
|
|
like allocating a guard zone before and after the chunk,
|
|
and possibly filling these guard zones
|
|
with some pattern, so accesses outside the allocated chunk could be detected
|
|
with some decent probability.
|
|
Another widely used technique is to use tables to keep track of which
|
|
chunks are actually in which state and so on.
|
|
.PP
|
|
This class of debugging has been taken to its practical extreme by
|
|
the product "Purify" which does the entire memory-colouring exercise
|
|
and not only keeps track of what is in use and what isn't, but also
|
|
detects if the first reference is a read (which would return undefined
|
|
values) and other such violations.
|
|
.PP
|
|
Later actual complete implementations of malloc arrived, but many of
|
|
these still based their workings on the basic schema mentioned previously,
|
|
disregarding that in the meantime virtual memory and paging have
|
|
become the standard environment.
|
|
.PP
|
|
The most widely used "alternative" malloc is undoubtedly ``gnumalloc''
|
|
which has received wide acclaim and certainly runs faster than
|
|
most stock mallocs. It does, however, tend to fare badly in
|
|
cases where paging is the norm rather than the exception.
|
|
.PP
|
|
The particular malloc that prompted this work basically didn't bother
|
|
reusing storage until the kernel forced it to do so by refusing
|
|
further allocations with sbrk(2).
|
|
That may make sense if you work alone on your own personal mainframe,
|
|
but as a general policy it is less than optimal.
|