Constrained Execution Regions Hoist Runtime Failure Points

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Code authors face challenges in ensuring deterministic execution of authored code due to reliance on runtime environment routines or sub-routines, which can lead to undefined or non-deterministic states caused by runtime-induced resource failures such as thread abort, out-of-memory, or stack overflow conditions.

Innovation Solution

The implementation of constrained execution regions (CERs) identifies potential failure points associated with the code and 'hoists' them to a point external to the code, ensuring that any runtime environment-induced failures are pre-executed or managed before executing the critical code regions, thereby preventing interruptions or corruption.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If runtime environment routines are used to support code execution, then code can execute in a runtime environment with resource management, but code execution becomes non-deterministic due to runtime-induced failures

Engineering Contradiction:

Improveruntime environment supportVSAvoiddeterministic execution

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

The code is divided into constrained execution regions (CERs) that are isolated from runtime environment interference. By segmenting the code into protected regions, the patent enables deterministic execution within those regions while still allowing runtime environment support outside the CERs. The CER boundaries create a segmentation between deterministic and non-deterministic execution contexts.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The patent extracts and removes runtime environment routines from within the constrained execution regions. By taking out the runtime support code from the critical execution paths, the patent eliminates the source of non-deterministic behavior while preserving the ability to access runtime environment services when exiting the CERs. This extraction ensures that only essential, deterministic code remains within the protected regions.

Inventive Principle:

Principle #2Taking out (Extraction)

2Reliability

If code is protected from runtime environment failures, then deterministic execution is achieved, but complexity increases due to constrained execution regions

Engineering Contradiction:

Improvedeterministic executionVSAvoidconstrained execution region management

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The patent applies preliminary action by establishing constrained execution region boundaries and failure point hoisting mechanisms before code execution begins. The CERs are pre-defined and compiled into the code structure, and potential failure points are identified and hoisted to external locations in advance. This preliminary setup eliminates the need for complex runtime protection mechanisms during execution, reducing operational complexity while maintaining deterministic behavior.

Inventive Principle:

Principle #10Preliminary action

3Reliability

If failure points are hoisted external to code regions, then deterministic execution is ensured, but execution time increases due to additional management overhead

Engineering Contradiction:

Improveexecution integrityVSAvoidexecution time

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

The patent implements skipping by allowing the execution engine to rapidly traverse through constrained execution regions without invoking runtime environment checks or handlers within those regions. By hoisting failure points external to the CERs, the patent enables the execution to skip over potential failure zones entirely during normal operation, resuming runtime environment interaction only when exiting the protected regions. This rushing through mechanism minimizes the time spent on failure management overhead while maintaining execution integrity.

Inventive Principle:

Principle #21Skipping (Rushing through)

Data Source

PatentUS7685574B2Constrained execution regions

Publication Date: 2010.03.23 MICROSOFT TECHNOLOGY LICENSING LLC

AI summary

Authored code may include a notification that no tolerance for failure or corruption is expected for an identified sub-set of the code. Any potential failure point, which may be induced by a runtime environment routine or sub-routine, that is associated with the identified sub-set of code may then be identified and hoisted to a point apart from the identified sub-set of code.