Run-time instrumentation reporting

BACKGROUND

0001The present invention relates generally to processing within a computing environment, and more specifically, to run-time instrumentation reporting.

0002Computer processors execute transactions using increasingly complex branch prediction and instruction caching logic. These processes have been introduced to increase instruction throughput, and therefore processing performance. The introduction of logic for improving performance makes it difficult to predict with certainty how a particular software application will execute on the computer processor. During the software development process there is often a balance between functionality and performance. Software is executed at one or more levels of abstraction from the underlying hardware that is executing the software. When hardware is virtualized, an additional layer of abstraction is introduced. With the introduction of performance enhancing logic, and the various layers of abstraction it is difficult to have a thorough understanding of what is actually occurring at the hardware level when a program is executing. Without this information, software developers use more abstract methods, such as execution duration, memory usage, number of threads, etc., for optimizing the software application.

0003When hardware specific information is available, it is typically provided to a developer after the fact and it is provided in aggregate, at a high level, and/or interspersed with the activity of other programs, and the operating system, making it difficult to identify issues that may be impacting the efficiency and accuracy of the software application.

SUMMARY

0004Embodiments include a computer program product, and system for run-time instrumentation reporting. An instruction stream is executed by a processor. Run-time instrumentation information of the executing instruction stream is captured by the processor. Run-time instrumentation records are created based on the captured run-time instrumentation information. A run-time instrumentation sample point of the executing instruction stream on the processor is detected. A reporting group is stored in a run-time instrumentation program buffer. The storing is based on the detecting and the storing includes: determining a current address of the run-time instrumentation program buffer, the determining based on instruction accessible run-time instrumentation controls; and storing the reporting group into the run-time instrumentation program buffer based on an origin address and the current address of the run-time instrumentation program buffer, the reporting group including the created run-time instrumentation records.

0005Additional features and advantages are realized through the techniques of the present invention. Other embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed invention. For a better understanding of the invention with advantages and features, refer to the description and to the drawings.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

0006The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The forgoing and other features, and advantages of the invention are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:

0007<figref idref="DRAWINGS">FIG. 1A</figref> is a diagram depicting an example host computer system in an embodiment;

0008<figref idref="DRAWINGS">FIG. 1B</figref> is a diagram depicting an example emulation host computer system in an embodiment;

0009<figref idref="DRAWINGS">FIG. 1C</figref> is a diagram depicting an example computer system in an embodiment;

0010<figref idref="DRAWINGS">FIG. 2</figref> is a diagram depicting an example computer network in an embodiment;

0011<figref idref="DRAWINGS">FIG. 3</figref> is a diagram depicting elements of a computer system in an embodiment;

0012<figref idref="DRAWINGS">FIGS. 4A-4C</figref> depict detailed elements of a computer system in an embodiment;

0013<figref idref="DRAWINGS">FIG. 5</figref> depicts a schematic diagram of a system for run-time instrumentation of a processor in accordance with an embodiment;

0014<figref idref="DRAWINGS">FIG. 6</figref> depicts a portion of a run-time-instrumentation control block (RICCB) including controls that are settable by a privileged state in an embodiment;

0015<figref idref="DRAWINGS">FIG. 7</figref> depicts a portion of a RICCB control block when the semi-privileged bit (K) is set to 1 in an embodiment;

0016<figref idref="DRAWINGS">FIG. 8</figref> depicts a collection buffer in accordance with an embodiment;

0017<figref idref="DRAWINGS">FIG. 9</figref> depicts a reporting group in accordance with an embodiment;

0018<figref idref="DRAWINGS">FIG. 10</figref> depicts an embodiment of a begin record in a reporting group;

0019<figref idref="DRAWINGS">FIG. 11</figref> depicts an embodiment of a timestamp record in a reporting group;

0020<figref idref="DRAWINGS">FIG. 12</figref> depicts embodiments of emit records in a reporting group;

0021<figref idref="DRAWINGS">FIG. 13</figref> depicts embodiments of abort records in a reporting group;

0022<figref idref="DRAWINGS">FIG. 14</figref> depicts embodiments of call records in a reporting group;

0023<figref idref="DRAWINGS">FIG. 15</figref> depicts an embodiment of a fill record in a reporting group;

0024<figref idref="DRAWINGS">FIG. 16</figref> depicts embodiments of instruction records in a reporting group;

0025<figref idref="DRAWINGS">FIG. 17</figref> depicts a process for run-time instrumentation reporting in accordance with an embodiment; and

0026<figref idref="DRAWINGS">FIG. 18</figref> illustrates a computer program product in accordance with an embodiment.

DETAILED DESCRIPTION

0027An embodiment of the present invention is a hardware based run-time instrumentation facility for managed run-times. As used herein the term “managed run-time” refers to an environment that encapsulates a state and manages resources used to execute a program or application (e.g., Java® virtual machine or “JVM”, operating system, middleware, etc.). Embodiments of the run-time instrumentation facility enable a program to collect information about program execution, including central processing unit (CPU) data. The collected information allows the program to acquire insights about the program from which the information is collected. Embodiments of the run-time instrumentation facility include a hardware facility for collecting sequences of events (e.g., taken branches, register values, etc.) in a collection buffer. Contents of the collection buffer (or a subset of the collection buffer containing the most recent records) are copied into a program buffer in the application's address space (for example the address space of a JVM) upon a programmable set of sample triggering events such as, but not limited to: a software directive in the form of an instruction inserted into the instruction stream; an interval of executed instructions are completed, a given elapsed time since the last sample expired, and/or a given hardware event such as data or instruction cache miss is observed.

0028The data stored at each sample point is stored as a set of related records, referred to herein as a reporting group. A reporting group is stored into the program buffer whose location is determined from controls associated with the run-time instrumentation. Thus, instrumented data stored as reporting groups in the program buffer are available to the program for post-analysis (or even aggressive analysis during run-time instrumentation).

0029Dynamic compilers may exploit run-time information, such as that collected by the hardware based run-time instrumentation facility described herein to perform online feedback directed optimizations. For example, information about important execution paths, profiled values and preferred branch directions can be used by a dynamic compiler to perform optimizations that specialize or version code, direct in-lining, re-order execution paths, and straighten branches. Embodiments described herein are not limited to use by compilers and may be used in variety of manners such as, but not limited to, for directing other managed run-time facilities. For example, data cache events can be used to help a garbage collector process make decisions about co-locating or distancing objects to gain better data locality or avoid false sharing problems.

0030<figref idref="DRAWINGS">FIG. 1A</figref>, depicts the representative components of a host computer system <b>50</b> in an embodiment. Other arrangements of components may also be employed in a computer system. The representative host computer system <b>50</b> comprises one or more processors <b>1</b> in communication with main store (computer memory) <b>2</b> as well as I/O interfaces to storage devices <b>11</b> and networks <b>10</b> for communicating with other computers or SANs and the like. The processor <b>1</b> is compliant with an architecture having an architected instruction set and architected functionality. The processor <b>1</b> may have dynamic address translation (DAT) <b>3</b> for transforming program addresses (virtual addresses) into a real address in memory. A DAT <b>3</b> typically includes a translation lookaside buffer (TLB) <b>7</b> for caching translations so that later accesses to the block of computer memory <b>2</b> do not require the delay of address translation. Typically a cache <b>9</b> is employed between the computer memory <b>2</b> and the processor <b>1</b>. The cache <b>9</b> may be hierarchical having a large cache available to more than one CPU and smaller, faster (lower level) caches between the large cache and each CPU. In some embodiments, the lower level caches are split to provide separate low level caches for instruction fetching and data accesses. In an embodiment, an instruction is fetched from the computer memory <b>2</b> by an instruction fetch unit <b>4</b> via the cache <b>9</b>. The instruction is decoded in an instruction decode unit <b>6</b> and dispatched (with other instructions in some embodiments) to instruction execution units <b>8</b>. Typically several instruction execution units <b>8</b> are employed, for example an arithmetic execution unit, a floating point execution unit and a branch instruction execution unit. The instruction is executed by the instruction execution unit <b>8</b>, accessing operands from instruction specified registers or the computer memory <b>2</b> as needed. If an operand is to be accessed (loaded or stored) from the computer memory <b>2</b>, the load store unit <b>5</b> typically handles the access under control of the instruction being executed. Instructions may be executed in hardware circuits or in internal microcode (firmware) or by a combination of both.

0031In <figref idref="DRAWINGS">FIG. 1B</figref>, depicts an emulated host computer system <b>21</b> is provided that emulates a host computer system of a host architecture, such as the host computer system <b>50</b> of <figref idref="DRAWINGS">FIG. 1</figref>. In the emulated host computer system <b>21</b>, a host processor (CPU) <b>1</b> is an emulated host processor (or virtual host processor) <b>29</b>, and comprises a native processor <b>27</b> having a different native instruction set architecture than that of the processor <b>1</b> of the host computer system <b>50</b>. The emulated host computer system <b>21</b> has memory <b>22</b> accessible to the native processor <b>27</b>. In an embodiment, the memory <b>22</b> is partitioned into a computer memory <b>2</b> portion and an emulation routines memory <b>23</b> portion. The computer memory <b>2</b> is available to programs of the emulated host computer system <b>21</b> according to the host computer architecture. The native processor <b>27</b> executes native instructions of an architected instruction set of an architecture other than that of the emulated processor <b>29</b>, the native instructions obtained from the emulation routines memory <b>23</b>, and may access a host instruction for execution from a program in the computer memory <b>2</b> by employing one or more instruction(s) obtained in a sequence &amp; access/decode routine which may decode the host instruction(s) accessed to determine a native instruction execution routine for emulating the function of the host instruction accessed. Other facilities that are defined for the host computer system <b>50</b> architecture may be emulated by architected facilities routines, including such facilities as general purpose registers, control registers, dynamic address translation and input/output (I/O) subsystem support and processor cache for example. The emulation routines may also take advantage of function available in the native processor <b>27</b> (such as general registers and dynamic translation of virtual addresses) to improve performance of the emulation routines. Special hardware and off-load engines may also be provided to assist the native processor <b>27</b> in emulating the function of the host computer system <b>50</b>.

0032In a mainframe, architected machine instructions are used by programmers, usually today “C” programmers often by way of a compiler application. These instructions stored in the storage medium may be executed natively in a z/Architecture IBM Server, or alternatively in machines executing other architectures. They can be emulated in the existing and in future IBM mainframe servers and on other machines of IBM (e.g. pSeries® Servers and xSeries® Servers). They can be executed in machines running Linux on a wide variety of machines using hardware manufactured by IBM®, Intel®, AMD™, Sun Microsystems and others. Besides execution on that hardware under a Z/Architecture®, Linux can be used as well as machines which use emulation by Hercules, UMX, Fundamental Software, Inc. (FSI) or Platform Solutions, Inc. (PSI), where generally execution is in an emulation mode. In emulation mode, emulation software is executed by a native processor to emulate the architecture of an emulated processor.

0033One or more of the components of the emulated host computer system <b>21</b> are further described in “IBM® z/Architecture Principles of Operation,” Publication No. SA22-7832-08, 9th Edition, August, 2010 which is hereby incorporated herein by reference in its entirety. IBM is a registered trademark of International Business Machines Corporation, Armonk, N.Y., USA. Other names used herein may be registered trademarks, trademarks or product names of International Business Machines Corporation or other companies.

0034The native processor <b>27</b> typically executes emulation software stored in the emulation routines memory <b>23</b> comprising either firmware or a native operating system to perform emulation of the emulated processor. The emulation software is responsible for fetching and executing instructions of the emulated processor architecture. The emulation software maintains an emulated program counter to keep track of instruction boundaries. The emulation software may fetch one or more emulated machine instructions at a time and convert the one or more emulated machine instructions to a corresponding group of native machine instructions for execution by the native processor <b>27</b>. These converted instructions may be cached such that a faster conversion can be accomplished. The emulation software maintains the architecture rules of the emulated processor architecture so as to assure operating systems and applications written for the emulated processor operate correctly. Furthermore the emulation software provides resources identified by the emulated processor architecture including, but not limited to control registers, general purpose registers, floating point registers, dynamic address translation function including segment tables and page tables for example, interrupt mechanisms, context switch mechanisms, time of day (TOD) clocks and architected interfaces to I/O subsystems such that an operating system or an application program designed to run on the emulated processor <b>29</b>, can be run on the native processor <b>27</b> having the emulation software.

0035A specific instruction being emulated is decoded, and a subroutine called to perform the function of the individual instruction. An emulation software function emulating a function of an emulated processor <b>29</b> is implemented, for example, in a “C” subroutine or driver, or some other method of providing a driver for the specific hardware as will be within the skill of those in the art after understanding the description of the preferred embodiment.

0036In an embodiment, the invention may be practiced by software (sometimes referred to licensed internal code, firmware, micro-code, milli-code, pico-code and the like, any of which would be consistent with the present invention). Referring to <figref idref="DRAWINGS">FIG. 1A</figref>, software program code which embodies the present invention is accessed by the processor also known as a CPU (Central Processing Unit) <b>1</b> of the host computer system <b>50</b> from the storage device <b>11</b> such as a long-term storage media, a CD-ROM drive, tape drive or hard drive. The software program code may be embodied on any of a variety of known media for use with a data processing system, such as a diskette, hard drive, or CD-ROM. The code may be distributed on such media, or may be distributed to users from the computer memory <b>2</b> or storage of one computer system over a network <b>10</b> to other computer systems for use by users of such other systems.

0037Alternatively, the program code may be embodied in the computer memory <b>2</b>, and accessed by the processor <b>1</b> using a processor bus (not shown). Such program code includes an operating system which controls the function and interaction of the various computer components and one or more application programs. Program code is normally paged from a dense media such as the storage device <b>11</b> to computer memory <b>2</b> where it is available for processing by the processor <b>1</b>. The techniques and methods for embodying software program code in memory, on physical media, and/or distributing software code via networks are well known and will not be further discussed herein. Program code, when created and stored on a tangible medium (including but not limited to electronic memory modules (RAM), flash memory, compact discs (CDs), DVDs, Magnetic Tape and the like is often referred to as a “computer program product.” The computer program product medium is typically readable by a processing circuit preferably in a computer system for execution by the processing circuit.

0038<figref idref="DRAWINGS">FIG. 1C</figref> illustrates a representative workstation or server hardware system in which the present invention may be practiced. The system <b>100</b> of <figref idref="DRAWINGS">FIG. 1C</figref> comprises a representative base computer system <b>101</b>, such as a personal computer, a workstation or a server, including optional peripheral devices. The base computer system <b>101</b> includes one or more processors <b>106</b> and a bus (not shown) employed to connect and enable communication between the one or more processors <b>106</b> and the other components of the base computer system <b>101</b> in accordance with known techniques. The bus connects the processor <b>106</b> to memory <b>105</b> and long-term storage <b>107</b> which may include a hard drive (including any of magnetic media, CD, DVD and Flash Memory for example) or a tape drive for example. The base computer system <b>101</b> may also include a user interface adapter, which connects the one or more processors <b>106</b> via the bus to one or more interface devices, such as a keyboard <b>104</b>, a mouse <b>103</b>, a printer/scanner <b>110</b> and/or other interface devices, which may be any user interface device, such as a touch sensitive screen, digitized entry pad, etc. The bus also connects the one or more processors to a display device <b>102</b>, such as an LCD screen or monitor via a display adapter.

0039The base computer system <b>101</b> may communicate with other computers or networks of computers by way of a network adapter capable of communicating <b>108</b> with a network <b>109</b>. Example network adapters are communications channels, token ring, Ethernet or modems. Alternatively, the base computer system <b>101</b> may communicate using a wireless interface, such as a cellular digital packet data (CDPD) card. The base computer system <b>101</b> may be associated with such other computers in a local area network (LAN) or a wide area network (WAN), or the base computer system <b>101</b> may be a client in a client/server arrangement with another computer, etc.

0040<figref idref="DRAWINGS">FIG. 2</figref> illustrates a data processing network <b>200</b> in which the present invention may be practiced. The data processing network <b>200</b> may include a plurality of individual networks, such as a wireless network and a wired network, each of which may include a plurality of individual workstations <b>201</b>, <b>202</b>, <b>203</b>, <b>204</b> and or the base computer system <b>101</b> of <figref idref="DRAWINGS">FIG. 1C</figref>. Additionally, as those skilled in the art will appreciate, one or more LANs may be included, where a LAN may comprise a plurality of intelligent workstations coupled to a host processor.

0041Programming code <b>111</b> may be embodied in the memory <b>105</b>, and accessed by the processor <b>106</b> using the processor bus. Such programming code includes an operating system which controls the function and interaction of the various computer components and one or more application programs <b>112</b>. Program code is normally paged from long-term storage <b>107</b> to high-speed memory <b>105</b> where it is available for processing by the processor <b>106</b>. The techniques and methods for embodying software programming code in memory, on physical media, and/or distributing software code via networks are well known and will not be further discussed herein. Program code, when created and stored on a tangible medium (including but not limited to electronic memory modules (RAM), flash memory, Compact Discs (CDs), DVDs, Magnetic Tape and the like is often referred to as a “computer program product”. The computer program product medium is typically readable by a processing circuit preferably in a computer system for execution by the processing circuit.

0042The cache that is most readily available to the processor (normally faster and smaller than other caches of the processor) is the lowest (L1 or level one) cache and main store (main memory) is the highest level cache (L3 if there are 3 levels). The lowest level cache is often divided into an instruction cache (I-Cache) holding machine instructions to be executed and a data cache (D-Cache) holding data operands.

0043Still referring to <figref idref="DRAWINGS">FIG. 2</figref>, the networks may also include mainframe computers or servers, such as a gateway computer (client server) <b>206</b> or application server (remote server) <b>208</b> which may access a data repository and may also be accessed directly from a workstation <b>205</b>. A gateway computer <b>206</b> serves as a point of entry into each network <b>207</b>. A gateway is needed when connecting one networking protocol to another. The gateway computer <b>206</b> may be preferably coupled to another network (the Internet <b>207</b> for example) by means of a communications link. The gateway computer <b>206</b> may also be directly coupled to the one or more workstations <b>101</b>, <b>201</b>, <b>202</b>, <b>203</b>, and <b>204</b> using a communications link. The gateway computer may be implemented utilizing an IBM eServer™ zSeries® z9® Server available from International Business Machines Corporation.

0044In an embodiment, software programming code which embodies the present invention is accessed by the processor <b>106</b> of the base computer system <b>101</b> from long-term storage media, such as the long-term storage <b>107</b> of <figref idref="DRAWINGS">FIG. 1C</figref>. The software programming code may be embodied on any of a variety of known media for use with a data processing system, such as a diskette, hard drive, or CD-ROM. The code may be distributed on such media, or may be distributed to users <b>210</b> and <b>211</b> from the memory or storage of one computer system over a network to other computer systems for use by users of such other systems.

0045Referring to <figref idref="DRAWINGS">FIG. 3</figref>, an exemplary processor embodiment is depicted for processor <b>106</b>. One or more levels of cache <b>303</b> are employed to buffer memory blocks in order to improve the performance of the processor <b>106</b>. The cache <b>303</b> is a high speed buffer holding cache lines of memory data that are likely to be used. Typical cache lines are 64, 128 or 256 bytes of memory data. In an embodiment, separate caches are employed for caching instructions than for caching data. Cache coherence (synchronization of copies of lines in memory and the caches) is often provided by various “snoop” algorithms well known in the art. Main storage, such as memory <b>105</b> of a processor system is often referred to as a cache. In a processor system having 4 levels of cache <b>303</b> memory <b>105</b> is sometimes referred to as the level 5 (L5) cache since it is typically faster and only holds a portion of the non-volatile storage (DASD, Tape etc) that is available to a computer system. Memory <b>105</b> “caches” pages of data paged in and out of the memory <b>105</b> by the operating system.

0046A program counter (instruction counter) <b>311</b> keeps track of the address of the current instruction to be executed. A program counter in a z/Architecture processor is 64 bits and may be truncated to 31 or 24 bits to support prior addressing limits. A program counter is typically embodied in a program status word (PSW) of a computer such that it persists during context switching. Thus, a program in progress, having a program counter value, may be interrupted by, for example, the operating system (i.e., the current context switches from the program environment to the operating system environment). The PSW of the program maintains the program counter value while the program is not active, and the program counter (in the PSW) of the operating system is used while the operating system is executing. In an embodiment, the program counter is incremented by an amount equal to the number of bytes of the current instruction. Reduced Instruction Set Computing (RISC) instructions are typically fixed length while Complex Instruction Set Computing (CISC) instructions are typically variable length. Instructions of the IBM z/Architecture are CISC instructions having a length of 2, 4 or 6 bytes. The program counter <b>311</b> is modified by either a context switch operation or a branch taken operation of a branch instruction for example. In a context switch operation, the current program counter value is saved in the PSW along with other state information about the program being executed (such as condition codes), and a new program counter value is loaded pointing to an instruction of a new program module to be executed. A branch taken operation is performed in order to permit the program to make decisions or loop within the program by loading the result of the branch instruction into the program counter <b>311</b>.

0047In an embodiment, an instruction fetch unit <b>305</b> is employed to fetch instructions on behalf of the processor <b>106</b>. The instruction fetch unit <b>305</b> either fetches the “next sequential instructions,” the target instructions of branch taken instructions, or the first instructions of a program following a context switch. In an embodiment, the instruction fetch unit <b>305</b> employs prefetch techniques to speculatively prefetch instructions based on the likelihood that the prefetched instructions might be used. For example, the instruction fetch unit <b>305</b> may fetch 16 bytes of instructions that include the next sequential instruction and additional bytes of further sequential instructions.

0048The fetched instructions are then executed by the processor <b>106</b>. In an embodiment, the fetched instruction(s) are passed to a decode/dispatch unit <b>306</b> of the instruction fetch unit <b>305</b>. The decode/dispatch unit <b>306</b> decodes the instruction(s) and forwards information about the decoded instruction(s) to appropriate execution units <b>307</b>, <b>308</b>, and/or <b>310</b>. An execution unit <b>307</b> receives information about decoded arithmetic instructions from the instruction fetch unit <b>305</b> and will perform arithmetic operations on operands according to the operation code (opcode) of the instruction. Operands are provided to the execution unit <b>307</b> either from the memory <b>105</b>, architected registers <b>309</b>, or from an immediate field of the instruction being executed. Results of the execution, when stored, are stored either in memory <b>105</b>, architected registers <b>309</b> or in other machine hardware (such as control registers, PSW registers and the like).

0049A processor <b>106</b> typically has one or more execution units <b>307</b>, <b>308</b>, and <b>310</b> for executing the function of the instruction. Referring to <figref idref="DRAWINGS">FIG. 4A</figref>, an execution unit <b>307</b> may communicate with the architected registers <b>309</b>, the decode/dispatch unit <b>306</b>, the load/store unit <b>310</b> and other processor units <b>401</b> by way of interfacing logic <b>407</b>. The execution unit <b>307</b> may employ several register circuits <b>403</b>, <b>404</b>, and <b>405</b> to hold information that the arithmetic logic unit (ALU) <b>402</b> will operate on. The ALU <b>402</b> performs arithmetic operations such as add, subtract, multiply and divide as well as logical function such as and, or and exclusive-or (xor), rotate and shift. In an embodiment, the ALU supports specialized operations that are design dependent. Other circuits may provide other architected facilities <b>408</b> including condition codes and recovery support logic for example. Typically the result of an ALU operation is held in an output register circuit <b>406</b> which can forward the result to a variety of other processing functions. In other embodiments, there are many arrangements of processor units, the present description is only intended to provide a representative understanding of one embodiment.

0050An ADD instruction for example would be executed in an execution unit <b>307</b> having arithmetic and logical functionality while a floating point instruction for example would be executed in a floating point execution unit (not shown) having specialized floating point capability. Preferably, an execution unit operates on operands identified by an instruction by performing an opcode defined function on the operands. For example, an ADD instruction may be executed by an execution unit <b>307</b> on operands found in two architected registers <b>309</b> identified by register fields of the instruction.

0051The execution unit <b>307</b> performs the arithmetic addition on two operands and stores the result in a third operand where the third operand may be a third register or one of the two source registers. The execution unit <b>307</b> preferably utilizes an arithmetic logic unit (ALU) <b>402</b> that is capable of performing a variety of logical functions such as shift, rotate, and, or and XOR as well as a variety of algebraic functions including any of add, subtract, multiply, divide. Some ALUs <b>402</b> are designed for scalar operations and some for floating point. In embodiments, data may be big endian (where the least significant byte is at the highest byte address) or little endian (where the least significant byte is at the lowest byte address) depending on architecture. The IBM z/Architecture is big endian. Signed fields may be sign and magnitude, 1's complement or 2's complement depending on architecture. A 2's complement number is advantageous in that the ALU does not need to design a subtract capability since either a negative value or a positive value in 2's complement requires only and addition within the ALU. Numbers are commonly described in shorthand, where a 12 bit field defines an address of a 4,096 byte block and is commonly described as a 4 Kbyte (Kilo-byte) block for example.

0052Referring to <figref idref="DRAWINGS">FIG. 4B</figref>, Branch instruction information for executing a branch instruction is typically sent to a branch unit <b>308</b> which employs a branch prediction algorithm such as a branch history table <b>432</b> to predict the outcome of the branch before other conditional operations are complete. The target of the current branch instruction will be fetched and speculatively executed before the conditional operations are complete. When the conditional operations are completed the speculatively executed branch instructions are either completed or discarded based on the conditions of the conditional operation and the speculated outcome. A typical branch instruction may test condition codes and branch to a target address if the condition codes meet the branch requirement of the branch instruction, a target address may be calculated based on several numbers including ones found in register fields or an immediate field of the instruction for example. In an embodiment, the branch unit <b>308</b> may employ an ALU <b>426</b> having a plurality of input register circuits <b>427</b>, <b>428</b>, and <b>429</b> and an output register circuit <b>430</b>. The branch unit <b>308</b> may communicate with general registers, decode/dispatch unit <b>306</b> or other circuits <b>425</b> for example.

0053The execution of a group of instructions may be interrupted for a variety of reasons including a context switch initiated by an operating system, a program exception or error causing a context switch, an I/O interruption signal causing a context switch or multi-threading activity of a plurality of programs (in a multi-threaded environment) for example. In an embodiment, a context switch action saves state information about a currently executing program and then loads state information about another program being invoked. State information may be saved in hardware registers or in memory for example. State information includes a program counter value pointing to a next instruction to be executed, condition codes, memory translation information and architected register content. A context switch activity may be exercised by hardware circuits, application programs, operating system programs or firmware code (microcode, pico-code or licensed internal code (LIC) alone or in combination.

0054A processor accesses operands according to instruction defined methods. The instruction may provide an immediate operand using the value of a portion of the instruction, may provide one or more register fields explicitly pointing to either general purpose registers or special purpose registers (floating point registers for example). The instruction may utilize implied registers identified by an opcode field as operands. The instruction may utilize memory locations for operands. A memory location of an operand may be provided by a register, an immediate field, or a combination of registers and immediate field as exemplified by the z/Architecture long displacement facility wherein the instruction defines a base register, an index register and an immediate field (displacement field) that are added together to provide the address of the operand in memory. Location herein implies a location in main memory (main storage) unless otherwise indicated.

0055Referring to <figref idref="DRAWINGS">FIG. 4C</figref>, a processor accesses storage using a load/store unit <b>310</b>. The load/store unit <b>310</b> may perform a load operation by obtaining the address of the target operand in memory through the cache/memory interface and loading the operand in an architected register <b>309</b> or another memory location, or may perform a store operation by obtaining the address of the target operand in memory and storing data obtained from an architected register <b>309</b> or another memory location in the target operand location in memory. The load/store unit <b>310</b> may be speculative and may access memory in a sequence that is out-of-order relative to the instruction sequence; however the load/store unit <b>310</b> maintains the appearance to programs that instructions were executed in order. A load/store unit <b>310</b> may communicate with architected registers <b>309</b>, decode/dispatch unit <b>306</b>, cache/memory interface or other elements <b>455</b> and comprises various register circuits, ALUs <b>458</b> and control logic <b>463</b> to calculate storage addresses and to provide pipeline sequencing to keep operations in-order. Some operations may be out of order but the load/store unit provides functionality to make the out of order operations appear to the program as having been performed in order as is well known in the art.

0056Preferably addresses that an application program “sees” are often referred to as virtual addresses. Virtual addresses are sometimes referred to as “logical addresses” and “effective addresses.” These virtual addresses are virtual in that they are redirected to physical memory location by one of a variety of DAT technologies such as the DAT <b>312</b> of <figref idref="DRAWINGS">FIG. 3</figref>, including, but not limited to prefixing a virtual address with an offset value, translating the virtual address via one or more translation tables, the translation tables including at least a segment table and a page table alone or in combination, preferably, the segment table having an entry pointing to the page table. In z/Architecture, a hierarchy of translations is provided including a region first table, a region second table, a region third table, a segment table and an optional page table. The performance of the address translation is often improved by utilizing a translation look-aside buffer (TLB) which comprises entries mapping a virtual address to an associated physical memory location. The entries are created when DAT <b>312</b> translates a virtual address using the translation tables. Subsequent use of the virtual address can then utilize the entry of the fast TLB rather than the slow sequential translation table accesses. The TLB content may be managed by a variety of replacement algorithms including least recently used (LRU).

0057In the case where the processor <b>106</b> is a processor of a multi-processor system, each processor has responsibility to keep shared resources such as I/O, caches, TLBs and Memory interlocked for coherency. In an embodiment, “snoop” technologies will be utilized in maintaining cache coherency. In a snoop environment, each cache line may be marked as being in any one of a shared state, an exclusive state, a changed state, an invalid state and the like in order to facilitate sharing.

0058The I/O units <b>304</b> of <figref idref="DRAWINGS">FIG. 3</figref> provide the processor <b>106</b> with means for attaching to peripheral devices including tape, disc, printers, displays, and networks for example. The I/O units <b>304</b> are often presented to the computer program by software drivers. In mainframes such as the z/Series from IBM, channel adapters and open system adapters are I/O units of the mainframe that provide the communications between the operating system and peripheral devices.

0059Instrumentation data is data related to the operations of the processor <b>106</b>. In an embodiment, access to instrumentation data and other system level metrics may be restricted, or unavailable. A computer processor operates under a privileged state (or supervisor state), and a lesser-privileged state (or problem state). In the privileged state, a program may have access to all system resources via privileged operations (e.g., access to all control registers and the supervisor memory space). The privileged state is also referred to as privileged mode or supervisor mode. An operating system executing on the computer processor may be operating in the privileged state. The lesser-privileged state is a non-privileged state where access to system resources is limited. For example, application programs running in lesser-privileged state may have limited or no access to control registers and may access only user memory space assigned to the application program by the operating system. The lesser-privileged state is typically assigned to application programs executed under control of an operating system, and no privileged operations can be performed in the lesser-privileged state. The lesser-privileged state is also known as a problem state, problem mode or user mode.

0060One such restricted resource that is not write accessible to a program executing in the lesser-privileged state is the program status word (PSW). The PSW may comprise a program counter of the next instruction to be executed, a condition code field usable by branch instructions, an instrumentation control field for indicating whether instrumentation is enabled or disabled, and other information used to control instruction sequencing and to determine the state of the computer processor including the privilege state assigned to the program. In a multithreaded processing environment, multiple programs share, or time slice, the available computer processor capacity. Each of the programs has context information including an associated PSW, an origin address of an address translation table for accessing main storage assigned to the program, a set of general purpose register current values, control registers, floating point registers, etc. The currently active, or controlling PSW, is called the current PSW. It governs the program currently being executed. The computer processor has an interruption capability, which permits the computer processor to context switch rapidly to another program in response to exception conditions and external stimuli. When an interruption occurs, the computer processor places the current PSW in an assigned storage location, called the old-PSW location, for the particular class of interruption. The computer processor fetches a new PSW from a second assigned storage location. This new context determines the next program to be executed. In an embodiment, these storage locations are located in a memory location accessible to the computer processor. When the computer processor has finished processing the interruption, the program handling the interruption may reload the old context including the old PSW, making it again the current PSW, so that the interrupted program can continue.

0061The fields of the PSW may be referenced either explicitly (e.g., when instruction execution reads part of the PSW bits), or implicitly (e.g., in instructions fetching, operand fetching, address generation calculations, address generation sources, etc.). The explicit reference is generally performed at execution time, whereas the implicit reference is generally performed at different stages of the pipeline during instruction execution (i.e., instruction fetch, instruction decode, execution time and completion time). Individual fields in the PSW may be referenced or updated independently of each other.

0062In an embodiment, by manipulating the context, an operating system controls computer processing resources, including enabling run-time-instrumentation by the computer processor. The run-time-instrumentation may be enabled or disabled during the execution of the operating system, as well as by any software applications executed by the operating system. The enabled/disabled state of run-time-instrumentation is saved as context information in the PSW associated with a program.

0063A run-time-instrumentation (RI) facility may be incorporated on models implementing z/Architecture. When the RI facility is installed and enabled, data is collected during program execution into one or more collection buffers within the CPU and then reported to a program buffer. Each unit of information stored is called a reporting group. The contents of a reporting group consist of multiple records whose contents represent events recognized by the CPU during program execution.

0064When the run-time-instrumentation facility is installed in a configuration, a PSW field (RI bit) enables run-time-instrumentation. Validity of the run-time-instrumentation controls determines the capability of turning on the RI bit, but when RI is one, the CPU controls are valid and run-time-instrumentation is enabled. The run-time-instrumentation facility may include the following instructions: load run-time-instrumentation controls, modify run-time-instrumentation controls, run-time-instrumentation emit, run-time-instrumentation next, run-time-instrumentation off, run-time-instrumentation on, store run-time-instrumentation controls, and test run-time-instrumentation controls.

0065The load run-time-instrumentation controls (LRIC) instruction initializes the run-time-instrumentation controls that govern run-time-instrumentation. The modify run-time-instrumentation controls (MRIC) instruction modifies all or a subset of the run-time-instrumentation controls originally established by LRIC. The run-time-instrumentation emit (RIEMIT) instruction collects the value of a general register by storing it into a collection buffer. The run-time-instrumentation next (RINEXT) instruction performs directed sampling of the next, sequential instruction (NSI) after RINEXT. The run-time-instrumentation off (RIOFF) instruction disables run-time-instrumentation. The run-time-instrumentation on (RION) instruction enables run-time-instrumentation. The store run-time-instrumentation controls (STRIC) instruction places the current values of the run-time-instrumentation controls into a specified storage location. The test run-time-instrumentation controls (TRIC) instruction examines the run-time-instrumentation controls. If valid, the state of a controls-altered indicator is set.

0066The run-time-instrumentation facility includes the ability for making a measurement-alert external interruption pending. Some of the information collected by run-time-instrumentation and reported to a program buffer is model-dependent and thus not defined. Samples and data provided by the run-time-instrumentation facility are intended for statistical estimation of performance characteristics, are substantially accurate, and may not be repeatable. For example, regardless of sampling mode, it is unpredictable if a sample instruction that caused an exception or is associated with certain system internal activities would result in the store of a reporting group and, if stored, whether the model-dependent data included in run-time-instrumentation data is affected.

0067A collection buffer is used to capture a set of records whose contents report on events recognized by the processor during program execution. Examples are: execution of one or more taken branches, transactional-execution abort events, instruction-fetch cache misses, data fetch or store cache misses, and an operand of the RIEMIT instruction. Execution of the RIEMIT instruction collects the value of a general register by storing it into the collection buffer. Additional data can be collected and/or stored in other buffers, such as an instruction-data buffer.

0068Reporting is subject to reporting controls. When a sample instruction is identified, each reporting control enables the checking of a corresponding condition. If a corresponding condition exists, a reporting group is formed and stored. A reporting group is not stored when no reporting control is enabled or the corresponding condition does not exist for an enabled reporting control. Data reported about a sample instruction may be acquired from the instruction-data buffer and other model-dependent sources, and then used to create the contents of one or more records of the reporting group, one such record being an instruction record.

0069Record types that may be captured in the reporting group store include: filler, extra, begin, timestamp, instruction, emit, TX abort, call, return, and transfer. A filler record is used in a reporting group when the number of valid records in the collection buffer is not sufficient to fill a reporting group of the current reporting-group size. An extra record may be used in the extra section of a reporting group. A begin record is the first record of the first reporting group. A timestamp record is stored as record <b>0</b> of every reporting group other than the first reporting group. An instruction record is created when a reporting group is stored for a sample instruction as the last record of the reporting group. An emit record is created by successful execution of RIEMIT. A transaction-execution (TX) mode abort record is created by either an implicit abort or by execution of a transaction abort instruction. A call record is created by execution of a branch instruction which is categorized as a call-type branch instruction. A return record is created by execution of a return-type branch instruction which is categorized as a return instruction. A transfer record is created by execution of a branch instruction which meets certain condition code criteria.

0070<figref idref="DRAWINGS">FIG. 5</figref> depicts a schematic diagram of a system for run-time-instrumentation of a processor that may be implemented in an embodiment. In an embodiment, the system <b>500</b> includes a central processing unit (CPU) such as the processor <b>106</b> of <figref idref="DRAWINGS">FIG. 1</figref>. In an embodiment, the processor <b>106</b> is a single processor. In an alternate embodiment, the processor <b>106</b> is a single processing core of a multi-core processor. In an embodiment, the processor <b>106</b> is capable of operating at varying speeds.

0071In an embodiment, the processor <b>106</b> further includes a register <b>510</b>. The register <b>510</b> is a hardware register capable of storing words of data for use by the processor <b>106</b>. The register <b>510</b> includes one or more latches for storing bits of data that are accessible by the processor <b>106</b>. The register <b>510</b> may include general purpose registers and control registers for example. The processor <b>106</b> additionally includes an instrumentation module <b>506</b> that is in communication with the register <b>510</b>. The instrumentation module <b>506</b> is a processing circuit that controls the instrumentation of the processor <b>106</b>. The instrumentation module <b>506</b> is configured to collect instrumentation data, such as the execution path of one or more taken branches, transactional execution abort events, various runtime operands, timestamp information, etc. directly from the processor <b>106</b>. The instrumentation module <b>506</b> collects the instrumentation data from the processor <b>106</b>, and stores the instrumentation data in a collection buffer <b>508</b>. In an embodiment, the collection buffer <b>508</b> is a circular buffer that collects data received from the instrumentation module <b>506</b>, and when the circular buffer is filled it overwrites the oldest data with new data.

0072The processor <b>106</b> executes one or more operating systems <b>516</b> and one or more applications <b>518</b>. The one or more operating systems <b>516</b> and one or more applications <b>518</b> are stored in a storage <b>520</b>, such as a hard drive, CD/ROM, flash memory, etc. and are loaded into a main memory <b>514</b> in a runtime memory <b>504</b> area reserved for storing one or more active pieces of the currently executing operating system and/or application, called pages, which are loaded from the storage <b>520</b> into runtime memory <b>504</b> as needed. In an embodiment, each of the operating systems execute as a virtual machine managed by a hypervisor (not shown) and executed by the processor <b>106</b>.

0073In an embodiment the processor <b>106</b> loads a PSW <b>512</b> in the register <b>510</b> from PSW data <b>512</b> in the main memory <b>514</b> for the currently executing operating system or application from the main memory <b>514</b> and sets one or more processor settings in, for example, the register <b>510</b>. In an embodiment, the PSW in the register <b>510</b>, includes one or more bits for enabling and controlling the instrumentation module <b>506</b>.

0074The one or more applications <b>518</b> include software applications compiled to execute on a specific operating system, interpreted code executing on an interpreter (e.g., Java), or operating system support threads (e.g., process management, daemons, etc.). Each of the one or more operating systems <b>516</b> and or the one or more applications <b>518</b> may execute an instruction to trigger the instrumentation module <b>506</b> to start, or to stop, the collecting instrumentation data.

0075In an embodiment, one of the one or more applications <b>518</b> executes an instruction that has been determined to be a sample instruction, thereby creating a sample point at the completion of execution of the sample instruction and that then causes the instrumentation module <b>506</b> to move the application's collected data from the collection buffer <b>508</b>, to a program buffer <b>522</b> in main memory <b>514</b> that is accessible to the application. The main memory <b>514</b> may be any addressable memory known in the art. In an embodiment, the main memory <b>514</b> may include a fast-access buffer storage, sometimes called a cache. Each CPU may have an associated cache. In an additional embodiment, the main memory <b>514</b> is dynamic random access memory (DRAM). In a yet another embodiment, the main memory is a storage device, such as a computer hard drive, or flash memory accessible by an application.

0076To configure run-time instrumentation controls, the processor <b>106</b> supports a load run-time instrumentation controls (LRIC) instruction. Beyond the specific LRIC fields described further herein, it will be understood that additional fields can be defined to support other functionality. The LRIC instruction can be used to load and initially configure run-time instrumentation and is supported by instrumentation module <b>506</b> of <figref idref="DRAWINGS">FIG. 5</figref>. In an embodiment, the instrumentation module <b>506</b>, also referred to as run-time instrumentation module <b>506</b>, implements run-time-instrumentation controls and reporting controls. A current state of run-time instrumentation controls can be stored from register <b>510</b> of <figref idref="DRAWINGS">FIG. 5</figref> into main memory <b>514</b> using the store run-time controls (STRIC) instruction. The definition of various fields of a control block loadable as an operand of the LRIC instruction is also used herein to refer to the state of corresponding values of the run-time-instrumentation controls.

0077<figref idref="DRAWINGS">FIG. 6</figref> depicts a portion of a run-time-instrumentation controls control block (RICCB) including controls that are settable by a privileged state in an embodiment. The control block portion <b>600</b> may include additional values other than those described in reference to <figref idref="DRAWINGS">FIG. 6</figref>. Modification to the control block portion <b>600</b> may be performed by an LRIC instruction.

0078The control block portion includes a validity bit <b>602</b> (V bit). The validity bit <b>602</b> indicates the validity of the set of run-time-instrumentation controls in the processor, as they were previously set by an LRIC instruction.

0079The control block also includes an S bit <b>604</b>, which is used to determine if the lesser-privileged state program is allowed to execute an MRIC instruction. The K bit <b>606</b> indicates if the lesser-privileged state program is permitted to execute in a semi-privileged state with regard to the run-time-instrumentation controls, such as the origin address, and the limit address of the run-time-instrumentation controls. The H bit <b>608</b> determines whether the address controls (i.e., the origin address, limit address, and current address) refer to a primary virtual address space or a home virtual address space. The 0 bit <b>610</b> is ignored and treated as a 0.

0080A lesser-privileged state sample reporting control bit <b>612</b> (Ps bit) is used in conjunction with lesser-privileged state programs. When in the lesser-privileged state and the Ps bit <b>612</b> in the run-time-instrumentation controls is zero, the reporting controls of the run-time-instrumentation controls are ignored when run-time-instrumentation is enabled, and thus do not cause a reporting group to be stored. When in the lesser-privileged state and the Ps bit <b>612</b> in the run-time-instrumentation controls is one, the reporting controls are checked and used according to their defined function.

0081A supervisor-state sample reporting control bit <b>614</b> (Qs bit) is used in conjunction with supervisor-state programs. When in the supervisor state and the Qs bit <b>614</b> in the run-time-instrumentation controls is zero, the reporting controls of the run-time-instrumentation controls are ignored when run-time-instrumentation is enabled, and thus do not cause a reporting group to be stored. When in the supervisor state and the Qs bit <b>614</b> in the run-time-instrumentation controls is one, the reporting controls are checked and used according to their defined function.

0082The lesser-privileged state collection buffer control bit <b>616</b> (Pc bit) controls updates to the collection buffer <b>508</b> of <figref idref="DRAWINGS">FIG. 5</figref>. When in lesser-privileged state and the Pc bit <b>616</b> in the run-time-instrumentation controls is zero, collection buffer controls of the run-time-instrumentation controls are ignored when run-time-instrumentation is enabled and updates of the collection buffer <b>508</b> are prevented. When in the lesser-privileged state and the Pc bit <b>616</b> in the run-time-instrumentation controls is one, the collection buffer controls are checked and used according to their defined function.

0083The supervisor-state collection buffer control bit <b>618</b> (Qc bit) controls updates to the collection buffer <b>508</b>. When in supervisor state and the Qc bit <b>618</b> in the run-time-instrumentation controls is zero, collection buffer controls of the run-time-instrumentation controls are ignored when run-time-instrumentation is enabled and the updates to the collection buffer <b>508</b> are prevented. When in supervisor state and the Qc bit <b>618</b> in the run-time-instrumentation controls is one, the indicated collection-buffer controls are checked and used according to their defined function.

0084The G bit <b>620</b> is the pending control of a run-time-instrumentation-halted interruption, also called a halted interruption. When the G bit <b>620</b> is zero, a halted interruption is not pending. When the G bit <b>602</b> is one, a halted interruption is pending. When the first reporting group in a program buffer <b>522</b> is written, the G bit <b>620</b> is set to zero. That is, when run-time-instrumentation program-buffer origin address (ROA) <b>702</b> equals a run-time-instrumentation program buffer current address (RCA) <b>706</b> of <figref idref="DRAWINGS">FIG. 7</figref>, the G bit <b>620</b> is set to zero. When an attempt to store other than the first reporting group in program buffer <b>522</b> is made, the G bit <b>620</b> is set to zero if the run-time-instrumentation-halted condition does not exist, and the reporting group is stored. When an attempt to store other than the first reporting group in program buffer <b>522</b> is made, the G bit <b>620</b> is set to one if the run-time-instrumentation-halted condition does exist, and the reporting group is not stored.

0085The U bit <b>622</b> is the enablement control for a buffer-full interruption and a halted interruption. When U bit <b>622</b> is zero, generation of an interruption request is disabled and, if pending, remains pending.

0086The L bit <b>624</b> is the pending control of a buffer-full interruption. When L bit <b>624</b> is zero, a buffer-full interruption is not pending. When L bit <b>624</b> is one, a buffer-full interruption is pending.

0087The key field <b>626</b> is a 4-bit unsigned integer whose value is used as a storage-protect key for the store of a reporting group. A store of a reporting group is permitted only when the storage key matches the access key associated with the request for storage access, and a fetch is permitted when the storage key matches the access key or when a fetch-protection bit of the storage key is zero. The keys match when the four access control bits of the storage key are equal to the access key, or when the access key is zero.

0088<figref idref="DRAWINGS">FIG. 7</figref> depicts a portion of a RICCB control block when MRIC is permitted to execute in semi-privileged mode (i.e., K bit is one). The control block <b>700</b> can also be an operand of an LRIC instruction for initialization of run-time-instrumentation controls. The control block <b>700</b> may include additional values other than those described in reference to <figref idref="DRAWINGS">FIG. 7</figref>. In an embodiment, sections of the MRIC instruction operand that are not otherwise designated are inaccessible by a lesser-privileged state program. When the semi-privileged mode is permitted, a 3run-time-instrumentation program-buffer origin address (ROA) <b>702</b> and a run-time-instrumentation program-buffer limit address (RLA) <b>704</b> are set with the MRIC instruction by the lesser-privileged state program. The ROA <b>702</b> is the location of the first byte of the program buffer <b>522</b> of <figref idref="DRAWINGS">FIG. 5</figref>. The RLA <b>704</b> indicates the location of the last byte of the program buffer <b>522</b>.

0089In an embodiment, a run-time-instrumentation program buffer current address (RCA) <b>706</b> may be updated by the MRIC instruction. The RCA <b>706</b> is the location in the program buffer <b>522</b> of a next reporting group to be stored. The RCA <b>706</b> examines the reporting group size field <b>744</b> (RGS field) and affects the number of significant bit positions used to form the address of the program buffer <b>522</b>. The 64-bit RCA <b>706</b> is word 0, bit positions <b>0</b> through <b>26</b>-RGS of word 1, and RGS+5 binary zeros appended on the right. This is the starting location in the program buffer <b>522</b> of <figref idref="DRAWINGS">FIG. 5</figref> of a subsequent reporting group that will be stored in the program buffer <b>522</b>. The reporting group is a unit of information that is created by the instrumentation module <b>506</b>, and subsequently stored in the program buffer <b>522</b>. In an embodiment, when the RGS field <b>744</b> specified by the RCA <b>706</b> is not equal to the run-time-instrumentation control's current reporting group size (i.e., the RCA <b>706</b> would change the RGS field <b>744</b>) then the RCA <b>706</b> is set to the ROA <b>702</b>.

0090A remaining sample interval count field <b>742</b> (RSIC field) may be updated by the lesser-privileged program using the MRIC instruction. The RSIC field <b>742</b> includes a 64-bit unsigned integer that indicates a remaining sample interval count. When the value of the RSIC field <b>742</b> in the run-time-instrumentation controls is zero or equal to the value in a scaling factor field <b>740</b> (SF field), and run-time-instrumentation is enabled, then the next sample interval is a full interval based on the sampling mode <b>708</b> (M) and SF field <b>740</b> values. When RSIC field <b>742</b> is nonzero and less than the SF field <b>740</b> and run-time-instrumentation is enabled, the next sample interval is a partial interval. When the RSIC field <b>742</b> is nonzero and greater than the SF field <b>740</b> value and run-time-instrumentation is enabled, the next sample interval is an extended interval. When an extended interval expires, the next interval is based on the SF field <b>740</b> value. When the RSIC field <b>742</b> is set to a nonzero value, it is subject to the same model-dependent maximum limit to which the SF field <b>740</b> is also subject. When the original value of the RSIC field <b>742</b> is zero, the sampling mode will dictate whether the RSIC field <b>742</b> is set to the value in the SF field <b>740</b> during execution of LRIC and MRIC instructions, or whether it continues to show as zero until run-time-instrumentation is enabled.

0091The SF field <b>740</b> contains a 64-bit unsigned integer whose value is a scaling factor count of units. The dimension of the units is determined from the mode field <b>708</b> (M field). When the value in the RSIC field <b>742</b> is zero, the SF field <b>740</b> provides an initial value of the RSIC field <b>742</b> that is decremented to zero at which point the current instruction is recognized as a sample instruction, and the interval count is refreshed from the SF field <b>740</b> value. A valid value of the SF field <b>740</b> is in the range one to 2⁶⁴-1. If zero is specified, a value of one is assumed. However, each model may have both a minimum and a maximum value of the SF field <b>740</b>. The minimum and maximum values may also be different based on the mode field <b>708</b>. If a value less than the minimum is specified, the model-dependent minimum value is loaded. If a value greater than the maximum value is specified, the model-dependent maximum value is loaded.

0092The DC control field <b>736</b> is a 4-bit unsigned integer whose value designates a cache-latency level associated with a data fetch or store cache miss. That is, the sample instruction encountered a data access cache miss. Unless prohibited by another run-time-instrumentation control, an attempt is made to store a reporting group representing the sample instruction whose data access recognized a miss at a cache-latency level numerically greater than or equal to the level designated by the value of the DC control field <b>736</b>. The cache structure and cache-latency level for data access is model dependent. For an instruction with multiple or long operands, it is model dependent which, if any, operand access is used for reporting control. Model-dependent behavior may ignore the value of the DC control field <b>736</b> and thus not use it as a reason to store a reporting group.

0093The IC field <b>734</b> is a 4-bit unsigned integer whose value designates a cache-latency level associated with an instruction-fetch cache miss. That is, the fetch of the sample instruction encountered an instruction-fetch cache miss. For both the IC field <b>734</b> and DC control field <b>736</b>, a cache-latency level is an abstraction of how far a certain cache level access is from the observing processor. The latency level depends on the combination of the amount of nested cache levels between the processor and main storage, and how such cache levels are shared among multiple processors. A larger latency level generally corresponds to a more time-consuming access. Values in the IC field <b>734</b> and DC control field <b>736</b> may be thought of as zero-origin identification of a cache-latency level. For example, a value of zero corresponds to an L1 cache (i.e., the cache that is closest to the processor). A value of one is therefore the next layer of cache which may be known as an L2 cache, or even an L1.5 cache in some machines. Values of 2-15 designate the logical progression of additional cache-latency layers until main memory is reached, but not including main memory itself. Generally, cache structures do not go as deep as fifteen layers. Therefore, a value of 15 in the IC field <b>734</b> and DC control field <b>736</b> is interpreted as a special case, meaning that a cache miss on instruction fetch or data access, respectively and regardless of cache-latency level, is not recognized for the purpose of generating the store of a reporting group. Unless prohibited by another run-time-instrumentation control, an attempt is made to store a reporting group representing the sample instruction whose fetch recognized a miss at a cache-latency level numerically greater than or equal to the level designated by the value of the IC field <b>734</b>. The cache structure and cache-latency level for instruction fetching is model dependent. Model-dependent behavior may ignore the value of the IC field <b>734</b> and thus not use it as a reason to store a reporting group.

0094The cache-latency-level-override reporting control bit <b>732</b> (F bit) is for non-branch instructions and for branch-prediction controls. When the F bit <b>732</b> in the run-time-instrumentation controls is zero, the cache-reporting controls (IC field <b>734</b> and DC control field <b>736</b>) of the run-time-instrumentation controls are checked and used according to their defined function. The branch-prediction controls (BPxn <b>722</b>, BPxt <b>724</b>, BPti <b>726</b>, and BPni <b>728</b> bits) of the run-time-instrumentation controls are checked and used according to their defined function. When the F bit <b>732</b> is one, these same controls are ignored and a reporting group is stored unless prohibited by another control.

0095The data-cache-miss control bit <b>730</b> (D bit) indicates if a reporting group is to be stored. If the D bit <b>730</b> is one, an extra type record may or may not be placed in the extra section of the reporting group which contains model dependent data about the sample instruction.

0096The MRIC instruction includes branch-prediction (BP) reporting controls (BPxn <b>722</b>, BPxt <b>724</b>, BPti <b>726</b>, and BPni <b>728</b>). If a BP reporting control bit in the run-time-instrumentation controls is zero, the corresponding condition is not checked. If a BP reporting-control bit is one and the corresponding branch-prediction condition exists, and a reporting group is stored.

0097The BPxn bit <b>722</b>, when one, enables checking of branch-prediction information. Thus, if the sample branch is incorrectly predicted to be taken but is not taken, a reporting group is stored.

0098The BPxt bit <b>724</b>, when one, enables checking of the branch-prediction information. Thus, if the sample branch is incorrectly predicted to be not taken but is taken, a reporting group is stored.

0099The BPti bit <b>726</b>, when one, enables checking of the branch-prediction information. Thus, if the sample branch is correctly predicted to be taken, and is taken, but the branch target is incorrectly predicted, a reporting group is stored.

0100The BPni bit <b>728</b>, when one, enables checking of the branch-prediction information. Thus, if the sample branch is correctly predicted to not be taken, and is not taken, and the branch target is incorrectly predicted, a reporting group is stored.

0101The enablement control of transactional-execution-mode records bit <b>720</b> (X bit) controls the collection of transactional-execution-mode abort records. When the X bit <b>720</b> in the run-time-instrumentation controls is zero, transactional-execution-mode abort records are not collected. When the X bit <b>720</b> is one, transactional-execution mode abort records are collected and placed in the collection buffer <b>508</b> of <figref idref="DRAWINGS">FIG. 5</figref>. If a model does not have a transactional-execution facility installed, the X bit <b>720</b> is ignored.

0102The RIEMIT instruction control bit <b>718</b> (E bit) controls the execution of the RIEMIT instruction. When the E bit <b>718</b> in the run-time-instrumentation controls is zero or ignored and treated as zero when run-time-instrumentation is enabled, RIEMIT executes a no-operation. When E bit <b>718</b> is one, and not otherwise ignored, RIEMIT is enabled to execute its defined function.

0103The J bit <b>746</b> when zero, specifies that the branch on condition (BC) instruction is in the other-type branch category, regardless of mask value. If the J bit <b>746</b> is one, the BC instruction which specifies a mask of 15 is in the return-type branch category. When the BC instruction specifies a mask of 1-14, it is not affected by the J bit <b>746</b> and is always in the other type branch category. When in the return-type branch category, the R bit <b>716</b> controls inclusion into the collection buffer <b>508</b> of <figref idref="DRAWINGS">FIG. 5</figref>. When in the other type branch category, the B bit <b>748</b> controls inclusion into the collection buffer <b>508</b>. The other-type branch category may also be indicated as the transfer-type branch category.

0104The instruction address code bit <b>714</b> (C bit) controls the enablement of call type branches. If the C bit <b>714</b> in the run-time-instrumentation controls is one and the instruction is a call-type branch, the collection buffer <b>508</b> is updated. If model-dependent detection of both call-type and return-type branches is combined, the C bit <b>714</b> operates on both types and the R bit <b>716</b> is not effective.

0105The R bit <b>716</b> is the enablement control of return-type branches. If the R bit <b>716</b> in the run-time-instrumentation controls is one and the instruction is a return-type branch, then the collection buffer <b>508</b> is updated.

0106The B bit <b>748</b> is the enablement control of branches other than call-type and return-type branches. If the B bit <b>748</b> in the run-time-instrumentation controls is one and the instruction is an other-type branch recognized by run-time-instrumentation, then the collection buffer <b>508</b> is updated.

0107The maximum-address exceeded bit <b>712</b> (MAE bit), if set to 1, indicates that, one or more reporting groups have been stored that have the C bit <b>714</b> set to one. Once the MAE bit <b>712</b> is set to one, continuing execution of run-time-instrumentation does not set it back to zero. Execution of the LRIC instruction or the MRIC instruction which specifies the MAE bit <b>712</b> as zero will set the MAE bit <b>712</b> to zero.

0108The run-time-instrumentation next (RINEXT) control bit <b>710</b> (N bit) controls the enablement of the run-time-instrumentation next instruction, which controls the execution of a sample instruction. When the N bit <b>710</b> in the run-time-instrumentation controls is zero or ignored and treated as zero, RINEXT executes a no-operation. When the N bit <b>710</b> is one, and not otherwise ignored, RINEXT is enabled to execute its defined function.

0109The mode field <b>708</b> (M field) is a 4-bit unsigned integer whose value in the run-time-instrumentation controls specifies the sampling mode for the run-time-instrumentation controls. Supported sampling modes, may include sampling based on counting CPU cycles, counting instructions, or be directed to sample in response to a sample instruction, such as RINEXT.

0110The reporting group size field <b>744</b> (RGS) is a 3-bit unsigned integer whose value specifies the number of records of a reporting group (R_RG). The number of records in a reporting group may vary from two records, including a begin/timestamp record and an instruction last record, up to two hundred fifty-six records. In an embodiment, the upper limit may be model dependent. The number of 16-byte records placed into a reporting group is 2^(RGS+1).

0111The primary-CPU capability suppression control bit <b>738</b> (Y bit) and the secondary-CPU capability suppression control bit <b>739</b> (Z bit) are collectively referred to as the suppression control. Suppression of the storing of a reporting group means that an attempt to store is not performed. The suppression control is not effective and no suppression occurs when the CPU capability of all CPUs in the configuration is the same. In a configuration, if the CPU capability of a CPU differs from the capability of another CPU, the suppression control is in effect, and at least one CPU is said to be operating at the CPU capability or primary-CPU capability while at least one other CPU is said to be operating at the secondary-CPU capability. The primary and secondary CPU capabilities are different operating speeds. When Y bit <b>738</b> and Z bit <b>739</b> are both zero, suppression does not occur. When Y bit <b>738</b> is zero and Z bit <b>739</b> is one, suppression occurs if the CPU, e.g., processor <b>106</b>, is operating at the secondary-CPU capability. When Y bit <b>738</b> is one and Z bit <b>739</b> is zero, suppression occurs if the CPU, e.g., processor <b>106</b>, is operating at the primary-CPU capability. When Y bit <b>738</b> and Z bit <b>739</b> are both one, suppression occurs.

0112The above fields and bits of <figref idref="DRAWINGS">FIG. 7</figref> are an example of the placement and naming of the fields and are provided herein for purposes of clarity. It will be understood that in other embodiments the only a subset of the fields may be used, fields may be in any order or position, and/or may be signified by different names.

0113When run-time instrumentation is installed and enabled, a number of events and data can be captured in collection buffer <b>508</b>. The collection buffer <b>508</b> is used to capture a set of records whose contents report on events recognized by the processor <b>106</b> during program execution. Examples are: execution of one or more taken branches, transactional-execution abort events, cache-misses, and an operand of a run-time instrumentation emit instruction. The IC and DC controls fields <b>734</b> and <b>736</b> set a level at which the program would be interested in taking some corrective action to improve instruction or data pre-fetch behavior. Execution of the RIEMIT instruction collects the value of a general register by storing it into the collection buffer <b>508</b>. Additional data can be collected and/or stored in other buffers, such as an instruction-data buffer (IDB) (not depicted) used to collect model-dependent sample-instruction data to construct a run-time-instrumentation instruction record.

0114Collected run-time-instrumentation information is reported on a sampling basis. Instructions from the instruction stream are sampled. The instruction that is sampled is called the sample instruction. A number of modes for determining a sample instruction are defined as follows when run-time instrumentation is enabled. In cycle-count mode, a count is the number of CPU cycles specified in either SF <b>740</b> or RSIC <b>742</b>, whichever is used to provide the count for the current interval. The count is adjusted responsive to an event associated with the sampling mode. For example, the count may be decremented when the processor <b>106</b> is in the operating state. When the count is decremented to threshold value, such as zero, the current instruction is recognized as a sample instruction, and the count is reinitialized to the SF <b>740</b> value and begins to be decremented with the next cycle. When execution of the sample instruction completes, reporting is performed, if appropriate.

0115In instruction-count mode, a count is specified in either SF <b>740</b> or RSIC <b>742</b>, whichever is used to provide the count for the current interval. For an instruction which consists of a single unit of operation, the count is decremented at the completion of the instruction as an event used to adjust the count. The instruction is a sample instruction when the count is decremented to a threshold value, such as zero. For an instruction which consists of multiple units-of-operation, the count may be decremented in one of the following ways: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0116">a. For an interruptible instruction, all units of operation through partial completion represent one counted unit for which the count is decremented.</li><li id="ul0001-0002" num="0117">b. For an interruptible instruction, all units of operation since the most-recent partial completion through final completion represent one counted unit for which the count is decremented.</li><li id="ul0001-0003" num="0118">c. For an instruction that completes after performing a CPU-determined subportion of the processing specified by the parameters of the instruction, the completion represents one counted unit for which the count is decremented.</li><li id="ul0001-0004" num="0119">d. For an instruction that completes after performing multiple units of operation but not in categories a-c above, completion of the last unit of operation represents one counted unit for which the count is decremented.</li></ul>

0120An instruction is a sample instruction when the count is decremented to zero for any counted unit of the instruction. When a threshold value is reached, such as zero, the count is reinitialized to the SF <b>740</b> value and begins to count down as described in a-d above. In all cases of the count modes, reporting, if appropriate, occurs after completion of the last unit of operation of the sample instruction.

0121In directed-sampling mode, directed sampling occurs when the N-bit <b>710</b> is one and the RINEXT instruction is executed successfully. The sample instruction is the next, sequential instruction (NSI) after the RINEXT instruction. If the next, sequential instruction is an execute-type instruction, the sample instruction is the target instruction of the execute-type instruction. Directed sampling may occur when in the cycle-count or instruction-count mode. Count sampling continues in conjunction with directed sampling and any of its resulting actions, and is not otherwise affected, except that if the sample instruction determined from count sampling is the same instruction determined by directed sampling, two reporting groups are not stored.

0122Whatever the sampling mode is, when a sample instruction is identified by execution of the RINEXT instruction, a reporting group is stored. However, the run-time-instrumentation controls Y <b>738</b>, Z <b>739</b>, Qs <b>614</b>, and Ps <b>612</b> continue to be effective.

0123Cycle-count and instruction-count sampling each determine an approximate interval which is subject to an amount of variability based on internal system events and exception conditions. The countdown begins when run-time instrumentation transitions from disabled to enabled. Directed sampling is subject to a lesser amount of variability, depending on any event that can be interposed between completion of RINEXT and the NSI. Of note, an interruption can cause what was thought to be the NSI to no longer be the NSI.

0124Sampling, regardless of the mode, identifies a sample instruction. Once a sample instruction is identified, collection stops upon completion of execution of the sample instruction and reporting begins. The various reporting controls that govern reporting then apply. Collection resumes when store of the reporting group is made pending.

0125When not in the transactional-execution mode, store of a reporting group becomes pending upon completion of execution of a sample instruction. When in the transactional-execution mode, upon completion of execution of a sample instruction, store of a reporting group is deferred until the transaction ends and then becomes pending. When the store of a reporting group is deferred or pending, it may be purged if any of the following interruptions is recognized: 1) program interruption; 2) exigent machine-check interruption; 3) restart interruption; and 4) supervisor-call interruption.

0126Any pending I/O, external, and repressible machine-check interruption remains pending until either the reporting group has been stored or the run-time-instrumentation controls determine that a reporting group is not to be stored.

0127Each mode may or may not allow a different set of reporting controls. When the sampling mode is either instruction count or cycle count, but directed sampling is also used, it is possible for the same sample instruction to be identified by multiple sampling methods. When this occurs, and the reporting controls to be used differ according to the sampling mode, the reporting controls associated with directed sampling apply.

0128Precise determination of an interval meant to sample a particular instruction is generally not feasible, due to asynchronous and unsolicited system events that may occur. Instead, the RINEXT instruction can be used to more-closely designate a sample instruction.

0129When in cycle-count mode or instruction-count mode, the RINEXT instruction can be issued in too close a proximity to the sample instruction identified from instruction-count or cycle-count sampling. The contents of the associated reporting group are as if the sample instruction were identified as the NSI of the RINEXT instruction and not as if a cycle-count or instruction-count identification of the sample instruction applied.

0130Execution of RINEXT may execute as a no-operation if any one or more of the following exception conditions is met: <ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0131">1. Run-time-instrumentation controls are not valid.</li><li id="ul0002-0002" num="0132">2. In the problem state, Ps <b>612</b> of the current run-time-instrumentation controls is zero, indicating that problem-state reporting is not permitted.</li><li id="ul0002-0003" num="0133">3. In the supervisor state, Qs <b>614</b> of the current run-time-instrumentation controls is zero, indicating that supervisor-state reporting is not permitted.</li><li id="ul0002-0004" num="0134">4. The N-bit <b>710</b> of the current run-time-instrumentation controls is zero, indicating that the RINEXT instruction itself is not permitted.</li><li id="ul0002-0005" num="0135">5. Storage is suppressed.</li><li id="ul0002-0006" num="0136">6. A field in the current PSW indicates that run-time instrumentation is disabled.</li><li id="ul0002-0007" num="0137">7. A model-dependent threshold would be exceeded. The number of times RINEXT has been issued in a period of time has exceeded a model-dependent limit.</li><li id="ul0002-0008" num="0138">8. A program-buffer-full condition exists.</li><li id="ul0002-0009" num="0139">9. A run-time-instrumentation-halted condition exists.</li><li id="ul0002-0010" num="0140">10. The next, sequential instruction is a start interpretive execution instruction.</li><li id="ul0002-0011" num="0141">11. The next, sequential instruction is a supervisor call instruction.</li></ul>

0142Turning to <figref idref="DRAWINGS">FIG. 8</figref>, an embodiment of collection buffer <b>508</b> is generally shown. As described previously, when run-time instrumentation is enabled during program execution, run-time-instrumentation data is collected within the processor <b>106</b>. In an embodiment, the place where data is collected within the processor <b>106</b> is the collection buffer <b>508</b>, and optionally an instruction-data buffer. In an embodiment, the collection buffer <b>508</b> is an internal buffer of the processor <b>106</b> that is used to save the most recent records collected. When a sample trigger point is detected, the records are copied from the collection buffer <b>508</b> into the program buffer <b>522</b> as part of a reporting group that is written to the program buffer <b>522</b>. In an embodiment, the records are copied from the collection buffer in a non-destructive manner.

0143The collection buffer <b>508</b> may be referred to as a “hardware collection buffer” because the collection buffer <b>508</b> is located in the processor and in an embodiment implemented as an array of register pairs representing instruction address <b>802</b> and event metadata <b>804</b> of a given event. In an embodiment, the instruction-data buffer is also implemented by an array of register pairs. An example of an event is a taken branch for which the register pair may hold the instruction address of the branch, and the metadata may hold the target of the branch as well as information regarding the historic behavior of the branch. In an embodiment, the registers pairs are ordered and updated sequentially as events occur in the instruction stream. A counter is maintained to indicate the index of the most recently updated entry in the array. In an embodiment the collection buffer <b>508</b> is a circular buffer, and when the collection buffer <b>508</b> is full, the next event overwrites the first entry in the array, and sequential updating of the array's register pairs re-starts on subsequent events. As such, assuming an array CB[0] to CB[N−1] and a counter i indicating the latest updated index, the trace of events captured would be represented by the sequence CB[i], CB[i−1] . . . CB[1], CB[0], CB[N−1], CB[N−2] . . . CB[i+1]. In another embodiment, two pointers are used: a head pointer pointing to the oldest entry in the buffer, and a tail/current pointer pointing to the newest entry in the buffer.

0144Events that represent a state of the processor <b>106</b> at any given execution point are captured sequentially in the collection buffer <b>508</b>. The collection buffer <b>508</b> is used to capture a set of records whose contents report on events recognized by the processor <b>106</b> during program execution (e.g., execution of one or more taken branches, transactional-execution abort events, the operand of a RIEMIT instruction, etc.). In an embodiment the events recognized depend on the contents of the RICCB shown in <figref idref="DRAWINGS">FIG. 7</figref>. Entries in the embodiment of the collection buffer <b>508</b> shown in <figref idref="DRAWINGS">FIG. 8</figref> include an event instruction address <b>802</b> and other relevant event metadata <b>804</b>. Examples of event metadata <b>804</b> include, but are not limited to: the instruction address of a taken branch and its target including some information about the historic behavior of the branch; the instruction address of a RIEMIT instruction and a respective register value; and the address of a transaction abort instruction and a respective transaction recovery entry point.

0145The embodiment of the collection buffer <b>508</b> shown in <figref idref="DRAWINGS">FIG. 8</figref> is capable of storing up to thirty-two entries (i.e., information about thirty-two events), with each instruction address <b>802</b> specified by sixty-four bits (e.g., bits 0:63), and event metadata <b>804</b> by sixty-four bits (e.g., bits 64:127). The size of the collection buffer (R_CB) is a model dependent count, representing a number of records. In the embodiment of the collection buffer <b>508</b> shown in <figref idref="DRAWINGS">FIG. 8</figref>, the byte size of the collection buffer is a multiple of the sixteen byte record size. In an embodiment, the size of the collection buffer is a number of records greater than or equal to the difference between the count of the largest reporting group (R_RG) of the model and the count of the records in a reporting group that are not acquired from the collection buffer (R_NC). Thus, in an embodiment, the size of the collection buffer is expressed as: R_CB≧(R_RG-R_NC).

0146In an embodiment, contents of the collection buffer <b>508</b> and the instruction data buffer (if one is used) are purged or otherwise affected by the following events: (1) an interruption; (2) the PSW bit that turns on and off the run-time instrumentation facility (e.g., bit <b>24</b>) changes from a one to a zero; and (3) when a sample instruction is identified when the run-time instrumentation facility is in a transactional-execution mode (in this case, further update of the collection data buffer <b>508</b> and instruction-data buffer stops and resumes when the transaction ends, at which time, a store of the reporting group is pending and the collection buffer <b>508</b> and instruction-data buffers are purged.

0147In an embodiment, such as the emulated host computer system shown in <figref idref="DRAWINGS">FIG. 1B</figref>, the host computer provides shared access to the run-time instrumentation facility and a save/restore run-time instrumentation state for each distinct user. The saved run-time instrumentation state is stored using registers and/or memory belonging to the host.

0148In embodiments, additional capabilities can affect data collection and may be viewed as providing additional data-collection points while not substantially disturbing the regular instruction-count or cycle-count sampling described previously. These include execution of a RIEMIT instruction, which collects the value of a general register by storing it into the collection buffer <b>508</b>. In addition, the data-collection control bits in the run-time instrumentation controls described previously can be used to customize the types of data collected (e.g., the E, C, R, and B control bits). In this manner, the type of data collected is programmable.

0149In an embodiment, an instruction-data buffer is implemented to collect model dependent sample instruction data that is used to construct a run-time-instrumentation instruction record. The instruction-data buffer collects data from an instruction in anticipation of being available when the instruction is identified as a sample instruction. In an embodiment, the instruction-data buffer is a hardware buffer/storage location in the processor where information about an instruction that would become the trigger as a sample point is saved, so that during the log out process, it can be written out together with data from the collection buffer <b>508</b>. Similar to the collection buffer <b>508</b> it includes the instruction address, and meta-data associated with that instruction. The metadata in the instruction-data buffer is often machine dependent and may include, but is not limited to: cache miss related information, and branch prediction related information.

0150In accordance with embodiments, other data collected may not be from the collection buffer <b>508</b> and not from the instruction-data buffer. Examples include data used to form parts of the following: (1) the first record of a reporting group: timestamp or begin record; and (2) additional types of records may be created for every reporting group and thus not stored in the collection buffer <b>508</b>, such records, when present, may be placed in the extra or machine-dependent section of a reporting group. These system generated records are referred to herein as “system information records.”

0151<figref idref="DRAWINGS">FIG. 9</figref> depicts a high-level example of a reporting group <b>900</b> stored to program buffer <b>522</b> at a sample point. The number of valid records from the collection buffer <b>508</b>, represented by R_VCB, is in the range 0≦R_VCB≦R_CB(where R_CBis the size of the collection buffer <b>508</b>). The size of a reporting group <b>900</b> in records, represented by R_RG, is equal to 2^(RGS+1), where RGS is the reporting group size as an exponent. A model-dependent number of records (R_NC), such as an instruction record, copied from a location other than the collection buffer <b>508</b> may or may not be copied non-destructively when used in a reporting group <b>900</b>. In an embodiment, if the R_VCBis less than R_RG-R_NC, then the remainder of the reporting group <b>900</b> is filled with filler type records, such that the requisite count of R_RGrecords in the reporting group <b>900</b> is met. In the example of <figref idref="DRAWINGS">FIG. 9</figref>, R_RG=8, R_GS=2, and R_NC=4. In an embodiment R_RGis in the range 2≦R_RG≦2⁸records. In accordance with an embodiment, R_GSis limited to a model dependent maximum that is less than seven, so the largest reporting group size in a model may be less than 256, but is still a power of two.

0152The example reporting group <b>900</b> shown in <figref idref="DRAWINGS">FIG. 9</figref> includes a header section <b>902</b>, a body section <b>904</b>, an extra records section <b>906</b>, and a footer section <b>908</b>. The header section <b>902</b> may include a begin record or a timestamp record to hold status, tracking, and/or timing information. The body section <b>904</b> may include a variety of records for events and information sampled from collection buffer <b>508</b>. Events and information may represent, for example, state information captured by an emit instruction, a transactional-execution abort, a call, a return, a branch, and filler. The extra records section <b>906</b> may include model-dependent records. The footer section <b>908</b> can include an instruction record containing information about execution of a sample instruction.

0153In accordance with an embodiment, the first record of a reporting group <b>900</b> is in the header section <b>902</b> and is either a begin record or a timestamp record to hold status, tracking, and/or timing information. A begin record is stored for the first reporting group <b>900</b> stored in a program buffer <b>522</b> (i.e., when the RCA <b>706</b> is equal to the ROA <b>702</b>). A timestamp record is stored as the first record of each subsequent reporting group. Neither the begin record nor the timestamp record are acquired from the collection buffer <b>508</b> and thus they are part of the R_NCcount. When R_RGequals R_NC, the body is null and no records from the collection buffer <b>508</b> are stored in the reporting group. When R_RGis greater than R_NCand R_NCis equal to two, the contents of records one through R_RG-R_NCof a reporting group are in the body section of a reporting group <b>900</b> and are acquired from the collection buffer <b>508</b>.

0154The collection buffer records stored in the body of a reporting group <b>900</b> are organized from oldest to newest in accordance with an embodiment, with the newest record being stored in record R_RG-R_NCwhen the collection buffer <b>508</b> has a sufficient number of valid records. When multiple records from the collection buffer <b>508</b> are stored as part of a reporting group <b>900</b>, record one is the oldest collection buffer record reported, although the collection buffer <b>508</b> may have records even older that do not fit into the body, since the newest record in the collection buffer <b>508</b> must be reported. If the number of valid records in the collection buffer <b>508</b> is insufficient to fill a reporting group <b>900</b>, one or more filler records are used to fill as many reporting group records as necessary, starting at the record immediately following the newest collection buffer record. That is, when necessary filler-type records are placed at the bottom of the body section <b>904</b>.

0155When R_RGis greater than R_NC, and R_NCis greater than two, the contents of records (R_RG-R_NC+1) through (R_RG-2) are the extra section <b>906</b> of a reporting group <b>900</b> and contain one or more model dependent or extra records. When R_NCis equal to two, the extra section <b>906</b> is null and no extra records are stored. Extra or model dependent type records in the extra section <b>906</b> occupy the space required and any remaining space becomes part of the body section <b>904</b>.

0156In an embodiment, record R_RG-1 of a reporting group <b>900</b> is the footer section <b>908</b> and contains an instruction record representing a sample instruction. The instruction record is not acquired from the collection buffer <b>508</b> and is partially acquired from the instruction-data buffer.

0157According to an embodiment, a reporting group <b>900</b> is stored at an integral boundary of the byte size of the reporting group in program buffer <b>522</b>.

0158When the store of a reporting group <b>900</b> is attempted, either all records of the group are stored or fewer records are stored. The RCA <b>706</b> is advanced only if all the records in the reporting group <b>900</b> are stored. In an embodiment, when a reporting group <b>900</b> is stored, the records in the reporting group <b>900</b> are not stored in any particular order. However, after all records of the reporting group <b>900</b> have been stored, the begin record is updated.

0159In an embodiment, low address protection, dynamic address translation (DAT) protection, and/or key controlled protection apply to a store of a reporting group <b>900</b>. Key controlled protection obtains the key from the run-time instrumentation controls (e.g., key <b>626</b>) rather than the current PSW. The address space used is either home or primary as specified by a run-time instrumentation control block (e.g., H bit <b>608</b>). If an access exception is recognized at either the reporting group location or the begin record location, or both, neither store is performed and the contents of the reporting group are not stored.

0160In an embodiment, the RCA <b>706</b> is incremented by sixteen for each record of the reporting group stored. The actual update is performed once per reporting group <b>900</b>, incrementing by the aggregate size of the reporting group <b>900</b>. Such incrementing of the RCA <b>706</b> is referred to herein as an advance of the current address. Thus, a successful store of a reporting group <b>900</b> is represented by whether or not the RCA <b>706</b> is advanced and a field storing the number of reporting groups (NRG) in the begin record is incremented by one. The RCA <b>706</b> is not advanced when a run-time instrumentation halted condition is recognized. A program buffer full condition exists when the RCA <b>706</b> is equal to the sum of one plus the RLA <b>704</b> (RCA=1+RLA). When the program buffer full condition exists, in accordance with an embodiment, a reporting group <b>900</b> is not stored. The program buffer full condition is recognized when the RCA <b>706</b> is advanced and causes the condition to exist. When the RCA <b>706</b> is advanced and the program buffer full condition is not recognized, if the advanced address has crossed a page boundary, an access exception may be recognized. Such an access exception is indicated as a side-effect store access. The measurement alert external interruption caused by recognition of the program buffer full condition is referred to herein as a buffer full interruption.

0161When the program buffer full condition is recognized, the following actions in the indicated order may be performed by an embodiment:

01621. A bit in a stop (S) field in the begin record is set to one to indicate the existence of a program buffer full condition.

01632. A buffer full interruption is made pending by setting a bit in a run-time instrumentation control block (e.g., L bit <b>624</b>) to one. The buffer full interruption remains pending until the L bit is zeroed. The L bit may be zeroed by any of the following: successful execution of a LRIC instruction which specifies L as zero; presentation of the buffer full interruption; a CPU reset; or successful execution of a MRIC instruction which implicitly sets L to zero if the program buffer full condition is not loaded.

0164In an embodiment, while the program buffer full condition exists, the following consequences apply: execution of RINEXT performs no operation; execution of RIEMIT performs no operation; it is model dependent whether further decrementing of the interval occurs, if it does occur, it is also model dependent whether it is re-initialized to the scaling factor (SF) value in the control block (e.g., SF <b>740</b>) upon being decremented to zero, if the interval is decremented to zero then a sample instruction is not recognized; and execution of the other run-time-instrumentation instructions are not affected.

0165In an embodiment, a run-time instrumentation halted condition first exists when a version code in the timestamp record of the reporting group <b>900</b> to be stored does not equal a version code in the begin record of the reporting group <b>900</b>, and continues until run-time instrumentation is resumed after a change to the run-time instrumentation controls (e.g., a control block) which eliminates the potential inequality. The run-time instrumentation halted condition is initially recognized at the point where the begin record is recognized. The measurement alert external interruption caused by recognition of the run-time instrumentation halted condition is referred to herein as a run-time instrumentation halted interruption. When the run-time instrumentation halted condition is recognized, the following steps, in the indicated order, apply.

01661. A halted (H) field in the begin record is set to one.

01672. A run-time instrumentation halted interruption is made pending by setting the G bit (e.g., G bit <b>62</b>) in a control block to one. The run-time instrumentation halted interruption remains pending until it is cleared. In an embodiment it is cleared by any of the following: successful execution of an LRIC instruction which specifies the G bit as zero; presentation of the run-time instrumentation halted interruption; CPU reset; successful execution of a MRIC instruction which implicitly sets G to zero if the RCA <b>706</b> that equals the ROA <b>702</b> is loaded (this is also a clearing of the run-time instrumentation halt condition).

0168While the run-time instrumentation halted condition exists, the following consequences apply: 1. execution of RINEXT performs no operation; 2. execution of RIEMIT performs no operation; 3. It is model dependent whether further decrementing of the interval (e.g., RSIC <b>742</b>) occurs, if it does occur then it is also model dependent whether it is re-initialized to the SF value (e.g., SF <b>740</b>) upon being decremented to zero, if the interval is decremented to zero then a sample instruction is not recognized; 4. no additional reporting groups <b>900</b> are stored; 5. the RCA <b>706</b> is not advanced; and 6. execution of the other run-time instrumentation instructions is not affected. If the G bit is loaded as a one during execution of a LRIC or a MRIC instruction, the run-time instrumentation halted interruption is made pending. The G bit is implicitly set to zero when a MRIC instruction specifies that the ROA <b>702</b> equals the RCA <b>706</b>. If U bit <b>622</b> in the run-time instrumentation controls is equal to zero, a run-time instrumentation halted interruption is disabled.

0169Turning now to <figref idref="DRAWINGS">FIG. 10</figref>, an embodiment of a begin record <b>1000</b> is generally shown. In an embodiment, the begin record <b>1000</b> is stored in the header section <b>902</b> for the first reporting group <b>900</b> stored in a program buffer <b>522</b> (i.e., when the RCA <b>706</b> is equal to the ROA <b>702</b>), and the begin record <b>1000</b> is updated after the first reporting group <b>900</b> is stored to the program buffer <b>522</b>. The begin record <b>1000</b> shown in <figref idref="DRAWINGS">FIG. 10</figref> includes a record type field <b>1002</b>, a number of reporting groups (NRG) field <b>1004</b>, a version field <b>1014</b>, a RGS field <b>1006</b>, a stopped (S) field <b>1008</b>, a capability (T) field <b>1016</b>, a halted (H) field <b>1010</b>, and a time of day (TOD) clock field <b>1012</b>. The begin record <b>1000</b> is initialized using run-time instrumentation control values (e.g., from the RICCB, or other control block). The record type field <b>1002</b> is set to “02” to indicate that the record is a begin record <b>1000</b>. The NRG field <b>1004</b> is set to one to indicate that there is one reporting group <b>900</b> stored in the program buffer <b>522</b>. The NRG field <b>1004</b> is updated each time a new reporting group is stored to the program buffer <b>522</b>. The version field <b>1014</b> stores an integer whose value indicates a functional engineering change level (e.g., of the instrumentation module <b>506</b>). During initialization of the begin record <b>1000</b>, the RGS field <b>1006</b> is updated with the current value of the RGS <b>1006</b> (e.g., from the RICCB) to indicate the size of all the reporting groups <b>900</b> in the program buffer <b>522</b>. The S field <b>1008</b> is set to zero to indicate that the program buffer <b>522</b> is not full. If the program buffer <b>522</b> becomes full, the S field <b>1008</b> is changed to a one which indicates that a program buffer full condition exists. The T field <b>1016</b> is set to zero during initialization when the reporting group <b>900</b> represents a sample captured on a CPU operating at its CPU capability, and is set to one when the reporting group <b>900</b> represents a sample captured on a CPU operating at a secondary CPU capability. The H field <b>1010</b> is set to zero during initialization and then set to one if the run-time instrumentation has been halted due to reasons other than the buffer full condition. When the H field <b>1010</b> is equal to one, the G bit <b>620</b> in the RICCB is also set to one. The TOD clock field <b>1012</b> is set to indicate the time of day when the reporting group containing the begin record <b>1000</b> was originally stored. The reserved portions of the begin record <b>1000</b> (and any reserved portions in the rest of the reporting group records) do not have predictable values.

0170<figref idref="DRAWINGS">FIG. 11</figref> is an embodiment of a timestamp record <b>1100</b> in the header section <b>902</b> of a reporting group <b>900</b>. A timestamp record <b>1100</b> is stored as record zero (i.e., the first record) of every reporting group <b>900</b> other than the first reporting group <b>900</b> in the program buffer <b>522</b>. A timestamp record <b>1100</b> is created when a reporting group <b>900</b> is stored to the program buffer <b>522</b> and the ROA <b>702</b> does not equal the RCA <b>706</b>. The embodiment of the timestamp record <b>1100</b> shown in <figref idref="DRAWINGS">FIG. 11</figref> includes a record type <b>1102</b>, a version field <b>1106</b>, a capability (T) field <b>1108</b>, and a TOD clock field <b>1104</b>. The record type <b>1102</b> is set to “03” to indicate that the record is a timestamp record <b>1100</b>. The version field <b>1106</b> stores an integer whose value indicates a functional engineering change level (e.g., of the instrumentation module <b>506</b>). The T field <b>1108</b> is set to zero during initialization when the reporting group <b>900</b> represents a sample captured on a CPU operating at its CPU capability, and is set to one when the reporting group <b>900</b> represents a sample captured on a CPU operating at a secondary CPU capability. The TOD clock field <b>1104</b> is set to indicate the time of day when the reporting group <b>900</b> containing the timestamp record <b>1100</b> was originally stored.

0171The body section <b>904</b> of the reporting group <b>900</b> may include a variety of events and information sampled from the collection buffer <b>508</b>. Events and information may represent, for example, state information captured by an emit instruction, a transactional execution mode abort, a call, a return, a branch, and filler.

0172An emit record is created and stored in the body section <b>904</b> of a reporting group <b>900</b> in the program buffer <b>522</b> upon a successful execution of a RIEMIT instruction. <figref idref="DRAWINGS">FIG. 12</figref> illustrates three different embodiments of an emit record <b>1202</b>, <b>1204</b> and <b>1206</b> that vary based on whether a 64, 31 or 24 bit addressing mode is being implemented. The emit records <b>1202</b>, <b>1204</b> and <b>1206</b> all include a record type field <b>1208</b>, an instruction address code (C) field <b>1210</b>, an instruction address field <b>1212</b>, and an emit data field <b>1214</b>. The record type field <b>1208</b> is set to “10” to indicate that the record is an emit record <b>1202</b>, <b>1204</b> or <b>1206</b>. In an embodiment, the C field <b>1210</b> is an unsigned integer whose value is a code which describes how the instruction address bit positions in the current PSW are represented in the emit record <b>1202</b>, <b>1204</b> and <b>1206</b>. When the C field <b>1210</b> is equal to zero, bit positions <b>22</b>-<b>62</b> of the instruction address (IA) of the current PSW are placed in bit positions <b>22</b>-<b>62</b> of the record and bit positions <b>0</b>-<b>21</b> of the instruction address are all zeros. When the C field <b>1210</b> is equal to one, bit positions <b>22</b>-<b>62</b> of the instruction address of the current PSW are placed in bit positions <b>22</b>-<b>62</b> of the record and bit positions <b>0</b>-<b>21</b> of the instruction address are not all zeros. When the C field is equal to one, a maximum address exceeded bit (e.g., MAE <b>712</b>) in the run-time instrumentation control block is set to one if the record is stored as part of a reporting group <b>900</b>. The instruction address field <b>1212</b> contains the instruction address of the RIEMIT instruction or execute type instruction if the RIEMIT was the target of an execute type instruction. As shown in <figref idref="DRAWINGS">FIG. 12</figref>, the instruction address field <b>1212</b> varies depending on the addressing mode (e.g., 64, 31 or 24 bit). The emit data field <b>1214</b> includes the data from the general register specified by the RIEMIT instruction.

0173A transactional execution mode abort record is created by either an implicit abort or by execution of transaction abort and stored in the body section <b>904</b> of a reporting group <b>900</b> in the program buffer <b>522</b>. <figref idref="DRAWINGS">FIG. 13</figref> illustrates three different embodiments of an abort record <b>1302</b>, <b>1304</b> and <b>1306</b> that vary based on whether a 64, 31 or 24 bit addressing mode is being implemented. The abort records <b>1302</b>, <b>1304</b> and <b>1306</b> all include a record type field <b>1308</b>, an instruction address code (C) field <b>1310</b>, an instruction address field <b>1312</b> and a model dependent field <b>1314</b>. The record type field <b>1308</b> is set to “11” to indicate that the record is an abort record <b>1302</b>, <b>1304</b> or <b>1306</b>. In an embodiment, the C field <b>1310</b> is an unsigned integer whose value is a code which describes how the instruction address bit positions in the current PSW are represented in the abort record <b>1302</b>, <b>1304</b> and <b>1306</b>, and has properties similar to the C field <b>1210</b> described above with respect to <figref idref="DRAWINGS">FIG. 12</figref>. The instruction address field <b>1312</b> contains the instruction address of the aborted instruction or execute type instruction if the aborted instruction was the target of an execute type instruction. As shown in <figref idref="DRAWINGS">FIG. 13</figref>, the instruction address field <b>1312</b> varies depending on the addressing mode (e.g., 64, 31 or 24 bit). The model dependent data field <b>1314</b> includes any model dependent data associated with the abort.

0174A call record is created by execution of a branch instruction which is categorized as a call type branch instruction. The call record is stored in the body section <b>904</b> of a reporting group <b>900</b> in the program buffer <b>522</b>. In an embodiment, call type branches include: BRANCH AND SAVE (BASR) when the R<b>2</b> field is nonzero, BRANCH AND SAVE (BAS), BRANCH RELATIVE AND SAVE LONG, RANCH RELATIVE AND SAVE, BRANCH AND LINK (BALR) when the R<b>2</b> field is nonzero, BRANCH AND LINK (BAL), and BRANCH AND SAVE AND SET MODE when the R<b>2</b> field is nonzero. <figref idref="DRAWINGS">FIG. 14</figref> illustrates three different embodiments of a call record <b>1402</b>, <b>1404</b> and <b>1406</b> that vary based on whether a 64, 31 or 24 bit addressing mode is being implemented. The call records <b>1402</b>, <b>1404</b> and <b>1406</b> all include a record type field <b>1408</b>, an instruction address code (C) field <b>1410</b>, an instruction address field <b>1412</b>, a well behaved (W) field <b>1416</b>, and a target address field <b>1414</b>. The record type field <b>1408</b> is set to “12” to indicate that the record is a call record <b>1402</b>, <b>1404</b> or <b>1406</b>. The C field <b>1410</b> is an unsigned integer whose value is a code which describes how the instruction address bit positions in the current PSW are represented in the call record <b>1402</b>, <b>1404</b> and <b>1406</b>, and it has properties similar to the C field <b>1210</b> described above with respect to <figref idref="DRAWINGS">FIG. 12</figref>. The instruction address field <b>1412</b> contains the address of the branch instruction or execute type instruction if the branch was the target of an execute type instruction. A W field <b>1414</b> having a value of one indicates that the branch was predicted correctly, and a value of zero indicates that the branch was not correctly predicted. The target address field <b>1414</b> contains the branch target address (also referred to as the “called location”).

0175Return records and transfer records in the body section <b>904</b> of a reporting group <b>900</b> in the program buffer <b>522</b> have the same format as the call records <b>1402</b><b>1404</b> and <b>1406</b>. In an embodiment, a return record has a record type field of “13” and is created by execution of a return type branch instruction such as a BRANCH ON CONDITION (BCR) when the R<b>2</b> field is nonzero and the mask is 15, BRANCH ON CONDITION (BC) when the J bit is one and the mask is 15, and BRANCH AND SET MODE when the R<b>2</b> field is nonzero. For the return record, the instruction address field contains the address of the branch instruction or execute type instruction if the branch as the target of an execute type instruction, and the target address field contains the return location.

0176In an embodiment, a transfer record has a record type field of “14” and is created by execution of a return type branch instruction such as: a. BRANCH ON CONDITION (BCR) when the R<b>2</b> field is nonzero and the mask is in the range 1-14; b. BRANCH ON CONDITION (BC) when the J bit is zero or the mask is in the range 1-14; c. BRANCH ON COUNT (BCT, BCTR, BCTG, BCTGR); d. BRANCH ON INDEX HIGH (BXH, BXHG); e. BRANCH ON INDEX LOW OR EQUAL (BXLE, BXLEG); f. BRANCH RELATIVE ON CONDITION (BRC); g. BRANCH RELATIVE ON CONDITIONLONG (BRCL); h. BRANCH RELATIVE ON COUNT (BRCT,BRCTG); i. BRANCH RELATIVE ON COUNT HIGH (BRCTH); j. BRANCH RELATIVE ON INDEX HIGH (BRXH, BRXHG); k. BRANCH RELATIVE ON INDEX LOW OREQUAL (BRXLE, BRXLG); l. COMPARE AND BRANCH (CRB, CGRB); m. COMPARE AND BRANCH RELATIVE (CRJ,CGRJ); n. COMPARE IMMEDIATE AND BRANCH (CIB, CGIB); o. COMPARE IMMEDIATE AND BRANCH RELATIVE (CIJ, CGIJ); p. COMPARE LOGICAL AND BRANCH (CLRB, CLGRB); q. COMPARE LOGICAL AND BRANCH RELATIVE (CLRJ, CLGRJ); r. COMPARE LOGICAL IMMEDIATE AND BRANCH (CLIB, CLGIB); and s. COMPARE LOGICAL IMMEDIATE AND BRANCH RELATIVE (CLIJ, CLGIJ). The transfer record is created when the branch is taken. For the transfer record, the instruction address field contains the address of the branch instruction or execute type instruction if the branch as the target of an execute type instruction, and the target address field contains the return location.

0177A filler record is used in the body section <b>904</b> of a reporting group <b>900</b> when the number of valid records in the collection buffer <b>508</b> is not sufficient to fill a reporting group <b>900</b> of the current RGS. <figref idref="DRAWINGS">FIG. 15</figref> is an embodiment of a filler record <b>1500</b>. The embodiment shown in <figref idref="DRAWINGS">FIG. 15</figref> includes a record type <b>1502</b> set to “00” to indicate that the record is a filler record <b>1500</b> and the remaining bytes are undefined.

0178The extra records section <b>906</b> in the reporting group <b>900</b>, when present, may contain model dependent records. In an embodiment, the format of an extra record is similar to the filler record <b>1500</b> except for the record type is set to “01” to indicate that the record is an extra record and the remaining bytes of the extra record contain model dependent data.

0179In an embodiment, the footer section <b>908</b> of the reporting group <b>900</b> includes an instruction record containing information about execution of a sample instruction. An instruction record is created when a reporting group <b>900</b> is stored for a sample instruction. <figref idref="DRAWINGS">FIG. 16</figref> illustrates three different embodiments of an instruction record <b>1602</b>, <b>1604</b> and <b>1606</b> that vary based on whether a 64, 31 or 24 bit addressing mode is being implemented. The instruction records <b>1602</b>, <b>1604</b> and <b>1606</b> all include a record type field <b>1608</b>, an instruction address code (C) field <b>1610</b>, an instruction address field <b>1612</b> and an instruction-data buffer (IDB) field <b>1614</b>. The record type field <b>1608</b> is set to “04” to indicate that the record is an instruction record <b>1602</b>, <b>1604</b> or <b>1606</b>. The C field <b>1610</b> is an unsigned integer whose value is a code which describes how the instruction address bit positions in the current PSW are represented in the instruction record <b>1602</b>, <b>1604</b> and <b>1606</b>, and it has properties similar to the C field <b>1210</b> described above with respect to <figref idref="DRAWINGS">FIG. 12</figref>. The instruction address field <b>1612</b> contains the address of the sample instruction or execute type instruction if the sample instruction was the target of an execute type instruction. As shown in <figref idref="DRAWINGS">FIG. 16</figref>, the instruction address field <b>1612</b> varies depending on the addressing mode (e.g., 64, 31 or 24 bit). The IDB field <b>1614</b> includes data collected from the instruction-data buffer and the contents are model dependent.

0180<figref idref="DRAWINGS">FIG. 17</figref> depicts a process flow for run-time instrumentation reporting in accordance with an embodiment. In an embodiment, the processing shown in <figref idref="DRAWINGS">FIG. 17</figref> is performed by instrumentation module <b>506</b>. At block <b>1702</b>, an instruction stream is executed on a processor, such as processor <b>106</b> or emulated processor <b>29</b>. At block <b>1704</b>, run-time instrumentation information of the executing instruction stream is captured, and at block <b>1706</b> run-time instrumentation records (such as those shown in collection buffer <b>508</b>) are created based on the captured run-time instrumentation information. A run-time instrumentation sample point of the executing instruction is detected at block <b>1708</b>. At block <b>1710</b>, a reporting group, such as reporting group <b>900</b>, is stored in a run-time instrumentation program buffer, such as program buffer <b>522</b>. The storing includes determining a current address of the run-time instrumentation program buffer based on the run-time instrumentation controls. In an embodiment, the current address of the run-time instrumentation controls is the RCA <b>706</b> stored in the RICCB <b>700</b>. The storing is based on the origin address (e.g., ROA <b>702</b>) and the current address of the run-time instrumentation program buffer.

0181As described above, embodiments can be embodied in the form of computer-implemented processes and apparatuses for practicing those processes. An embodiment may include a computer program product <b>1800</b> as depicted in <figref idref="DRAWINGS">FIG. 18</figref> on a computer readable/usable medium <b>1802</b> with computer program code logic <b>1804</b> containing instructions embodied in tangible media as an article of manufacture. Exemplary articles of manufacture for computer readable/usable medium <b>1802</b> may include floppy diskettes, CD-ROMs, hard drives, universal serial bus (USB) flash drives, or any other computer-readable storage medium, wherein, when the computer program code logic <b>1804</b> is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. Embodiments include computer program code logic <b>1804</b>, for example, whether stored in a storage medium, loaded into and/or executed by a computer, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code logic <b>1804</b> is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. When implemented on a general-purpose microprocessor, the computer program code logic <b>1804</b> segments configure the microprocessor to create specific logic circuits.

0182Technical effects and benefits include the ability to extract run-time instrumentation data in a laboratory environment, for off-line analysis, and in live software environments within programs at run-time and under program control. A reporting group is stored into the program buffer whose location is determined from controls associated with the run-time instrumentation. Thus, instrumented data stored as reporting groups in the program buffer are available to the program for post-analysis (or even aggressive analysis during run-time instrumentation).

0183The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

0184The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

0185As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

0186Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

0187A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

0188Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

0189Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

0190Aspects of the present invention are described above with reference to flowchart illustrations and/or schematic diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

0191These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

0192The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

0193As described above, embodiments can be embodied in the form of computer-implemented processes and apparatuses for practicing those processes. In embodiments, the invention is embodied in computer program code executed by one or more network elements. Embodiments include a computer program product on a computer usable medium with computer program code logic containing instructions embodied in tangible media as an article of manufacture. Exemplary articles of manufacture for computer usable medium may include floppy diskettes, CD-ROMs, hard drives, universal serial bus (USB) flash drives, or any other computer-readable storage medium, wherein, when the computer program code logic is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. Embodiments include computer program code logic, for example, whether stored in a storage medium, loaded into and/or executed by a computer, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code logic is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. When implemented on a general-purpose microprocessor, the computer program code logic segments configure the microprocessor to create specific logic circuits.

0194The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.