Tech-notes: Single Level Store or Teraspace: which storage model to choose?

Single Level Store

Single Level Store (SLS) is one of the key priciples on which IBM i (formerly known as AS/400 and iSeries) and its ascendant (S/38) are designed. The SLS is a single, large, and contiguous virtual storage space. From the MI level upward, MI instructions, application programming interfaces (APIs), OS applications, and user programs can see only this single virtual storage space instead of seperated main storage and auxiliary storage.

Addresses in SLS are 8-byte virtual addresses. SLS storage is allocated by SLIC in form of segments. Each segment allocated in SLS is uniquely identified by the segment ID portion in an 8-byte virtual address. There are big and little segments. For a big segment, the segment ID is the high-order 5 bytes of a virtual address, and the remaining 3 bytes are used to represent the offset value into the segment (range from 0 to 16M - 1); for a little segment, the segment ID is the high-ordr 6 bytes of a virtual address, and the remaining 2 bytes are used to represent the offset value into the segment (range from 0 to 64K - 1). This also the reason why there is the 16MB - 1Page size limit on different types of SLS storage: automatic storage of a thread, static storage of an activation group, maximum size of a space object, and a single allocation on an SLS heap.

Storage occupied by an MI object may consists of one or more segments in SLS. Since the virtual addresses in SLS can keep valid across IPLs, in IBM i MI objects may be created as permanent objects.

SLS is closely connected with other two key features of IBM i, object-based and the tagged pointer architecture.

In a UNIX-like platform, everything is a file, while in IBM i, everything is an object. And at the MI level, everything is an MI object. An MI object can be refered to only by a resolved system pointer (one of all types of 16-byte MI pointers). The base-segment ID portion in the lower-order 8-byte of a system pointer uniquely identifies an MI object, which represents a unique virtual address in the SLS virtual storage space. In a a resolved system pointer, along with the base-segment ID, the authority given to user programs to access the MI object via it is stored. System pointers to permanent MI objects can be reused even across IPLs, if they are stored in the storage of another permanent MI object.

The tagged pointer architecture is to keep MI pointers from being mocked. It has been well explained in section "Pointers and Tags" at page 158 of Fortress Rochester by Dr. Frank G. Soltis.

Teraspace

For years, IBM has added support for numerous open standards to IBM i. Teraspace is the support as for storage model being added to IBM i, upon which POSIX-compliant Unix system calls such as mmap can be implemented. From the user's point of view, Teraspace is a storage model identical to that used by common 64-bit platforms. It's a 64-bit, process-private storage space. It allows a single heap allocation of size larger than 16MB. Also, since storage for automatic and static variables in a Teraspace program is allocated in Teraspace, you can use larger that 16MB contiguous automatic and static storage. Storage allocated in Teraspace cannot be shared between MI processes unless via the share memory APIs. "Chapter 4. Teraspace and Single-Level Storage" of the ILE Concepts book gives a thorough introduction to basic concepts of Teraspace (ILE Concepts: V5R4 and V7R1 ).

Which storage model to choose?

Here comes the question, the Teraspace storage model seems more powerful and easy to use than SLS, why should we choose the SLS storage model?

As the native storage model of IBM i, SLS is the basis upon which the entire object-based system architecture of IBM i can be set up. In this object-based architecture, MI objects along with their attributes and data stored in them can be persistent at the OS level and absolutely independent with any server process (e.g. DBMS server) or runtime environment (e.g. JVM). In a word, no SLS, no MI.