summaryrefslogtreecommitdiffstats
path: root/share/doc
diff options
context:
space:
mode:
Diffstat (limited to 'share/doc')
-rw-r--r--share/doc/papers/malloc/alternatives.ms2
-rw-r--r--share/doc/papers/malloc/conclusion.ms2
-rw-r--r--share/doc/papers/malloc/implementation.ms12
-rw-r--r--share/doc/papers/malloc/intro.ms8
-rw-r--r--share/doc/papers/malloc/performance.ms4
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
OpenPOWER on IntegriCloud