Extend type-profile pollution to the remaining map/set benchmarks (perf toolbox - benchmark)

[dougqh]

What Does This Do

Stacked on #12294. Wires BenchmarkUtils.polluteHashDispatch() into the rest of this module's HashMap/HashSet/ConcurrentHashMap-comparing JMH benchmarks — until now only ImmutableSetBenchmark/ImmutableMapBenchmark had type-profile pollution applied, so every other file's isolated single-key-type usage left those JDK collections' shared internal hashCode()/equals() dispatch call sites artificially monomorphic, understating their real per-call cost.

• BenchmarkUtils: polluteHashDispatch() now also warms a scratch ConcurrentHashMap (a separate class from HashMap/HashSet, with its own dispatch call sites — pollinating HashSet alone doesn't reach it). Added populateTypeProfileMap/populateTypeProfileMutableMap as the Map counterparts to the existing Collection-based helpers, for callers that need finer control.
• Wired into: SingleThreadedMapBenchmark, SingleThreadedSetBenchmark, ThreadSafeMapBenchmark, HashtableD1Benchmark, HashtableD2Benchmark, CaseInsensitiveMapBenchmark, TagMapAccessBenchmark. FlatHashtableIteratorBenchmark is intentionally untouched — it only exercises the project's own FlatHashtable/HashStrategy, never java.util.HashMap/HashSet/ConcurrentHashMap.
• Reran the full suite for all 7 files (JDK 8, Apple M1) and folded pollution-corrected numbers + updated key-findings into each file's Javadoc, following the pattern already used in ImmutableSetBenchmark/ImmutableMapBenchmark.

Motivation

#12294 showed that leaving JDK collections' shared hashCode()/equals() call sites monomorphic (single key type per benchmark) understates their real production cost by ~20%, since in a real system those call sites are shared and megamorphic. That pollution fix only reached ImmutableSetBenchmark/ImmutableMapBenchmark; this PR extends the same treatment to the module's other map/set benchmarks so their numbers are consistent and realistic too.

Additional Notes

Honest caveat on this rerun: this session's rerun landed on a noticeably slower baseline across several files — including numbers for the project's own Hashtable.D1/D2 and FlatHashtable, which don't touch java.util.HashMap/HashSet dispatch at all and so shouldn't be affected by this pollution change. That points to session-to-session machine variance (the run spanned ~2 hours; power source changed partway through) rather than a genuine pollution effect for those files. Each affected file's Javadoc calls this out explicitly rather than presenting the new numbers as clean deltas. The relative conclusions in every file (which structure wins which operation) are unchanged either way; only ImmutableSetBenchmark/ImmutableMapBenchmark (from #12294) had pollution produce a real qualitative shift.

ThreadSafeMapBenchmark.get_concSkipListMap moved ~11x from its prior Java 21 measurement — flagged as an open anomaly in its Javadoc, not asserted as a real finding.

Test plan

• ./gradlew :internal-api:compileJmhJava — compiles clean
• ./gradlew :internal-api:spotlessApply — formatting clean
• Full JMH suite run for all 7 affected files (JDK 8, Apple M1, @Fork(2)/@Threads(8) per file's existing config) — results folded into each file's Javadoc

🤖 Generated with Claude Code

[dd-octo-sts]

🟡 Java Benchmark SLOs — Performance SLO warning (near threshold)

Suite	Status
Startup	🟡 warning

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.96 s	14.04 s	[-1.3%; +0.1%] (no difference)
startup:insecure-bank:tracing:Agent	13.03 s	13.04 s	[-0.7%; +0.6%] (no difference)
startup:petclinic:appsec:Agent	17.04 s	16.25 s	[+0.6%; +9.1%] (maybe worse)
startup:petclinic:iast:Agent	16.94 s	16.91 s	[-0.7%; +1.2%] (no difference)
startup:petclinic:profiling:Agent	16.67 s	16.56 s	[-0.4%; +1.7%] (no difference)
startup:petclinic:sca:Agent	16.94 s	16.80 s	[+0.1%; +1.7%] (maybe worse)
startup:petclinic:tracing:Agent	15.67 s	16.07 s	[-6.6%; +1.7%] (no difference)

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

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7f6889d388

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[datadog-datadog-prod-us1-2]

The new ConcurrentHashMap setup reuses each inserted key for get(). The identity check then bypasses equals() and leaves the measured lookup call site monomorphic.

_{Open Bits AI session}

_{🤖 Bits Code Review · Commit 7f6889d · @DataDog review to ask questions}

[datadog-datadog-prod-us1-2]

The setup gives hash structures a megamorphic profile but leaves sorted structures and MapN monomorphic. The Java 8 tables also label fallback HashMap and HashSet results as MapN and SetN.

_{Open Bits AI session}

_{🤖 Bits Code Review · Commit 56a31d9 · @DataDog review to ask questions}

[bric3]

Does this achieve its stated purpose?

• I wonder, are we able to verify that the compiled lookups remain megamorphic after warmup?

• If the scope is only setup coverage, what evidence supports presenting these results as representative of production workloads?

[bric3]

issue: Calling each decoy once doesn't keep the lookup profile megamorphic through warmup.

On acd9bd09, ImmutableSetBenchmark.hashSet_hitFresh with -XX:+PrintInlining still inlined String.hashCode() and String.equals() on Corretto 17: over 99.8% of receiver samples were String. Corretto 8 also specialized them. I'd check the final compiled lookup before calling these results “pollution-corrected”.

[bric3]

Currently I don't know how that can be automated, but we could look at the JIT inlining decisions, I think this -Pjmh.jvmArgsAppend=-XX:+UnlockDiagnosticVMOptions -XX:+PrintCompilation -XX:+PrintInlining

[dougqh]

Yes, you are right that String::hashCode is still getting inlined into HashMap. I was expecting that, but I was not clear about it.
What I’m trying to do is exercise HashMap, etc in a way that is realistic for a customer system.

In a customer system, I expect there to be maps that use a variety of key types, so I’m trying to simulate that.
My aim is to avoid the speculative optimizations which are based on runtime state that are unlikely to occur in a real system,
but there are places where devirtualization and inlining can occur without relying on speculation & profiling.

For invocations, those speculative optimizations are based on the loaded class hierarchy analysis and the call site’s TypeProfile.
Here, I’m specifically aiming to pre-populate / pollute the TypeProfile.

In spite of this, in many cases, C2 will still be able to devirtualize and inline calls based off of static type reasoning.
This usually occurs when the call is on a parameter coming into a method rather than a reference stored inside the Map.

In the provided example, I believe that is what is happening. The collections are typically written to call equals & hashCode on the incoming parameter,
so C2 can take advantage of type-based reasoning.

ImmutableSetBenchmark::hashSet_hitFresh          inline (hot)
  Cursor::nextHitFresh                           inline (hot)
    HashSet::contains                            inline (hot)
      HashMap::containsKey                       inline (hot)
        HashMap::getNode                         inline (hot)
          HashMap::hash → String::hashCode → StringLatin1::hashCode   inline (hot)
          String::equals ×2                      inline (hot)

Unfortunately, PrintInlining doesn’t clearly indicate how the decision was made. To make sure, I’ll switch to checking LogCompilation which is more detailed.
It is an XML-ish format, so not as nice to read, but it does provide the detail that we want.

[dougqh]

As promised, I had Claude dig deeper into LogCompilation. LogCompilation does show that the “pollution” mechanism is largely having the desired effect.
Admittedly, this approach is really just a “best effort” at making our benchmarks more realistic. I think it is safe to say that some type profile pollution is more realistic than no type profile pollution.
So in that regard, I think this is working as intended, but I won’t be surprised if further adjustments are needed.

Claude’s analysis…

LogCompilation shows the real invocation histogram, not just a compiled decision — it's on the <call> element itself (receiver/receiver_count, receiver2/receiver2_count), frozen at whatever moment the interpreter/C1 handed the profile to C2. <predicted_call> is just the consequence: C2's guard, generated from that snapshot.

Digging into HashMap.getNode's own early compile, the same method body has two structurally identical equals call sites fed by different code paths, and pollution landed on them completely differently:

• One call site: 2780 Integer calls vs. 2778 String calls — genuinely ~50/50. C2 looked at that and declined to speculate at all — inline_fail reason='virtual call', real vtable dispatch, no guard.
• The other: 3024 Long calls vs. 1 String call. C2 still emits a bimorphic-shaped guard pair (because its policy covers the top-2 recorded types whenever more than one shows up at all), but the underlying traffic was never actually balanced there.

So even within one method, in one compile, pollution's effectiveness at a given call site depends on which code path happened to route which key types through it during the warmup burst — it's not uniform, and it's not something that "decays" from a shared profile so much as something that was never evenly distributed to begin with.

[dougqh]

Re-ran everything with -prof gc on Zulu 17, plus a LogCompilation pass. Conclusions moved, and the first two are mine to retract.

Retracted. HashtableD2 claimed a ~1.8x hashtable win on add and ~11.6x on update. Both were artifacts of Objects.hash in the Key2 constructor — it's varargs, so it allocated an Object[] per key construction and the HashMap baseline was carrying 24 B/op that nothing in the design required. Switched to HashingUtils.hash, which exists in this repo precisely to avoid that. update_hashMap roughly doubled (196.7 → 463.0), so update is ~5.4x and add is a tie (1018.9 vs 1009.6). The contention ratios in both ThreadSafeMap files were also computed off stale tables — they're ~280-290x, not ~150x.

Your PrintInlining run is what started all of this, and it turned out to be showing something more interesting than pollution failing. Chasing it led to measuring Key2, and the result splits cleanly by call shape:

arm	shape	alloc
HashtableD2.update_hashMap	merge(new Key2(...), ...)	48 B/op
ThreadSafeMapD2.get_* / getOrCreate_*	get, then guarded computeIfAbsent	0 B/op

LogCompilation shows eliminate_allocation for Key2 in the second case. The never-taken computeIfAbsent branch is pruned as an unstable_if uncommon trap, which removes the only store of the key and leaves it provably non-escaping, so EA scalar-replaces it. With merge the present/absent decision lives inside the callee, so there's no caller-visible branch to prune and the wrapper survives.

But that elimination is manufactured by the benchmark. It only works because @Setup installs every key before warmup, so the absent branch is never recorded. A real cache records its population-phase misses in the same profile — MDO counters accumulate from interpretation onward and are never reset — so the profile is two-sided, nothing is pruned, and the key is allocated per lookup. Those ConcurrentHashMap numbers are an upper bound; it's stated in the javadoc.

The general lesson is about forking. JMH runs each benchmark method in a fresh JVM — 29 methods, 29 VM invoker lines in our log. Right for measurement, but it means every arm is compiled in a process that has only ever seen that one code path, that one arm's key types, and that one arm's branch outcomes. Production is the reverse. So JMH forks to eliminate cross-benchmark profile pollution, while profile pollution is the production condition. Receiver profiles collapse, CHA gets a thin hierarchy, and branch profiles go one-sided — and BenchmarkUtils only addresses the first two.

Filed as APMLP-1870: a warmUpArms(Blackhole, Arm...) that drives every arm in shuffled order during setup, with reflective discovery so coverage can't silently drift.

Your call on sequencing: I can pull that into this PR, which means better numbers but a bigger diff and another re-measure, or land it as a follow-on with its first adopter and a before/after. Genuinely happy either way — you're the one reading it.

[dougqh]

My general approach here is to recreate the common case which also happens to be the worst case -- megamorphic call site.
Admittedly, I don't think the current pollution process is sufficient. I need to exercise the call sites more during pollution to make this more predictable.

From what you found, it sounds like some of the benchmark surpassed the TypeProfileMajorReceiver limit. In a real system, I don't think that's not likely to happen, so I want to adjust the benchmark accordingly.

As for whether, we can verify that a callsite stays megamorphic. Generally speaking for most optimizations, C2 starts in an optimistic state and then reaches a pessimistic state and then stops.
So once we get into a pessimistic (e.g. megamorphic) state, we're generally safe in assuming it will stay there.
And given that my aim is to exercise the worst case behavior, I think that's want we want in our benchmarks.

I was concerned that the pollution process was insufficient, but let it be after spot checking with PrintInlining.
Clearly, I need to update it. While that's a bit annoying, I also think it helps demonstrate why having a utility that encapsulates the process is important.
Once we get it right, we'll remove a subtle source of benchmarking errors going forward.

Once I've updated the pollution process, I'll re-run the benchmarks and make sure the conclusions still hold.