Browse Prior Art Database

Memory Reference Monitor

IP.com Disclosure Number: IPCOM000078799D
Original Publication Date: 1973-Mar-01
Included in the Prior Art Database: 2005-Feb-26
Document File: 2 page(s) / 14K

Publishing Venue

IBM

Related People

Winters, RM: AUTHOR

Abstract

At present, there are no software monitoring tools available which can both efficiently and completely record memory reference patterns, for application and control program services. The existing techniques for monitoring reference patterns include instruction tracing or interpretive execution, which requires long execution times. If the sampling interval is large, data is lost; whereas, if the interval is small, the degradation is large. The subject monitoring technique detects memory references rapidly with a minimal amount of degradation.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Memory Reference Monitor

At present, there are no software monitoring tools available which can both efficiently and completely record memory reference patterns, for application and control program services. The existing techniques for monitoring reference patterns include instruction tracing or interpretive execution, which requires long execution times. If the sampling interval is large, data is lost; whereas, if the interval is small, the degradation is large. The subject monitoring technique detects memory references rapidly with a minimal amount of degradation.

The memory reference monitor is designed primarily to provide memory reference patterns for application load modules. The data collected by the monitor is useful in performance evaluation for existing applications on operating systems. If a paging operating system were available, the memory or page reference patterns of application load modules could be used to estimate performance, without actual execution under the paging operating system.

The monitor collects two sets of data. The first set is required to identify the state of the system and is collected by existing IBM S360/S370 techniques; whereas, the second set is required to record the types of memory references. The data-collection process is briefly described below.

To collect the first set of data, the monitor detects entries to and exits from the operating system by overlaying the new program status words (PSW's) and setting "hook" points in the nucleus. A "hook" is set, by invalidating the operation code of an instruction that is to be monitored. Each attempt to execute the instruction results in a program check interrupt which the monitor intercepts, then records the data necessary to identify the event and simulates the instruction before returning control to the normal sequence of operation. The data recorded for interrupts and "hook" points identify the state of the system, the task and load module in execution, and the application interfaces with the operating system.

The second set of data is collected as follows. The memory references are detected by utilizing the protection feature of OS - S360/S370. Store and fetch protect are standard features for all System 370 models and System 360 models 50 or above. The monitor uses the insert storage key and the set storage key, to activate the store and fetch protection for each 2K block. The monitor executes as a job and is assigned a storage key. The monitor modifies its PSW to use a zero protect key and uses its assigned storage key as the control key. The control key is assigned to the 2K block that is "in control" by modifying the protect key (PK) in the current PSW, and by setting the storage key of the current 2K block. All other 2K blocks in the machine retain valid protect keys (with fetch protection active). Execution proceeds normally until the current 2K block references another 2K block and a protection check interrupt occurs.

The monitor uses...