diff --git a/internal-api/src/jmh/java/datadog/trace/api/TagMapAccessBenchmark.java b/internal-api/src/jmh/java/datadog/trace/api/TagMapAccessBenchmark.java
index de33c957e9a..3cd021a65b4 100644
--- a/internal-api/src/jmh/java/datadog/trace/api/TagMapAccessBenchmark.java
+++ b/internal-api/src/jmh/java/datadog/trace/api/TagMapAccessBenchmark.java
@@ -1,5 +1,6 @@
package datadog.trace.api;
+import datadog.trace.util.BenchmarkUtils;
import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.TimeUnit;
@@ -56,6 +57,31 @@
* TagMapAccessBenchmark.insert_hashMap_builderStyle thrpt 5 28057827.189 ± 1359655.664 ops/s
* TagMapAccessBenchmark.insert_via_ledger thrpt 5 41169656.095 ± 773264.754 ops/s
*
+ *
+ * Rerun on JDK 8 with a new top-level {@code @Setup(Level.Trial)} calling {@link
+ * BenchmarkUtils#polluteHashDispatch()} (this file had none before). M ops/s, 8 threads:
+ *
+ *
{@code
+ * getEntry 83 getObject 87
+ * insert 37 insert_hashMap 48
+ * insert_hashMap_builderStyle 20 insert_via_ledger 37*
+ * }
+ *
+ * * = error bar about a quarter of the mean at {@code @Fork(2)} — directional only.
+ *
+ *
Every number here is 9-29% below the Java 17 table above, with no clear split between the
+ * TagMap paths and the HashMap paths this pollution should affect. The table above is Java 17; this
+ * rerun is JDK 8, whose C2 backend for Apple Silicon (AArch64) is far less mature than JDK 17+'s —
+ * a broad-based slowdown across every entry is expected from that JDK gap alone, independent of
+ * pollution — the same JDK-crossing explanation applies to {@link
+ * datadog.trace.util.CaseInsensitiveMapBenchmark}'s rerun. ({@link
+ * datadog.trace.util.HashtableD1Benchmark} and {@link datadog.trace.util.HashtableD2Benchmark} saw
+ * a similar broad drop despite holding the JDK constant — that one is same-session run-to-run
+ * noise, not a JDK effect.) The relative story survives: {@code insert_hashMap} (48M) still beats
+ * {@code insert} (37M) for plain insertion, and {@code insert_via_ledger} (37M) still clearly beats
+ * the HashMap builder-style path (20M); {@code insert_via_ledger} landing roughly level with {@code
+ * insert} here (vs. clearly behind it in the table above) is within that path's own wide error bar,
+ * not a new finding.
*/
@BenchmarkMode(Mode.Throughput)
@OutputTimeUnit(TimeUnit.SECONDS)
@@ -99,6 +125,11 @@ public class TagMapAccessBenchmark {
* Pre-populated read map, PER-THREAD ({@code Scope.Thread}): each thread owns its own map so
* reads don't contend on shared mutable state under {@code @Threads(8)}.
*/
+ @Setup(Level.Trial)
+ public void setUp() {
+ BenchmarkUtils.polluteHashDispatch();
+ }
+
@State(Scope.Thread)
public static class ReadMap {
TagMap map;
diff --git a/internal-api/src/jmh/java/datadog/trace/util/BenchmarkUtils.java b/internal-api/src/jmh/java/datadog/trace/util/BenchmarkUtils.java
new file mode 100644
index 00000000000..e785757a515
--- /dev/null
+++ b/internal-api/src/jmh/java/datadog/trace/util/BenchmarkUtils.java
@@ -0,0 +1,118 @@
+package datadog.trace.util;
+
+import java.util.Arrays;
+import java.util.Collection;
+import java.util.HashSet;
+import java.util.Map;
+import java.util.concurrent.ConcurrentHashMap;
+
+/** Shared setup helpers for JMH benchmarks in this module. */
+public final class BenchmarkUtils {
+ private BenchmarkUtils() {}
+
+ private static final Object[] DEFAULT_DECOY_KEYS = {
+ "decoy", 1, 1L, 1.0d, Boolean.TRUE, new Object()
+ };
+
+ /**
+ * Exercises {@link HashSet}/{@link java.util.HashMap}, the tracer's {@link
+ * CollectionUtils#tryMakeImmutableSet} immutable sets, and {@link ConcurrentHashMap} with several
+ * distinct key classes, so each structure's internal {@code hashCode()}/{@code equals()} dispatch
+ * -- a call site shared JVM-wide by every instance of that structure in the process, regardless
+ * of which specific instance or call site invokes {@code add}/{@code contains}/{@code get} -- is
+ * already megamorphic before a benchmark measures lookups against a single key type.
+ *
+ *
This matches production: those shared internal call sites are hit by every hash-based
+ * structure in the JVM across whatever key types the whole application uses, so they're
+ * realistically almost always megamorphic. An isolated benchmark that only ever looks up one key
+ * type (e.g. {@code String}) would otherwise leave them artificially monomorphic for the entire
+ * run, understating real dispatch cost.
+ *
+ *
{@code HashSet} is backed by {@code HashMap} in the JDK, so polluting it also covers plain
+ * {@code HashMap} and {@code LinkedHashMap} (which extends {@code HashMap}) -- they share the
+ * same internal dispatch call site. {@code ConcurrentHashMap} does not: it's an unrelated class
+ * with its own {@code hashCode()}/{@code equals()} call sites, so it needs its own scratch
+ * instance (also covers {@code ConcurrentHashMap#newKeySet()}, which is backed by a {@code
+ * ConcurrentHashMap}). Structures that dispatch on {@code compareTo} instead ({@code TreeMap},
+ * {@code TreeSet}, {@code ConcurrentSkipListMap}) aren't affected by any of this and don't need
+ * pollution.
+ *
+ *
Deliberately does not touch the benchmark's own {@code contains}/{@code add}/{@code get}
+ * call sites -- those are realistically free to specialize per caller, the way a genuinely hot,
+ * narrowly-typed call site would in production.
+ *
+ *
Not to be confused with the CHA-defeat decoys in {@code SingleThreadedMapBenchmark}/{@code
+ * ThreadSafeMapBenchmark} ({@code KeyStrategy} implementors referenced only so they're loaded,
+ * never invoked): that technique denies class-hierarchy analysis a single-implementor bet for a
+ * narrow, dd-trace-java-owned interface, and works by class-loading alone. It doesn't apply here
+ * -- {@code Object.hashCode()}/{@code equals()} already have countless implementors loaded in any
+ * real JVM, so a single-implementor CHA bet was never available for them. What gates their
+ * dispatch is the interpreter's per-call-site type profile, which only invocation can pollute --
+ * hence this helper actually calls {@code add}/{@code contains}/{@code get}, rather than just
+ * loading classes.
+ */
+ public static void polluteHashDispatch() {
+ polluteHashDispatch(DEFAULT_DECOY_KEYS);
+ }
+
+ public static void polluteHashDispatch(Object... decoyKeys) {
+ populateTypeProfileMutable(new HashSet<>(), decoyKeys);
+ populateTypeProfile(CollectionUtils.tryMakeImmutableSet(Arrays.asList(decoyKeys)), decoyKeys);
+ populateTypeProfileMutableMap(new ConcurrentHashMap<>(), decoyKeys);
+ }
+
+ /**
+ * The entry point most benchmarks should reach for: pass the same kind of collection instance
+ * under test (or an equivalent scratch instance). Works for both mutable and immutable
+ * collections since it only drives {@code contains()} -- the operation every {@link
+ * java.util.Set} supports, and the one these lookup benchmarks actually measure.
+ */
+ public static void populateTypeProfile(Collection populated) {
+ populateTypeProfile(populated, DEFAULT_DECOY_KEYS);
+ }
+
+ public static void populateTypeProfile(Collection populated, Object... decoyKeys) {
+ for (Object key : decoyKeys) {
+ populated.contains(key);
+ }
+ }
+
+ /**
+ * Lower-level control: also drives {@code add()} dispatch, so {@code scratch} must genuinely
+ * support mutation, and lets the caller pick the decoy keys. Reach for this only when {@code
+ * add()} dispatch matters too, or the default decoys aren't the right shape.
+ */
+ public static void populateTypeProfileMutable(Collection scratch, Object... decoyKeys) {
+ for (Object key : decoyKeys) {
+ scratch.add(key);
+ scratch.contains(key);
+ }
+ }
+
+ /**
+ * {@link Map} counterpart to {@link #populateTypeProfile(Collection)}: pass the map instance
+ * under test (or an equivalent scratch instance) to drive its {@code get()} dispatch. Safe
+ * against immutable maps too, since it only calls {@code get()}.
+ */
+ public static void populateTypeProfileMap(Map populated) {
+ populateTypeProfileMap(populated, DEFAULT_DECOY_KEYS);
+ }
+
+ public static void populateTypeProfileMap(Map populated, Object... decoyKeys) {
+ for (Object key : decoyKeys) {
+ populated.get(key);
+ }
+ }
+
+ /**
+ * Lower-level control, {@link Map} counterpart to {@link #populateTypeProfileMutable}: also
+ * drives {@code put()} dispatch, so {@code scratch} must genuinely support mutation.
+ */
+ public static void populateTypeProfileMutableMap(
+ Map scratch, Object... decoyKeys) {
+ for (Object key : decoyKeys) {
+ scratch.put(key, key);
+ scratch.get(key);
+ }
+ }
+}
diff --git a/internal-api/src/jmh/java/datadog/trace/util/CaseInsensitiveMapBenchmark.java b/internal-api/src/jmh/java/datadog/trace/util/CaseInsensitiveMapBenchmark.java
index 9cbbddcf299..62a48976691 100644
--- a/internal-api/src/jmh/java/datadog/trace/util/CaseInsensitiveMapBenchmark.java
+++ b/internal-api/src/jmh/java/datadog/trace/util/CaseInsensitiveMapBenchmark.java
@@ -6,8 +6,10 @@
import java.util.function.Supplier;
import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.Fork;
+import org.openjdk.jmh.annotations.Level;
import org.openjdk.jmh.annotations.Measurement;
import org.openjdk.jmh.annotations.Scope;
+import org.openjdk.jmh.annotations.Setup;
import org.openjdk.jmh.annotations.State;
import org.openjdk.jmh.annotations.Threads;
import org.openjdk.jmh.annotations.Warmup;
@@ -52,6 +54,31 @@
* lookup_hashMap thrpt 15 441875038.1 ± 110408182.2 ops/s 24.0 B/op (129 GCs)
* lookup_treeMap thrpt 15 251195415.1 ± 14662568.3 ops/s ~0 B/op
*
+ *
+ * Rerun on JDK 8 with {@link BenchmarkUtils#polluteHashDispatch()} added to a new
+ * {@code @Setup(Level.Trial)} (this file had none before), at this file's actual {@code @Fork(2)}
+ * (the numbers above are from an ad hoc higher-fork run; not directly comparable). M ops/s, 8
+ * threads:
+ *
+ *
{@code
+ * create_baseline 26 create_flatHashtable 13
+ * create_hashMap 9 create_treeMap 7
+ *
+ * lookup_baseline 2618 lookup_flatHashtable 415
+ * lookup_flatHashtable_lowLoad 415 lookup_hashMap 367*
+ * lookup_treeMap 209
+ * }
+ *
+ * * = error bar over a third of the mean at {@code @Fork(2)} — directional only.
+ *
+ *
All four {@code lookup_*} numbers sit 17-23% below the table above (415 vs 537 flatHashtable,
+ * 367 vs 442 hashMap, 209 vs 251 treeMap) despite {@code flatHashtable} and {@code treeMap} using
+ * neither {@code java.util.HashMap} nor {@code hashCode()}/{@code equals()} dispatch — so this drop
+ * isn't attributable to pollution. The likelier explanation: the table above is Zulu 21, this rerun
+ * is JDK 8, and JDK 8's C2 backend for Apple Silicon (AArch64) is far less mature than JDK 17+'s —
+ * a broad-based slowdown across every entry, pollution-affected or not, is expected from that JDK
+ * gap alone on this machine. The relative ranking — {@code flatHashtable} > {@code hashMap}
+ * > {@code treeMap} — is unchanged.
*/
@Fork(2)
@Warmup(iterations = 2)
@@ -101,6 +128,11 @@ static T init(Supplier supplier) {
// masking exactly the differences this benchmark compares.
int lookupIndex = 0;
+ @Setup(Level.Trial)
+ public void setUp() {
+ BenchmarkUtils.polluteHashDispatch();
+ }
+
String nextLookupKey() {
int localIndex = ++lookupIndex;
if (localIndex >= LOOKUP_KEYS.length) {
diff --git a/internal-api/src/jmh/java/datadog/trace/util/HashtableD1Benchmark.java b/internal-api/src/jmh/java/datadog/trace/util/HashtableD1Benchmark.java
index f8ba7177e88..9581a8db520 100644
--- a/internal-api/src/jmh/java/datadog/trace/util/HashtableD1Benchmark.java
+++ b/internal-api/src/jmh/java/datadog/trace/util/HashtableD1Benchmark.java
@@ -38,10 +38,14 @@
* iterate — walk every entry and consume its key + value.
*
*
- * Update is where Hashtable dominates: D1 is ~14x faster, because the HashMap path
- * allocates per call (a {@code Long}) and the resulting GC pressure throttles throughput under
- * multiple threads. Add is roughly comparable (both allocate one entry per insert).
- * Iterate is essentially a wash — both are bucket walks.
+ * Update is where Hashtable dominates: D1 is ~14x faster on JDK 8 (see the Java 17 rerun
+ * below for a narrower but still decisive margin), because the HashMap path allocates per call (a
+ * {@code Long}) and the resulting GC pressure throttles throughput under multiple threads. This is
+ * the headline case for {@code Hashtable}: a simple counter/tally with a primitive value is exactly
+ * where HashMap's autoboxing tax bites hardest, and {@code Hashtable.D1} sidesteps it entirely by
+ * mutating a field on the retrieved entry in place. Add is roughly comparable (both allocate
+ * one entry per insert). Iterate is essentially a wash on JDK 8, though not on Java 17 (see
+ * below).
* MacBook M1 8 threads (Java 8)
*
* Benchmark Mode Cnt Score Error Units
@@ -54,6 +58,44 @@
* HashtableD1Benchmark.iterate_hashMap thrpt 6 20.043 ± 0.752 ops/us
* HashtableD1Benchmark.iterate_hashtable thrpt 6 22.208 ± 0.956 ops/us
*
+ *
+ *
Rerun with {@link BenchmarkUtils#polluteHashDispatch()} added to {@code D1State.setUp()} (same
+ * machine/JVM/config): every number moved down somewhat (add_hashMap 188→101, update_hashtable
+ * 1810→1465, iterate_hashtable 22→17 ops/us), including {@code *_hashtable}. That's expected to be
+ * a no-op for {@code *_hashtable}: {@link Hashtable.D1.Entry#hash} and {@link
+ * Hashtable.D1.Entry#matches} are call sites private to {@code Hashtable.java}, structurally
+ * distinct from {@code java.util.HashMap}/{@code HashSet}'s internal {@code hashCode()}/{@code
+ * equals()} call sites — JIT type profiles are keyed per call site, so {@code
+ * polluteHashDispatch()} cannot reach them regardless of key-type overlap. Since the JDK and
+ * machine were held constant across this rerun (unlike the JDK 8-vs-17 comparisons in {@link
+ * datadog.trace.util.CaseInsensitiveMapBenchmark} and {@link
+ * datadog.trace.api.TagMapAccessBenchmark}), the drop here is same-session run-to-run noise
+ * (thermal/power, not controlled for) rather than either a pollution effect or a JDK effect. The
+ * relative conclusion (D1 dominates {@code update}, is roughly comparable on {@code add},
+ * ties on {@code iterate}) is unchanged either way.
+ *
+ *
Separately rerun on Zulu 17.0.7 (native AArch64, same machine, pollution wiring unchanged; JMH
+ * auto-detected the cheap "compiler" Blackhole mode here, unlike JDK 8, so absolute numbers below
+ * are not comparable to the JDK 8 tables above — see {@code HashtableD2Benchmark}'s javadoc for the
+ * full caveat). M ops/us, 8 threads:
+ *
+ *
{@code
+ * add_hashMap 1502.6 add_hashtable 1377.3
+ * update_hashMap 644.2 update_hashtable 2706.5
+ * iterate_hashMap 19.3 iterate_hashtable 78.0
+ * }
+ *
+ * Within this single run (so the cross-JDK Blackhole-mode confound doesn't apply to the ratios),
+ * {@code update_hashtable} still wins by ~4.2x — down from ~14x on JDK 8, because Java 17's
+ * allocator/GC absorbs {@code update_hashMap}'s per-call {@code Long} boxing far better than JDK 8
+ * did (update_hashMap itself got ~5x faster; update_hashtable only ~1.5x faster). {@code
+ * iterate_hashtable} also now clearly wins (~4.0x), flipping from JDK 8's "wash" — HashMap's {@code
+ * entrySet()} iterator does more per-entry work than a modern JIT's allocation improvements erase.
+ * {@code add} is the one case that flips the other way: {@code add_hashMap} edges out {@code
+ * add_hashtable} slightly (1502.6 vs 1377.3). Net takeaway: {@code Hashtable} is a strong
+ * substitute for {@code HashMap} particularly for simple counter/tally use cases with a primitive
+ * value, where avoiding the per-update boxing allocation pays off even on a JVM with much better
+ * allocation handling than JDK 8 had.
*/
@Fork(2)
@Warmup(iterations = 2)
@@ -103,6 +145,8 @@ public static class D1State {
@Setup(Level.Iteration)
public void setUp() {
+ BenchmarkUtils.polluteHashDispatch();
+
table = new Hashtable.D1<>(CAPACITY);
hashMap = new HashMap<>(CAPACITY);
keys = SOURCE_KEYS;
diff --git a/internal-api/src/jmh/java/datadog/trace/util/HashtableD2Benchmark.java b/internal-api/src/jmh/java/datadog/trace/util/HashtableD2Benchmark.java
index 6f46a702005..49357ab9a17 100644
--- a/internal-api/src/jmh/java/datadog/trace/util/HashtableD2Benchmark.java
+++ b/internal-api/src/jmh/java/datadog/trace/util/HashtableD2Benchmark.java
@@ -42,10 +42,13 @@
*
The D2 variants additionally pay for a composite-key wrapper allocation in the HashMap path
* (Java has no built-in tuple-as-key) — D2 sidesteps it by taking both key parts directly.
*
- *
Update is where Hashtable dominates: D2 is ~26x faster, because the HashMap path
- * allocates per call (a {@code Long}, plus a {@code Key2}) and the resulting GC pressure throttles
- * throughput under multiple threads. Add is ~3x faster for D2 (Hashtable sidesteps the
- * {@code Key2} allocation). Iterate is essentially a wash — both are bucket walks.
+ * Update is where Hashtable dominates: D2 is ~26x faster on JDK 8 (see the Java 17 rerun
+ * below for a narrower but still decisive margin), because the HashMap path allocates per call (a
+ * {@code Long}, plus a {@code Key2}) and the resulting GC pressure throttles throughput under
+ * multiple threads. Like D1, this is the headline case for {@code Hashtable}: a simple
+ * counter/tally with a primitive value is exactly where HashMap's autoboxing tax bites hardest.
+ * Add is ~3x faster for D2 (Hashtable sidesteps the {@code Key2} allocation). Iterate
+ * is essentially a wash on JDK 8, though not on Java 17 (see below).
* MacBook M1 8 threads (Java 8)
*
* Benchmark Mode Cnt Score Error Units
@@ -58,6 +61,46 @@
* HashtableD2Benchmark.iterate_hashMap thrpt 6 19.508 ± 0.760 ops/us
* HashtableD2Benchmark.iterate_hashtable thrpt 6 16.968 ± 0.371 ops/us
*
+ *
+ *
Rerun with {@link BenchmarkUtils#polluteHashDispatch()} added to {@code D2State.setUp()} (same
+ * machine/JVM/config): results were noisy and inconsistent with a clean pollution story —
+ * add_hashMap actually rose (77→103), while add_hashtable fell sharply (217→118, error bars wider
+ * than the mean both times); update_hashtable fell (1446→1225) and both iterate numbers fell
+ * (19.5→15.4, 17.0→13.1). As with {@link HashtableD1Benchmark}, {@code *_hashtable} is expected to
+ * be a no-op here: {@link Hashtable.D2.Entry#hash} and {@link Hashtable.D2.Entry#matches} are call
+ * sites private to {@code Hashtable.java}, structurally distinct from {@code
+ * java.util.HashMap}/{@code HashSet}'s internal dispatch call sites — pollution cannot reach them.
+ * With the JDK and machine held constant across this rerun, the drop is same-session run-to-run
+ * noise (thermal/power, not controlled for) rather than a genuine pollution effect. Treat these two
+ * runs as not directly comparable on absolute numbers. The relative conclusion (D2 dominates
+ * {@code update}, wins {@code add} by avoiding the {@code Key2} allocation, ties on {@code
+ * iterate}) is unchanged either way.
+ *
+ *
Separately rerun on Zulu 17.0.7 (native AArch64, same machine, pollution wiring unchanged).
+ * JMH auto-detected the cheap "compiler" Blackhole mode on Java 17 (its log explicitly warns that
+ * Blackhole-mode differences between JVMs can swing results significantly), which JDK 8 cannot use
+ * — so absolute numbers below are not comparable to the JDK 8 tables above; only within-run
+ * ratios are, since both benchmark methods in a given run get identical Blackhole treatment. M
+ * ops/us, 8 threads:
+ *
+ *
{@code
+ * add_hashMap 656.7 add_hashtable 1185.5
+ * update_hashMap 196.7 update_hashtable 2292.2
+ * iterate_hashMap 20.5 iterate_hashtable 69.2
+ * }
+ *
+ * {@code update_hashtable} still wins decisively (~11.6x, down from ~26x on JDK 8 — Java 17's
+ * allocator/GC absorbs {@code update_hashMap}'s per-call {@code Long}+{@code Key2} boxing far
+ * better than JDK 8 did: update_hashMap got ~3.5x faster, update_hashtable only ~1.6x faster).
+ * Unlike JDK 8, Hashtable now wins clearly on every operation: {@code add_hashtable} wins
+ * ~1.8x (vs. JDK 8's ~3x — HashMap's {@code Key2} allocation also got relatively cheaper), and
+ * {@code iterate_hashtable} flips from JDK 8's wash to a ~3.4x win (HashMap's {@code entrySet()}
+ * iterator does more per-entry work than a modern JIT's allocation improvements erase). Net
+ * takeaway, consistent with {@link HashtableD1Benchmark}: {@code Hashtable} is a strong substitute
+ * for {@code HashMap} particularly for simple counter/tally use cases with a primitive value, where
+ * avoiding the per-update boxing allocation pays off even on a JVM with much better allocation
+ * handling than JDK 8 had — and for D2 specifically, avoiding the composite-key wrapper allocation
+ * pays off across the board, not just on {@code update}.
*/
@Fork(2)
@Warmup(iterations = 2)
@@ -138,6 +181,8 @@ public static class D2State {
@Setup(Level.Iteration)
public void setUp() {
+ BenchmarkUtils.polluteHashDispatch();
+
table = new Hashtable.D2<>(CAPACITY);
hashMap = new HashMap<>(CAPACITY);
k1s = SOURCE_K1;
diff --git a/internal-api/src/jmh/java/datadog/trace/util/ImmutableMapBenchmark.java b/internal-api/src/jmh/java/datadog/trace/util/ImmutableMapBenchmark.java
index 39aaf82183c..5826e92e10c 100644
--- a/internal-api/src/jmh/java/datadog/trace/util/ImmutableMapBenchmark.java
+++ b/internal-api/src/jmh/java/datadog/trace/util/ImmutableMapBenchmark.java
@@ -44,40 +44,50 @@
* {@code *_sameKey} variants reuse the original interned key instances to show the identity fast
* path — which is the common tracer case, since map keys are typically interned tag-name constants.
*
- *
JDK 17 results (Apple M1, quiet machine, {@code @Fork(5)}, {@code @Threads(8)}; M ops/s).
- * {@code get} uses distinct keys (exercises {@code equals()}); {@code sameKey} reuses the interned
- * key (the {@code ==} fast path — the common tracer case):
+ *
{@link BenchmarkUtils#polluteHashDispatch()} runs in {@link #setUp}, for the same reason as
+ * {@link ImmutableSetBenchmark}: {@code Object.hashCode()}/{@code equals()} are JVM-wide shared
+ * call sites, hit by every hash-based structure in the process (this benchmark's {@code HashMap},
+ * {@code LinkedHashMap}, and {@code Map.copyOf}/{@code MapN} all dispatch through them for their
+ * {@code String} keys) — realistically almost always megamorphic, so leaving them monomorphic for
+ * the whole run would understate real dispatch cost.
*
- *
{@code
- * Structure get sameKey
- * stringIndex_embedded (static) 1498 2081 (fastest)
- * stringIndex (inst) 1363 1900
- * hashMap 1216 1850
- * linkedHashMap 1214 -
- * tagMap 1167 1386
- * tracerImmutableMap 1049 1364 (MapN)
- * treeMap 656 -
- * }
- *
- * {@code iterate} (full traversal):
+ *
JDK 8 results (Apple M1, quiet machine, {@code @Fork(5)}, {@code @Threads(8)}, with {@link
+ * BenchmarkUtils#polluteHashDispatch()} in effect; M ops/s). {@code get} uses distinct keys
+ * (exercises {@code equals()}); {@code sameKey} reuses the interned key (the {@code ==} fast path —
+ * the common tracer case):
*
*
{@code
- * tagMap.forEach 148 (fastest)
- * linkedHashMap 136
- * tracerImmutableMap 135 (MapN)
- * treeMap 134
- * hashMap 104
- * tagMap (iterator) 96
+ * Structure get sameKey iterate iterate_forEach
+ * hashMap 1202 1438 120 -
+ * linkedHashMap 1097 - 127 -
+ * treeMap 487 - 121 -
+ * tagMap 1005 1235 109 121
+ * tracerImmutableMap 1052 1249 123 - (MapN)
+ * stringIndex 1366 1724 - -
+ * stringIndex_embedded 1479 1846 - - (fastest get)
* }
*
* Key findings:
*
*
- * StringIndex-as-map ({@code EmbeddingSupport}) is the fastest {@code get} — beating {@code
- * HashMap} and {@code Map.copyOf}/{@code MapN}, most on the interned path; the instance
- * wrapper trails it by ~10%. (vs {@code MapN} the edge is speed + the slot/parallel-array
- * capability, not footprint — see {@link ImmutableSetBenchmark}.)
- * {@code TagMap.forEach} (148) beats its own {@code iterator} (96) by ~1.5x: TagMap's
+ * StringIndex-as-map is a reliable {@code get} win, and it holds up under type-profile
+ * pollution: {@code stringIndex_embedded} (the {@code static final}-array form) and {@code
+ * stringIndex} (the instance wrapper) both beat every {@code Map} here by a wide margin, on
+ * both the {@code equals()} and identity-fast-path lookups. Unlike {@link
+ * ImmutableSetBenchmark}'s {@code hitFresh} case, there's no bimodality here — this win is
+ * unconditional, not access-pattern-dependent.
+ * This table still compares boxed {@code Integer} values ({@code hashMap}/{@code
+ * linkedHashMap}/{@code treeMap}/{@code tracerImmutableMap} all return {@code Integer};
+ * {@code tagMap}/{@code stringIndex} happen to expose primitive {@code int} accessors, but
+ * that's not exercised as a differentiator here). StringIndex's edge should widen further
+ * against a {@code Map} once the comparison is against genuinely autoboxed
+ * reads on both sides — not yet measured.
+ * {@code treeMap}'s {@code get} has a wide error bar (±129, one fork's measurement iterations
+ * dropped to ~230-300, the rest sit around 490-610) — a known {@code TreeMap} comparison
+ * characteristic (uses {@code compareTo} not {@code hashCode}/{@code equals}, so it's
+ * unaffected by dispatch pollution), not the same warmup-race bimodality investigated in
+ * {@link ImmutableSetBenchmark}.
+ * {@code TagMap.forEach} (121) beats its own {@code iterator} (109) by ~10%: TagMap's
* structure makes a faithful external {@code Iterator} expensive (externalized cursor +
* skip-empty + per-call re-entry + the iterator allocation) — all of which internal {@code
* forEach} avoids. Traverse TagMap via {@code forEach}, never its iterator; that gap only
@@ -145,6 +155,8 @@ static void fill(Map map) {
@Setup(Level.Trial)
public void setUp() {
+ BenchmarkUtils.polluteHashDispatch();
+
hashMap = new HashMap<>();
fill(hashMap);
linkedHashMap = new LinkedHashMap<>();
diff --git a/internal-api/src/jmh/java/datadog/trace/util/ImmutableSetBenchmark.java b/internal-api/src/jmh/java/datadog/trace/util/ImmutableSetBenchmark.java
index f0604e6ddd4..ce5e7dc5ee2 100644
--- a/internal-api/src/jmh/java/datadog/trace/util/ImmutableSetBenchmark.java
+++ b/internal-api/src/jmh/java/datadog/trace/util/ImmutableSetBenchmark.java
@@ -44,37 +44,75 @@
* indirection cost of the wrapper.
*
*
- * Lookups are interned (the {@code ==} fast path where a structure has one); misses are short
- * and never present.
+ *
Hit lookups come in two flavors, because reusing the exact same key instances for both
+ * building a structure and measuring lookups against it is its own validity bug, independent of
+ * hash-dispatch pollution: {@link String#equals} takes an {@code ==} fast path, and {@link
+ * String#hashCode()} caches its result in a field on first call, so a key instance that was already
+ * inserted (or previously looked up) pays neither real cost again.
*
- *
JDK 17 results (Apple M1, quiet machine, {@code @Fork(5)}, {@code @Threads(8)}; M ops/s =
- * millions):
+ *
+ * {@code hit} -- looks up the same interned {@link #STRINGS} literals used to build every
+ * structure. This is realistic and worth keeping (fixed header/config-key lookups commonly
+ * are interned literals), but identity with the stored element is inherent to interning, not
+ * a choice this benchmark makes -- two equal literals are always the same instance.
+ * {@code hitFresh} -- looks up {@link #FRESH_STRINGS}, separate {@code new String(..)}
+ * instances never touched by {@link #setUp}, so each carries an uncached hash and forces a
+ * real {@code equals()} beyond the {@code ==} check. Models keys arriving from
+ * parsing/concatenation/deserialization rather than literals. Only meaningful for the
+ * hash-based structures ({@code hashSet}, {@code tracerImmutableSet}, {@code stringIndex},
+ * {@code stringIndex_embedded}); not measured for {@code array}/{@code sortedArray}/{@code
+ * treeSet}.
+ *
+ *
+ * Misses are already representative of both effects for free: {@link #MISSES} is built via
+ * concatenation (never interned) and never touched by {@link #setUp}.
+ *
+ *
Full re-run, all six structures across {@code hit}/{@code hitFresh}/{@code miss} together,
+ * with {@link BenchmarkUtils#polluteHashDispatch()} in effect (Apple M1, Java 8u382 -- the
+ * repo-default {@code jmh} test launcher, no {@code -PtestJvm} override --, {@code @Fork(5)},
+ * {@code @Threads(8)}; M ops/s = millions):
*
*
{@code
- * Structure hit miss
- * stringIndex_embedded (static) 2320 2159 (fastest)
- * hashSet 2198 2134
- * stringIndex (inst) 2098 1548 * (* miss bimodal -- see caveat)
- * tracerImmutableSet 1914 1663 (Set.copyOf / SetN)
- * array 941 589
- * sortedArray 685 610
- * treeSet 657 610
+ * Structure hit hitFresh miss
+ * stringIndex_embedded (static) 2098 1563 2030 (fastest hit and miss)
+ * hashSet 1723 1276 1823
+ * stringIndex (inst) 1883 1184 * 1700 * (* bimodal -- see caveat)
+ * tracerImmutableSet 1632 1232 1625 (Set.copyOf / SetN)
+ * array 854 - 495
+ * sortedArray 713 - 613
+ * treeSet 646 - 544
* }
*
* Key findings:
*
*
- * The static {@code EmbeddingSupport} path is the fastest — it beats {@code HashSet} on hit
- * and miss and crushes the scan/search/tree forms.
+ * The static {@code EmbeddingSupport} path is the fastest on both hit and miss -- it beats
+ * {@code HashSet} on both and crushes the scan/search/tree forms.
* {@code stringIndex} (the instance wrapper) trails {@code EmbeddingSupport} by the
- * field-load indirection (~10% on hit), landing near {@code HashSet} — fine off the hot path,
- * prefer {@code EmbeddingSupport} on it.
- * {@link java.util.Set#copyOf} ({@code SetN}, the agent's compact fixed-set form) is ~1.2x
- * behind {@code EmbeddingSupport} on hit but the most compact (~27% smaller — no
- * cached hashes, no 2x table). So StringIndex's edge over {@code SetN} is speed + the {@code
- * indexOf}->parallel-array capability, not footprint; over {@code HashSet} it wins both.
- * {@code array} / {@code sortedArray} / {@code treeSet} trail the hashed structures, most on
+ * field-load indirection. It reliably beats {@code HashSet} on {@code hit} (its actual design
+ * case: repeated lookups of a known, fixed name set). On {@code miss} and {@code hitFresh} it
+ * is not a reliable win -- both are bimodal across forks (see caveat below) and the
+ * mean in each case already sits at or below {@code HashSet}'s steady figure. For miss- or
+ * fresh-key-heavy membership use, prefer {@link StringIndex.EmbeddingSupport} directly rather
+ * than assuming the wrapper is strictly better than a plain {@code Set}. This doesn't apply
+ * to {@code StringIndex}'s parallel-value (map) use case ({@code mapValues}/{@code lookup})
+ * -- that win comes from avoiding boxing and node overhead entirely and is unaffected by any
+ * of this.
+ * {@link java.util.Set#copyOf} ({@code SetN}, the agent's compact fixed-set form) trails
+ * {@code EmbeddingSupport} on every scenario but remains the most compact (~27%
+ * smaller -- no cached hashes, no 2x table). So StringIndex's edge over {@code SetN} is speed
+ * + the {@code indexOf}->parallel-array capability, not footprint.
+ * {@code array} / {@code sortedArray} / {@code treeSet} trail every hashed structure, most on
* miss.
+ * {@code hitFresh} is the slowest of the three scenarios for every hash-based
+ * structure -- clearly below both {@code hit} and {@code miss}, not merely below {@code hit}
+ * as previously guessed. This makes sense once the two failure shapes are compared: a miss
+ * usually short-circuits on the first hash mismatch during probing and rarely reaches {@code
+ * equals()}, while a {@code hitFresh} lookup must probe until it finds the match and pay a
+ * real, uncached {@code equals()} there -- so it is not simply "the honest version of hit",
+ * it exercises a genuinely more expensive path than either {@code hit} (cached hash + {@code
+ * ==}) or {@code miss} (hash-only rejection). Superseded an earlier partial-data guess that
+ * {@code hitFresh} would land at the same cost as {@code miss}.
*
*
* Caveat — the instance {@code stringIndex} miss is bimodal across forks (confirmed at
@@ -100,6 +138,21 @@ public class ImmutableSetBenchmark {
/** Distinct String instances that are never present, for the miss path. */
static final String[] MISSES = newMisses();
+ /**
+ * Equal-content, non-interned, never-before-hashed copies of {@link #STRINGS}, built once here
+ * and never touched by {@link #setUp} -- so a lookup against them can't ride the {@code ==} fast
+ * path or a hash cached during set construction. See {@code hitFresh} in the class javadoc.
+ */
+ static final String[] FRESH_STRINGS = newFreshStrings();
+
+ static String[] newFreshStrings() {
+ String[] fresh = new String[STRINGS.length];
+ for (int i = 0; i < STRINGS.length; ++i) {
+ fresh[i] = new String(STRINGS[i]);
+ }
+ return fresh;
+ }
+
static String[] newMisses() {
String[] misses = new String[STRINGS.length * 4];
for (int i = 0; i < misses.length; ++i) {
@@ -131,6 +184,8 @@ static String[] newMisses() {
@Setup(Level.Trial)
public void setUp() {
+ BenchmarkUtils.polluteHashDispatch();
+
array = STRINGS;
sortedArray = Arrays.copyOf(STRINGS, STRINGS.length);
Arrays.sort(sortedArray);
@@ -144,6 +199,7 @@ public void setUp() {
@State(Scope.Thread)
public static class Cursor {
int hitIndex = 0;
+ int hitFreshIndex = 0;
int missIndex = 0;
String nextHit() {
@@ -155,6 +211,16 @@ String nextHit() {
return STRINGS[i];
}
+ /** See {@code hitFresh} in the class javadoc. */
+ String nextHitFresh() {
+ int i = hitFreshIndex + 1;
+ if (i >= FRESH_STRINGS.length) {
+ i = 0;
+ }
+ hitFreshIndex = i;
+ return FRESH_STRINGS[i];
+ }
+
String nextMiss() {
int i = missIndex + 1;
if (i >= MISSES.length) {
@@ -199,6 +265,11 @@ public boolean hashSet_hit(Cursor cursor) {
return hashSet.contains(cursor.nextHit());
}
+ @Benchmark
+ public boolean hashSet_hitFresh(Cursor cursor) {
+ return hashSet.contains(cursor.nextHitFresh());
+ }
+
@Benchmark
public boolean hashSet_miss(Cursor cursor) {
return hashSet.contains(cursor.nextMiss());
@@ -219,6 +290,11 @@ public boolean tracerImmutableSet_hit(Cursor cursor) {
return tracerImmutableSet.contains(cursor.nextHit());
}
+ @Benchmark
+ public boolean tracerImmutableSet_hitFresh(Cursor cursor) {
+ return tracerImmutableSet.contains(cursor.nextHitFresh());
+ }
+
@Benchmark
public boolean tracerImmutableSet_miss(Cursor cursor) {
return tracerImmutableSet.contains(cursor.nextMiss());
@@ -229,6 +305,11 @@ public boolean stringIndex_hit(Cursor cursor) {
return stringIndex.contains(cursor.nextHit());
}
+ @Benchmark
+ public boolean stringIndex_hitFresh(Cursor cursor) {
+ return stringIndex.contains(cursor.nextHitFresh());
+ }
+
@Benchmark
public boolean stringIndex_miss(Cursor cursor) {
return stringIndex.contains(cursor.nextMiss());
@@ -236,11 +317,16 @@ public boolean stringIndex_miss(Cursor cursor) {
@Benchmark
public boolean stringIndex_embedded_hit(Cursor cursor) {
- return StringIndex.EmbeddingSupport.indexOf(SI_HASHES, SI_NAMES, cursor.nextHit()) >= 0;
+ return StringIndex.EmbeddingSupport.contains(SI_HASHES, SI_NAMES, cursor.nextHit());
+ }
+
+ @Benchmark
+ public boolean stringIndex_embedded_hitFresh(Cursor cursor) {
+ return StringIndex.EmbeddingSupport.contains(SI_HASHES, SI_NAMES, cursor.nextHitFresh());
}
@Benchmark
public boolean stringIndex_embedded_miss(Cursor cursor) {
- return StringIndex.EmbeddingSupport.indexOf(SI_HASHES, SI_NAMES, cursor.nextMiss()) >= 0;
+ return StringIndex.EmbeddingSupport.contains(SI_HASHES, SI_NAMES, cursor.nextMiss());
}
}
diff --git a/internal-api/src/jmh/java/datadog/trace/util/SingleThreadedMapBenchmark.java b/internal-api/src/jmh/java/datadog/trace/util/SingleThreadedMapBenchmark.java
index cb792cc1ca9..26753867d18 100644
--- a/internal-api/src/jmh/java/datadog/trace/util/SingleThreadedMapBenchmark.java
+++ b/internal-api/src/jmh/java/datadog/trace/util/SingleThreadedMapBenchmark.java
@@ -50,6 +50,48 @@
* unsynchronized {@code hashMap} {@code get}/{@code iterate} methods are the in-harness baseline;
* the tax is the delta to the {@code synchronizedHashMap} equivalents. Comparing across JVM
* versions at stock flags shows the biased-locking effect. (Results pending a fresh multi-JVM run.)
+ *
+ *
JDK 8 results (Apple M1, {@code @Fork(2)}, {@code @Threads(8)}, with {@link
+ * BenchmarkUtils#polluteHashDispatch()} in effect; M ops/s):
+ *
+ *
{@code
+ * create_hashMap 79 create_hashMap_sized 38*
+ * create_synchronizedHashMap 8.6 create_treeMap 5*
+ * create_linkedHashMap 8* create_tagMap 10
+ * create_tagMap_via_ledger 9 create_flatHashtable 190
+ *
+ * clone_hashMap 68* clone_synchronizedHashMap 58
+ * clone_treeMap 100 clone_linkedHashMap 94
+ * clone_tagMap 249
+ *
+ * get_hashMap 164 get_synchronizedHashMap 67
+ * get_flatHashtable 196
+ *
+ * iterate_hashMap 119 iterate_synchronizedHashMap 81
+ * iterate_flatHashtable 14*
+ * }
+ *
+ * * = error bar as wide as (or wider than) the mean at {@code @Fork(2)} — treat these as
+ * directional, not decisive; a {@code @Fork(5)} rerun would tighten them (see {@code
+ * ThreadSafeMapBenchmark}'s Javadoc for the same caveat pattern). The construction benchmarks are
+ * consistently the noisy ones; the read/clone/iterate benchmarks are comparatively tight.
+ *
+ *
Key findings:
+ *
+ *
+ * {@code flatHashtable} dominates both {@code create} (190M) and {@code get} (196M) — the
+ * unboxed, self-contained entry and comparison-free insert pay off, consistent with every
+ * other FlatHashtable comparison in this module.
+ * {@code tagMap} clone (249M) is ~3.7x {@code hashMap} clone (68M) — the same story {@link
+ * datadog.trace.api.TagMapAccessBenchmark} reports from an earlier (unpolluted, Java 17) run
+ * at ~4.6x; the ratio survives pollution and a different JDK, even though the absolute
+ * numbers aren't directly comparable across those two runs.
+ * The uncontended synchronization tax is large here even though this run is on JDK 8, where
+ * biased locking is enabled by default: {@code get_hashMap} (164M) → {@code
+ * get_synchronizedHashMap} (67M) is a ~59% hit, and {@code iterate} (119M → 81M) is ~32%.
+ * That's a bigger tax than the "biased locking should make uncontended locking nearly free"
+ * story predicts — not root-caused here, left as an open question rather than papered over.
+ *
*/
@Fork(2)
@Warmup(iterations = 2)
@@ -191,6 +233,8 @@ static IntEntry[] newFilledFlat() {
@Setup(Level.Trial)
public void setUp() {
+ BenchmarkUtils.polluteHashDispatch();
+
hashMap = new HashMap<>();
fill(hashMap);
synchronizedHashMap = Collections.synchronizedMap(new HashMap<>(hashMap));
diff --git a/internal-api/src/jmh/java/datadog/trace/util/SingleThreadedSetBenchmark.java b/internal-api/src/jmh/java/datadog/trace/util/SingleThreadedSetBenchmark.java
index e145e6bbe8b..2b19e3ac48f 100644
--- a/internal-api/src/jmh/java/datadog/trace/util/SingleThreadedSetBenchmark.java
+++ b/internal-api/src/jmh/java/datadog/trace/util/SingleThreadedSetBenchmark.java
@@ -45,16 +45,36 @@
* create_treeSet 36
* }
*
+ * JDK 8 results (Apple M1, {@code @Fork(2)}, {@code @Threads(8)}, with {@link
+ * BenchmarkUtils#polluteHashDispatch()} in effect; M ops/s):
+ *
+ *
{@code
+ * contains_hashSet 1421
+ * contains_synchronizedSet 746 (~48% slower — the uncontended sync tax)
+ * iterate_hashSet 134
+ * iterate_synchronizedSet 129 (one monitor acquire amortized over the walk)
+ *
+ * create_hashSet 67 clone_hashSet 56
+ * create_hashSet_sized 83* clone_synchronizedSet 48*
+ * create_linkedHashSet 63 clone_linkedHashSet 56
+ * create_synchronizedSet 71* clone_treeSet 77
+ * create_treeSet 38
+ * }
+ *
+ * * = error bar over half the mean at {@code @Fork(2)} — directional only.
+ *
*
Key findings:
*
*
- * Uncontended synchronization tax on {@code contains} is ~37% (1291 → 808M ops/s) even
- * with no contention and biased locking disabled (Java 17, JEP 374) — the full per-lock CAS
- * cost. On {@code iterate} it nearly vanishes: a single monitor acquire amortized over the
- * traversal.
- * Construction: {@code TreeSet} is the slowest to build (~36M); the {@code synchronizedSet}
- * wrapper adds a modest cost over plain {@code HashSet}. (Allocation-path numbers carry more
- * run-to-run variance than the read paths.)
+ * Uncontended synchronization tax holds up under pollution and on a different JDK:
+ * {@code contains} is ~48% slower synchronized (1421 → 746M ops/s on JDK 8, vs. ~37% on Java
+ * 17) — same story, somewhat larger tax. {@code iterate}'s tax stays small either way (~4%
+ * here): one monitor acquire amortized over the walk.
+ * Type-profile pollution didn't change the qualitative story from the original Java 17 run —
+ * {@code contains_hashSet} and {@code iterate_hashSet} land in the same range (1291 vs 1421M,
+ * 91 vs 134M) rather than collapsing, unlike {@link ImmutableSetBenchmark}'s {@code hitFresh}
+ * case. Construction numbers remain the noisiest (several {@code @Fork(2)} error bars exceed
+ * half the mean); {@code TreeSet} stays the slowest to build across both runs.
*
*/
@Fork(2)
@@ -94,6 +114,8 @@ static void fill(Set set) {
@Setup(Level.Trial)
public void setUp() {
+ BenchmarkUtils.polluteHashDispatch();
+
hashSet = new HashSet<>(Arrays.asList(ELEMENTS));
synchronizedSet = Collections.synchronizedSet(new HashSet<>(hashSet));
treeSet = new TreeSet<>(Arrays.asList(ELEMENTS));
diff --git a/internal-api/src/jmh/java/datadog/trace/util/ThreadSafeMapBenchmark.java b/internal-api/src/jmh/java/datadog/trace/util/ThreadSafeMapBenchmark.java
index 63ccb734e9c..53a009597c5 100644
--- a/internal-api/src/jmh/java/datadog/trace/util/ThreadSafeMapBenchmark.java
+++ b/internal-api/src/jmh/java/datadog/trace/util/ThreadSafeMapBenchmark.java
@@ -8,8 +8,10 @@
import java.util.function.Supplier;
import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.Fork;
+import org.openjdk.jmh.annotations.Level;
import org.openjdk.jmh.annotations.Measurement;
import org.openjdk.jmh.annotations.Scope;
+import org.openjdk.jmh.annotations.Setup;
import org.openjdk.jmh.annotations.State;
import org.openjdk.jmh.annotations.Threads;
import org.openjdk.jmh.annotations.Warmup;
@@ -62,6 +64,29 @@
* ThreadSafeMapBenchmark.get_hashMap_synchronized thrpt 6 20123419.604 ± 4858466.787 ops/s
* ThreadSafeMapBenchmark.get_hashMap_volatile thrpt 6 286024211.995 ± 114449056.603 ops/s
*
+ *
+ *
Rerun on JDK 8 with a new {@code @Setup(Level.Trial)} calling {@link
+ * BenchmarkUtils#polluteHashDispatch()} (not present before this change — this file had no
+ * {@code @Setup} at all). Not directly comparable to the Java 21 numbers above (different JDK, and
+ * this is the first run with pollution), so treat this as its own baseline rather than a delta:
+ *
+ *
{@code
+ * create_concHashMap 47 create_concSkipListMap 17
+ * create_hashMap 130 create_hashMap_synchronized 92*
+ * create_flatHashtable 178
+ *
+ * get_concHashMap 977 get_concSkipListMap 309
+ * get_flatHashtable 1654 get_hashMap_synchronized 26
+ * get_hashMap_volatile 1257
+ * }
+ *
+ * * = error bar over half the mean at {@code @Fork(2)} — directional only.
+ *
+ *
{@code get_concSkipListMap} (309M) is ~11x the Java 21 measurement above (27M) — far more than
+ * a JDK swap plausibly explains for an O(log n), {@code compareTo}-dispatched structure that this
+ * pollution change doesn't touch. Flagging this as an open anomaly rather than a finding: don't
+ * treat it as "ConcurrentSkipListMap got faster" without a controlled re-run isolating the JDK
+ * variable.
*/
@Fork(2)
@Warmup(iterations = 2)
@@ -93,6 +118,11 @@ static T init(Supplier supplier) {
// (e.g. FlatHashtable's lock-free probe), hiding exactly the differences this benchmark compares.
int lookupIndex = 0;
+ @Setup(Level.Trial)
+ public void setUp() {
+ BenchmarkUtils.polluteHashDispatch();
+ }
+
String nextLookupKey() {
return nextLookupKey(EQUAL_KEYS);
}
diff --git a/internal-api/src/main/java/datadog/trace/util/StringIndex.java b/internal-api/src/main/java/datadog/trace/util/StringIndex.java
index 868558e0c38..66644e0fecf 100644
--- a/internal-api/src/main/java/datadog/trace/util/StringIndex.java
+++ b/internal-api/src/main/java/datadog/trace/util/StringIndex.java
@@ -74,7 +74,7 @@ public int indexOf(String name) {
}
public boolean contains(String name) {
- return indexOf(name) >= 0;
+ return EmbeddingSupport.indexOf(this.hashes, this.names, name) >= 0;
}
/** Table size — allocate parallel payload arrays of this length. */
@@ -288,8 +288,8 @@ public static long[] mapLongValues(String[] names, ToLongFunction fn) {
*/
static int put(int[] hashes, String[] names, String name, int h) {
final int mask = hashes.length - 1;
- int i = h & mask;
- for (int probes = 0; probes <= mask; probes++, i = (i + 1) & mask) {
+ for (int probes = 0; probes <= mask; probes++) {
+ int i = (h + probes) & mask;
if (hashes[i] == 0) {
hashes[i] = h;
names[i] = name;
@@ -313,8 +313,8 @@ static int put(int[] hashes, String[] names, String name, int h) {
*/
public static int indexOf(int[] hashes, String[] names, String name, int h) {
final int mask = hashes.length - 1;
- int i = h & mask;
- for (int probes = 0; probes <= mask; probes++, i = (i + 1) & mask) {
+ for (int probes = 0; probes <= mask; probes++) {
+ int i = (h + probes) & mask;
int sh = hashes[i];
if (sh == 0) {
return -1;
@@ -334,6 +334,11 @@ public static int indexOf(int[] hashes, String[] names, String name) {
return indexOf(hashes, names, name, hash(name));
}
+ /** {@code indexOf(hashes, names, name) >= 0}. Mirrors {@link StringIndex#contains}. */
+ public static boolean contains(int[] hashes, String[] names, String name) {
+ return indexOf(hashes, names, name) >= 0;
+ }
+
/** Number of slots — the length to size parallel payload arrays to. */
public static int numSlots(int[] hashes) {
return hashes.length;
diff --git a/internal-api/src/test/java/datadog/trace/util/StringIndexTest.java b/internal-api/src/test/java/datadog/trace/util/StringIndexTest.java
index 46fa68d040e..966d0d0d4ae 100644
--- a/internal-api/src/test/java/datadog/trace/util/StringIndexTest.java
+++ b/internal-api/src/test/java/datadog/trace/util/StringIndexTest.java
@@ -81,6 +81,16 @@ void support_create_then_indexOf() {
assertEquals(-1, EmbeddingSupport.indexOf(d.hashes, d.names, "q"));
}
+ @Test
+ void support_contains_internedAndCopy_andMiss() {
+ Data d = EmbeddingSupport.create("foo", "bar", "baz");
+
+ assertTrue(
+ EmbeddingSupport.contains(d.hashes, d.names, "foo")); // interned literal -> == fast path
+ assertTrue(EmbeddingSupport.contains(d.hashes, d.names, new String("bar"))); // non-interned
+ assertFalse(EmbeddingSupport.contains(d.hashes, d.names, "nope"));
+ }
+
/** Controlled hashes force collision, linear-probe wraparound, and the already-present path. */
@Test
void put_and_indexOf_collisionAndWraparound() {