Partial Program Execution Recording for Replay Across OS Environments

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Software failures in production environments are difficult to reproduce due to differences between production and development systems, and existing record and replay techniques are inadequate in identifying the root cause of failures, often requiring identical environments and resulting in high data storage overhead.

Innovation Solution

A method for partial recording of program execution, capturing processor context, system call results, and memory pages for each thread, allowing reconstruction of the execution state in a different operating system environment, decoupling the program from installed code binaries and underlying OS, and minimizing data storage requirements.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If conventional checkpointing techniques capture the complete state of an application for replay, then the replay can be accurate and complete, but the amount of recorded data becomes relatively large increasing data storage overhead

Engineering Contradiction:

Improvereplay accuracyVSAvoiddata storage overhead

Core Design Contradiction:

ReliabilityVSQuantity of substance

Solution Approach 1:

The patent extracts only the essential elements needed for accurate replay: processor context, system call results, and memory pages. By taking out only these critical components rather than capturing the complete application state, the system achieves accurate replay with significantly reduced data storage overhead.

Inventive Principle:

Principle #2Taking out (Extraction)

Solution Approach 2:

The patent segments the application state into distinct components: processor context for each thread, system call results, and memory pages. This segmentation allows selective recording of only the necessary parts for replay, avoiding the need to store the entire application state and reducing data storage requirements.

Inventive Principle:

Principle #1Segmentation

2Reliability

If record and replay tools represent the aftermath of failure, then the failure state is captured, but the steps that precede the failure cannot be identified making root cause analysis difficult

Engineering Contradiction:

Improvefailure state captureVSAvoidroot cause identification

Core Design Contradiction:

ReliabilityVSDifficulty of detecting and measuring

Solution Approach 1:

The patent records processor context, system calls, and memory pages at multiple checkpoints during normal execution before the failure occurs. This preliminary recording of execution steps enables backward analysis to identify the sequence of events leading to failure, making root cause detection possible while maintaining accurate failure state capture.

Inventive Principle:

Principle #10Preliminary action

3Adaptability or versatility

If the recorded log is replayed in a programmer's environment with different configuration, then the environment flexibility is improved, but the execution may diverge due to discrepancies in installed base and library versions

Engineering Contradiction:

Improveenvironment flexibilityVSAvoidexecution consistency

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

The patent uses recorded system call results as intermediaries between the original execution and the replay. Instead of directly executing the application in the new environment which would cause divergence, the system call results serve as a mediator that preserves the original execution behavior while allowing the application to run in different environments.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent copies the essential execution state information (processor context, system call results, memory pages) from the original environment to the replay environment. This copying approach enables the application to be replayed in different configurations without requiring exact copies of all libraries and system components, thus achieving both flexibility and consistency.

Inventive Principle:

Principle #26Copying

4Device complexity

If conventional techniques isolate and replay system calls, then the replay process is simplified, but the model becomes inadequate when libraries are missing or incompatible causing replay failure

Engineering Contradiction:

Improvereplay process simplicityVSAvoidreplay success rate

Core Design Contradiction:

Device complexityVSReliability

Solution Approach 1:

The patent merges multiple recording components (processor context capture, system call tracking, memory page recording) into a unified partial checkpointing system. This combined approach provides comprehensive replay capability that handles missing or incompatible libraries more effectively than isolated system call replay, improving replay success rate while maintaining reasonable complexity.

Inventive Principle:

Principle #5Merging (Combining)

Data Source

PatentUS9514029B2Partial recording of a computer program execution for replay

Publication Date: 2016.12.06 INTERNATIONAL BUSINESS MACHINE CORPORATION

AI summary

A method, system and program product for recording a program execution comprising recording processor context for each thread of the program, results of system calls by the program, and memory pages accessed by the program during an execution interval in a checkpoint file. Processor context includes register contents and descriptor entries in a segment descriptor table of the operating system. System calls are recorded for each program thread, tracked by an extension to the operating system kernel and include returned call parameter data. Accessed memory pages are recorded for each program process and include data, libraries and code pages. The program address space, processor context, and program threads are reconstructed from checkpoint data for replaying the program execution in a different operating system environment.