Add full-trace creation benchmark; production-shape the front-half span benchmarks

[dougqh]

What

Adds a full-trace front-half JMH benchmark and production-shapes the existing single-span benchmark's tracer config, so tracer core-optimization work has a reference to key gains — and regressions — off of.

New: TraceCreationBenchmark

One op = one complete trace (local-root span + children created under an active root scope, so it exercises real parent-context propagation and trace-tag inheritance a single-span bench can't reach). Two arms:

• webRequestTrace — fixed realistic request: server root + JDBC-client + HTTP-client + internal child (the headline shape).
• fanoutTrace — @Param childCount={1,5,10}, the scaling axis: per-trace cost as span count grows exposes how per-span optimizations compound.

Isolated via the no-op DropWriter (front-half only, no serialization/agent I/O). Historical-results table is a (TBD) stub to fill from a committed baseline run.

Changed: SpanCreationBenchmark

Production-shape the fork config (dd.service/dd.env/dd.version + 6 global dd.tags) so mergedTracerTags — the trace-level bundle every span merges — is realistically sized. A bare CoreTracer.builder().build() leaves it near-empty, hiding any win that scales with tags-per-span. The existing 1.53→1.64 historical table is flagged as a pre-config (bare-tracer) baseline, not comparable going forward — re-baseline rather than stitching onto that curve.

Why

These are the old-API reference / regression-guard tier: drift-stable, deliberately separate from any new-API showcase benchmarks, so year-over-year comparisons hold and later core changes surface as a delta. Read gc.alloc.rate.norm (B/op, deterministic) as the primary signal; throughput is directional-only.

Notes

• Old-API only by design (no SpanPrototype/new-API arms — those belong in a separate showcase class).
• ScopeLifecycleBenchmark deliberately left unchanged: its spans are built in @Setup, so the fork config never reaches its measured activate/close paths.
• Compiles clean (:dd-trace-core:jmhClasses) and is google-java-format clean.

🤖 Generated with Claude Code

[dougqh]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. 🎉

Reviewed commit: 01ae43b9a0

ℹ️ 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".

[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.98 s	13.96 s	[-0.6%; +0.9%] (no difference)
startup:insecure-bank:tracing:Agent	12.92 s	13.03 s	[-1.7%; +0.0%] (no difference)
startup:petclinic:appsec:Agent	16.22 s	16.68 s	[-7.1%; +1.6%] (no difference)
startup:petclinic:iast:Agent	16.93 s	16.87 s	[-0.6%; +1.3%] (no difference)
startup:petclinic:profiling:Agent	16.06 s	16.82 s	[-8.9%; -0.2%] (maybe better)
startup:petclinic:sca:Agent	16.84 s	16.63 s	[+0.3%; +2.2%] (maybe worse)
startup:petclinic:tracing:Agent	16.07 s	15.71 s	[-2.1%; +6.6%] (no difference)

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