Add Java 17 results to set benchmark Javadocs

ImmutableSetBenchmark: HashSet fastest; Set.copyOf (SetN) ~10% behind on hit,
the compact form the agent uses for fixed config sets. SingleThreadedSetBenchmark:
uncontended synchronizedSet tax ~37% on contains (biased locking off, Java 17),
near-zero on iterate.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: dougqh

internal-api/src/jmh/java/datadog/trace/util/ImmutableSetBenchmark.java

@@ -37,8 +37,29 @@
  * </ul>
  *
  * <p>Lookups are interned (the {@code ==} fast path where a structure has one); misses are short
- * and never present. (Results pending a fresh multi-JVM run — {@code Set.copyOf} only materializes
- * the compact form on Java 10+.)
+ * and never present.
+ *
+ * <p>Java 17 results (Apple M1, {@code @Fork(2)}, {@code @Threads(8)}; M ops/s = millions):
+ *
+ * <pre>{@code
+ * Structure              hit     miss
+ * hashSet               2159     1751    (fastest)
+ * copyOf (SetN)         1946     1633
+ * array                  926      584
+ * sortedArray            664      588
+ * treeSet                642      593
+ * }</pre>
+ *
+ * <p>Key findings:
+ *
+ * <ul>
+ *   <li>{@code HashSet} is fastest; {@link java.util.Set#copyOf} ({@code SetN}) trails by only ~10%
+ *       on hit and ~7% on miss — and it's the compact, array-backed form the agent already uses for
+ *       fixed config sets, so it's a strong default when the set is immutable.
+ *   <li>{@code array} / {@code sortedArray} / {@code treeSet} cluster at ~0.6–0.9B — they scan,
+ *       binary-search, or tree-walk per lookup, so they trail the hashed structures, most visibly
+ *       on the miss path.
+ * </ul>
  */
 @Fork(2)
 @Warmup(iterations = 2)

internal-api/src/jmh/java/datadog/trace/util/SingleThreadedSetBenchmark.java

@@ -29,7 +29,33 @@
  * monitor is only ever locked by one thread: biased locking ≈ free on Java ≤ 11, full uncontended
  * CAS on Java 15+ (biased locking disabled by default, JEP 374). The unsynchronized {@code hashSet}
  * {@code contains}/{@code iterate} methods are the in-harness baseline; the tax is the delta.
- * (Results pending a fresh multi-JVM run.)
+ *
+ * <p>Java 17 results (Apple M1, {@code @Fork(2)}, {@code @Threads(8)}; M ops/s = millions):
+ *
+ * <pre>{@code
+ * contains_hashSet            1291
+ * contains_synchronizedSet     808    (~37% slower — the uncontended sync tax)
+ * iterate_hashSet              91
+ * iterate_synchronizedSet      90    (one monitor acquire amortized over the walk)
+ *
+ * create_hashSet         81    clone_hashSet          48
+ * create_hashSet_sized   78    clone_synchronizedSet  47
+ * create_linkedHashSet   61    clone_linkedHashSet    59
+ * create_synchronizedSet 41    clone_treeSet          83
+ * create_treeSet         36
+ * }</pre>
+ *
+ * <p>Key findings:
+ *
+ * <ul>
+ *   <li><b>Uncontended synchronization tax</b> 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.
+ *   <li>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.)
+ * </ul>
  */
 @Fork(2)
 @Warmup(iterations = 2)