Reduce size_of<HashMap> ?

With the switch to Hashbrow, std::mem::size_of::<std::collections::HashMap<(), ()>>() on 64-bit platforms grew from 40 bytes to 56. (24 to 40 bytes with BuildHasherDefault.)

In Servo’s DOM implementation we have types whose size_of is several hundreds of bytes. Because some not-so-unusual pages can have very many DOM nodes this size can add up to significant memory usage. We have unit tests for size_of to ensure it does not accidentally grow, which fail in today’s Rust Nightly because several types grew by 16 bytes because they contain a HashMap.

Hashbrown’s HashMap contains a RawTable which has five pointer-sized fields:

https://github.com/rust-lang/hashbrown/blob/7e79b0c33ec434857e46a8ff3d4ece413c21aaba/src/raw/mod.rs#L328-L348

Some of them seem potentially redundant, but I’m not sure. For example there are two pointers that seem to be in the same allocation. How expensive would it be to re-compute the second pointer every time it is needed?

Are bucket_mask, growth_left, and len related such that one of them could be computed from the others?

Start by reading the RawTable fields in src/raw/mod.rs around lines 328-348 and inspect how each field is used. Review the existing size_of unit tests mentioned in the issue, then determine whether any field can be removed or recomputed without changing HashMap behavior. Done means a justified design and passing size checks, or a documented reason the size cannot be reduced.