[dougqh]

What Does This Do

Sampling decisions on a trace's propagation tags now publish with a compare-and-set instead of a per-trace lock.

• Before: every PTags allocated a lock Object and took its monitor for every decision. The sampling state is already an immutable snapshot behind one volatile field, so the lock only serialized computing the next snapshot.
• After: each decision reads the current state, computes the next one, and compare-and-sets it, retrying if another decision got there first. A decision that changes nothing doesn't write at all.
  • The deferred ot check (Defer parsing the inherited OpenTelemetry tracestate member #13028) uses the same pattern: it returns the next state instead of installing it.
  • canChangeDecisionMaker becomes volatile. It is only ever cleared, and it's cleared before the decision maker is locked, so a racing decision either lands first and is overwritten, or retries and sees it cleared.
  • setOtelTraceState had no callers on this stack and is removed.

Motivation

• TraceSegment work (APMLP-2049). Phase 3's immutable decision holder will publish with this same CAS.
• Removes one lock Object per trace.
• Avoids monitor costs on JDK 15+, where biased locking is gone. Most orgs run 17+.

Testing

• ConcurrentSamplingDecisionTest races two decisions per trial (2000 trials) whose result is the same in either order:

  • a manual keep against a sampler decision;
  • locking the decision maker against a decision with a different decision maker.

• Mutation checks:

  Mutation	Result
  Sampler decision writes without retrying	caught 3/3
  Decision-maker flag cleared after the swap	caught 2/3 (the window is a few instructions)
  forceKeep writes without retrying	can't be observed: forceKeep overwrites the whole state anyway

• Corpus and suites:

  • CompoundExtractionGoldenTest passes.
  • Full corpus: 0 of 10150 cases differ.
  • dd-trace-core suite: only the known failures (Docker-only TracerConnectionReliabilityTest, order-dependent PendingTraceBufferTest flare dump).

Additional Notes

• Ported from dougqh/ptags-sampling-state-cas (written against master) onto this stack. That branch can be retired.
• Throughput not measured yet; it's in the stack's interleaved benchmark run.
• Stacked on Propagate trace source and debug tags set on any span #13039.

🤖 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	13.99 s	13.96 s	[-0.4%; +1.0%] (no difference)
startup:insecure-bank:tracing:Agent	12.90 s	13.05 s	[-2.2%; -0.2%] (maybe better)
startup:petclinic:appsec:Agent	17.01 s	16.34 s	[+0.0%; +8.3%] (maybe worse)
startup:petclinic:iast:Agent	16.85 s	16.99 s	[-1.6%; -0.0%] (maybe better)
startup:petclinic:profiling:Agent	16.30 s	16.72 s	[-7.0%; +1.9%] (no difference)
startup:petclinic:sca:Agent	16.64 s	16.88 s	[-5.6%; +2.8%] (no difference)
startup:petclinic:tracing:Agent	16.07 s	16.05 s	[-0.8%; +1.1%] (no difference)

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