[dougqh]

What Does This Do

Optimizations on top of the store split (#12918), mostly for the dense tag store (trace.experimental.dense.tags.enabled, off by default). With the flag off, spans allocate exactly what #12918's do.

• Presize each span's dense store from a per-operation sizing hint. A port of Store known span tags densely, behind an experimental flag (phase 3b - dense tag storage) #12856's SizingHint / SizingHintTable: a bounded, racy table of hints, keyed by operation name, with separate lanes for entry spans and child spans.

  • Where the hint lives: on the span's DenseIdStore, not on DDSpanContext, so flag-off spans carry no extra field.

  • When spans record their size:

    • a published span, when it's serialized, with every tag present;
    • a span in a dropped trace, in CoreTracer.write, after the early post-processors and the root's sampling decision have added their tags.

    Recording at span finish would miss those late tags, and every later span of the operation would grow its store to twice the hint.

• One reference store per dense write path. store and getAndPut resolve the slot index first, then store the value once. On JDK 17 and earlier, C2 expands each reference-store site's G1 write barriers inline, at about 250 B apiece.
• Seed a SpanPrototype's known tags in bulk. The new method IdStore.seedAbsent appends a frozen, parentless, dense source with two array copies, provided the source's occupancy words share no bit with the target's live, tombstoned or inherited words, checked per level. If they share none, no prototype tag can already be present, so "absent only" holds without a per-tag check. If they share any, it copies nothing and the caller falls back to seeding tag by tag.
  • The plan: whether to use the bulk path is decided once per prototype and cached on it. It records whether the store supports bulk seeding, whether the interceptor needs any known tag other than span.kind, and span.kind's ordinal, which is set directly.
  • Where it applies: both at span construction and in applyOverwriting, the path BaseDecorator.afterStart takes today.
  • Custom prototype tags always go one at a time.
• Sizing hints cached on the prototype. A span that uses its prototype's own operation name takes the hint cached on the prototype and skips the table lookup. A span given any other operation name gets that name's hint from the table, so the cache never shares a hint the table wouldn't.
• singleSpanBuilder(SpanPrototype, …), so the prototype entry points mirror the plain ones (startSpan, buildSpan, singleSpanBuilder).
• Public forEach on HashStore and IdStore, so the prototype paths can walk a prototype's custom store directly.

Motivation

Without sizing, every fresh span grew its dense store on its first tag. C2 then inlined grow() and its two allocations into DenseIdStore.store, which compiled to 2816 B, over InlineSmallCode, so every setTag called store out of line. With the hints converged, grow() is cold:

Fresh spans, dense on, JDK 17	before	after
DenseIdStore.store	2816 B	768 B, inlined again
DDSpanContext.setTag(long, int)	3648 B	1792 B
DDSpanContext.setTag(long, CharSequence)	3328 B	1408 B

The id-keyed setters now compile under the 2500 B limit with the store inlined, which C2 needs before it can coarsen the locks in a decorator's run of setTag calls.

Measurements

SpanCreationBenchmark on an M1 Max with Zulu 17, -Xms2g -Xmx2g, 4 forks, 5 × 5 s iterations, -prof gc. Experiment jars carried a LongAdder fix for SpanMetricsImpl's counters, which isn't part of this PR; without it, counter contention dominates at 8 threads.

Bytes per span, dense on: jdbc-shaped spans drop by −130 to −196 B (about 12%) at 1 to 8 threads. Web-shaped spans barely change, because they already fit their first allocation. Flag off, bytes are identical to #12918.

Throughput, dense on, vs. #12918: flat. Single-threaded it's within ±1%, except bare spans, which are about 4% slower from the per-span hint lookup. With the LongAdder fix, this branch is ahead in 13 of 16 cells at 1 to 8 threads (+0.5% to +4.5%), but only one cell clears the error bars. Scaling to 8 threads is limited by per-trace costs outside the tag store, so the byte saving doesn't show up as throughput yet.

Prototype entry points (jdbc, dense on, with the LongAdder fix, ops/µs):

entry point	1 thread	8 threads
direct setTags	2.16 ± 0.04	7.43 ± 0.34
startSpan + applyOverwriting (decorators today)	2.27 ± 0.02	7.72 ± 0.14
buildSpan(prototype)	2.36 ± 0.02	7.72 ± 0.20
singleSpanBuilder(prototype)	2.29 ± 0.02	7.21 ± 0.24
startSpan(prototype)	2.36 ± 0.02	7.73 ± 0.16

• Construction vs. after-start stamping: building the span from the prototype beats stamping it after start by about 4% single-threaded. That's two lock acquisitions fewer and no hint lookup. At 8 threads the two are even.
• The bulk seed itself is within noise, because prototypes carry only two or three known tags today. It pays off as prototypes take on more constants.
• singleSpanBuilder(prototype) measures slower than buildSpan(prototype), whose builder escape analysis already removes. It's kept for API symmetry.

Additional Notes

• Stacked on Split TagMap into id and name stores, owned directly by the span #12918. Review this PR's own commits.
• Reviews: /techdebt and /perf-review ran over these commits, and their findings are addressed. One was a real default-path regression: an extra lock acquisition in applyOverwriting with the flag off, which now has a test guarding it. One remains open: the hint only ever grows, so one unusually large span presizes every later span of its operation. That needs a benchmark with mixed span sizes before deciding on decay.
• Tests:
  • SizingHintTable{,HashOnly}ForkedTest;
  • seedAbsent cases in TagStoresTest;
  • prototype construction, overwrite and custom-tag cases on both stores: SpanPrototypeConstructionDenseForkedTest reruns the suite with the dense store on and asserts that it is.
• Follow-ups, kept separate on purpose:
  • SpanMetricsImpl counters to LongAdder: +28% at 8 threads in these runs, a separate small PR off master;
  • removing read-through;
  • cheap span snapshots, and moving post-processing off the application thread.

🤖 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	14.75 s	14.59 s	[+0.3%; +1.9%] (maybe worse)
startup:insecure-bank:tracing:Agent	13.62 s	13.64 s	[-1.0%; +0.7%] (no difference)
startup:petclinic:appsec:Agent	17.67 s	17.53 s	[-0.1%; +1.7%] (no difference)
startup:petclinic:iast:Agent	17.43 s	17.43 s	[-0.8%; +0.9%] (no difference)
startup:petclinic:profiling:Agent	17.24 s	17.10 s	[-0.0%; +1.6%] (no difference)
startup:petclinic:sca:Agent	17.62 s	17.52 s	[-0.3%; +1.4%] (no difference)
startup:petclinic:tracing:Agent	16.49 s	16.64 s	[-1.8%; +0.1%] (no difference)

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