A collection of spelling fixes and minor grammar corrections.

Safe for 2.2.

9 files changed, 71 insertions, 69 deletions

diff --git a/share/doc/papers/malloc/abs.ms b/share/doc/papers/malloc/abs.ms
index beb418c..1dabf7e 100644
--- a/share/doc/papers/malloc/abs.ms
+++ b/share/doc/papers/malloc/abs.ms
@@ -6,7 +6,7 @@
 .\" this stuff is worth it, you can buy me a beer in return.   Poul-Henning Kamp
 .\" ----------------------------------------------------------------------------
 .\"
-.\" $Id$
+.\" $Id: abs.ms,v 1.1 1996/04/13 08:30:08 phk Exp $
 .\"
 .if n .ND
 .TL
@@ -23,10 +23,10 @@ Valbygaardsvej 8
 DK-4200 Slagelse
 Denmark
 .AB
-Malloc/free is one of the oldest part of the C language environment
+Malloc/free is one of the oldest parts of the C language environment
 and obviously the world has changed a bit since it was first made.
-The fact that most UNIX kernels have changed from a swap/segment to
-a virtual memory/page based memory management has not been sufficiently
+The fact that most UNIX kernels have changed from swap/segment to
+virtual memory/page based memory management has not been sufficiently
 reflected in the implementations of the malloc/free API.
 .PP
 A new implementation was designed, written, tested and bench-marked
diff --git a/share/doc/papers/malloc/alternatives.ms b/share/doc/papers/malloc/alternatives.ms
index b336208..af9582e 100644
--- a/share/doc/papers/malloc/alternatives.ms
+++ b/share/doc/papers/malloc/alternatives.ms
@@ -6,7 +6,7 @@
 .\" this stuff is worth it, you can buy me a beer in return.   Poul-Henning Kamp
 .\" ----------------------------------------------------------------------------
 .\"
-.\" $Id$
+.\" $Id: alternatives.ms,v 1.1 1996/04/13 08:30:10 phk Exp $
 .\"
 .ds RH Alternative implementations
 .NH
@@ -16,11 +16,11 @@ 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 fill these guard zones
-with some pattern, so accesses outside the allocated chunk can be detected
+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 what
-chunks were actually in what state and so on.
+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
@@ -34,8 +34,8 @@ 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 have received wide acclaim and certainly runs faster than
-most stock mallocs.  It does however tend to fare badly in a
+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 
diff --git a/share/doc/papers/malloc/conclusion.ms b/share/doc/papers/malloc/conclusion.ms
index afd64fc..05edd51 100644
--- a/share/doc/papers/malloc/conclusion.ms
+++ b/share/doc/papers/malloc/conclusion.ms
@@ -6,7 +6,7 @@
 .\" this stuff is worth it, you can buy me a beer in return.   Poul-Henning Kamp
 .\" ----------------------------------------------------------------------------
 .\"
-.\" $Id$
+.\" $Id: conclusion.ms,v 1.1 1996/04/13 08:30:11 phk Exp $
 .\"
 .ds RH Conclusion and experience.
 .NH
@@ -23,9 +23,9 @@ Apart from that gnumalloc and this implementation are pretty
 much head-on performance wise.
 .PP
 Several legacy programs in the BSD 4.4 Lite distribution had
-code that depended on the memory returned from malloc to
-be zeroed, in a couple of cases free(3) was called more than
-once for the same allocation and a few cases even called free(3)
+code that depended on the memory returned from malloc
+being zeroed.  In a couple of cases, free(3) was called more than
+once for the same allocation, and a few cases even called free(3)
 with pointers to objects in the data section or on the stack.
 .PP
 A couple of users have reported that using this malloc on other
diff --git a/share/doc/papers/malloc/implementation.ms b/share/doc/papers/malloc/implementation.ms
index 781d034..c74204f 100644
--- a/share/doc/papers/malloc/implementation.ms
+++ b/share/doc/papers/malloc/implementation.ms
@@ -6,7 +6,7 @@
 .\" this stuff is worth it, you can buy me a beer in return.   Poul-Henning Kamp
 .\" ----------------------------------------------------------------------------
 .\"
-.\" $Id: implementation.ms,v 1.3 1996/10/04 14:01:54 wosch Exp $
+.\" $Id: implementation.ms,v 1.4 1996/11/14 08:10:30 phk Exp $
 .\"
 .ds RH Implementation
 .NH
@@ -27,8 +27,8 @@ The value can be one of:
 .IP
 .B MALLOC_NOT_MINE
 Another part of the code may call brk(2) to get a piece of the cake.
-Consequently we cannot rely on the memory we get from the kernel to
-be one consecutive piece of memory and therefore we need a way to
+Consequently, we cannot rely on the memory we get from the kernel
+being one consecutive piece of memory, and therefore we need a way to
 mark such pages as "untouchable".
 .IP
 .B MALLOC_FREE
@@ -45,7 +45,7 @@ struct pginfo*
 .R
 A pointer to a structure describing a partitioned page.
 .PP
-In addition there exist a linked list of small data structures that
+In addition, there exists a linked list of small data structures that
 describe the free space as runs of free pages.
 .PP
 Notice that these structures are not part of the free pages themselves,
@@ -54,23 +54,23 @@ are never referenced while they are free.
 .PP
 When a request for storage comes in, it will be treated as a ``page''
 allocation if it is bigger than half a page.
-The freelist will be searched and the first run of free pages that
+The free list will be searched and the first run of free pages that
 can satisfy the request is used.  The first page gets set to
 .B MALLOC_FIRST
-status, if more than that one page is needed the rest of them gets
+status.  If more than that one page is needed, the rest of them get
 .B MALLOC_FOLLOW
 status in the page-directory.
 .PP
-If there were no pages on the free-list, brk(2) will be called, and
+If there were no pages on the free list, brk(2) will be called, and
 the pages will get added to the page-directory with status
 .B MALLOC_FREE
 and the search restarts.
 .PP
 Freeing a number of pages is done by changing their state in the 
-page directory to MALLOC_FREE, and then traverse the free-pages list to
+page directory to MALLOC_FREE, and then traversing the free-pages list to
 find the right place for this run of pages, possibly collapsing
-with the two neighbouring runs into one run and, if it is possible,
-release some memory back to the kernel by calling brk(2).
+with the two neighbouring runs into one run and, if possible,
+releasing some memory back to the kernel by calling brk(2).
 .PP
 If the request is less than or equal to half of a page, its size will be
 rounded up to the nearest power of two before being processed
@@ -90,12 +90,12 @@ and numbers used to keep track of the stuff in the page.
 .PP
 For each size of sub-page allocation, the pginfo structures for the
 pages that have free chunks in them form a list.
-The head of these lists are stored in predetermined slots at
+The heads of these lists are stored in predetermined slots at
 the beginning of the page directory to make access fast.
 .PP
 To allocate a chunk of some size, the head of the list for the
-corresponding size is examined, and a free chunk found, the number
-of free chunks on that page is decreased by one and if zero the
+corresponding size is examined, and a free chunk found.  The number
+of free chunks on that page is decreased by one and, if zero, the
 pginfo structure is unlinked from the list.
 .PP
 To free a chunk, the page is derived from the pointer, the page table
@@ -139,25 +139,27 @@ Bells and whistles.
 brk(2) is actually not a very fast system call when you ask for storage.
 This is mainly because of the need by the kernel to zero the pages before
 handing them over, so therefore this implementation does not release 
-back heap-pages, until there is a large chunk to release back to the kernel.
+heap pages until there is a large chunk to release back to the kernel.
 Chances are pretty good that we will need it again pretty soon anyway.
 Since these pages are not accessed at all, they will soon be paged out
 and don't affect anything but swap-space usage.
 .PP
 The page directory is actually kept in a mmap(2)'ed piece of
 anonymous memory.  This avoids some rather silly cases that
-we would otherwise have to be handled when the page directory
+would otherwise have to be handled when the page directory
 has to be extended.
 .PP
-One particular nice feature is that all pointers passed to free(3)
+One particularly nice feature is that all pointers passed to free(3)
 and realloc(3) can be checked conclusively for validity:
 First the pointer is masked to find the page.  The page directory
 is then examined, it must contain either MALLOC_FIRST, in which
 case the pointer must point exactly at the page, or it can contain
-a struct pginfo*, in which case the pointer must point to a one of
+a struct pginfo*, in which case the pointer must point to one of
 the chunks described by that structure.
-Warnings will be printed on stderr and nothing will be done with
-the pointer in case it is found to be invalid.
+Warnings will be printed on
+.B stderr
+and nothing will be done with
+the pointer if it is found to be invalid.
 .PP
 An environment variable
 .B MALLOC_OPTIONS
@@ -182,12 +184,13 @@ page heavily by eliminating unnecessary page-ins and page-outs of
 unused data.
 .IP
 .B Realloc
-Always do a free and malloc when realloc(3) is called.  The default
+Always do a free and malloc when realloc(3) is called.
+For programs doing garbage collection using realloc(3), this make the
+heap collapse faster since malloc will reallocate from the 
+lowest available address.
+The default
 is to leave things alone if the size of the allocation is still in
 the same size-class.
-For programs doing garbage collect using realloc(3) this make the
-heap collapse faster.  Since the malloc will reallocate from the 
-lowest available address.
 .IP
 .B Junk
 will explicitly fill the allocated area with a particular value
@@ -220,4 +223,3 @@ the memory use, but so far it doesn't seem to be worth the effort.
 Malloc/Free can be a significant point of contention in multi-threaded
 programs.  Low-grain locking of the data-structures inside the 
 implementation should be implemented to avoid excessive spin-waiting.
-
diff --git a/share/doc/papers/malloc/intro.ms b/share/doc/papers/malloc/intro.ms
index 333c54b..9d526f4 100644
--- a/share/doc/papers/malloc/intro.ms
+++ b/share/doc/papers/malloc/intro.ms
@@ -6,7 +6,7 @@
 .\" this stuff is worth it, you can buy me a beer in return.   Poul-Henning Kamp
 .\" ----------------------------------------------------------------------------
 .\"
-.\" $Id: intro.ms,v 1.1 1996/04/13 08:30:14 phk Exp $
+.\" $Id: intro.ms,v 1.2 1996/11/14 08:10:30 phk Exp $
 .\"
 .ds RH Introduction
 .NH
@@ -49,7 +49,7 @@ of the current subroutine is intact.
 .PP
 Due to the nature of normal use of the stack, there is no corresponding
 "free" operator, but instead the space is returned when the current
-function returns to its caller and the stack frame is dismanteled.
+function returns to its caller and the stack frame is dismantled.
 This is the cause of much grief, and probably the single most important
 reason that alloca(3) is not, and should not be, used widely.
 .PP
@@ -66,9 +66,9 @@ front for brk(2).
 .PP
 In addition to these two memory resources, modern virtual memory kernels
 provide the mmap(2)/mmunmap(2) interface which allows almost complete
-control over any bit of virtual memory in the process address room.
+control over any bit of virtual memory in the process address space.
 .PP
 Because of the generality of the mmap(2) interface and the way the 
 data structures representing the regions are laid out, sbrk(2) is actually
-faster in use than the equivalent mmap(2) call, simply because the
+faster in use than the equivalent mmap(2) call, simply because
 mmap(2) has to search for information that is implicit in the sbrk(2) call.
diff --git a/share/doc/papers/malloc/kernel.ms b/share/doc/papers/malloc/kernel.ms
index 220e502..787a581 100644
--- a/share/doc/papers/malloc/kernel.ms
+++ b/share/doc/papers/malloc/kernel.ms
@@ -6,7 +6,7 @@
 .\" this stuff is worth it, you can buy me a beer in return.   Poul-Henning Kamp
 .\" ----------------------------------------------------------------------------
 .\"
-.\" $Id: kernel.ms,v 1.2 1996/10/05 18:37:06 wosch Exp $
+.\" $Id: kernel.ms,v 1.3 1996/11/14 08:10:31 phk Exp $
 .\"
 .ds RH The kernel and memory
 .NH
@@ -30,7 +30,7 @@ for the data and bss section combined and one for the stack.
 On some systems the text shared a segment with the data and bss, and was
 consequently just as writable as them.
 .PP
-In this setup all the brk(2) system call have to do is to find the
+In this setup all the brk(2) system call has to do is to find the
 right amount of free storage, possibly moving things around in physical
 memory, maybe even swapping out a segment or two to make space,
 and change the upper limit on the data segment according to the address given.
@@ -38,17 +38,17 @@ and change the upper limit on the data segment according to the address given.
 In a more modern page based virtual memory implementation this is still
 pretty much the situation, except that the granularity is now pages:
 The kernel finds the right number of free pages, possibly paging some
-pages out to free them up, and then plug them into the page-table of 
+pages out to free them up, and then plugs them into the page-table of 
 the process.
 .PP
 As such the difference is very small, the real difference is that in
 the old world of swapping, either the entire process was in primary
-storage (or it wouldn't be selected to be run) in a modern VM kernel,
+storage or it wouldn't be selected to be run.  In a modern VM kernel,
 a process might only have a subset of its pages in primary memory,
 the rest will be paged in, if and when the process tries to access them.
 .PP
-Only very few programs deal with the brk(2) interface directly, the
-few that does usually have their own memory management facilities.
+Only very few programs deal with the brk(2) interface directly.
+The few that do usually have their own memory management facilities.
 LISP or FORTH interpreters are good examples.
 Most other programs use the
 .B malloc(3) 
diff --git a/share/doc/papers/malloc/malloc.ms b/share/doc/papers/malloc/malloc.ms
index 6837c9f..d4a37ff 100644
--- a/share/doc/papers/malloc/malloc.ms
+++ b/share/doc/papers/malloc/malloc.ms
@@ -6,7 +6,7 @@
 .\" this stuff is worth it, you can buy me a beer in return.   Poul-Henning Kamp
 .\" ----------------------------------------------------------------------------
 .\"
-.\" $Id: malloc.ms,v 1.2 1996/09/29 18:36:13 phk Exp $
+.\" $Id: malloc.ms,v 1.3 1996/10/04 14:01:55 wosch Exp $
 .\"
 .ds RH Malloc and free
 .NH
@@ -36,8 +36,8 @@ is changed to free and if one or both of the surrounding chunks
 are free, they are collapsed to one.
 .PP
 A third kind of request, 
-.B realloc(3)
-exists, it will resize
+.B realloc(3) ,
+will resize
 a chunk, trying to avoid copying the contents if possible.
 It is seldom used, and has only had a significant impact on performance
 in a few special situations.
@@ -63,10 +63,10 @@ A best-fit algorithm can be used instead of first-fit at an expense
 of memory, because statistically fewer chances to brk(2) backwards will 
 present themselves.
 .IP
-Splitting the list in two, once for used and one for free chunks to
+Splitting the list in two, one for used and one for free chunks, to
 speed the searching.
 .IP
-Putting free chunks on one of several free-list depending on the size
+Putting free chunks on one of several free lists, depending on their size,
 to speed allocation.
 .IP
 \&...
diff --git a/share/doc/papers/malloc/performance.ms b/share/doc/papers/malloc/performance.ms
index 272015f..2d4c7af 100644
--- a/share/doc/papers/malloc/performance.ms
+++ b/share/doc/papers/malloc/performance.ms
@@ -6,7 +6,7 @@
 .\" this stuff is worth it, you can buy me a beer in return.   Poul-Henning Kamp
 .\" ----------------------------------------------------------------------------
 .\"
-.\" $Id: performance.ms,v 1.1 1996/04/13 08:30:19 phk Exp $
+.\" $Id: performance.ms,v 1.2 1996/11/14 08:10:31 phk Exp $
 .\"
 .ds RH Performance
 .NH
@@ -42,7 +42,7 @@ In a paging environment this is not a bad choice for a default, but
 a couple of details needs to be looked at much more carefully.
 .PP
 First of all, the size of a process becomes a more vague concept since
-only the pages that are actually used needs to be in primary storage
+only the pages that are actually used need to be in primary storage
 for execution to progress, and they only need to be there when used.
 That implies that many more processes can fit in the same amount of
 primary storage, since most processes have a high degree of locality
@@ -85,15 +85,15 @@ Minimize the number of pages accessed.
 .R
 .PP
 This really is the core of it all.
-If the number of accessed pages is small, then locality of reference is
-higher, and all kinds of caches (which essentially is what the
-primary storage is in a VM system) works better.
+If the number of accessed pages is smaller, then locality of reference is
+higher, and all kinds of caches (which is essentially what the
+primary storage is in a VM system) work better.
 .PP
 It's interesting to notice that the classical malloc fails on this one
-because the information about free chunks are kept with the free
+because the information about free chunks is kept with the free
 chunks themselves.  In some of the benchmarks this came out as all the
-pages were paged in every time a malloc were made, because malloc
-had to traverse the free-list to find a suitable chunk for the allocation.
+pages being paged in every time a malloc call was made, because malloc
+had to traverse the free list to find a suitable chunk for the allocation.
 If memory is not in use, then you shouldn't access it.
 .PP
 The secondary goal is more evident:
@@ -102,11 +102,11 @@ Try to work in pages.
 .R
 .PP
 That makes it easier for the kernel, and wastes less virtual memory.
-Most modern implementations does this when they interact with the
+Most modern implementations do this when they interact with the
 kernel, but few try to avoid objects spanning pages.
 .PP
-If an objects size
-is less or equal to a page, there is no reason for it to span two pages.
+If an object's size
+is less than or equal to a page, there is no reason for it to span two pages.
 Having objects span pages means that two pages must be
 paged in, if that object is accessed.
 .PP
diff --git a/share/doc/papers/malloc/problems.ms b/share/doc/papers/malloc/problems.ms
index c566b6c..3494f99 100644
--- a/share/doc/papers/malloc/problems.ms
+++ b/share/doc/papers/malloc/problems.ms
@@ -6,14 +6,14 @@
 .\" this stuff is worth it, you can buy me a beer in return.   Poul-Henning Kamp
 .\" ----------------------------------------------------------------------------
 .\"
-.\" $Id$
+.\" $Id: problems.ms,v 1.1 1996/04/13 08:30:21 phk Exp $
 .\"
 .ds RH The problems
 .NH
 The problems
 .PP
 Even though malloc(3) is a lot simpler to use
-than the raw brk(2)/sbrk(2) interface
+than the raw brk(2)/sbrk(2) interface,
 or maybe exactly because
 of that,
 a lot of problems arise from its use.
@@ -43,12 +43,12 @@ message before the core-dump.
 Even worse though, very often the program will just continue,
 possibly giving wrong results.
 .PP
-An entirely different form for problem is that
+An entirely different form of problem is that
 the memory returned by malloc(3) can contain any value.
 Unfortunately most kernels, correctly, zero out the storage they 
 provide with brk(2), and thus the storage malloc returns will be zeroed 
 in many cases as well, so programmers are not particular apt to notice 
-that their code depend on malloc'ed storage to be zeroed.
+that their code depends on malloc'ed storage being zeroed.
 .PP
 With problems this big and error handling this weak, it is not
 surprising that problems are hard and time consuming to find and fix.