refactor(trace): generic byte code injection for Python 3.10, 3.11 (AIDM-380)

[labbati]

The current code we have in ddtrace/internal/coverage to inject invocation of callback presents the following limitations:

• very specific to coverage reporting: it hard codes the fact that every line should be traced.
• drastically different implementations for 3.10, 3.11 that makes. The team is leaning toward refactoring all to the 3.10 approach which has been measured to be more performant (past work, out of scope for this PR).
• lack (or at least not evident) of testing for a tricky scenario for injection which is try/except/finally blocks, where it is extremely important to not mess around with the line table and the exception table (py 3.11) that are used to determine which code lines are executed in case of exceptions.
• for py3.11, some line table adjustments weren't working for specific patterns (added in tests)

At the same time, we need to capability to inject at some desired code location the invocation of a callback for a new functionality that we are currently adding: automatic reporting of handled exceptions. The only thing that really changes, in this case, is the selection of the injection points.

This PR does (for py 3.10 and 3.11):

• move the business logic for injection, as a generic abstraction, from ddtrace.internal.coverage to a more generic ddtrace.internal.bytecode_injection.
• add extensive testing specific to byte code manipulation (including opcode, argument, jump, exception verification).
• replace coverage's 3.10 usage of line injection with this more generic version.
• fixes a few inaccuracies with line calculation under specific conditions (e.g. in some cases when there are try/except blocks).

Checklist

• PR author has checked that all the criteria below are met
• The PR description includes an overview of the change
• The PR description articulates the motivation for the change
• The change includes tests OR the PR description describes a testing strategy
• The PR description notes risks associated with the change, if any
• Newly-added code is easy to change
• The change follows the library release note guidelines
• The change includes or references documentation updates if necessary
• Backport labels are set (if applicable)

Reviewer Checklist

• Reviewer has checked that all the criteria below are met
• Title is accurate
• All changes are related to the pull request's stated goal
• Avoids breaking API changes
• Testing strategy adequately addresses listed risks
• Newly-added code is easy to change
• Release note makes sense to a user of the library
• If necessary, author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment
• Backport labels are set in a manner that is consistent with the release branch maintenance policy

[P403n1x87]

Is the more generic inject_hook not good enough in terms of implementation/performance for the intended use? I'm asking to check whether we can avoid extra complexity in the coverage code, which is quite an ad-hoc implementation.

[pr-commenter]

Benchmarks

Benchmark execution time: 2025-01-24 09:18:52

Comparing candidate commit 1f84078 in PR branch labbati/generic-bytecode-injection with baseline commit fce6d75 in branch main.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 394 metrics, 2 unstable metrics.

[github-actions]

CODEOWNERS have been resolved as:

ddtrace/internal/bytecode_injection/__init__.py                         @DataDog/apm-core-python
ddtrace/internal/bytecode_injection/core.py                             @DataDog/apm-core-python
tests/internal/bytecode_injection/__init__.py                           @DataDog/apm-core-python
tests/internal/bytecode_injection/test_core.py                          @DataDog/apm-core-python
ddtrace/internal/coverage/instrumentation_py3_10.py                     @DataDog/apm-core-python @datadog/ci-app-libraries

[labbati]

Is the more generic inject_hook not good enough in terms of implementation/performance for the intended use? I'm asking to check whether we can avoid extra complexity in the coverage code, which is quite an ad-hoc implementation.

On a large number of modules to be instrumented, using bytecode (used by inject_hook) it was causing a x10 startup overhead (200ms --> 2s). By profiling, I tracked it down to the overhead added by bytecode.

Following up in DM with more details.