Dynamic Intimate Shared Memory (DISM) was introduced in the 1/01 release of Solaris 8 (Update 3) to supply provide applications with ISM shared memory that is dynamically resizable. The first major application to support DISM was Oracle9i. Oracle9i uses DISM for its newly introduced dynamic System Global Area (SGA) capability.
With regular ISM, it is not possible to change the size of an ISM segment once it has been created. To change the size of database buffer caches, databases must be shut down and restarted (or designed to use a variable number of shared memory segments—a more complicated alternative). This limitation has a negative impact on system availability. For example, if memory is to be removed from a system due to a dynamic reconfiguration event, it may be necessary to first shut down one or more database instances. DISM was designed to overcome this limitation. A large DISM segment can be created when the database boots, and sections of it can be selectively locked or unlocked as memory requirements change. Instead of the kernel automatically locking DISM memory though, locking and unlocking is done by the application (e.g., Oracle), providing the flexibility to make adjustments dynamically. DISM is like ISM except that it isn’t automatically locked. Locking is done by the application using mlock(), rather than by the kernel. Kernel virtual-to-physical memory address translation structures are shared between processes that attach to the DISM segment, saving kernel memory and CPU time.
Tests have shown that, as of Solaris 9, DISM and ISM performance are equivalent. This is an important development, since it means that the availability benefits of DISM can be realized without compromising performance in any way.