/share/doc/papers/malloc/intro.ms

 1.\"
 2.\" ----------------------------------------------------------------------------
 3.\" "THE BEER-WARE LICENSE" (Revision 42):
 4.\" <phk@FreeBSD.org> wrote this file.  As long as you retain this notice you
 5.\" can do whatever you want with this stuff. If we meet some day, and you think
 6.\" this stuff is worth it, you can buy me a beer in return.   Poul-Henning Kamp
 7.\" ----------------------------------------------------------------------------
 8.\"
 9.\" $FreeBSD$
10.\"
11.ds RH Introduction
12.NH
13Introduction
14.PP
15Most programs need to allocate storage dynamically in addition
16to whatever static storage the compiler reserved at compile-time.
17To C programmers this fact is rather obvious, but for many years
18this was not an accepted and recognized fact, and many languages 
19still used today don't support this notion adequately.
20.PP
21The classic UNIX kernel provides two very simple and powerful
22mechanisms for obtaining dynamic storage, the execution stack 
23and the heap.
24The stack is usually put at the far upper end of the address-space,
25from where it grows down as far as needed, though this may depend on
26the CPU design.
27The heap starts at the end of the
28.B bss
29segment and grows upwards as needed.
30.PP
31There isn't really a kernel-interface to the stack as such.
32The kernel will allocate some amount of memory for it,
33not even telling the process the exact size.
34If the process needs more space than that, it will simply try to access
35it, hoping that the kernel will detect that an access has been 
36attempted outside the allocated memory, and try to extend it.
37If the kernel fails to extend the stack, this could be because of lack
38of resources or permissions or because it may just be impossible
39to do in the first place, the process will usually be shot down by the 
40kernel.
41.PP
42In the C language, there exists a little used interface to the stack,
43.B alloca(3) ,
44which will explicitly allocate space on the stack.
45This is not an interface to the kernel, but merely an adjustment
46done to the stack-pointer such that space will be available and
47unharmed by any subroutine calls yet to be made while the context
48of the current subroutine is intact.
49.PP
50Due to the nature of normal use of the stack, there is no corresponding
51"free" operator, but instead the space is returned when the current
52function returns to its caller and the stack frame is dismantled.
53This is the cause of much grief, and probably the single most important
54reason that alloca(3) is not, and should not be, used widely.
55.PP
56The heap on the other hand has an explicit kernel-interface in the 
57system call
58.B brk(2) .
59The argument to brk(2) is a pointer to where the process wants the
60heap to end.
61There is also an interface called
62.B sbrk(2)
63taking an increment to the current end of the heap, but this is merely a
64.B libc
65front for brk(2).
66.PP
67In addition to these two memory resources, modern virtual memory kernels
68provide the mmap(2)/munmap(2) interface which allows almost complete
69control over any bit of virtual memory in the process address space.
70.PP
71Because of the generality of the mmap(2) interface and the way the 
72data structures representing the regions are laid out, sbrk(2) is actually
73faster in use than the equivalent mmap(2) call, simply because
74mmap(2) has to search for information that is implicit in the sbrk(2) call.