65,536 sat just past a resize boundary. Dictionary<UInt128,long> grown from
empty steps 36,353 -> 75,431 -> 156,437 (ExpandPrime doubles and takes the
next prime), so a 65,536 cap allocated capacity 75,431 and stranded 9,895
slots at 52 bytes each -- 515 KB reserved and unreachable.
156,437 fills a capacity exactly: 2.4x the headroom for ~8 MB, no wasted
slots. Measured Entry layout is 48 bytes (4 hashCode + 4 next + 8 alignment
padding for UInt128 + 16 key + 8 value) plus a 4-byte bucket int.
The binding constraint is the sweep, not memory, since it is O(n) on the
loop. Measured full sweeps: ~2 ms at 156,437, ~6 ms at 324,449, ~26 ms at
968,897 -- so a million-entry cap costs 72 MB and a three-tick stall when a
flood's entries all lapse together. The remark records the curve because
maxEntries is operator-facing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ff7e70258e