What Does This Do

No functional change. Tag id values change, because each id now carries a slot, but nothing in the tracer reads slots yet, and hashing, iteration order and tag identity are unaffected.

Gives every known tag a slot in bits [47-32] of its id, assigned at build time by graph coloring. Tags that appear together on a span type get distinct slots, so 1L << slotOf(id) gives a span's tags their own presence bits in one long when instrumentation follows its span type.

This is split out of the dense store (#12856) for ease of review, and to enable similar existence-check optimizations in the span builder's tag ledger.

Slots don't limit what a span can hold. The dense store still allows two tags with the same slot on one span. A slot is only a fast path for the common case: when instrumentation follows its span type, the tags it sets are colored apart. So a clear bit means a tag is definitely absent, while a set bit means it's probably present and the store confirms with a scan.

• Coloring in the tag-registry generator. Each concrete span type's resolved tags form a clique, and the trace-level tags form another (they live in a separate TagMap). colorSlots colors the co-occurrence graph greedily: tags that are required, conditional or recommended on some span type go first, then the rest; within each group, most-constrained first, then by name, so ids stay a pure function of the conventions. Tags that never share a span type can share a slot, which keeps the count bounded by the largest clique.
• Every tag on a modeled span type gets a slot, whatever its requirement level. A tag on no modeled span type (the tracer overlay's routing-only keys, tags of unmodeled span types) gets NO_SLOT (0xFFFF).
• Capped at 63 slots, so they fit one occupancy long with bit 63 left over. 1L << slotOf(id) needs no branch for NO_SLOT: a long shift uses only the low 6 bits of its count, so 0xFFFF lands on bit 63, which every unslotted tag shares.
• A span type with more than 63 tags shares slots among its optional tags. The requirement level the conventions already carry decides it, so the registry needs no slot concept: on a span type that overflows, two tags that are both optional or opt_in there may share a slot once the free slots run out, on the slot the fewest of them already hold. Its other tags keep exact slots, and a span type that fits never has two tags on one slot. The build fails only if a span type's non-optional tags alone need more than 63. Generated KnownTags marks a tag that shares a slot with + shares slot.
• KnownTagCodec: SLOT_SHIFT, NO_SLOT, slotOf, hasSlot (false for a custom tag's 0L id), and slotCount() (the generated SLOT_COUNT). tag-assignment.txt gains a slot column, and each generated id's comment shows its slot.

How slots are assigned: an example

Here's the current output for three span types. Slots 0–7 hold the non-optional tags every one of them has, and slots 18–21 the optional ones, which are colored last; each of those tags gets the same slot everywhere. In between, the span types diverge, and each slot is reused by tags that usually don't appear on the same span:

• A tag keeps one slot wherever it appears: http.method is 10 on both HTTP spans, and peer.hostname is 14 on both client spans.
• A slot is shared only by tags that usually don't appear together: slot 14 is http.query.string on a server span but peer.hostname on a client span.
• Trace-level tags are a separate clique and reuse the low slots: env is 9, version is 12. They live in a separate TagMap, so they never share a word with span tags.
• 24 slots is the minimum: http.server alone has 24 tags, which all need distinct slots, so the greedy coloring is optimal for the current conventions. Nothing overflows, so no tag shares a slot.

Motivation

Per-span structures want a compact presence word for known tags:

• The dense tag store (Store known span tags densely, behind an experimental flag (phase 3b - dense tag storage) #12856) uses it to skip its scan for a tag that is definitely absent.
• TagMap.Ledger (span builder tags) could answer smartRemove of a never-set tag with one bit test instead of canonicalizing the name and scanning, and could keep one change per slot.
• A planned routing summary can sit in the same word.

A presence bit keyed by serial & 63 would collide arbitrarily, and most often on exactly the spans with the most tags. Coloring keeps the bits distinct for tags that usually occur together, so collisions only come from tags set outside their span type.

Additional Notes

• Ids change value; nothing should depend on that. Every generated id now carries its slot, and the generator emits ids as literals, so they are regenerated consistently. makeTagId(serial) still builds a slot-0, flag-free id: it's for serial-keyed lookups such as nameOf, and its doc now says not to compare it with a real id. I checked every caller; none does.
• Based on master now that Route intercepted tags by id instead of by name (otlp - tag registry - phase 3) #12817 has merged. Store known span tags densely, behind an experimental flag (phase 3b - dense tag storage) #12856 will merge this in and drop its own copy of the coloring.
• Current numbers: 66 known tags color into 24 slots, well under the 63 cap; 17 tags have no slot.
• Overflow is real in the stack: with every tag registered (Register APM tag constants on their span types (otlp - tag registry) #12893, Register CI Visibility tags on test span types (otlp - tag registry) #12900), CI Visibility's test spans carry 73 to 104 tags. Run against those conventions, this coloring fits 306 tags in 63 slots; only the ten CI test span types have tags sharing a slot (the occasional ones: pull request info, retries, ITR, test management, ...), and every APM span type stays exact. Alternatives considered: leaving the overflow unslotted (every slotless tag shares bit 63, set on most spans, so checks become scans), two occupancy longs (8 bytes and a word select on every span, for CI's sake), and a group bit like trace-level (doesn't help: the overflow is within one span type). tag-assignment.txt shows each tag's slot. The modeled span types today are http.server, http.client, db.client and view.render.

🤖 Generated with Claude Code