This is useful for saving memory when allocating an object that has many
optional components. The optional objects are allocated sequentially in
memory, and a single integer is used to represent each optional object
and whether it is present based on each corresponding bit.
This is part of a larger effort to improve the memory layout of AST
nodes of the self-hosted parser to reduce wasted memory. Reduction of
wasted memory also translates to improved performance because of fewer
memory allocations, and fewer cache misses.
Compared to master, when running `zig fmt` on the std lib:
* cache-misses: 801,829 => 768,624
* instructions: 3,234,877,167 => 3,232,075,022
* peak memory: 81480 KB => 75964 KB
Also, check for overflow on incremented file descriptors. Previously,
we'd trigger a panic if we exceeded the `fd_t` resolution. Now, instead,
we throw an `error.Overflow` to signal that there can be no more
file descriptors available from the runtime. This way we give the user
the ability to still be able to check if their desired preopen exists
in the list or not.
* breaking changes to the API. Some of the weird decisions from before
are changed to what would be more expected.
- `get` returns `?V`, use `getEntry` for the old API.
- `put` returns `!void`, use `fetchPut` for the old API.
* HashMap now has a comptime parameter of whether to store hashes with
entries. AutoHashMap has heuristics on whether to set this parameter.
For example, for integers, it is false, since equality checking is
cheap, but for strings, it is true, since equality checking is
probably expensive.
* The implementation has a separate array for entry_index /
distance_from_start_index. Entries no longer has holes; it is an
ArrayList, and iteration is simpler and more cache coherent.
This is inspired by Python's new dictionaries.
* HashMap is separated into an "unmanaged" and a "managed" API. The
unmanaged API is where the actual implementation is; the managed API
wraps it and provides a more convenient API, storing the allocator.
* Memory usage: When there are less than or equal to 8 entries, HashMap
now incurs only a single pointer-size integer as overhead, opposed to
using an ArrayList.
* Since the entries array is separate from the indexes array, the holes
in the indexes array take up less room than the holes in the entries
array otherwise would. However the entries array also allocates
additional capacity for appending into the array.
* HashMap now maintains insertion order. Deletion performs a "swap
remove". It's now possible to modify the HashMap while iterating.
