The Regents of the University of California. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software
must display the following acknowledgement:
This product includes software developed by the University of
California, Berkeley and its contributors.
4. Neither the name of the University nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
@(#)1.2.t 8.1 (Berkeley) 6/8/93
$FreeBSD$
.sh "Memory management\(dg Text, data and stack
.FS \(dg This section represents the interface planned for later releases of the system. Of the calls described in this section, only sbrk and getpagesize are included in 4.3BSD. .FE Each process begins execution with three logical areas of memory called text, data and stack. The text area is read-only and shared, while the data and stack areas are private to the process. Both the data and stack areas may be extended and contracted on program request. The call addr = sbrk(incr); result caddr_t addr; int incr; changes the size of the data area by incr bytes and returns the new end of the data area, while addr = sstk(incr); result caddr_t addr; int incr; changes the size of the stack area. The stack area is also automatically extended as needed. On the VAX the text and data areas are adjacent in the P0 region, while the stack section is in the P1 region, and grows downward. Mapping pages
The system supports sharing of data between processes by allowing pages to be mapped into memory. These mapped pages may be shared with other processes or private to the process. Protection and sharing options are defined in <sys/mman.h> as: /* protections are chosen from these bits, or-ed together */ #define PROT_READ 0x04 /* pages can be read */ #define PROT_WRITE 0x02 /* pages can be written */ #define PROT_EXEC 0x01 /* pages can be executed */ /* flags contain mapping type, sharing type and options */ /* mapping type; choose one */ #define MAP_FILE 0x0001 /* mapped from a file or device */ #define MAP_ANON 0x0002 /* allocated from memory, swap space */ #define MAP_TYPE 0x000f /* mask for type field */ /* sharing types; choose one */ #define MAP_SHARED 0x0010 /* share changes */ #define MAP_PRIVATE 0x0000 /* changes are private */ /* other flags */ #define MAP_FIXED 0x0020 /* map addr must be exactly as requested */ #define MAP_INHERIT 0x0040 /* region is retained after exec */ #define MAP_HASSEMAPHORE 0x0080 /* region may contain semaphores */ #define MAP_NOPREALLOC 0x0100 /* do not preallocate space */ The cpu-dependent size of a page is returned by the getpagesize system call: pagesize = getpagesize(); result int pagesize;
The call: maddr = mmap(addr, len, prot, flags, fd, pos); result caddr_t maddr; caddr_t addr; int *len, prot, flags, fd; off_t pos; causes the pages starting at addr and continuing for at most len bytes to be mapped from the object represented by descriptor fd, starting at byte offset pos. The starting address of the region is returned; for the convenience of the system, it may differ from that supplied unless the MAP_FIXED flag is given, in which case the exact address will be used or the call will fail. The actual amount mapped is returned in len. The addr, len, and pos parameters must all be multiples of the pagesize. A successful mmap will delete any previous mapping in the allocated address range. The parameter prot specifies the accessibility of the mapped pages. The parameter flags specifies the type of object to be mapped, mapping options, and whether modifications made to this mapped copy of the page are to be kept private, or are to be shared with other references. Possible types include MAP_FILE, mapping a regular file or character-special device memory, and MAP_ANON, which maps memory not associated with any specific file. The file descriptor used for creating MAP_ANON regions is used only for naming, and may be given as -1 if no name is associated with the region.\(dd .FS \(dd The current design does not allow a process to specify the location of swap space. In the future we may define an additional mapping type, MAP_SWAP, in which the file descriptor argument specifies a file or device to which swapping should be done. .FE The MAP_INHERIT flag allows a region to be inherited after an exec. The MAP_HASSEMAPHORE flag allows special handling for regions that may contain semaphores. The MAP_NOPREALLOC flag allows processes to allocate regions whose virtual address space, if fully allocated, would exceed the available memory plus swap resources. Such regions may get a SIGSEGV signal if they page fault and resources are not available to service their request; typically they would free up some resources via unmap so that when they return from the signal the page fault could be successfully completed.
A facility is provided to synchronize a mapped region with the file it maps; the call msync(addr, len); caddr_t addr; int len; writes any modified pages back to the filesystem and updates the file modification time. If len is 0, all modified pages within the region containing addr will be flushed; if len is non-zero, only the pages containing addr and len succeeding locations will be examined. Any required synchronization of memory caches will also take place at this time. Filesystem operations on a file that is mapped for shared modifications are unpredictable except after an msync.
A mapping can be removed by the call munmap(addr, len); caddr_t addr; int len; This call deletes the mappings for the specified address range, and causes further references to addresses within the range to generate invalid memory references. Page protection control
A process can control the protection of pages using the call mprotect(addr, len, prot); caddr_t addr; int len, prot; This call changes the specified pages to have protection prot\|. Not all implementations will guarantee protection on a page basis; the granularity of protection changes may be as large as an entire region. Giving and getting advice
A process that has knowledge of its memory behavior may use the madvise call: madvise(addr, len, behav); caddr_t addr; int len, behav; Behav describes expected behavior, as given in <sys/mman.h>: #define MADV_NORMAL 0 /* no further special treatment */ #define MADV_RANDOM 1 /* expect random page references */ #define MADV_SEQUENTIAL 2 /* expect sequential references */ #define MADV_WILLNEED 3 /* will need these pages */ #define MADV_DONTNEED 4 /* don't need these pages */ #define MADV_SPACEAVAIL 5 /* insure that resources are reserved */ Finally, a process may obtain information about whether pages are core resident by using the call mincore(addr, len, vec) caddr_t addr; int len; result char *vec; Here the current core residency of the pages is returned in the character array vec, with a value of 1 meaning that the page is in-core. Synchronization primitives
Primitives are provided for synchronization using semaphores in shared memory. Semaphores must lie within a MAP_SHARED region with at least modes PROT_READ and PROT_WRITE. The MAP_HASSEMAPHORE flag must have been specified when the region was created. To acquire a lock a process calls: value = mset(sem, wait) result int value; semaphore *sem; int wait; Mset indivisibly tests and sets the semaphore sem. If the previous value is zero, the process has acquired the lock and mset returns true immediately. Otherwise, if the wait flag is zero, failure is returned. If wait is true and the previous value is non-zero, mset relinquishes the processor until notified that it should retry.
To release a lock a process calls: mclear(sem) semaphore *sem; Mclear indivisibly tests and clears the semaphore sem. If the ``WANT'' flag is zero in the previous value, mclear returns immediately. If the ``WANT'' flag is non-zero in the previous value, mclear arranges for waiting processes to retry before returning.
Two routines provide services analogous to the kernel sleep and wakeup functions interpreted in the domain of shared memory. A process may relinquish the processor by calling msleep with a set semaphore: msleep(sem) semaphore *sem; If the semaphore is still set when it is checked by the kernel, the process will be put in a sleeping state until some other process issues an mwakeup for the same semaphore within the region using the call: mwakeup(sem) semaphore *sem; An mwakeup may awaken all sleepers on the semaphore, or may awaken only the next sleeper on a queue.