Dual-Mode Debugger Native to Interpreted Transition

Solution Overview

Problem

Debugging of computationally intensive programs is inefficient due to the slower response time of interpreters compared to native code debuggers, and existing solutions do not effectively combine the speed of native mode debugging with the simplicity of interpreted mode debugging.

Innovation Solution

A dual-mode debugger that transitions from native mode to interpreted mode at defined bailout points, allowing for efficient debugging operations by saving variable values to the stack and using an interpreter to resume debugging in interpreted mode, enabling execution control and variable inspection.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Speed

If debugging is performed in native mode, then response time is faster, but implementation complexity is higher

Engineering Contradiction:

Improveresponse timeVSAvoidimplementation complexity

Core Design Contradiction:

SpeedVSDevice complexity

Solution Approach 1:

The debugging process is segmented into two distinct modes: native mode for fast execution and interpreted mode for simple debugging operations. The system dynamically switches between these modes based on the debugging needs, allowing fast native code execution during normal operation and simple interpreted mode when debugging is required, thus resolving the contradiction between speed and complexity

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The debugger implements dynamic mode switching capability, transitioning from static native mode execution to dynamic interpreted mode execution based on bailout conditions. This dynamic adaptation allows the system to optimize performance during normal execution while providing simplicity during debugging operations, resolving the trade-off between response time and implementation complexity

Inventive Principle:

Principle #15Dynamics

2Device complexity

If debugging is performed in interpreted mode, then implementation complexity is lower, but response time is slower

Engineering Contradiction:

Improveimplementation complexityVSAvoidresponse time

Core Design Contradiction:

Device complexityVSSpeed

Solution Approach 1:

The debugging process is segmented into two distinct modes: native mode for fast execution and interpreted mode for simple debugging operations. The system dynamically switches between these modes based on the debugging needs, allowing fast native code execution during normal operation and simple interpreted mode when debugging is required, thus resolving the contradiction between speed and complexity

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The system changes the execution parameter dynamically by switching between native mode and interpreted mode based on bailout conditions. This parameter change allows the system to optimize for speed during normal execution and for simplicity during debugging operations, resolving the trade-off between response time and implementation complexity

Inventive Principle:

Principle #35Parameter changes

3Ease of operation

If full-scale interpretation is used for debugging, then simplicity is achieved, but performance penalty increases

Engineering Contradiction:

ImprovesimplicityVSAvoidperformance

Core Design Contradiction:

Ease of operationVSProductivity

Solution Approach 1:

The debugging process is segmented into two distinct modes: native mode for fast execution and interpreted mode for simple debugging operations. The system dynamically switches between these modes based on the debugging needs, allowing fast native code execution during normal operation and simple interpreted mode when debugging is required, thus resolving the contradiction between speed and complexity

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

Instead of applying full-scale interpretation to the entire program, the system applies interpretation only partially at specific bailout points where debugging is needed. This partial action approach maintains performance for most of the code while providing simplicity for debugging operations, resolving the contradiction between ease of operation and productivity

Inventive Principle:

Principle #16Partial or excessive action

Data Source

PatentEP3005121B1Debugging native code by transitioning from execution in native mode to execution in interpreted mode

Publication Date: 2019.03.06 MICROSOFT TECHNOLOGY LICENSING LLC

Figure 1a
Figure 1b
Figure 1c

AI summary

A dual-mode debugger can debug native code or interpreted code. Transitioning between modes can be triggered by defined bailout conditions. A program can be debugged by attaching a debugger and compiling the program into native code under the debugger. At defined points in the program, debugging can transition from native mode to interpreted mode. Debugging the native code can stop, current state can be captured, and an interpreter can be instantiated. An interpreter stack can be created and can be populated with the captured current state. Debugging operations which involve execution control: pausing execution, continuing execution, stepping into, out of or over a section of code and so on, can occur in interpreted mode, which is typically easier to implement. Debugging operations which involve inspection and modification of variables can occur in native mode.