[dougqh]

What Does This Do

Introduces TagStore, a span's tags as stored, and runs the eager tag post-processors against it instead of a TagMap.

• TagStore has load, loadString and store, each by name or by known tag id, plus store(EntryReader). Loads and stores go straight to storage, with no interception or interpretation, as Map was to TagMap. A null value removes the tag, and a null entry is a no-op. Thread safety is left to each implementation.
• Known tags by id. A known tag's KnownTags id and its name address the same tag. The id skips classifying the name on every call, and after Have the span own its tag stores directly (dense store - part 7) #13003 it's a direct lookup in the span's id store. Custom tags have no id.
• Its own verbs. load/store are distinct from TagMap's get/set and the span's intercepted getTag/setTag. One type can offer the raw and the intercepted operations without a name clash, and a call site's verb says which one it means.
• DDSpanContext implements TagStore, but a span isn't conceptually one. The store is the storage beneath the span. The span implements it only so post-processing can be handed that storage without allocating: a wrapper would be free only if escape analysis removed it, and the processor chain's dispatch loop prevents that. Its methods are unsynchronized, because callers already hold the span's tag lock, as earlyProcessTags does.
• TagMap implements it too, through its own get and set, so standalone maps and tests can be passed directly.
• The eager processors switch to EagerTagsPostProcessor, which takes a TagStore. They are PeerServiceCalculator, InternalTagsAdder and HttpEndpointPostProcessor, chained by EagerPostProcessorChain. NamingSchema.ForPeerService and EndpointResolver take TagStore too.
• They address their tags by id. Every tag they touch is a known tag. The peer service precursor lists stay names, since they include tags outside the registry, such as hazelcast.instance.
• OtelHttpSemantics.urlOrPath(TagStore). Master's OpenTelemetry HTTP semantics (Emit OpenTelemetry semantic conventions on HTTP spans #12765) made HttpEndpointPostProcessor read the URL through urlOrPath, falling back to url.path. The processor now gets a TagStore, so urlOrPath gains an overload that reads by id with the same fallback.
• Why TagStore, not SpanStorage. Everything on it is a tag, and TagMap implements it too. Span-named types stay the layer with more to them: SpanData (Take the span's tag lock once in setTagsFrom (tag api - part 1) #13030) is the intercepted view, with span-level fields as well as tags.

Motivation

The eager post-processors run on the application thread as a span finishes. Once a span's tags are no longer one TagMap (#13003), handing them a TagMap means building a view per span on the application thread. In earlier measurements that view cost +4–5% per trace. With TagStore, the span passes itself, and nothing is allocated. That matters because the processor chain loops over an array, so its call sites are megamorphic and any adapter object handed down it would escape.

Additional Notes

• No behavior change, and no allocation change: the probe gives identical bytes at every step of the trace, 7,936 B per trace both before and after.
• Tests: internal-api passes, as do the dd-trace-core post-processor, naming, endpoint, DDSpanContext and DDSpan suites. EndpointResolverTest now uses TagMap instead of HashMap.
• InternalTagsAdder's prebuilt TagMap.Entry objects are a stop-gap. They avoid an Entry per span until the dense store lands (Add a dense known-tag store behind an experimental flag (dense store - part 8) #13004, on by default in Presize dense tag stores and seed span prototypes in bulk (dense store - part 9) #12926). Once it does, the processor can store plain values by id, and the prebuilt entries go. A broader cleanup of the post-processors, including some dead null checks in InternalTagsAdder, is planned separately.
• The id variants don't change allocation either: TraceShapeBenchmark (children=5, a 7-span trace) gives 7984.0 B/op (legacy) and 7312.0 B/op (newApi, normal) with names and with ids.
• TagStoreTest checks, for both TagMap and DDSpanContext, that a tag stored by id loads by name and vice versa, that loadString by id converts, and that a null stored by id removes the tag. It passes at every step of the stack, including with the dense store on (Presize dense tag stores and seed span prototypes in bulk (dense store - part 9) #12926).
• OtelHttpSemanticsTest checks that urlOrPath answers the same from a TagStore as from a map, for each of its URL and path scenarios.

Where this is going

This PR is one step in replacing the span's single TagMap with storage that knows each tag's kind. The goal is to cut what every span allocates on the application thread, without changing behavior.

The end state

• A tag is classified once, at the boundary. A known tag becomes an id (from the tag registry, Resolve direction-scoped OpenTelemetry names at the OpenTelemetry boundary (otlp - tag registry - phase 3) #12731), and a custom tag stays a name. Instrumentation sets known tags by id (Route intercepted tags by id instead of by name (otlp - tag registry - phase 3) #12817), so the JIT can constant-fold the routing.
• The span owns its tag stores directly. Known tags are kept by id and custom tags by name. TagMap becomes a thin view for code outside the span.
• Known tags live in a dense store by default. Parallel arrays of serials and values replace an Entry object per tag, and each span's store is presized from a per-operation hint. With the flag on, a web-request-shaped trace allocates about 30% less on the application thread than on master.
• Core reads and writes a span's stored tags through TagStore, not a TagMap. That covers post-processors now and serializers later, so no TagMap view gets built for them. TagStore has its own verbs, load and store, apart from TagMap's get/set and the span's intercepted getTag/setTag, so DDSpanContext can offer both. The tag stores themselves use the same verbs (Add id and name tag stores, not yet used (dense store - part 5) #13006). It starts with what the eager processors use, by name and by id, and grows typed-load and primitive-store variants. Its intercepted counterpart, SpanData (Take the span's tag lock once in setTagsFrom (tag api - part 1) #13030), is what setTagsFrom, TagContributor and TagExtractor take, with one lock per batch.

Later, not in this stack: cheaper read-through to parent spans, trace-level tags in a per-trace holder (TraceSegment), and primitive tag values without boxing.

The stack. This replaces #12918, split into pieces that can each be reviewed, and measured, on their own.

PR	Step	Allocation per 7-span trace (flag off unless noted)
#12999	A null tag value removes the tag in TagMap. This is the stack's only behavior change, kept separate on purpose.	unchanged
#12992	Bucket known tags by slot in TagMap, and add TraceShapeBenchmark	−96 B vs master
#13001	TagStore for the eager post-processors	unchanged
#13002	Extract TagMap's bucket mechanics into HashSupport (a pure move)	unchanged
#13006	Add the id and name tag stores, not yet used	unchanged
#13007	Make TagMap a facade over the two stores	unchanged
#13003	Have the span own its tag stores directly	+104 B (+1.3%)
#13004	Dense id store behind trace.experimental.dense.tags.enabled (off by default)	flag on: −30.6%
#12926	Turn the dense store on by default, add sizing hints and bulk prototype seeding	flag on: about 3% less again

Every PR after #12999 is behavior-preserving.

The pieces' allocation figures come from a deterministic per-thread probe (ThreadMXBean allocated bytes) that builds the same 7-span trace as TraceShapeBenchmark. The #12992 and #12926 figures come from TraceShapeBenchmark itself.

🤖 Generated with Claude Code

[datadog-prod-us1-6]

🎯 Code Coverage (details)
• Patch Coverage: 74.07%
• Overall Coverage: 59.47% (+0.01%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: cdfc195 | Docs | 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	14.81 s	14.70 s	[-0.2%; +1.7%] (no difference)
startup:insecure-bank:tracing:Agent	13.56 s	13.68 s	[-1.7%; -0.1%] (maybe better)
startup:petclinic:appsec:Agent	17.71 s	17.63 s	[-0.4%; +1.3%] (no difference)
startup:petclinic:iast:Agent	17.57 s	17.63 s	[-1.1%; +0.4%] (no difference)
startup:petclinic:profiling:Agent	17.33 s	17.30 s	[-0.8%; +1.2%] (no difference)
startup:petclinic:sca:Agent	17.84 s	17.70 s	[-0.1%; +1.7%] (no difference)
startup:petclinic:tracing:Agent	16.57 s	16.70 s	[-1.7%; +0.2%] (no difference)

Commit: cdfc195b · 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]

In this PR, DDSpanContext becomes TagStore, but I think we still want to keep them conceptually separate. I made that change because TagStore is direct to the underlying store without locking or extra interpretation -- just like Map & TagMap before.

The main reason that DDSpanComponent implements TagStore directly is to avoid allocation. Ideally, I think EA (escape analysis)-friendly wrapper could have been used, but the EagerPostProcessorChain dispatch loop isn't EA-friendly.

[dougqh]

Once dense store is on by default, we can drop the TagMap.Entry creation in the post processors.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-26T20:37:26.517873Z	36bbbd2	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[datadog-prod-us1-6]

More details

Static review supports preservation of eager processor ordering, caller-held locking, tag addressing, and HTTP URL-to-path fallback behavior. The completed specialist returned no reportable findings.

Was this helpful? React 👍 or 👎

_{Open Bits AI session}

_{🤖 Bits Code Review · Commit 36bbbd2}

[datadog-prod-us1-6]

More details

TagStore preserves the eager processors’ raw-storage access, existing tag-lock boundary, and HTTP URL-to-path fallback. The completed static review reported no actionable defects.

Was this helpful? React 👍 or 👎

_{Open Bits AI session}

_{🤖 Bits Code Review · Commit 3eed220}

[PerfectSlayer]

❔ question: ‏Why did the Javadoc leaks implementation details from another module?

[dougqh]

Fair point, fixed in cdfc195. The interface now only says thread safety is up to the implementation. DDSpanContext's implementation already documents that its callers hold the span's tag lock.

Reply written by Claude (Claude Code) on behalf of dougqh.

[PerfectSlayer]

🎯 suggestion: ‏I would document and annotate nullable return values

[dougqh]

Done in cdfc195: the four load* methods are @Nullable, and so are the values passed to store.

Reply written by Claude (Claude Code) on behalf of dougqh.

[PerfectSlayer]

❔ question: ‏Does null reader make sense?

[dougqh]

It's deliberate, to match how DDSpan.setTag works. TagMap.Entry.create returns null for a null or empty value, and the intent is that null flows through safely, so a caller can write store(Entry.create(id, value)) without its own check. Whether that convention should carry down into TagStore is debatable, though. For now cdfc195 marks the parameter @Nullable so the contract is explicit.

Reply written by Claude (Claude Code) on behalf of dougqh.

[dougqh]

Following up now that this is settled: the rule is that the caller-facing levels (DDSpan.setTag, TagMap, TagStore) accept null, and the storage level doesn't. A null value means the tag is absent, so it removes. A null entry names no tag and no id, so a no-op is the only thing it can mean. One level down, #13006 (dense store part 5) makes HashStore/IdStore reject nulls on writes (0291032), so null is handled once, by their owner.

Reply written by Claude (Claude Code) on behalf of dougqh.

[PerfectSlayer]

❔ question: ‏Is there a rationale behind allowing null value for removal rather than dedicated remove method? Won't we allow unexpected code path doing that? (caller that did not know they had null values removing the existing oner rather than updating)

[dougqh]

It matches TagMap.set and a span's setTag(tag, null), both of which remove. It also can't produce the path you describe: load returns null for an absent tag, so a tag holding a null value can't be represented. "Updated to null" and "removed" leave the store in the same observable state. I'd rather keep the interface small, but I can add an explicit remove if you think it reads better at call sites.

Reply written by Claude (Claude Code) on behalf of dougqh.

[PerfectSlayer]

❔ question: ‏Does it make sense to forbid null but allow empty array?

[dougqh]

It mirrors the existing PostProcessorChain on master. An empty chain is a valid no-op (no processors enabled), while a null array is a programming error. In practice it's never empty: TagsPostProcessorFactory always adds PeerServiceCalculator.

Reply written by Claude (Claude Code) on behalf of dougqh.