diff options
Diffstat (limited to 'share/doc')
| -rw-r--r-- | share/doc/papers/malloc/alternatives.ms | 2 | ||||
| -rw-r--r-- | share/doc/papers/malloc/conclusion.ms | 2 | ||||
| -rw-r--r-- | share/doc/papers/malloc/implementation.ms | 12 | ||||
| -rw-r--r-- | share/doc/papers/malloc/intro.ms | 8 | ||||
| -rw-r--r-- | share/doc/papers/malloc/performance.ms | 4 |
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 |
