Testing a guarded storage facility

A computer-implemented method includes executing one or more test programs on a computing device, where the computing device includes a Guarded Storage (GS) facility managing use of GS. Each test program of the one or more test programs comprises a respective GS event, and each respective GS event prompts execution of a respective garbage reclaim function associated with the GS. A memory storage is analyzed, by a computer processor, to verify expected operation of each of the one or more test programs. Test results of the one or more test programs are determined based on the analyzing the memory storage. A remedial action is performed in response to the test results of the one or more test programs.

BACKGROUND

Embodiments of the present invention relate to system testing and, more specifically, to testing a Guarded Storage facility.

During execution of a Java program, the Java runtime collects the program's garbage, which is made up of memory objects that are deemed to be no longer in use. If these unused memory objects are not freed and released for reuse, the program can continue consuming more and more resources unchecked. This can slow down the computer system on which the program runs, and can reduce resources available to the program and other applications running on the computer system.

Guarded Storage is a facility incorporated into the z System® of International Business Machines®. With Guarded Storage, memory objects that are no longer needed are periodically made available for reuse.

SUMMARY

According to an embodiment of this invention, a computer-implemented method includes executing one or more test programs on a computing device, where the computing device includes a Guarded Storage (GS) facility managing use of GS. Each test program of the one or more test programs comprises a respective GS event, and each respective GS event prompts execution of a respective garbage reclaim function associated with the GS. A memory storage is analyzed, by a computer processor, to verify expected operation of each of the one or more test programs. Test results of the one or more test programs are determined based on the analyzing the memory storage. A remedial action is performed in response to the test results of the one or more test programs.

In another embodiment, a system includes a memory having computer-readable instructions and one or more processors for executing the computer-readable instructions. The computer-readable instructions include executing one or more test programs on a computing device, where the computing device includes a GS facility managing use of GS. Each test program of the one or more test programs comprises a respective GS event, and each respective GS event prompts execution of a respective garbage reclaim function associated with the GS. Further according to the computer-readable instructions, a memory storage is analyzed to verify expected operation of each of the one or more test programs. Test results of the one or more test programs are determined based on the analyzing the memory storage. A remedial action is performed in response to the test results of the one or more test programs.

In yet another embodiment, a computer program product for testing Guarded Storage includes a computer-readable storage medium having program instructions embodied therewith. The program instructions are executable by a processor to cause the processor to perform a method. The method includes executing one or more test programs on a computing device, where the computing device includes a GS facility managing use of GS. Each test program of the one or more test programs comprises a respective GS event, and each respective GS event prompts execution of a respective garbage reclaim function associated with the GS. Further according to the method, a memory storage is analyzed to verify expected operation of each of the one or more test programs. Test results of the one or more test programs are determined based on the analyzing the memory storage. A remedial action is performed in response to the test results of the one or more test programs.

DETAILED DESCRIPTION

The Guarded Storage (GS) facility is critical in that it frees up resources for use within a computing device. However, it is also critical to ensure that GS, which is managed by the GS facility, is operating as expected on each computing device in which it is incorporated. Given that GS is a relatively new technology, there is no conventional mechanism for testing GS to ensure it operates properly.

Turning now to an overview of aspects of the present invention, some embodiments of a test system provide a test mechanism to verify the functionality of a GS architecture in a virtual environment. In some embodiments, the test system applies to computer systems, such as the z System, that use Guarded Storage in virtual environments. The test system may operate with or without the use of Transactional Execution (TX) and Runtime Instrumentation (RI), which are additional facilities that may be incorporated into systems using GS.

FIG. 1is a diagram of the test system100for verifying functionality of GS on a computing device50, according to some embodiments of this invention. As shown inFIG. 1, the test system100may include one or more test programs110, executable on the computing device50to verify that GS, and thus the GS facility120, is operating properly on the computing device50. In some embodiments, the test programs110of the test system100may be executable within a virtual machine of the computing device50, to verify that GS is operating properly within a virtual environment of the computing device50. Example test programs110of the test system100will be described in detail below.

Generally, GS is activated by first loading GS enablement controls onto the computing device50being tested, such as by calling a GS load instruction to load GS-control. Additionally, a GS parameter storage area may be initialized and may include a GS event handler. When GS is active, a GS instruction encountered in a running program acts as a GS event, which causes a branch from the program into the GS event handler, which calls a reclaim function for the GS facility120. In some embodiments, the reclaim function executes code of the GS facility120for releasing unused memory, and then returns control back to the running program.

In the test system100, according to some embodiments, the running program is a test program110designed to test the functionality of GS. In the test programs110described below, these operations to initialize GS before running the test program110may be performed unless otherwise indicated. Results of each test program110may be available to the test system100, which may verify that GS is behaving as expected. For example, the results may be changes in memory of the computing device50, such that certain changes or lack of changes may be expected in the case of proper operation of GS. In some embodiments, verification may be performed automatically by the test system100, when the test system100is aware of expected memory changes due to proper operation. Alternatively, however, verification may be performed manually and may be entered into the test system100.

In some embodiments, the test system100may implement test programs110to verify proper operation of one or more of the following: standalone GS, GS interaction with the TX facility130, GS interaction with the RI facility140, GS interaction with both TX and RI, and adverse conditions of GS. It will be understood that an embodiment of the test system100may include one or more of the test programs110described below, and need not include every test program110described herein.

In some embodiments, the test system100may include a first test program used to verify proper operation of the standalone GS.FIG. 2is a block diagram of the first test program110a, according to some embodiments. The first test program110amay include a GS instruction, which may be followed by another instruction used to verify that a GS event occurred with the GS instruction. For instance, this other instruction may be notification code, which may be designed to notify when the program does not branch to the GS event handler and, thus, when no GS event GS event occurred. After execution of the first test program110a, the test system100may verify that the GS event occurred.

In some embodiments, the test system100may include a second test program used to verify that GS operates properly when used in conjunction with TX.FIG. 3is a block diagram of the second test program110b, according to some embodiments. Generally, TX is a facility that enables operations within transactional code to be performed atomically without another processor (i.e., other than the one executing the transactional code) accessing the memory referenced in the transactional code. With TX, a begin point and an end point of transactional code are specified in a program, and the program attempts to execute all the code between the begin point and the end point atomically. If the transactional code cannot be completed, then the TX facility generally reverts memory affected by all the executed instructions since the begin point and aborts the transactional code, indicating a failure. The second test program110bmay then reattempt the transaction code, once again starting from the begin point. Generally, however, a store operation within transactional code may be specified as a non-transactional store. Unlike other instructions in the transactional code, a non-transactional store is generally not reverted after an abort. The second test program110bmay verify that a non-transactional store within transactional code was executed and was not reversed, regardless of failure to complete the transactional code.

Specifically, for instance, the second test program110bmay include transactional code, marked by a begin point and an end point, and that transactional code may include a non-transactional store as well as a GS instruction following the non-transactional store. The expected behavior may be that the GS event handler is initiated, and a branch is taken to the reclaim function when the GS instruction is encountered as part of the transactional code. However, due to the GS event, the transactional code is unable to complete, and therefore aborts. In some embodiments, the transactional code returns a GS abort code recognizable by the test system100. Memory affected by the transactional code may be reverted, with the exception of the non-transactional store. The test system100may then verify that the memory modified by the transactional store retained the changes made by the transactional store, and may further verify that other changes to memory by the transactional code were reverted.

In some embodiments, the test system100may include a third test program, also for testing operation of the GS in conjunction with TX.FIG. 4is a block diagram of the third test program110c, according to some embodiments. Specifically, the third test program110cmay be used to verify that storage reverts to its previous state on abortion of transactional code. The third test program110cmay include transactional code, which may include a GS instruction as well as one or more store operations that are not non-transactional stores. Further, the third test program110cmay include a branch relative on condition (BRC) instruction immediately after the begin point of the transactional code. The expected behavior of the third test program110cin some embodiments is to branch to the reclaim function upon recognizing the GS event. However, in some embodiments, when a GS event occurs, the GS instruction is expected to cause an abort of the transactional code. In some embodiments, this is expected to result in an abort code indicating an unknown abort. After execution of the reclaim function, execution may return to the BRC. After execution of the third test program110c, the test system100may verify that the operations occurred as expected.

In some embodiments, the test system100may include a fourth test program, which may be used to verify that storage is restored, and thus that any operations of the transactional code are reversed, upon an abort from the transactional code.FIG. 5is a diagram of the fourth test program110d, according to some embodiments of this invention. As shown inFIG. 5, the fourth test program110dmay initially specify a valid branch address to the GS event handler before the begin point of the transactional code. A BRC instruction may immediately follow the begin point. Later in the transactional code, a bad branch address to the GS event handler may be specified, followed by a GS instruction. After execution of the fourth test program110d, the test system100may verify that the bad branch address is not taken, while the valid branch address is. The test system100may additionally verify that the memory storage reverts back to its state prior to the transactional code being entered, since the execution of the transactional code may be expected to abort due to the GS instruction.

In some embodiments, the test system100includes a fifth test program.FIG. 6is a block diagram of the fifth test program110e, according to some embodiments. The fifth test program110emay be used to verify that general purpose registers are restored, when applicable, upon abortion of the transactional code. The fifth test program110emay include, in order as shown inFIG. 6, a load register (LG) with no event value, a begin point for transactional code, a BRC instruction, an LG with an event value, and then a GS instruction. If behaving as expected, a GS event (i.e., the GS instruction) may cause the transactional code to abort. In some embodiments, this leads to an abort code indicating an unknown abort. Upon reaching the GS instruction, the processing may branch to the reclaim function. After execution of the reclaim function, processing may continue at the BRC instruction. The test system100may verify that the execution of the fifth test program110eproceeds as described above.

In some embodiments, the test system100includes a sixth test program to verify that RI and GS work as expected in conjunction with each other.FIG. 7is a block diagram of the sixth test program110f, according to some embodiments. Generally, RI enables recording of instructions performed following an RINEXT instruction. Such recordings are saved for later use in accordance with the RI implementation. The sixth test program110fmay be used by the test system100to verify that RI recording of GS operations behaves as expected. As shown inFIG. 7, the RI controls may be loaded into the system. In some embodiments, an RINEXT instruction and the GS instruction may be ordered back to back in the sixth test program110f. After running the sixth test program110f, the test system100may verify that RI recorded the GS event.

In some embodiments, the test system100includes a seventh test program also used to verify that RI and GS work as expected in conjunction with each other.FIG. 8is a block diagram of the seventh test program110g, according to some embodiments of this invention. The seventh test program110gmay be used by the test system100to verify that GS, TX, and RI operate as expected in conjunction with one another. Generally, when transactional code within a begin point and a respective end point includes multiple RINEXT instructions, only the first of such instructions within that transactional code may result in a recording. In other words, all but the first RINEXT instruction within a segment of transactional code are generally ignored. However, according to the expected operation, RI may be implemented to record the operation of GS instructions, even when those GS instructions appear within the transactional code. Specifically, the seventh test program110gmay be used to verify that a GS instruction within transactional code is recorded by RI, when that GS instruction is not the first indicated RI recording within the transactional code. As shown inFIG. 8, two RINEXT instructions may be included in the seventh test program110g, with the second one appearing directly before a GS instruction. After execution of the seventh test program110g, the test system100may verify that the GS event corresponding to the GS instruction was recorded using RI.

FIG. 9is a flow diagram of a method900for testing GS functionality on a computing device50, according to some embodiments of this invention. As shown inFIG. 9, at block905, the test system100may be loaded onto a computing device50having GS. In some embodiments, the computing device50may be a new computer system, such as a z System, and the test system100may be used to verify operation of GS on the computing device50before the computing device50is sold or otherwise released for use. At block910, the test system100may be initiated by the computing device50. At decision block915, the test system100may determine whether any test programs110are available to be run on the computing device50. In some embodiments, this determination may be performed automatically by the test system100, such as by determining whether any test programs110applicable to the computing device50have not yet been run on the computing device50. Alternatively, however, a user may manually determine whether an additional test program110is to be run, and the test system's determination may thus be based on user entry. If no test programs110remain to be run at decision block915, then the method may end at block920by automatically performing a remedial action on the computing device50in response to the results of the test programs110. In some embodiments, such a remedial action may include reporting errors or indicating progress, or both, that occurred through running the test programs110.

If a test program110is identified at decision block915as not yet having been run, then at block925, the test system100may run that test program110. For example, and not by way of limitation, the test program110may be one of those described above. At block930, after running the test program110, the test system100may verify proper operation of the test program110. In other words, the test system100may determine whether the test program110ran as expected. In some embodiments, the test system100may be aware of the expected results and may thus perform this verification automatically. Alternatively, however, manual verification may be received by the test system100. The method900may then return to decision block915to determine whether additional test programs110remain to be run.

FIG. 10illustrates a block diagram of a computer system1000for use in implementing a test system100or method according to some embodiments. The test systems100and methods described herein may be implemented in hardware, software (e.g., firmware), or a combination thereof. In some embodiments, the methods described may be implemented, at least in part, in hardware and may be part of the microprocessor of a special or general-purpose computer system1000, such as a personal computer, workstation, minicomputer, or mainframe computer. For instance, the computing device50on which the test system100runs test programs110may be a computer system1000as shown inFIG. 10.

In some embodiments, as shown inFIG. 10, the computer system1000includes a processor1005, memory1010coupled to a memory controller1015, and one or more input devices1045and/or output devices1040, such as peripherals, that are communicatively coupled via a local I/O controller1035. These devices1040and1045may include, for example, a printer, a scanner, a microphone, and the like. Input devices such as a conventional keyboard1050and mouse1055may be coupled to the I/O controller1035. The I/O controller1035may be, for example, one or more buses or other wired or wireless connections, as are known in the art. The I/O controller1035may have additional elements, which are omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers, to enable communications.

The processor1005is a hardware device for executing hardware instructions or software, particularly those stored in memory1010. The processor1005may be a custom made or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the computer system1000, a semiconductor based microprocessor (in the form of a microchip or chip set), a macroprocessor, or other device for executing instructions. The processor1005includes a cache1070, which may include, but is not limited to, an instruction cache to speed up executable instruction fetch, a data cache to speed up data fetch and store, and a translation lookaside buffer (TLB) used to speed up virtual-to-physical address translation for both executable instructions and data. The cache1070may be organized as a hierarchy of more cache levels (L1, L2, etc.).

The memory1010may include one or combinations of volatile memory elements (e.g., random access memory, RAM, such as DRAM, SRAM, SDRAM, etc.) and nonvolatile memory elements (e.g., ROM, erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), programmable read only memory (PROM), tape, compact disc read only memory (CD-ROM), disk, diskette, cartridge, cassette or the like, etc.). Moreover, the memory1010may incorporate electronic, magnetic, optical, or other types of storage media. Note that the memory1010may have a distributed architecture, where various components are situated remote from one another but may be accessed by the processor1005.

The instructions in memory1010may include one or more separate programs, each of which comprises an ordered listing of executable instructions for implementing logical functions. In the example ofFIG. 10, the instructions in the memory1010include a suitable operating system (OS)1011. The operating system1011essentially may control the execution of other computer programs and provides scheduling, input-output control, file and data management, memory management, and communication control and related services.

Additional data, including, for example, instructions for the processor1005or other retrievable information, may be stored in storage1020, which may be a storage device such as a hard disk drive or solid state drive. The stored instructions in memory1010or in storage1020may include those enabling the processor to execute one or more aspects of the test systems100and methods of this disclosure.

The computer system1000may further include a display controller1025coupled to a display1030. In some embodiments, the computer system1000may further include a network interface1060for coupling to a network1065. The network1065may be an IP-based network for communication between the computer system1000and an external server, client and the like via a broadband connection. The network1065transmits and receives data between the computer system1000and external systems. In some embodiments, the network1065may be a managed IP network administered by a service provider. The network1065may be implemented in a wireless fashion, e.g., using wireless protocols and technologies, such as WiFi, WiMax, etc. The network1065may also be a packet-switched network such as a local area network, wide area network, metropolitan area network, the Internet, or other similar type of network environment. The network1065may be a fixed wireless network, a wireless local area network (LAN), a wireless wide area network (WAN) a personal area network (PAN), a virtual private network (VPN), intranet or other suitable network system and may include equipment for receiving and transmitting signals.

Test systems100and methods according to this disclosure may be embodied, in whole or in part, in computer program products or in computer systems1000, such as that illustrated inFIG. 10.

Technical effects and benefits of some embodiments include the ability to test a computing device50to verify operation of GS and, thus, to determine whether it will operate as intended for a user. Specifically, the test system100may run various test programs110with code designed to provide verifiable changes in memory.