next up previous contents index
Next: Debugging and Profiling Up: Running Ultrix Applications on Previous: Scheduling

Virtual Memory

    As with processor scheduling, most Taos virtual memory management is performed by the Nub. The Nub virtual memory manager does not currently provide facilities for sharing read-only program text segments or for demand loading.

     

The virtual memory page size implemented by the Nub is considered to be a tuning parameter, and may end up larger than the 1024 bytes used by Ultrix. This difference is visible to a program that uses the brk/sbrk kernel call, since this kernel call rounds up the break (the end of the data segment) to a multiple of the Nub-defined virtual page size. On the other hand, the getpagesize kernel call always returns 1024. (The Ultrix 1.1 version of the ld command won't work if getpagesize returns a different value.)

  Franz Lisp executes the vadvise kernel call even though no such kernel call is documented in Ultrix 1.1 or 2.0. Therefore Taos implements vadvise as a no-op. (There is a comment `72 is old: vadvise' in /usr/include/syscall.h.)

  Taos does not limit the number or total length of arguments and environment strings passed via the execve kernel call.

  If virtual memory backing store runs out, Taos may fail in different ways than Ultrix. This is because a process can cause Taos to allocate an unbounded amount of virtual memory (within the Taos address space); when backing store runs out, a Taos thread holding global locks may be blocked.


next up previous contents index
Next: Debugging and Profiling Up: Running Ultrix Applications on Previous: Scheduling
Paul McJones
8/28/1997