Applications use the virtual memory facilities through several sets of memory management interfaces. This section summarizes memory management interfaces and provides examples of the usage of the interfaces.
The mmap() function establishes a mapping of a named file system object into a process address space. A named file system object can also be partially mapped into a process address space. This basic memory management interface is very simple. Use the open() function to open the file, then use the mmap() function to create the mapping with the appropriate access and sharing options to proceed with your application.
The mapping established by the mmap() function replaces any previous mappings for the specified address range.
The flags MAP_SHARED and MAP_PRIVATE, specifies the type of mapping. You must specify the mapping type. If the MAP_SHARED flag is set, write operations modify the mapped object. No further operations on the object are needed to make the change. If the MAP_PRIVATE flag is set, the first write operation to the mapped area creates a copy of the page. All further write operations reference the copy. Only modified pages are copied.
You can use the MAP_ADI flag on platforms that support Application Data Integrity (ADI). When the MAP_ADI flag is set, ADI is enabled on the mapped region. When a region of memory is mapped for ADI, the ADI versions for the region are undefined until they are explicitly set by the application. The mapping type is retained across a fork() function.
After you have established the mapping through the mmap() function, the file descriptor used in the call is no longer used. If you close the file, the mapping remains until the munmap() function removes the mapping. Creating a new mapping replaces an existing mapping. For more information, see the munmap(2) man page.
A mapped file can be shortened by a call to truncate. An attempt to access the area of the file that no longer exists causes a SIGBUS signal.
Mapping /dev/zero gives the calling program a block of zero-filled virtual memory. This can also be done by setting the MAP_ANON flag and the file descriptor variable, filedes to -1. The size of the block is specified in the call to mmap() function.
Some devices or files are useful only when accessed by a mapping. Frame buffer devices used to support bit-mapped displays are an example of this phenomenon. Display management algorithms are imple to implement when the algorithms operate directly on the addresses of the display.
For more information, see the mmap(2), munmap(2), open(2), fork(2), adi(2), and adi(3C) man pages.
The munmap() function removes all mappings of pages in the specified address range of the calling process and has no affect on the objects that were mapped.
The virtual memory system in Oracle Solaris OS is a cache system, in which processor memory buffers data from file system objects. Interfaces are provided to control or interrogate the status of the cache.
The mincore() interface determines the residency of the memory pages in the address space covered by mappings in the specified range. Because the status of a page can change after mincore() checks the page but before mincore() returns the data, returned information can be outdated. Only locked pages are guaranteed to remain in the memory. For more information, see the mincore(2) man page.
The mlock() interface causes the pages in the specified address range to be locked in a physical memory. References to locked pages in a process do not result in page faults that require an I/O operation. Because an I/O operation interferes with normal operation of virtual memory, and slowsother processes, the use of mlock() is limited to the superuser. The limit of number of pages that can be locked in a memory is dependent on the system configuration. The call to mlock() fails if this limit is exceeded. For more information, see the mlock(3C) man page.
The munlock() interface releases the locks on physical pages. If multiple mlock() calls are made on an address range of a single mapping, a single munlock() call releases the locks. However, if different mappings to the same pages are locked by mlock(), the pages are not unlocked until the locks on all the mappings are released.
Removing a mapping also releases locks, either through being replaced with the mmap() operation or removed with the munmap() operation.
The copy-on-write event that is associated with a MAP_PRIVATE mapping transfers a lock on the source page to the destination page. Thus locks on an address range that includes MAP_PRIVATE mappings are retained transparently along with the copy-on-write redirection. For more information about creating and using mappings, see Creating and Using Mappings.
For more information, see the mlock(3C) and munlock(3C) man pages.
The mlockall() and mlockall() interfaces are similar to mlock() and munlock(), but mlockall() and munlockall() operate on an entire address space. The mlockall() interface sets locks on all the pages in the address space. The munlockall() interface removes all the locks on all the pages in the address space, whether established by mlock() or mlockall().
For more information, see the mlockall(3C) and munlockall(3C) man pages.
The msync() interface causes all modified pages in the specified address range to be flushed to the objects mapped by those addresses. This command is similar to the fsync() function, which operates on files.
For more information, see the fsync(3C) and msync(3C) man pages.