Measure the memory usage of HashMap better

[jdm]

Currently we estimate it at capacity() * (size_of::<K>() + size_of::<V>()). I briefly looked into duplicating the internals in mem.rs, but it was looked really complicated.

[SimonSapin]

Should we file an issue on Rust to add some API?

[Gankra]

As of today (and for the last ~year) it's basically (cap() * 11 / 10) * (size(K) + size(V) + size(u64)), but there's some minor loss due to alignment and integer arith.

Basically a HashMap is [hash, hash, hash, ..., key, key, key, ... value, value, value...] allocated as a single buffer via jemalloc.

But the reported capacity is real_cap * 10 / 11 because we don't let the table get totally full (~91% max load factor). The internal capacity is always a power of two, so some careful math can let you figure out the "true" inner capacity from the reported capacity if you really care (round to the nearest power of two should be sufficient).

In practice I wouldn't expect any meaningful wasteage from alignment/padding. At most it would basically be the wasteage in a (u64, K, V) tuple, I think.

[Gankra]

As an aside, @pczarn had a PR to change this to [hash, hash, hash,... (K,V), (K,V), (K,V), ...] which shuffled around some perf characteristics, but we didn't go forward with it.

[pczarn]

Exactly as above, and (capacity() * 11 / 10).next_power_of_two() * (...) will correct off-by-one loss.

[nnethercote]

This issue is now blocking https://bugzilla.mozilla.org/show_bug.cgi?id=1387958. Stylo has some significant HashMaps which I want to measure the size of. I can estimate the size, but (a) it might be inaccurate (i.e. it won't measure slop), and (b) DMD doesn't get told that the block has been reported.

It would be nice if HashMap had a function exposing the pointer to the storage. (That's assuming there is a single pointer; it's conceivable that the internal representation could use 2 or 3 separate chunks of storage.)

What I'll probably end up doing is cloning HashMap for Stylo. Stylo already has its own copy of Arc, and we've been considering cloning Vec and HashMap anyway to add fallible growth methods.

[nnethercote]

Cloning (forking) HashMap turns out to be difficult, because it uses various unstable Rust features and we are using stable Rust only for Firefox.

[SimonSapin]

We could consider an alternative hash map like https://crates.io/crates/ordermap. Adding memory tracking might be easier there.

[dralley]

Still applicable after HashBrown-based HashMaps?

[nnethercote]

The change to HashBrown doesn't affect this.