Thread SpanPrototype through span construction (parked until dense store)

[dougqh]

⚠️ Retired — superseded by #11894. The clean SpanPrototype API (single-commit, frozen-TagMap builder) lives in #11894. This construction lineage diverged from it and predates the frozen-copy / plan-based apply design; the span-construction wiring will be rebuilt fresh on top of #11894.

---

Draft — PARKED. Stacked on #11828. Do not merge before the dense store.

Increment 2a of the SpanPrototype work: threads a spanPrototype through CoreSpanBuilder (mirroring tagLedger — field, startImpl, both startSpan overloads, buildSpan, buildSpanContext, reset) and applies it at buildSpanContext right after defaultSpanTags (before the per-span ledger, so per-span tags override the prototype's constants). Adds CoreSpanBuilder.withSpanPrototype(...).

Why parked

The construction-seed's payoff is a copy-down, which only beats per-span N-set when the copy is cheap. On today's bucketed OptimizedTagMap it isn't — the per-mechanism micro (on #11828) showed copy() of a 4-entry map losing to 4 set(cachedEntry) (≈295M/243M vs 417M ops/s), with identical 104 B/op across all arms. The win is dense-store-gated: a contiguous positional layout makes copy-down an arraycopy, and drops the alloc.

So this lands with/after the dense store, where touching the critical span-creation path arrives with a demonstrable win rather than a flat change. Because SpanPrototype rides the existing TagMap.copy/setAllTags API (not dense internals), the wiring auto-cashes-in when the dense store lands — no surface change, no penalty to holding.

Safety

Additive: SpanPrototype.NONE default at every threaded site → the applied branch is skipped and every existing span-creation path is byte-for-byte unchanged. CoreSpanBuilderTest (25) + CoreTracerTest2 (15) green.

Remaining (when unparked)

• Public startSpan/buildSpan(SpanPrototype, …) entry points (additive overloads, delegate existing → NONE).
• The 4-arm SpanStartBenchmark ({startSpan, buildSpan} × {old afterStart, new prototype}) to characterize the dispatch-level delta on the dense store.

🤖 Generated with Claude Code

[datadog-prod-us1-5]

🎯 Code Coverage (details)
• Patch Coverage: 20.00%
• Overall Coverage: 54.93% (-0.01%)

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

[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	13.99 s	13.98 s	[-0.6%; +0.6%] (no difference)
startup:insecure-bank:tracing:Agent	12.94 s	13.06 s	[-1.7%; -0.0%] (maybe better)
startup:petclinic:appsec:Agent	16.21 s	16.62 s	[-7.9%; +3.0%] (unstable)
startup:petclinic:iast:Agent	16.65 s	16.89 s	[-2.2%; -0.6%] (maybe better)
startup:petclinic:profiling:Agent	16.89 s	16.84 s	[-0.9%; +1.4%] (no difference)
startup:petclinic:sca:Agent	16.95 s	16.08 s	[+1.1%; +9.7%] (significantly worse)
startup:petclinic:tracing:Agent	16.06 s	16.23 s	[-1.9%; -0.3%] (maybe better)

Commit: a1cd0c41 · 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.

[dougqh]

Retiring in favor of the clean SpanPrototype API in #11894 (single-commit, frozen-TagMap builder). This construction lineage diverged from #11894 and predates the frozen-copy / plan-based apply design; the span-construction wiring will be rebuilt fresh on top of #11894.

From Claude