Code-Origin Tracing With Alternate Paths for Low-Overhead Debugging

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing tracing and instrumentation methods in computing systems are computationally expensive and resource-intensive, leading to performance degradation and making it difficult to match traces to the responsible code segments for debugging, thus diminishing their usefulness.

Innovation Solution

Implementing a code origin for spans technique that tags spans with metadata for precise code location identification, and employing duplicity optimization by creating a lower overhead alternate execution path for instrumented functions to reduce unnecessary computations.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If automated instrumentation by tracing libraries is used to generate spans and traces, then program execution tracking capability is improved, but computational overhead and resource consumption increase

Engineering Contradiction:

Improveprogram execution tracking capabilityVSAvoidcomputational overhead

Core Design Contradiction:

Measurement precisionVSUse of energy by moving object

Solution Approach 1:

The system performs preliminary actions by creating duplicate execution call paths and retargeting code to call variations of instrumented functions before actual execution occurs. This allows the system to pre-establish alternative execution paths that can be activated based on runtime conditions, reducing the need for full instrumentation on every code path.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The system applies local quality by implementing instrumented functions only at specific locations of interest in the code rather than uniformly across all code. By creating duplicates and retargeting selectively, the system concentrates instrumentation resources on critical code segments while leaving other areas with reduced or no instrumentation, thereby reducing overall computational overhead while maintaining tracking capability where needed.

Inventive Principle:

Principle #3Local quality

2Reliability

If instrumented functions are called every time the same code is executed, then complete program monitoring is achieved, but performance degradation occurs

Engineering Contradiction:

Improveprogram monitoring completenessVSAvoidprogram execution performance

Core Design Contradiction:

ReliabilityVSProductivity

Solution Approach 1:

The system implements dynamics by making the execution path adaptive based on runtime conditions. Duplicate execution call paths are created with retargeted code that can dynamically select between calling the original instrumented function or a variation with different operations. This dynamic switching allows the system to maintain monitoring completeness when needed while optimizing performance during repetitive executions.

Inventive Principle:

Principle #15Dynamics

Solution Approach 2:

The system applies copying by creating duplicate execution call paths that replicate the original code flow. These duplicates include retargeted code that calls variations of instrumented functions. The duplicate paths serve as alternative execution routes that can be activated based on whether monitoring is needed, thus preserving monitoring capability while reducing overhead during normal operation.

Inventive Principle:

Principle #26Copying

3Use of energy by moving object

If traces are generated without runtime information about the user's method, then trace generation overhead is reduced, but trace usefulness for debugging diminishes

Engineering Contradiction:

Improvetrace generation overheadVSAvoidcode location information

Core Design Contradiction:

Use of energy by moving objectVSLoss of information

Solution Approach 1:

The system extracts code location information from the execution call path at the point where the instrumented function would be called. By creating duplicate paths and retargeting code, the system can extract necessary metadata (such as code origin information) selectively without requiring full instrumentation of all code paths. This extraction approach obtains the essential debugging information while minimizing the overhead of comprehensive tracing.

Inventive Principle:

Principle #2Taking out (Extraction)

Data Source

PatentUS20260072809A1Code origin and runtime duplicity optimization

Publication Date: 2026.03.12 DATADOG INC

AI summary

The technology relates to program monitoring, which can involve using metadata as part of span information evaluated by the system in order to identify a location of interest in user (source) code. This can be used to pinpoint the exact code location that participated in a trace being debugged. The span information may be enriched with the code location from which it originated. The technology is also able to avoid unnecessary execution of instrumented functions by creating an alternate code execution path. This alternate path gets the code path to a variation of the instrumented function, in which the variation has a different set of operations. Upon determination that an execution call path has been previously followed, the alternate path would be automatically called instead of the path with the original instrumented function.