Single-level store
| Industry | Computer hardware, software, and IT services |
|---|---|
| Founded | June 16, 1911 in Endicott, New York, United States |
| Products | IBM i operating system, IBM Power Systems |
| Website | www |
Single-level storage (SLS), also known as single-level memory, is a concept in computer storage with two interconnected interpretations: in both cases, memory pages may reside either in primary storage (RAM) or on secondary storage devices such as disks, and the actual physical location remains transparent to the executing process.
Initially, this term described what is currently recognized as virtual memory, a system first introduced in 1962 by the Atlas machine developed at the University of Manchester.
In contemporary usage, SLS typically refers to a computing architecture where traditional files do not exist; instead, there are persistent objects or segments directly mapped into the address space of processes. These address spaces are composed entirely of such mapped objects. The entire storage hierarchy is viewed as a unified two-dimensional address space defined by segment and offset within that segment.
The idea of persistent objects was pioneered by Multics during the mid-1960s, a collaborative effort involving the MIT, General Electric, and Bell Labs. Multics implemented virtual memory spanning multiple tiers of storage, including main memory, high-speed drum, and disk-based storage.
IBM possesses patents related to single-level storage as it is implemented in the IBM i operating system running on IBM Power Systems and their predecessors, tracing back to the 1978 release of the System/38 platform.
Design
In early computing systems, a clear separation existed between main memory and secondary storage. Applications were responsible for explicitly transferring data from secondary storage into main memory for processing and then writing it back afterward. This separation remains characteristic of most modern operating systems.
With the advent of timesharing and multiprogramming during the 1960s, multiple applications operated simultaneously, each requiring allocation of memory resources. Operating systems responded by partitioning main memory into segments assigned to programs, often providing less memory than requested.
Virtual memory (VM) offered a solution by dividing main memory into fixed-size pages allocated dynamically as needed. This allowed programs to access an extensive "virtual" address space exceeding physical memory capacity. When physical RAM became fully utilized, VM transparently swapped out inactive pages to secondary storage. Despite this, programs still needed explicit instructions to perform input/output operations for permanent data via file systems or databases.
Single-level store builds upon VM concepts by treating all secondary storage as an extension of "main memory." Instead of maintaining a separate file system, programs allocate memory conventionally, with data automatically stored and retrieved without programmer intervention. Consequently, applications no longer handle data transfers between primary and secondary storage explicitly. For instance, data generated in-memory persists seamlessly across sessions without requiring dedicated I/O routines. Additionally, programs themselves reside within this integrated memory space, facilitating smooth restarts or user logins with all applications and corresponding data restored intact.
The operating system oversees page placement: pages resident in primary storage are instantly accessible; if located on disk, accessing them triggers a page fault, prompting their loading into main memory. Processes do not perform direct input/output operations; instead, reads occur implicitly via page faults while writes happen when modified pages are committed back to secondary storage.
System/38 and IBM i Architecture
The innovative single-level storage model was developed by Frank Soltis and Glenn Henry during the late 1970s as part of a strategy to move toward entirely solid-state memory systems. The System/38 was engineered to be independent of specific hardware for secondary storage, anticipating a future where disk drives would become outdated. Although the cost of solid-state memory has decreased over time, disk drives continue to offer a more economical solution due to their larger storage capacities, despite having slower access times.
Within System/38 and IBM i environments, every piece of stored information is assigned a virtual memory address that processor instructions can access, no matter where the data physically resides. When data is not present in physical memory, a page fault occurs, prompting software routines to retrieve the necessary page and load it into primary memory.
IBM i categorizes page faults into two distinct groups: database faults—occurring when pages associated with relational database components such as tables, views, or indexes are missing from primary memory—and non-database faults—happening when other types of objects are absent from primary storage. This approach enables effective memory management essential for handling demanding enterprise workloads.