Seed FlatHashtable's hash-to-slot mapping against hash-flooding

[dougqh]

What Does This Do

Folds a per-process random seed into FlatHashtable#home (the hash-to-slot mapping shared by FlatHashtable, D1, and D2), generated once at class-init via ThreadLocalRandom (fast, non-blocking — no SecureRandom startup cost, and no cryptographic-strength guarantee is needed here).

Adds FlatHashtableTest#homeFoldsInProcessSeed, which pins down that the seed actually participates in the mix (not just that the golden-ratio mix runs) by comparing against what the old unseeded formula would have produced for the same input.

Motivation

home()'s golden-ratio mix was previously a fixed, public function of the hash alone. When a table is keyed by attacker-influenced input (e.g. String keys through the default hashCode, or CaseInsensitiveStringStrategy), an attacker who can predict or choose colliding hash values can craft a key set that all probe into the same bucket run, degrading every insert/lookup from O(1) to a long linear scan — the same class of algorithmic-complexity/CPU-flooding attack that motivated hash randomization elsewhere in the JDK ecosystem.

Seeding is done once at the single home() chokepoint rather than per-table or per-strategy: every hash — however it was produced upstream (a raw hashCode, a composite from HashingUtils/LongHashingUtils, or a cached Entry#hash) — has to pass through home() before it can influence probe placement, so this one change closes the gap for every FlatHashtable/D1/D2 instance and every hash source, with no public API change.

This was raised as a follow-up finding from the @Strategy/@StrategyConsumer annotation review (#12475) and split out into its own PR since it's an orthogonal, independently reviewable fix.

Additional Notes

Existing tests are unaffected: home() stays self-consistent within a single process/run, which is all they rely on (several precompute a hash that lands on a specific slot via home() itself, so they adapt automatically to whatever seed that run has).

Contributor Checklist

• Format the title according to the contribution guidelines
• Assign the type: and (comp: or inst:) labels in addition to any other useful labels
• Avoid using close, fix, or any linking keywords when referencing an issue
• Update the CODEOWNERS file on source file addition, migration, or deletion
• Update public documentation with any new configuration flags or behaviors
• Once approved, use merge queue to merge the PR

Jira ticket: [none]

🤖 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.84 s	14.74 s	[-0.2%; +1.5%] (no difference)
startup:insecure-bank:tracing:Agent	13.53 s	13.73 s	[-2.3%; -0.6%] (maybe better)
startup:petclinic:appsec:Agent	17.41 s	17.22 s	[+0.1%; +2.1%] (maybe worse)
startup:petclinic:iast:Agent	16.79 s	16.80 s	[-6.3%; +6.2%] (unstable)
startup:petclinic:profiling:Agent	17.33 s	17.27 s	[-0.7%; +1.4%] (no difference)
startup:petclinic:sca:Agent	17.04 s	17.42 s	[-6.5%; +2.2%] (no difference)
startup:petclinic:tracing:Agent	16.42 s	16.17 s	[-2.8%; +5.9%] (no difference)

Commit: 13b5e30d · 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.