WO2017155551A1

WO2017155551A1 - Register store

Info

Publication number: WO2017155551A1
Application number: PCT/US2016/022182
Authority: WO
Inventors: Terence P Kelly; Charles B MORREY; Dhruva Chakrabarti; Aasheesh KOLLI; Qiong Cai; Andrew C Walton; Joseph IZRAELEVITZ
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2016-03-11
Filing date: 2016-03-11
Publication date: 2017-09-14

Abstract

Examples herein involve storing registers in the event of a system failure. In examples herein, an association is made between a register and a location in persistent memory based on an execution of a process. Upon detection of the failure, the content of the register is stored to the persistent memory location based on the association.

Description

REGISTER STORE

BACKGROUND

[0001] In computer architecture, registers are small local storage units used in processing application or program data. Registers are generally within a processor or collocated with a processor. Registers provide fast access to data relative to main memory or other types of memory. In many instances, processors utilize registers to manipulate data during processing of executable instructions (e.g., execution of software, such as a program or application).

[0002] Volatile memory or volatile storage devices (e.g., cache, dynamic random access memory (DRAM), etc.) lose memory state due to stoppage events (e.g., power failure, shutdown, software crashes, etc.) or when not under power. Non-volatile memory or non-volatile storage devices maintain(s) memory state when not under power. Persistent memory preserves its contents across process termination/crashes, operating system halt/reboot, and machine power cycling and may be implemented by volatile memory (e.g., with a power backup) and/or non-volatile memory.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] FIG. 1 is a block diagram of an example processor platform including an example register store manager implemented in accordance with the teachings of this disclosure.

[0004] FIG. 2 a block diagram of an example register store manager that may be used to implement the register store manager of FIG. 1 .

[0005] FIG. 2 illustrates an example register store implemented by the example register store manager of FIGS. 1 or 2 in accordance with an aspect of this disclosure. [0006] FIG. 4 is a flowchart representative of example machine readable instructions that may be executed to implement the register store manager of FIG. 2.

[0007] FIG. 5 is another flowchart representative of example machine readable instructions that may be executed to implement the register store manager of FIG. 2.

[0008] Wherever possible, the same reference numbers will be used throughout the drawing(s) and accompanying written description to refer to the same or like parts.

DETAILED DESCRIPTION

[0009] Examples disclosed herein involve storing register content (e.g., by issuing store instructions followed by cache flush instructions) to preserve the content in the event of a failure (a power failure, application software failure, system software failure, etc.). In examples herein, persistent memory locations to which performance critical variables of a program are to be written are identified, an association between the registers holding the performance critical variables and the persistent memory locations is recorded, and in the event of failure, the association is used to preserve the content of the registers in the persistent memory locations.

[0010] Persisting data enables the preservation of data after a system failure. In many instances cache, and in some instances registers may be preserved in order to allow recovery from failure. However, previous save-it-all techniques, such as core dumps, indiscriminately include entire address spaces of a program, which may include redundant or unnecessary backup of data. Examples herein provide an efficient streamlined approaches to storing register content with and without the use of a core dump file. Furthermore, previous techniques, such as core dumps, may not allow for power failures or operating system (OS) kernel panics, only process crashes, while examples herein enable recovery from both software failures and power failures. Additionally, in previous save-it-all core dump approaches, preserved data may be inconsistent with a memory state of an application at a point of a crash or failure. For example, in a banking transaction using previous approaches, if a crash occurs during transfer of funds, a "from" account may be decremented while a "to" account is not incremented, resulting in a loss of funds. Examples herein cure these deficiencies by recording (e.g., within a core file, within a local location of a processor, etc.) an association between registers and memory location. As used herein, program data of a program is considered consistent when it satisfies an application-level consistency criteria (e.g., that all funds of a transaction be preserved).

[0011] Some efforts to preserve data of a program (e.g., data being manipulated in registers during execution of the program) involve storing or flushing data after each iteration of a loop of an application or program, though this consumes time and resources with frequent stores to memory. However, waiting for iterations of loops to complete may put application data at risk of being lost during execution due to failures (e.g. power failures, software failures, etc.). Examples herein enable optimization techniques (e.g., storing data after completion of a loop, rather than after each iteration of loop) to be used in processing data, while ensuring persistence of the program/application data without degrading execution performance.

[0012] Examples herein involve analyzing a program to identify a memory location of a persistent memory to which content of a register used in the execution of the program is to be stored. Examples further involve associating the register to the memory location by recording an association between the register and the memory location, and upon detection of a failure during the execution, the content of the register is stored to the persistent memory.

[0013] FIG. 1 is a block diagram of an example processor system 100 of a machine including a register store manager 1 10 implemented in accordance with the teachings of this disclosure. The processor system 100 includes registers 1 15, a processor 1 20, a cache 130, a volatile memory 1 50, a nonvolatile memory 160, a platform bus 170, an interface circuit 180, and a mass storage device 190. In the illustrated example of FIG. 1 , the processor 120 includes the register store manager 1 10 constructed in accordance with the teachings of this disclosure. The register store manager 1 10 handles store operations to preserve content of the registers 1 15 in the event of a system failure (e.g., a power failure (e.g., abrupt shutdown, power outage, etc.), a software failure (e.g., an application crash, operating system kernel panic, etc.), etc.). In examples herein, when referring to a single register 1 15, it may be understood to refer to any or all of the registers 1 15.

[0014] The example register store manager 1 10 of FIG. 1 stores (or causes the processor 120 to store) content of a register 1 1 5 to a persistent memory location (e.g., a memory address in the volatile memory 150 and/or the non-volatile memory 1 60). In examples herein, the register store manager 1 1 0 may identify, record, and/or store an association between the registers 1 1 5 being used in an execution of a program and corresponding memory locations to which content of the registers is to be stored. Furthermore, the register store manager 1 10 may store and/or execute an instruction to cause content of the registers 1 15 to be stored to corresponding memory locations. In some examples, the register store manager 1 10 may be implemented by a compiler of the system 100 (or compiler software), which may then add functionality of the register store manager 1 10 to the processor 1 20. In such examples, the memory locations may be located in persistent memory locations specified by a program under execution by the processor 120. In some examples, the memory locations may be locations of a core file corresponding to persistent memory locations. Accordingly, in examples herein, the register store manager 1 10 may preserve the content of registers during execution of a program in the event of a failure to maintain a consistent state of program data, thus providing crash- tolerance, but also enabling use of optimization techniques.

[0015] The processor 120 of FIG. 1 is hardware that executes software and/or computer readable instructions of the processor system 100. For example, the processor 120 may be implemented by at least one integrated circuit, logic circuit, microprocessor, or controller from any desired family or manufacturer. More specifically, the processor 1 20 may be an ARM processor, an x86 processor, an MIPS core processor, or any other type of processor. The processor 120 of FIG. 1 may include a central processing unit (CPU) of the processor system 1 00 with a hardware processing core, a memory controller, and/or other software, firmware, or hardware components. The processor 1 20 of FIG. 1 may be collocated on a same device (e.g., a same semiconductor chip) as the registers 1 15 and/or the cache 130.

[0016] The example registers 1 15 of FIG. 1 may be implemented by local circuitry of the processor 120 to manipulate data, such as data loaded from the cache 130 or other memory. For example, the processor 1 20 may load variables or parameters of a program or application into the registers 1 15 to adjust values of the variables or parameters during execution of a program. The example cache 130 is a local addressable storage circuit that may be collocated on a same device (e.g., a semiconductor chip) as the example processor 120. In the illustrated example of FIG. 1 , the processor 1 20 can perform faster read and/or write operations when accessing data in the cache 130 than when accessing data in the volatile memory 150 and/or in the non-volatile memory 160 via the platform bus 170. Accordingly, the processor 1 20 may load data from the volatile memory 150 and/or the non-volatile memory 160 into the cache 130 so that the processor 120 can access the data relatively faster using the cache 130. The processor 120 may then utilize the registers 1 15 to manipulate data in the cache 130 (and/or data from the volatile memory 150, non-volatile memory 160, or mass storage 190). For example, instructions (e.g.,

computation (addition, subtraction, etc.) of the processor 1 20 may utilize the registers 1 15 by loading data from memory into the registers and storing results of the instructions (e.g., results of a computation) back into memory. The example cache 130 may enhance such performance as loads/stores from/to the cache 130 are faster than from memory (e.g., the volatile memory 150, the nonvolatile memory 160, etc.).

[0017] In examples herein, the processor 1 20 may implement a flush-on- failure protocol to preserve states of executing programs by persisting data from the registers 1 1 5 and the cache 130 to persistent memory (e.g., the volatile memory 150 or the non-volatile memory 160) (or other persistent storage in communication with the processor system 100). In such cases, in the event of a failure, (e.g., a power failure or a software failure) the register store manager 1 1 0 manages persistence of the content of the registers 1 1 5 to ensure that the content of the registers 1 1 5 is preserved in persistent memory. The content of a register 1 1 5 (and thus preserve a consistent state of application data) may be preserved by storing the content of the register 1 1 5 to a persistent memory location in persistent memory based on an association between the register 1 15 and the memory location determined from execution of the program.

Accordingly, the program data for a program may remain consistent so as to avoid any data errors or data failures (e.g., such as loss of program data) caused by the crash when executing the program and ensure a consistent state of the program data.

[0018] The example volatile memory 150 of FIG. 1 is any volatile memory storage device that stores data when powered, but loses memory state when power is removed. For example, the volatile memory 150 may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic

Random Access Memory (DRAM), Static Random Access Memory (SRAM), RAMBUS Dynamic Random Access Memory (RDRAM) and/or any other type of volatile memory. The non-volatile memory 160 is any non-volatile memory storage device (e.g., phase-change memory, memristor memory, etc.) that is capable of storing data when powered and when not powered. The non-volatile memory 160 is considered a persistent memory device in that it is crash-tolerant (e.g., maintains memory state in the event of a failure). In examples herein, the volatile memory 150 may also be considered persistent memory. For example, the volatile memory 1 50 may be powered by a standby power device in the event of a failure which enables the data in the volatile memory 1 50 to be preserved by storing it to the non-volatile memory 160 using the backup power from the standby power device. In examples herein, transient memory is not crash tolerant in that transient memory does not maintain memory state in the event of failure or when not under power.

[0019] The interface circuit 180 of FIG. 1 may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), a Peripheral Component Interconnect (PCI) express interface, etc. The example interface circuit 180 may include an advance extensible interface (AXI) controller, a PCI controller, a PCIe controller, an Infiniband, etc. to facilitate a bridge to the platform bus 170 from any peripheral of the processor system 100. In the illustrated example, at least one input device 182 is connected to the interface circuit 180. The input device(s) 182 permit(s) a user (e.g., a programmer, a compiler, etc.) to enter data and commands into the processor 120. The input device(s) 182 can be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, a voice recognition system, or any other type of input device. Output device(s) 184 is/are also connected to the interface circuit 180 of the illustrated example of FIG. 1 . The output devices 184 may be implemented, for example, by display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display, a cathode ray tube display (CRT), a touchscreen, a tactile output device, a light emitting diode (LED), a printer and/or speakers). The interface circuit 180 of the illustrated example, thus, typically includes a graphics driver card, a graphics driver chip or a graphics driver processor.

[0020] The interface circuit 180 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem and/or network interface card to facilitate exchange of data with external machines (e.g., computing devices of any kind) via a network 1 86 (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.). Accordingly, the interface circuit 180 may facilitate communication with the network 186.

[0021] The processor system 100 in the illustrated example of FIG. 1 also includes at least one mass storage device 1 90 for storing software and/or data, though such a device may not be included in the processor system 100.

Examples of such mass storage devices 190 include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, RAID systems, and digital versatile disk (DVD) drives. In some examples, the mass storage devices 1 90 may be implemented using the non-volatile memory 150.

[0022] The processor system 100 of FIG. 1 may be, for example, a server, a personal computer, a mobile device, a personal digital assistant (PDA), or any other type of computing device. [0023] FIG. 2 is a block diagram of an example implementation of a register store manager 1 1 0 that may be used to implement the register store manager 1 10 of FIG. 1 . The example register store manager 1 10 of FIG. 2 includes a program analyzer 210, a register association recorder 220, and a register store initiator 230. In examples herein, the program analyzer 210 analyzes programs and/or source code of the programs to be executed by the processor 120 to determine a memory location to which content of a register is to be stored, the register association recorder 220 is to create an association between the register and the memory location, and the register store initiator 230 to persist the content of the register in the memory location based on the generated association between the register and the memory location. In examples herein, the register store initiator 230 may store the content of the register 1 1 5 in an appropriate memory location (e.g., of a persistent memory or of a core file memory location corresponding to a persistent memory location) in response to the register store manager 1 10 responding to a failure or a detected failure in the processor system 100 or upon recovery from a system failure.

[0024] The example program analyzer 210 of FIG. 2 may analyze or utilize execution of a program and/or source code for a program to identify registers or content of registers that are to be preserved in the event of a failure. In examples herein, the program analyzer 210 identifies performance critical variables within the execution (or source code) of a program and determines memory locations to which the performance critical variables are to be stored during or after execution of the program. For example, the performance critical variables may be indicated in annotations of the source code (e.g., provided by the program developer). Additionally or alternatively, the program analyzer 210 may identify the performance critical variables from operations within the source code (e.g., loops, inner loops, etc.). In examples herein, a performance critical variable is a variable of a program that is to be preserved in the event of a failure occurring during execution of the program. For example, a performance critical variable may include a variable of an inner loop of a program that remains in a register 1 15 until completion of the inner loop. [0025] In examples herein, the program analyzer 210 may identify the registers 1 15 to be used in processing performance critical variables during execution. Accordingly, the program analyzer 21 0 may analyze execution of a program or source code of a program to identify registers 1 1 5 that are used to process the performance critical variables and corresponding memory locations that are to store the performance critical values after execution. The example memory locations may be memory locations of persistent memory (e.g., memory locations of the volatile memory 150 or the non-volatile memory 160) that are to store the performance critical variables after completion of the execution of the program or after completion of a loop in the execution. The program analyzer 210 may provide the identified registers 1 15 and the corresponding memory locations to the register association recorder 220.

[0026] In some examples, the program analyzer 210 may identify registers 1 15 that include performance critical variables of a program from annotations accompanying the source code (e.g., the annotations are in lines of the source code). Accordingly, the program analyzer 210 may scan source code of a program to identify the annotations. Such annotations may be provided by a user (e.g., a programmer) to ensure that the content of the registers 1 15 (including the performance critical variables) is preserved in designated memory addresses. For example, a user (e.g., a programmer) may include identifiers within annotations of the source code that are performance critical.

[0027] The example register association recorder 220 of FIG. 2 records an association between the registers 1 15 storing performance critical variables and memory locations in persistent memory (e.g., memory locations in the volatile memory 150 or the non-volatile memory 160) to which the performance critical variables are to be stored after an iteration of the execution. The example association may be recorded as an instruction for the processor 120, such that, upon detection of a failure, the register store initiator 230 stores the values of the performance critical variables to the corresponding memory locations. In some examples, if the processor 120 supports simultaneous multithreading, disabling the simultaneous multithreading enables some of the registers 1 15 to be accessed so that the addresses corresponding to memory locations for the performance critical variables may be stored in the unused registers. Accordingly, the register association recorder 220 may record the association of the register 1 15 in the unused registers made available by disabling the simultaneous multithreading. In some examples, the register store manager 1 15 may disable simultaneous multithreading capabilities of the processor 120 (e.g., in response to a user instruction). The example register store initiator 230 may then refer to those registers to identify addresses corresponding to memory locations that are to store the performance critical variables of the registers 1 1 5 used in execution of the program.

[0028] In some examples, the register association recorder 220 may record an association between the registers in dedicated memory of a program (e.g., provide example memory locations). The example association may then be stored in a core file in the event of a system failure. The example core file may include a preserved copy of a program's memory state at the time of the failure. In some examples, the core file may include designated memory states (e.g., registers, memory locations, etc.) that preserves specified data (e.g., performance critical variables of the programs, such as those indicated by a user or application developer). In examples herein, the core file may store any amount of data (whether all or specified) along with associations between the registers and memory locations to preserve a consistent state of application data. In such examples, the register store manager 1 10 may implement recovery software (e.g., such a debugging mechanism) to copy preserved data from the registers into appropriate memory locations of the core file. Such an example is illustrated in FIG. 3.

[0029] In the event of a failure, the example register store initiator 230 stores the content of the registers to the designated memory locations based on the associations recorded by the register association recorder 220. Accordingly, the register store initiator 230 may communicate with the processor 120 or other components of the processor system 100 to detect a failure and/or retrieve information corresponding to an imminent failure using any suitable technique. In some examples, the register store initiator 230 may store the associations recorded by the register association recorder 220. In some examples, the register store initiator may store register content to appropriate memory locations of a core file generated from a failure (as illustrated in FIG. 4)

[0030] Accordingly, in the event of a failure, the example register store manager 1 10 of FIG. 2 preserves content of registers used in execution of a program using optimization techniques. In other words, the program may use optimization techniques (e.g., storing performance critical variables after completion of a loop rather than after each iteration of a loop) and the register store manager 1 10 may provide crash tolerance by preserving a consistent state of the program data without degrading the performance. In the event of a crash, the register store manager 1 10 may record the register content to appropriate memory locations based on recorded associations between the registers and the memory locations. In some examples, the consistent state of the program data may be preserved using a recovery mechanism implemented after a failure that refers to the recorded associations between the registers and memory locations. Accordingly, following implementations of such recovery mechanisms, the register contents may be stored in the appropriate memory locations of persistent memory (e.g., the volatile memory 1 50, the non-volatile memory 160, a memory-mapped file that is to be written to persistent memory, etc.) to preserve the consistency of the program data.

[0031] While an example manner of implementing the register store manager 1 10 of FIG. 1 is illustrated in FIG. 2, at least one of the elements, processes and/or devices illustrated in FIG. 2 may be combined, divided, rearranged, omitted, eliminated and/or implemented in any other way. Further, the program analyzer 21 0, the register association recorder 220, the register store initiator 230, and/or, more generally, the example register store manager 1 10 of FIG. 2 may be implemented by hardware and/or any combination of hardware and executable instructions (e.g., software and/or firmware). Thus, for example, any of the program analyzer 210, the register association recorder 220, the register store initiator 230, and/or, more generally, the example register store manager 1 10 could be implemented by at least one of an analog or digital circuit, a logic circuit, a programmable processor, an application specific integrated circuit (ASIC), a programmable logic device (PLD) and/or a field programmable logic device (FPLD). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of the program analyzer 21 0, the register association recorder 220, or the register store initiator 230 is/are hereby expressly defined to include a tangible machine readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. storing the executable instructions. Further still, the example register store manager 1 10 of FIG. 2 may include at least one element, process, and/or device in addition to, or instead of, those illustrated in FIG. 2, and/or may include more than one of any or all of the illustrated elements, processes and devices.

[0032] In FIG. 3, a register store manager 1 1 0, which may be

implemented by the register store manager 1 10 of FIG. 2 to preserve content of registers 315a, 315b, 315c used in a running program 310 using a core file 370. A program analyzer 210 of the register store manager 310 of FIG. 3 may identify associations between the registers 315a, 315b, 315c and memory locations 360a, 360b, 360c in persistent memory 360 (e.g., the volatile memory 150, the non-volatile memory 1 60, etc.) of the running program 31 0. The example associations may be identified from source code or created from execution of the program. For example, an application developer may specify (via

instructions within the program or annotations in source code of the program) the performance critical variables that are to be preserved (e.g., the variables in the registers 31 5a, 31 5b, 31 5c). An example register association recorder 220 of the register store manager 1 10 of FIG. 3 may record the associations in an association record 320. The association record 320 may be stored in program address space. In the event of a crash, a core file (that stores the program address space) may be generated using any suitable technique. The core file preserves a copy of the memory state of the running program at the time of the crash (including the association record 320). In the illustrated example of FIG. 3, the register store manager 1 10 may move the content of the registers into corresponding memory locations within the core file. For example, a register store initiator 230 of the register store manager 1 1 0 of FIG. 3 may move the contents of copies of the registers 355a, 355b, 355c from the core file 370 to persistent memory locations 365a, 365b, 365c of the copy of the persistent memory 365 in the core register store core file 370. Accordingly, using any suitable recovery mechanism the system may resume operation using the core file 370 debugged by the register store manager 1 10 of FIG. 3.

[0033] In some examples, the register store manager 1 1 0 (e.g., serving as a debugger or recovery mechanism) may refer to the association record copy 325 of the core file, and return the content of the registers 355a, 355b, 355c in the core file register copy to the appropriate memory locations 360a, 360b, 360c in the persistent memory 360. Accordingly, following recovery by the register store manager 1 10, the consistent state of the program data of a program is preserved in persistent memory.

[0034] As an example discussion of the implementations herein, the following pseudocode in Table 1 may be executed to determine a max of N numbers:

int a [N] , i, max=0;

for (i=0, i<N; i++)

if (a [ i ] > max)

max+=a [ i ] ;

Table 1

in which the variables max and i are calculated and incremented in a register 1 1 5. Using a compiler optimization technique as shown in Table 2, the values of the variables max and i are not stored to a persistent memory location (e.g., a memory location in the persistent memory 160) in each iteration of the "for" loop; rather, registers corresponding to the variables max and i are updated within the loop. The variables max and i in persistent memory are then updated after the "for" loop is completed as shown in the following:

int a [N] , register_i, max, register_max=0 ; for (register_i=0 ; register_i<N; register_i++)

if (a [register i] > register max)

register_max += a [ register_i ] ; max = register_max

Table 2

Therefore, in the above examples, the values of the variables (if they are in registers) may be lost in the event of a failure during the calculation of the max. Storing the values of the variables max and i in persistent memory in each iteration may preserve the values, however, this technique degrades performance of the program by slowing down execution with more stores to the persistent memory.

[0035] The following example pseudocode in Table 3 may be used or executed (e.g., by the processor 120 of FIG. 1 ) to implement the register store manager 1 10 of FIG. 2 to preserve the variables max and i in accordance with examples herein: int a[N], i, register_i, max, register_max=0 ; STASH (register_max, Smax) ;

STASH (register_i, &i) ;

for (register_i=0 ; register_i<N; register_i++) if (a [register i] > register max)

register_max += a [ register_i ] ;

max = register_max;

STASH (register_max, 0) ;

STASH (register_i, 0) ;

Table 3

in which the STASH instructions cause the register store manager 1 10 to store register_max to memory address smax and register_i to memory address &i. Therefore, the registers register_max, register_i and memory locations smax, &i can be identified by the program analyzer 210 and associated with one another by the register association recorder 220 to enable the register store initiator 230 to store the content of the registers

register_max, register_i to the corresponding memory locations Smax, &i. The last two lines of the above pseudocode clear the instructions after max is calculated. [0036] Accordingly, in the event of a failure during calculation of max in the given examples above, the register store manager 1 10 of FIGS. 1 and/or 2 preserve the values of the variables max and i in the event of a failure in accordance with examples herein. Accordingly, upon recovery of a system, consistent data of the program of Table 3 is preserved. In this example, the find-max computation may be resumed at a preserved array index i , thus obviating the need to re-examine the contents of the array starting at element zero.

[0037] Flowcharts representative of example machine readable instructions for implementing the register store manager 1 10 of FIG. 2 is shown in FIGS. 4 and 5. In this example, the machine readable instructions comprise a program/process for execution by a processor such as the processor 120 shown in the example processor platform 100 discussed above in connection with FIG. 1 . The program(s)/process(es) may be embodied in executable instructions (e.g., software) stored on a tangible machine readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), a Blu-ray disk, or a memory associated with the processor 120, but the entirety of the program(s)/process(es) and/or parts thereof could alternatively be executed by a device other than the processor 120 and/or embodied in firmware or dedicated hardware. For example, coded instructions to implement the example processes of FIGS. 4 and 5 may be stored in any of the storage devices of FIG. 1 , including the registers 1 15, the cache 130, the volatile memory 1 50, the nonvolatile memory 160, the mass storage 190, etc. Furthermore, the example processes of FIGS. 4 and 5 may be executed by the processor 120 of FIG. 1 . Further, although the example program(s)/process(es) is/are described with reference to the flowcharts illustrated in FIGS. 4 and 5, many other methods of implementing the example register store manager 1 10 may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.

[0038] The example process 400 of FIG. 4 begins with an initiation of the code register store manager 1 10 (e.g., upon startup, upon instructions from a user, upon startup of a device implementing the register store manager 1 10 (e.g., the processor system 100), etc.). The example process 400 may be executed to preserve the content of the registers 1 1 5 in persistent memory (e.g., the volatile memory 1 50 and/or the non-volatile memory 160) in the event of a failure. At block 410 of FIG. 4, the program analyzer 21 0 analyzes a program to be executed to identify a memory location of persistent memory to which content of a register 1 15 is to be stored. The example register is used in the execution of the program. In some examples, at block 410, the program analyzer 21 0 may analyze source code to identify a performance critical variable (e.g., variables of inner loops) to be loaded into the register. Additionally or alternatively, the program analyzer 210 may analyze annotations accompanying the source code identifying the performance critical variables.

[0039] At block 420 of FIG. 4, the register association recorder 220 associates the register to the memory location by recording an association between the register and the memory location. For example, at block 420, the register association recorder 220 may record or provide the association to the register store initiator 230. In some examples, the register association recorder 230 may store the memory location in an unused register (e.g., a register made accessible by disabling simultaneous multithreading of the processor 120) and provide instructions to the register store initiator to retrieve corresponding memory locations for registers from the unused registers. At block 430, upon detection of a failure, the register store initiator 230 stores the content of the register to the memory location of the persistent memory. In some examples, the register store initiator 230 may detect (or receive a notification from the processor 120) that a failure has occurred or is imminent. After block 430, the example process ends.

[0040] The process 500 of FIG. 5 begins with an initiation of the code register store manager 1 1 0. The example process 500 may be executed to preserve a consistent state of a program after a failure using a core file and any suitable recovery mechanism. At block 610, the program analyzer 210 identifies an indication that a performance critical variable of a program is to be

preserved. For example, at block 61 0, the program analyzer 210 may detect instructions in the program and/or annotations (e.g., from a user, such as an application developer) in source code of the program. At block 520, the register association recorder 220 records an association between a register 1 15 used to store a value of the performance critical variable during execution of the program and a persistent memory location. The example persistent memory location may be a memory location in persistent memory (e.g., the volatile memory 150 and/or the non-volatile memory 160) that is to store the

performance critical variable due to execution of the program (e.g., either after an iteration of a loop or inner loop, after execution of the program, etc.).

[0041] At block 530, after a failure, the register store initiator 230 stores the value of the performance critical variable in the register to a memory location of a core file corresponding to the persistent memory location based on the association. For example, at block 530, the register store initiator 230 may access a core file that stores a copy of a state of the program. The register store initiator 230, at block 530 may then store the content of the register in the core file (i.e., the value of the performance critical variable at or near the time of the failure) to the persistent memory location of the core file. Accordingly, the core file may be used to preserve the consistent state of the data of the program upon recovery from the failure. In some examples, the core file may be used to return the program to the state of execution at the time of the failure using the examples herein. After block 530, the example process 500 ends.

[0042] As used herein, the term tangible machine readable storage medium is expressly defined to include any type of machine readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media. As used herein, "computer readable storage medium" and "machine readable storage medium" are used interchangeably. Additionally or alternatively, the example processes of FIGS. 4 and 5 may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term non- transitory machine readable medium is expressly defined to include any type of machine readable storage device and/or storage disk and to exclude

propagating signals and to exclude transmission media. As used herein, when the phrase "at least" is used as the transition term in a preamble of a claim, it is open-ended in the same manner as the term "comprising" is open ended.

[0043] As used herein the term "a" or "an" may mean "at least one," and therefore, "a" or "an" do not necessarily limit a particular element to a single element when used to describe the element. As used herein, when the term "or" is used in a series, it is not, unless otherwise indicated, considered an "exclusive or."

[0044] From the foregoing, it will be appreciated that the above disclosed methods, apparatus and articles of manufacture involve storing registers in the event of a system failure. In examples herein, an association is made between a register and a location in memory based on an execution of a process. Upon detection of the failure, the content of the register is stored to the memory location based on the association. Accordingly, using examples herein, upon recovery of a system from a failure, the system may include a consistent state of data (e.g., application data) to enable the system to recover without further complications (e.g., due to an inconsistent state of application data or program data). Examples herein enable optimization techniques (e.g., storing data after completion of a loop, rather than after each iteration of the loop), while ensuring preservation of the data in registers during execution without degrading execution performance.

[0045] Although certain example methods, apparatus and articles of manufacture have been disclosed herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus and articles of manufacture fairly falling within the scope of the claims of this patent.

Claims

CLAIMS What is claimed is:

1 . A method comprising: analyzing a program to identify a memory location of a persistent memory to which content of a register is to be stored, the register used in the execution of the process; and

recording an association between the register and the memory location; and

upon detection of a failure during the execution, storing the content of the register to the memory location based on the association.

2. The method as defined in claim 1 , further comprising recording the association as an instruction for a processor to store the content of the register in the event of a failure.

3. The method as defined in claim 1 , further comprising: disabling simultaneous multithreading in a processor executing the program to enable access to an unused register of the processor; and

recording the association by storing the memory location in the unused register of the processor.

4. The method as defined in claim 1 , wherein the content of the register comprise a performance critical variable of an inner loop in the process.

5. The method as defined in claim 1 , wherein analyzing the program comprises analyzing source code of the program prior to execution of the program to identify the memory location.

6. The method as defined in claim 5, further comprising identifying the memory location from annotations of the source code.

7. An apparatus comprising:

a program analyzer to:

identify performance critical variables in a process, the performance critical variables to be stored in registers of a processor, and

identify memory locations in a persistent memory associated with the respective performance critical variables, the memory locations to respectively store the performance critical variables after an iteration of a process;

a register association recorder to record associations between the registers and the corresponding memory locations; and

a register store initiator to store the performance critical variables from the registers to the respective memory location in the event of a failure.

8. The apparatus of claim 7, wherein the register store initiator is further to detect the failure.

9. The apparatus of claim 7, wherein the program analyzer identifies the performance critical variables and memory locations from annotations in a source code of the program.

10. The apparatus of claim 7, wherein the register association recorder is to record the association between the registers and the corresponding memory location by storing the memory location in unused registers of the processor.

1 1 . The apparatus of claim 7, wherein the failure comprises a software failure occurring in a system of the processor.

12. A non-transitory machine readable medium comprising instructions that, when executed, cause a machine to at least:

identify an indication that a performance critical variable of a program is to be preserved;

record an association between a register that is to store a value of the performance critical variable during execution of the program and a persistent memory location, the persistent memory location to store the value of the performance critical variable due to the execution of the program; and

after a failure, store the value of the performance critical variable in the register to a memory location of a core file based on the association, the memory location of the core file corresponding to the persistent memory location.

13. The non-transitory machine readable medium of claim 12, wherein the instructions, when executed, further cause the machine to:

identify the register used in the program and the persistent memory location from annotations accompanying a source code of the process.

14. The non-transitory machine readable medium of claim 12, wherein the instructions, when executed, further cause the machine to:

record the association in a the persistent memory.

15. The non-transitory machine readable medium of claim 12, wherein the instructions, when executed, further cause the machine to:

store the content of the register to a memory location of the core file in response to recovering the program from the failure.