2. PERFORMANCE REPORTING ANALYSIS › 2.2 Real Storage Management Analysis › 2.2.4 MVS Concepts › 2.2.4.1 Virtual Storage Concepts › 2.2.4.1.1 Address Resolution Schemes
2.2.4.1.1 Address Resolution Schemes
The resolution of addresses is a central issue to virtual
systems for two reasons. First, memory may not be shared
unless the code and data of one user is protected against
unauthorized modification by the other users (be it
accidental or malicious). Second, the address resolution
mechanism largely dictates the manner in which users may be
moved in and out of real storage.
If a virtual system is to provide more apparent (virtual)
storage than is actually available, the system must be able
to allocate the real memory it has in an efficient manner.
One method of moving users in and out of real storage is
paging. This is discussed in Section 2.2.4.1.2.
This section briefly traces the development of address
resolution by the IBM operating systems in order to provide a
conceptual basis for discussing MVS real storage issues.
In general, there are three kinds of address resolution used:
o Absolute addressing
o Relative addressing
o Dynamic addressing
There are three times in the life of a program when addresses
may be assigned: when the program is written or compiled
(absolute addressing), when the program is loaded into memory
(relative addressing), and when the program is executed
(dynamic addressing). Of these schemes, only dynamic
addressing requires hardware to support the resolution of an
address. In this section, we discuss each of these
addressing schemes in terms of the problems they impose or
solve for a virtual memory system.
ABSOLUTE ADDRESSING
The early computers did not have any hardware to support
memory sharing, such as memory protection features or dynamic
address resolution. These computers had an instruction
format something like that shown in Figure 2-19:
ooooxxxaaaaaaaa
| | |
| | |
| | +--- address field
| |
| +-------- register specification
|
+------------ instruction op-code
Figure 2-19. Computer Instruction Format
where the instruction had an op-code (o) and a general
register specification (x), and the remainder of the bits
comprised the address (a). The amount of real memory was
limited by the number of bits in the address portion of the
instruction format. Programs were prevented from accessing
or altering the data of other programs because real memory
was not shared concurrently. Only one task was present in
memory at one time. There was no effective protection for
the resident operating system code.
In terms of memory management, the only virtual memory
allocation scheme possible for implementing a time-sharing
system on these machines was swapping. Swapping involves
moving an entire program into real storage from auxiliary
storage in order to make it active, or moving an active
program out of real storage into auxiliary storage, making it
inactive.
RELATIVE ADDRESSING (ADDRESS RESOLUTION AT PROGRAM LOAD)
Nothing in the instruction format shown in Figure 2-19
precluded address resolution at the time the program was
loaded. However, without memory protection facilities such
as the protect keys used by the IBM S/360 series, there was
no reason to develop the program loaders and linkage editors
to implement load time address resolution. In the IBM S/360
series, there are two levels of address constants and the
instruction format is designed to make load time address
resolution more efficient. The S/360 instruction formation
shown in Figure 2-20 provides two other advantages for
program load address resolution.
oorxbaaa
| ||||
| ||||
| |||+---- address offsets (12 bits)
| |||
| ||+----- Base Register (4 bits)
| ||
| |+------ Index register (4 bits)
| |
| +------- General Register (4 bits)
|
+--------- Instruction op-code (8 bits)
Figure 2-20. S/360 RX Instruction Format
The instruction length of an RX instruction is 32 bits (one
full word). The address field of the instruction is defined
by the baaa portion, which is 16 bits in length. This
address is resolved as a displacement (aaa) from the base
register (b), which contains a 24-bit address. This defines
a 24-bit address with only 16 bits in the instruction. Also,
because all addresses are relative to a base register set by
the program, the object code is relocatable in its executable
format. Thus, less overhead is involved during the program
load, as only address constants must be resolved at this
time.
However, in the S/360, once a program is loaded it may not be
moved. The loader resolves address constants with absolute
addresses and the program execution places absolute addresses
in the required base registers. From that point on, the
program is fixed in the real memory locations where it was
loaded. Thus, for swapping to work, a program would have to
be swapped back into these same storage locations.
IBM developed two multiprogramming systems on the S/360
series. The first, MFT, divided memory into a number of
fixed partitions. The second, MVT, dynamically assigned real
memory to jobs as they were started.
Neither of these system designs was flexible enough for a
time-sharing environment. In MFT, the fixed partitions made
swapping a possibility but required a preallocation of
memory, which severely constrained the batch workload. In
MVT, swapping was not practical because a job had to be
swapped back into exactly the same real memory it was first
loaded into, and that memory had to be contiguous.
The first IBM time-sharing system combined ideas from each of
these systems. The first Time-Sharing Option (TSO), released
with MVT in the early 1970s, allocated a number of fixed
time-sharing partitions, with the remainder of real storage
dedicated to batch.
Figure 2-21 shows a memory allocation for an MVT system. The
System Control Program (SCP) occupied the high and low
addresses, with the area in between dynamically assigned to
jobs.
In MVT, the memory between the executing programs was
available for execution. Eventually, 50 percent of the
available memory is lost to the type of memory fragmentation
shown in Figure 2-21. This type of fragmentation is called
EXTERNAL FRAGMENTATION. In MVT and in other similar systems,
the real memory lost to external fragmentation was shown to
average around 33 percent. This represented a serious
constraint on throughput, as well as requiring a substantial
effort for the installation in trying to minimize the
occurrence and impact of this fragmentation.
---------------------------
| |
| System Queue Area |
| |
|-------------------------|
| PROGRAM 2 |
|-------------------------|
| ////////////////////// |
| ////// not used ////// |
| ////////////////////// |
|-------------------------|
| |
| |
| PROGRAM 1 |
| |
| |
|-------------------------|
| ////// not used ////// |
|-------------------------|
| |
| PROGRAM 4 |
| |
|-------------------------|
| ////////////////////// |
| ////////////////////// |
| ////// not used ////// |
| ////////////////////// |
| ////////////////////// |
|-------------------------|
| PROGRAM 3 |
|-------------------------|
| |
| Nucleus |
| |
---------------------------
Figure 2-21. An MVT Real Memory Allocation
DYNAMIC ADDRESS RESOLUTION
This discussion of dynamic addressing outlines the benefits
of using a dynamic scheme in implementing a virtual system.
The mechanics of dynamic addressing in MVS is discussed in
Section 2.2.4.1.2. Address resolution performed as each
instruction is executed solves the problem of code and data
relocation. Two schemes were implemented: segmentation
systems and paging systems. A segmentation system divides
each program into a number of parts called segments.
Segments of a program may be relocated in real memory. The
number of segments a program could be divided into was small.
On the GE635, for example, there were seven segmentation
registers. As this scheme still had the external
fragmentation problem illustrated by Figure 2-21, it never
gained wide use.
In a paging system, all real memory is divided into equal
parts (pages) of a fixed length. Each active program in
virtual storage is "paged in" to real storage in order to
gain access to the CPU. A paging system allows the virtual
pages making up a job to be placed anywhere in real memory.
In a paging system, there can be no external fragmentation,
because each program in memory occupies an integral number of
pages. Each program has some wasted space, because
allocation is by pages. This is called internal
fragmentation. This problem is minimized for a given system
by the selection of a page size and by the techniques used
for dynamic storage allocation within a program. Early work
in this area with IBM virtual systems is described in the IBM
Journal of Research and Development.
One of the goals of a virtual system is to relieve
application programs of memory management concerns. In
non-dynamic systems such as MVT, a great deal of system
design went into making a program use memory more efficiently
through the use of overlay structures and dynamic loading
facilities. In a virtual memory system, a program is given a
large amount of virtual memory to use. The operating system
then allocates real storage to jobs as required. Figure 2-22
shows a simplified view of the virtual storage allocation in
an MVS/370 (pre-MVS/XA) system running four programs. To
each program, it appears as if the entire virtual storage of
16 megabytes is available to it (less the areas used by the
control program).
-------------
| |
|Common Area|
| |
|-----------| ------------- -------------
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| PROGRAM 1 | | PROGRAM 2 | ... | PROGRAM 4 |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
|-----------| ------------- -------------
| |
| Nucleus |
| |
-------------
Figure 2-22. MVS/370 Virtual Memory Allocation
An implication of the MVS/370 24-bit addressing scheme is
that the size of a user application program is constrained by
the limitations of 16 megabytes minus the size of the control
program. As user application programs grew larger and
larger, it became evident that an addressing scheme that
allowed only 16 megabytes of virtual storage addressability
was inadequate.
To provide the necessary virtual storage constraint relief,
allowing users to write applications that are substantially
larger than those possible in MVS/370 systems, MVS/XA
(extended addressing) was developed. By expanding the size
of the address to 31 bits, jobs can address up to 2 billion
bytes (2 gigabytes) of virtual storage. To maintain
compatibility with MVS/370 and yet provide the expanded
addressability, MVS/XA provides regions of virtual storage
that are defined below the 16 megabyte line and "extended"
portions of these regions are defined above the 16MB line.
Figure 2-22 shows conceptually how this is done. MVS/XA
treats both the portion below the 16MB line and the extended
portion above the 16MB line as one logical area. As with the
example in Figure 2-22, each job running in an MVS/XA system
would have its own copy of the Private and Extended Private
areas.
2Gb ------------- ------------- -------------
| | | | | |
| PROGRAM 1 | | PROGRAM 2 | | PROGRAM 4 |
| Extended | | Extended | | Extended |
| Private | | Private | ... | Private |
| Area | | Area | | Area |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
|-----------| ------------- -------------
| Extended |
| Common |
| Area |
16MB -------------
| |
|Common Area|
| |
|-----------| ------------- -------------
| | | | | |
| PROGRAM 1 | | PROGRAM 2 | | PROGRAM 4 |
| Private | | Private | | Private |
| Area | | Area | | Area |
| | | | ... | |
| | | | | |
| | | | | |
|-----------| ------------- -------------
|Common Area|
0K -------------
Figure 2-23. MVS/XA Virtual Memory Allocation
You can determine whether the program, or modules, use 24 bit
or 31 bit addressing via the AMODE attribute which is
specified to the assembler or the linkage editor. The
default if the AMODE attribute is not specified is 24 bit
addressing.
You can also determine whether the modules are to be loaded
into the User Region (below the 16MB line) or the Extended
User Region (above the 16MB line) via the RMODE attribute for
the assembler or linkage editor. The default if the RMODE
attribute is not specified is to load the module into the
User Region below the 16MB line. This allows programs
written for MVS/370 to run in MVS/XA with generally no
modification.
Figure 2-24 shows how real memory might be allocated to the
four jobs concurrently executing in Figure 2-22. First, no
real memory is lost to external fragmentation. If another
job starts and no real memory is available, either some pages
may be taken from other jobs to make real memory available,
or one or more of the active jobs may be removed from memory
(in MVS, swapped out).
Real memory is more efficiently used because idle portions of
the program (either code or data) are not kept in real
memory. In Figure 2-24, the page numbering indicates the
page number in the program's virtual storage. Thus, in MVS,
where the page size is 4096 bytes, page 1 is the first 4K of
the program, page 2 the second 4K, and page n is the nth 4K
section of the program.
We see from Figure 2-24 that only referenced parts of the
program need to be resident and that these need not be
contiguous in real memory. In theory, a program could be
executing (efficiently) with only one page in memory at a
given time.
---------------------------
| PROGRAM 3, Page 9 |
---------------------------
.
.
.
.
---------------------------
| PROGRAM 2, Page 7 |
|-------------------------|
| PROGRAM 1, Page 1 |
|-------------------------|
| PROGRAM 4, Page 4 |
|-------------------------|
| PROGRAM 3, Page 6 |
|-------------------------|
| PROGRAM 2, Page 1 |
|-------------------------|
| PROGRAM 1, Page 4 |
|-------------------------|
| PROGRAM 1, Page 5 |
|-------------------------|
| PROGRAM 3, Page 2 |
|-------------------------|
| PROGRAM 2, Page 4 |
|-------------------------|
| PROGRAM 1, Page 3 |
|-------------------------|
| PROGRAM 4, Page 3 |
|-------------------------|
| PROGRAM 1, Page 9 |
|-------------------------|
| |
| Nucleus |
| |
---------------------------
Figure 2-24. An MVS Real Memory Allocation
Copyright © 2014 CA.
All rights reserved.
|
|