Remove LegacyTagMap; OptimizedTagMap is the sole TagMap implementation

[dougqh]

What This Does

OptimizedTagMap has been the default for several months (the optimized.map.enabled flag defaulted to true). With Legacy effectively dead, this removes it so OptimizedTagMap is the sole TagMap implementor — satisfying CHA's unique-implementor precondition (a prerequisite for upcoming read-through / dense-store work).

Motivation

The removal of LegacyTagMap makes future changes to TagMap easier.
Possible future work includes...

• deriving one TagMap from another TagMap
• dense storage for known / commonly used tags

Changes

• Delete LegacyTagMap and the whole TagMapFactory abstraction (the abstract class + its lone OptimizedTagMapFactory); TagMap.create()/create(int)/EMPTY now construct OptimizedTagMap directly.
• Delete the now-trivial TagMapType / TagMapTypePair test enums and de-parameterize their tests to plain @Test. TagMapScenario (parameterizes by size) is kept.
• Remove the optimized.map.enabled flag — Config field/getter, GeneralConfig constant, and the metadata/supported-configurations.json entry. Per the Config team, removing the registry entry is detected automatically at the next release (FPD + public docs get a Max Version: v1.xx.0 marker).

Notable

• Fixes a latent static-init cycle that removing the flag exposed: TagMap (interface with default methods) ↔ OptimizedTagMap could leave TagMap.EMPTY null when OptimizedTagMap initialized first. A lazy EmptyHolder builds the empty singleton via the constructor instead of reading a mid-<clinit> static.
• isOptimized() is intentionally left in place — it now constant-folds to true and is DCE'd at its call site (DDSpanContext); simplifying it away is a trivial follow-up.

Validation

• internal-api TagMap suite green (TagMapTest, TagMapLedgerTest, TagMapFuzzTest); internal-api / dd-trace-api / dd-trace-core compile clean.
• ⏳ Draft pending a broader dd-trace-core integration run before marking ready.

Benchmark — overhead-neutral (parity)

TagMapAccessBenchmark (threading-correct, @Threads(8)) run on the pre-kill tree vs. this branch — the two differ by exactly these two commits (verified byte-identical pre-image). Throughput, 1 fork, 3 warmup + 5 measurement iters:

Benchmark	Pre-kill (ops/s)	Post-kill (ops/s)	Δ
insert	55.2M ±2.7M	53.9M ±6.2M	−2.3%
getObject	91.8M ±8.7M	93.3M ±10.2M	+1.6%
getEntry	91.7M ±18.2M	93.3M ±11.2M	+1.8%

All deltas are within run-to-run error (single fork) → no measurable change, as expected for a dead-code removal.

🤖 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.92 s	13.97 s	[-1.0%; +0.2%] (no difference)
startup:insecure-bank:tracing:Agent	12.91 s	12.99 s	[-1.3%; +0.2%] (no difference)
startup:petclinic:appsec:Agent	16.91 s	16.85 s	[-0.8%; +1.5%] (no difference)
startup:petclinic:iast:Agent	16.87 s	16.10 s	[+0.6%; +9.0%] (maybe worse)
startup:petclinic:profiling:Agent	16.66 s	16.83 s	[-2.1%; -0.1%] (maybe better)
startup:petclinic:sca:Agent	16.84 s	16.76 s	[-0.6%; +1.5%] (no difference)
startup:petclinic:tracing:Agent	15.75 s	16.18 s	[-6.7%; +1.4%] (no difference)

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

[bric3]

question: For my own information, do the hierarchy analysis do not work with interfaces ?

[dougqh]

There are two flavors of hierarchy analysis.

There's single unique method which I believe does work for interfaces
-- and allows method call to be devirtualized

And there's single implementor which allows the reference to be refined to the more specific type
-- which in turn, then allows the method call to be devirtualized

And devirtualization can lead to inlining

There's also profile guided devirtualization which would work here, too, but that has a slightly higher execution cost

[bric3]

question: Might need some updated on the configuration portal

[sarahchen6]

Nice