Wire mergedTracerTags as a read-through parent at span build (level-split) (phase 1a)

[dougqh]

What Does This Do

Splits trace-level tags & span-level tags into two separate TagMap-s
To maintain full semantic compatibility, this is done via the read-through parent capability introduced in #11789.

Motivation

Reduces some allocation by avoiding the cloning of the BucketGroup collision chain
Reduces span creation time by replacing O(n) map-walk with O(1) referencing of parent TagMap

Additional Notes

Stacked on #11789 (TagMap read-through mechanism) — review that first.

Level-split phase 1: the wiring. Attaches mergedTracerTags as a read-through parent at span build (gated on !mergedTracerTagsNeedsIntercept) instead of copying it into every span's storage. This is the change that actually activates read-through — #11789 alone is inert (parent == null).

Commits: config-version handling out of the trace-level bundle, the read-through flip (DDSpanContext.parentTags / CoreTracer copy-vs-share gate), and a TagMapReadThroughBenchmark.

Draft — description to be refined; posting now so review can start this week ahead of the release cut.

🤖 Generated with Claude Code

[dd-octo-sts]

🟢 Java Benchmark SLOs — All performance SLOs passed

Suite	Status
Startup	🟢 pass

SLO thresholds are defined here based on automatically generated metrics. A warning is raised when results are within 5% of the threshold.

PR vs. master results

Scenario	Candidate	master	Δ (95% CI of mean)
startup:insecure-bank:iast:Agent	14.02 s	13.94 s	[-0.4%; +1.4%] (no difference)
startup:insecure-bank:tracing:Agent	12.96 s	13.02 s	[-1.2%; +0.3%] (no difference)
startup:petclinic:appsec:Agent	16.90 s	16.73 s	[+0.1%; +1.9%] (maybe worse)
startup:petclinic:iast:Agent	16.83 s	16.99 s	[-1.6%; -0.1%] (maybe better)
startup:petclinic:profiling:Agent	16.54 s	16.71 s	[-2.4%; +0.4%] (no difference)
startup:petclinic:sca:Agent	16.94 s	16.88 s	[-0.8%; +1.4%] (no difference)
startup:petclinic:tracing:Agent	16.01 s	16.14 s	[-1.8%; +0.3%] (no difference)

Commit: 170eedb1 · CI Pipeline · Benchmarking Platform UI

---

Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion.

[datadog-datadog-prod-us1-2]

🎯 Code Coverage (details)
• Patch Coverage: 61.54%
• Overall Coverage: 57.31% (-0.00%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 170eedb | Docs | Datadog PR Page | Give us feedback!}

[dougqh]

Directional span-creation benchmark: master vs this branch

Grafted SpanCreationBenchmark (from #11915) onto both master and this branch and ran a directional comparison with a realistic trace-level bundle. Not committed to the branch — a one-off directional check.

Config: -f 2 -wi 3 -i 3 -w 5 -r 5 -prof gc, @Threads(8), JDK 17, quiet box. Trace-level bundle via -jvmArgsAppend "-Ddd.env=bench -Ddd.version=1.0.0 -Ddd.tags=team:apm,tier:web,region:us1,shard:7,build:1234" (7 non-interceptable tags → a non-empty mergedTracerTags for read-through to fall through to). Alloc = gc.alloc.rate.norm.

method	master B/op	branch B/op	Δ	Δ%
bareStartSpan	52,511	52,457	−54	−0.10%
bareBuildSpan	52,514	52,447	−67	−0.13%
webServerSpan	62,871	62,872	+1	~0%
webServerSpanViaBuilder	69,543	69,484	−59	−0.08%
jdbcClientSpan	64,508	64,356	−153	−0.24%

Throughput deltas were all within noise (≤1.6%, no trend) — directional only, not quoted.

Read: the deltas are small but real — a consistent ~50–150 B/op reduction (the mergedTracerTags bucket structure read-through shares instead of copying), visible even on bare spans since the bundle applies to every span. But it's <0.25% of total span-creation alloc, which is dominated by a ~52–69 KB/op baseline (span/context/PendingTrace object graph). So this benchmark confirms read-through does what it should but is the wrong lens for its alloc win — that shows in the isolated TagMapReadThroughBenchmark (~300–600 B/op, −13% to −48% by bundle size).

Consistent with the settled framing: read-through is structural groundwork (dense-store enabler), not a standalone span-creation alloc headline.

From Claude: directional check requested during the fold/read-through rebase; grafted benches, not part of the branch diff.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ea094ce0bc

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[datadog-datadog-prod-us1-2]

More details

54 adversarial synthetic scenarios — simulating the full CoreTracer.buildSpan() wiring from the PR across 8 core behavioral equivalences and 5 edge cases — all passed. The read-through TagMap path is observationally identical to the old copy-down path for every tested scenario: trace-tag visibility, coreTags/contextualTags precedence override, builder-ledger tombstoning, multi-span parent isolation across config updates, and the version-exclusion change that prevents tombstone allocation on the shared frozen parent.

Was this helpful? React 👍 or 👎

_{📊 Validated against 54 scenarios · Open Bits AI session}

_{🤖 Datadog Autotest · Commit ea094ce · What is Autotest? · Any feedback? Reach out in #autotest}