Just typo corrections (mmunmap->munmap etc), no content changes.

MFC after:	1 week

5 files changed, 14 insertions, 14 deletions

diff --git a/share/doc/papers/malloc/alternatives.ms b/share/doc/papers/malloc/alternatives.ms
index 36acdee..9a7d884 100644
--- a/share/doc/papers/malloc/alternatives.ms
+++ b/share/doc/papers/malloc/alternatives.ms
@@ -23,7 +23,7 @@ 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
+the product "Purify" which does the entire memory-coloring 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.
diff --git a/share/doc/papers/malloc/conclusion.ms b/share/doc/papers/malloc/conclusion.ms
index 1643c90..0c30281 100644
--- a/share/doc/papers/malloc/conclusion.ms
+++ b/share/doc/papers/malloc/conclusion.ms
@@ -20,7 +20,7 @@ wastes time paging in pages it's not going to use.
 In such cases as much as a factor of five in wall-clock time has 
 been seen in difference.
 Apart from that gnumalloc and this implementation are pretty
-much head-on performance wise.
+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
diff --git a/share/doc/papers/malloc/implementation.ms b/share/doc/papers/malloc/implementation.ms
index 7dbb10f..11a48d4 100644
--- a/share/doc/papers/malloc/implementation.ms
+++ b/share/doc/papers/malloc/implementation.ms
@@ -69,7 +69,7 @@ and the search restarts.
 Freeing a number of pages is done by changing their state in the 
 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 possible,
+with the two neighboring 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
@@ -113,7 +113,7 @@ information is not available and it would essentially mean a reordering
 of the list on every memory reference to keep it up-to-date.
 Instead they are ordered according to the address of the pages.
 Interestingly enough, in practice this comes out to almost the same 
-thing performance wise.
+thing performance-wise.
 .PP
 It's not that surprising after all, it's the difference between
 following the crowd or actively directing where it can go, in both
@@ -127,7 +127,7 @@ It is an interesting twist to the implementation that the
 .B
 struct pginfo
 .R
-Is allocated with malloc.
+is allocated with malloc.
 That is, "as with malloc" to be painfully correct.
 The code knows the special case where the first (couple) of allocations on
 the page is actually the pginfo structure and deals with it accordingly.
@@ -163,7 +163,7 @@ the pointer if it is found to be invalid.
 .PP
 An environment variable
 .B MALLOC_OPTIONS
-allows the user some control over the behaviour of malloc.
+allows the user some control over the behavior of malloc.
 Some of the more interesting options are:
 .IP
 .B Abort
@@ -185,7 +185,7 @@ unused data.
 .IP
 .B Realloc
 Always do a free and malloc when realloc(3) is called.
-For programs doing garbage collection using realloc(3), this make the
+For programs doing garbage collection using realloc(3), this makes the
 heap collapse faster since malloc will reallocate from the 
 lowest available address.
 The default
@@ -212,7 +212,7 @@ knows a lot of the things that mmap has to find out first.
 .PP
 In general there is little room for further improvement of the
 time-overhead of the malloc, further improvements will have to
-be in the area of improving paging behaviour.
+be in the area of improving paging behavior.
 .PP
 It is still under consideration to add a feature such that
 if realloc is called with two zero arguments, the internal
diff --git a/share/doc/papers/malloc/intro.ms b/share/doc/papers/malloc/intro.ms
index 49f6acd..e2d79c8 100644
--- a/share/doc/papers/malloc/intro.ms
+++ b/share/doc/papers/malloc/intro.ms
@@ -32,7 +32,7 @@ There isn't really a kernel-interface to the stack as such.
 The kernel will allocate some amount of memory for it,
 not even telling the process the exact size.
 If the process needs more space than that, it will simply try to access
-it, hoping that the kernel will detect that access have been 
+it, hoping that the kernel will detect that an access has been 
 attempted outside the allocated memory, and try to extend it.
 If the kernel fails to extend the stack, this could be because of lack
 of resources or permissions or because it may just be impossible
@@ -42,7 +42,7 @@ kernel.
 In the C language, there exists a little used interface to the stack,
 .B alloca(3) ,
 which will explicitly allocate space on the stack.
-This is not a interface to the kernel, but merely an adjustment
+This is not an interface to the kernel, but merely an adjustment
 done to the stack-pointer such that space will be available and
 unharmed by any subroutine calls yet to be made while the context
 of the current subroutine is intact.
@@ -58,14 +58,14 @@ system call
 .B brk(2) .
 The argument to brk(2) is a pointer to where the process wants the
 heap to end.
-There is also a interface called
+There is also an interface called
 .B sbrk(2)
 taking an increment to the current end of the heap, but this is merely a
 .B libc
 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
+provide the mmap(2)/munmap(2) interface which allows almost complete
 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 
diff --git a/share/doc/papers/malloc/performance.ms b/share/doc/papers/malloc/performance.ms
index 997a5a8..57beb93 100644
--- a/share/doc/papers/malloc/performance.ms
+++ b/share/doc/papers/malloc/performance.ms
@@ -20,7 +20,7 @@ We will refer to this as ``overhead time''.
 B: How well does it manage the storage.
 This rather vague metric we call ``quality of allocation''.
 .PP
-The overhead time is easy to measure, just to a lot of malloc/free calls
+The overhead time is easy to measure, just do a lot of malloc/free calls
 of various kinds and combination, and compare the results.
 .PP
 The quality of allocation is not quite as simple as that.
@@ -32,7 +32,7 @@ agree that it should be minimized as well, and if malloc(3) can do
 anything to do so, it should.
 Explanation why it is still a good metric follows:
 .PP
-In a traditional segment/swap kernel, the desirable behaviour of a process
+In a traditional segment/swap kernel, the desirable behavior of a process
 is to keep the brk(2) as low as possible, thus minimizing the size of the
 data/bss/heap segment, which in turn translates to a smaller process and
 a smaller probability of the process being swapped out, qed: faster