Converge on one language.

Reviewed by:	phk
Submitted by:	Alex Nash <nash@mcs.com>

4 files changed, 20 insertions, 19 deletions

diff --git a/share/doc/papers/malloc/implementation.ms b/share/doc/papers/malloc/implementation.ms
index 14ae9d2..781d034 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.2 1996/09/29 18:36:11 phk Exp $
+.\" $Id: implementation.ms,v 1.3 1996/10/04 14:01:54 wosch Exp $
 .\"
 .ds RH Implementation
 .NH
@@ -171,6 +171,16 @@ It's amazing how few programs actually handle this condition correctly,
 and consequently the havoc they can create is the more creative or
 destructive.
 .IP
+.B Dump
+Writes malloc statistics to a file called ``malloc.out'' prior
+to process termination.
+.IP
+.B Hint
+Pass a hint to the kernel about pages we no longer need through the
+madvise(2) system call.  This can help performance on machines that
+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
 is to leave things alone if the size of the allocation is still in
@@ -189,7 +199,7 @@ space after the allocation in the chunk will be filled with the
 junk value to try to catch out of the chunk references.
 .ds RH The road not taken.
 .NH
-The road yet not taken.
+The road not yet taken.
 .PP
 A couple of avenues were explored that could be interesting in some
 set of circumstances.
@@ -197,15 +207,6 @@ set of circumstances.
 Using mmap(2) instead of brk(2) was actually slower, since brk(2)
 knows a lot of the things that mmap has to find out first.
 .PP
-A system call where we could tell the kernel that "we don't
-need the contents of this page anymore" would allow us to
-return the pages on the free list to the kernel and to instruct
-the kernel that it doesn't need to page it out nor in.
-It would save some page-out events, and the page-in would be replaced
-by a zero-fill page.
-This is, according to the VM goods in the FreeBSD camp, "easy",
-and it will probably be attempted at some point in the future.
-.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.
diff --git a/share/doc/papers/malloc/intro.ms b/share/doc/papers/malloc/intro.ms
index b0301f8..333c54b 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$
+.\" $Id: intro.ms,v 1.1 1996/04/13 08:30:14 phk Exp $
 .\"
 .ds RH Introduction
 .NH
@@ -16,7 +16,7 @@ Most programs need to allocate storage dynamically in addition
 to whatever static storage the compiler reserved at compile-time.
 To C programmers this fact is rather obvious, but for many years
 this was not an accepted and recognized fact, and many languages 
-still used today doesn't support this notion adequately.
+still used today don't support this notion adequately.
 .PP
 The classic UNIX kernel provides two very simple and powerful
 mechanisms for obtaining dynamic storage, the execution stack 
diff --git a/share/doc/papers/malloc/kernel.ms b/share/doc/papers/malloc/kernel.ms
index 21dff8d..220e502 100644
--- a/share/doc/papers/malloc/kernel.ms
+++ b/share/doc/papers/malloc/kernel.ms
@@ -6,13 +6,13 @@
 .\" this stuff is worth it, you can buy me a beer in return.   Poul-Henning Kamp
 .\" ----------------------------------------------------------------------------
 .\"
-.\" $Id: kernel.ms,v 1.1 1996/04/13 08:30:16 phk Exp $
+.\" $Id: kernel.ms,v 1.2 1996/10/05 18:37:06 wosch Exp $
 .\"
 .ds RH The kernel and memory
 .NH
 The kernel and memory
 .PP
-Brk(2) isn't a particular convenient interface,
+Brk(2) isn't a particularly convenient interface,
 it was probably made more to fit the memory model of the 
 hardware being used, than to fill the needs of the programmers.
 .PP
diff --git a/share/doc/papers/malloc/performance.ms b/share/doc/papers/malloc/performance.ms
index bb023ea..272015f 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$
+.\" $Id: performance.ms,v 1.1 1996/04/13 08:30:19 phk Exp $
 .\"
 .ds RH Performance
 .NH
@@ -63,15 +63,15 @@ For now we can simply say that it is the number of pages the process
 needs in order to run at a sufficiently low paging rate in a congested
 primary storage.
 (If primary storage isn't congested, this is not really important 
-of course, but most systems would be better of using the pages for
+of course, but most systems would be better off using the pages for
 disk-cache or similar functions, so from that perspective it will
 always be congested.)
-If this number of pages is to small, the process will wait for the its
+If the number of pages is too small, the process will wait for its
 pages to be read from secondary storage much of the time, if it's too
 big, the space could be used better for something else.
 .PP
 From the view of any single process, this number of pages is 
-"all of my pages", but from the point of view of the OS is should
+"all of my pages", but from the point of view of the OS it should
 be tuned to maximise the total throughput of all the processes on
 the machine at the time.
 This is usually done using various kinds of least-recently-used